Použití OnStep pro řízení platformy

[roman-dvorak]

Existuje opensource projekt OnStep který je určení pro řízení paralaktických a azimutálních montáží.

V případě montáží a takových to zařízení mi přijde lepší mít vlastní kontrolér přímo u montáže, který bude dále komunikovat po jiném rozhraní (ideálně ethernet, sériovku nebo CAN). Dost to odpovídá mé představě. V tomto zařízení jsem chtěl také použít nějaký STM32 arm. Ano. Má to vlastní FW.. ale lze nějakým způsobem zajistit, aby si ho to aktualizovalo samo.

OnStep nyní podporuje řadu procesorů od nějakých arduin přes STM32F103, ESP32 po Teeansy 3.6.

Výhodu vlastního kontroléru vidím v tom, že může ovládat přímo (mikro)kroky motorů. Což vede i k lepší optimalizaci trajektorie dalekohledu po obloze.

Jako nevýhodu vidím v tom, že celá ta věc je napsaná v arduinu. Což nadruhou stanu má výhodu v obrovské aktivitě lidí. Má to přes 3000 commitů a 71 forků. Když jsem kdysi začal uvažovat o vlastním open-source kontroléru, tak tento projekt byl úplně v počátcích vývoje a nic to tehdy neumělo. Resp. dostat se na stejnou úroveň by nebylo složité. Dnes to umí mnoho věcí. Například ten ethernet to má už implementovaný, LX200 protokol a další. Takže už existuje kompatibilita s INDI.

Já jsem tam chtěl použít nějaký RTOS (Chibios, Nuttx) možná micropython. Tohle bohužel nic takového nenabízí. Ale už to existuje. Například pro platformu si myslím, že je to pouze o nakonfigurování. Ostatní věci. Jako orientace auta/platformy, ... může být prozatím řešena nějakým externím pythonem.

[roman-dvorak]

Co si o tom @kaklik myslíš?

[roman-dvorak]

Dalším OpenSource řešením je OpenDrive <https://github.com/selste/openDrive/wiki/Hardwaredesign> Tam jako největší nevýhodu vidím v tom, že to podporuje pouze řešení s jednou Olimex deskou s nějakým ARMem od NXP. Ale zase architektura celého systému mi připadá lepší. A dost dokumentace je napsáno německy. pá 10. 4. 2020 v 23:41 odesílatel Roman Dvořák <[email protected]> napsal:

…

Co si o tom @kaklik <https://github.com/kaklik> myslíš? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHUXOIWQ23N3LQWUYO66BTRL6HALANCNFSM4MFW7T2A> .

[roman-dvorak]

Jako nejrychlejší varianta k otestování tohoto systému mi příjde použít RAMPS desku a Arduino. Nevýhody tohoto řešení jsou nestabilita oscilátoru (což nám zatím nevadí) a pomalejší slew přejezdy. Vzhledem k tomu, že to budeme mít directdrive, tak nás to vůbec neomezuje. https://onstep.groups.io/g/main/wiki/2D-RAMPS14

[kaklik]

Myslím že nejlepší je použít teď ten RAMPS.. Myslím že nějaký snad ještě i máme. @ChroustJan ?

[roman-dvorak]

@kaklik ty bys to mohl vědět, proč se ty drivery motorů takhle často dávají na externí moduly? Je to třeba kvůli tomu, že snadno odchází? Aby byla ta základní deska levnější? Nebo to má jiný důvod?

[kaklik]

Dřív snadno odcházely, protože drivery pro krokové motory byly staré založené na bipolárních tranzistorech, v důsledku toho se přehřívaly. To už teď s jejich masovým rozšířením do tiskáren neplatí a tiskárny jsou v podstatě to, co táhne vývoj driverů krokových motorů.
Další aspekt byl fakt, že vývoj driverů krokových motorů byl překotný, takže byla idea mít možnost na základní desku osadit více typů driverů. Takhle to nějakou dobu i fungovalo. Ale teď už to taky není výhodné, protože se kromě typů driverů často trochu mění i způsob kterým se s ním zachází a už to nebývá jen jednoduché pulzní rozhraní STEP/DIR, ale jdou tam i další řídící a diagnostické signály přes SPI/I2C, nebo UART. Navíc cena těchto lepších driverů je už často i srovnatelná se zbytkem desky.
Takže tohle konstrukční řešení už přestává dávat smysl. Navíc celkem znatelně snižuje spolehlivost.

[roman-dvorak]

Díky.. tak to nějak popisuje mé představy o tom.