Vlákno názorů k článku Stavíme kvadrokoptéru #2: Arduino a řízení otáček motoru od Yenya - Já jsem se nad tím do detailů nezamýšlel,...
-
Yenya (neregistrovaný)
Já jsem se nad tím do detailů nezamýšlel, takže mě opravte, jestli následující je úplná blbost, nicméně:
Není to příliš složité? Nebylo by lepší aby ty motory přímo řídilo arduino? Atmel má spoustu dokumentů popisující řízení bezkomutátorových motorů, ať už s Hallovou sondou nebo se zpětnou vazbou ze zrovna neaktivního vinutí. Tady je příklad pro ATTiny861a a třífázový bezsenzorový motor: http://www.atmel.com/Images/doc8192.pdf
Ostatně i Pi má docela dost volných GPIO pinů, nešlo by jen dodělat výkonovou část a zbytek nechat na Pi? Akorát nevím jestli umí hardwarové PWM, případně jestli je dostatečně výkonné na to, aby se PWM
dalo udělat softwarově v nějakem real-time procesu.V těch regulátorech beztak bude nějaký podobný mikrokontroler jako v Arduinu,, tak mi přijde zbytečné zapojovat ještě mezi to další procesor - to Arduino.
BTW, mám za to, že pojem "střídavý motor" není možná v tomto kontextu správný. Ta věc co má cívky spínané nějakou externí elektronikou se myslím anglicky jmenuje BLDC motor (brush-less direct current), česky jsem slyšel pojem "bezkomutátorový".
-Yenya
-
Petr (neregistrovaný)
Pi nemuzes na rizeni cehokoliv "time critical" pouzit, protoze si nikdy nemuzes byt jisty, jestli ma na to zrovna cas. Toto je vyhoda mikrokontroleru, u toho totiz vzdy vis, co v dany okamzik dela. Proto je tady Pi, ktere zajistuje komunikaci s okolnim svetem a zaroven preposila prikazy do Arduina, ktere se stara o rizeni motoru.
-
Yenya (neregistrovaný)
Ja myslim ze s RTlinuxem (nebo jinou real-time extenzi) by to jit melo. Na takovemto HW by melo byt mozno dosahnout garantovanych latenci nekolika malo mikrosekund. Pokud teda neni ten HW nejak zmrseny (jako SMM na procesorech intel).
Kazdopadne i kdyby to nebylo realizovatelne jen pres Pi + vykonovou cast, melo by fungovat aspon Pi + regulatory (400 Hz s rozumnymi latencemi ta Pi musi dat i kdyby nechtela). Nebo Pi + arduino + vykonova cast (bez regulatoru).
Proste mi prijde, ze je tam jedna, mozna i dve vrstvy rizeni navic.
-
Pilot (neregistrovaný)
Nezapomente, ze je treba zpracovat v realnem case i signaly z nemalo senzoru (3D gyra, 3D acc, kompas, ev. alti baro nebo gps), pocitat pomerne slozite nekolik PI/PID regulaci a vystup pro X motoru aplikovat na regulatory. Stejne musite resit vykonovou cast regulatoru. Tak proc tam nedat hotovy levny spolehlivy a odladeny HW regl za par korun a zbytecne si tim komplikovat situaci v jednom CPU, ktery ridi cely let a pripadne navigaci atd.
-
Yenya (neregistrovaný)
To je právě to hezké, že ta regulace už může být proces s nižší prioritou než obsluha PWM a čtení senzorů.
No ale hlavně, v arduinu bude ten stejný problém, akorát na o víc než jeden řád pomalejším CPU.
Proč tam nedat HW regulátor? Proč to vlastně celé nekoupíme hotové? :-)
Ale jinak jo, pokud existují ty HW regulátory a jsou vyzkoušené, levné, funkční, a dokonce programovatelné/flashovatelné, pak bych byl pro konfiguraci
Pi plus HW regulátory motorů napojené na GPIO. Zvlášť pokud se tady píše, že když ten regulátor zrovna nedostane pluz včas, tak funguje i nadále a zastaví se až po několika sekundách.To arduino tam ale furt vidím jako zbytečnou komplikaci.
-Y.
-
Dark (neregistrovaný)
S Raspberry pi momentálně stavím jako bakalářku robota. Se sanou malinou jde řídit max 2 serva (má jen 2x HW PWM piny) pak další 2 jdou nahradit softwarově, ale pouze dva, jelikož víc už jich nezvládá výkonově. Ale našel jsem i knihovnu ve, které to autor řeší přes DMA (Direct Memory Access) a tím se prakticky vyřadí procesor pro řízení serv ze hry a četl jsem, jak malina pak zvládala ovládat 8 i víc serv. Další procesor mezi je tedy podle mě zbytečnost navíc a jsou s tím jen problémy (vlastní zkušenost sám to tak používám kvůli sensorům, které malina nezvládá). Viz forum http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=22923
-
"ale pouze dva, jelikož víc už jich nezvládá výkonově"
Nevěř vlastním očím a cizím písmenkům a zkus i sám myslet. Když si vezmeš inspiraci z http://mcu.cz/plugins/smf/smf.php?topic=3090.0 , http://hackaday.com/2013/02/10/better-pwm-on-the-raspberry-pi/ a dalších projektů, tak můžeš do R-Pi nacpat poměrně dost PWM kanálů. Všechny PWM nemusí běžet synchronně, můžeš poslat puls prvnímu servu, pak druhému... na jednom časovači může být tedy cca 20ms/2ms = 10 PWM kanálů. -
Dark (neregistrovaný)
Možná jsem to blbě napsal, ale myslel jsem obdobu ServoBlastru. V tom odkazu na forum je knihovna, která je ServoBlastrem inspirovaná a líp se používá. Jelikož řídí serva sama a ne přes extra aplikaci řízenou zápisem do souboru. Tím, že zvládá ovládat jen 2 serva bylo myšleno řízení "běžným způsobem" bez využití DMA.
-
nosense.cz (neregistrovaný)
Použitím raspberry jako hlavní článek regulace vidím (mimo jiné) v tom, co se stane pokud dojde k zamrznutí systému a motory zůstanou běžet naplno. Zkuste si odhadnout spolehlivost následujících komponent:
20kB SRAM vs 256 MB DRAM
128kB flash paměť vs 8 GB SD karta
software regulátoru (cca tísíce řádků kódu) vs celý Linux a samotná aplikaceJá bych v tomto případě věřil tomu jednoduššímu systému. Už třeba proto, že v případě poruchy lze restartovat během milisekund. Jak dlouho nabíhá systém v malině?
-
Přesně tak. Pokud by z toho všechno lezlo jako analogová napětí, tak není problém vzít hrst operačních zesilovačů a pohrát si s tím (plus komparátor s generátorem pily pro tvorbu PWM na konci). Jenže tady to takhle nefunguje.
A jak už bylo psáno, tak latence - regulátor se chvíli obejde bez signálu a použije hodnotu co do něj přišla před chvílí. Ale pokud dám k RaspberryPi dva H-můstky pro spínání motorů a něco se zdrží, tak se stane co? Ano - signál se o kus posune a bude působit proti otáčení motoru.
-
"Pi nemuzes na rizeni cehokoliv "time critical" pouzit"
To je spíš taková pověra. Minulý týden jsem zkoušel měřit zpoždění obsluhy přerušení v linuxu a pohybovalo se u 720MHz procesoru mezi 10 a 11 us. Nezkoumal jsem zatím využití timerů v R-Pi, ale určitě by tam nějaký volný vhodný byl. Rapsberry by spíš chyběly volné piny a AD převodník. -
klusacek (neregistrovaný)
Prave ze nejde o to `kde se to pohybovalo' ani kolik byl prumer, ale kolik to muze nejvice byt. Tohle je hard-real-time uloha a ne nejake prehravani videa, kde si jednoho vypadleho obrazku skoro nevsimnete. Zde musi byt zaruka ze prodleva bude vzdy mensi nez napr. 50us. To vam bezne linuxove jadro nezaruci, takze byste potreboval RT-linux.
Jinak se zbytkem souhlasim.
-
klusacek (neregistrovaný)
Tech 50 us byl jen priklad --- chtel jsem tim rict, ze ani tak nezalezi na presne dobe latence jako spis na tom aby mela deadline ktery to nikdy nepresahne.
Mozna kdyby sis dal hodne prace a zkontroloval ze vsechna ostatni IRQ maji nizsi prioritu nez to, na kterem mas ten motor tak pak by to mozna takto i slo.
Ale nevim v cem je pak vyhoda pouzivat linux kdyz musim psat v kernel-spacu. To uz tam rovnou muzu dat nejaky real-time OS a vse bude pohodlnejsi. Nebo tuhle cast exportovat do dedikovaneho hardwaru, jako je to psano v serialu.
-
Abych to uvedl na pravou míru: Nechtěl jsem tvrdit, že je vhodné použít RPi na stavbu čehokoliv pohybujícího. Pokud někdo používá RPi jako palubní počítač letadla, auta, vrtulníku, robota, ..., tak by to mělo být jen důkaz, že to jde, ne na podporu tvrzení, že se k tomu RPi hodí.
Využití v modelářství může najít jako levný záznamník dat, se kterým se snadno pracuje. -
Atlasz (neregistrovaný)
Bezne levne serva nekdy zaregistruji i ochylku 5-10us. Pokud nechces zbytecne riskovat `bebo i zbytecne zatezovat serva, tak potrebujes sirku impulsu generovat s presnosti 1-2us. Preji hodne stesti k SW generovani takovych impulsu na RPi.. Ja bych to delal podobne, jak autor. Ardunino se da koupit jednoduse, je to funckni blok, co lehce pouzije i zacatecnik a pritom dostatecne spolehlivy.
-
Nevím jak serva, ale běžné levné ESC řídí výkon na řádově desítkách kroků, např. mnou vyzkoušený Turnigy Multistar má těch kroků 32. Pokud bych bral pracovní rozsah 1100-1900 us, dělá to 25us/krok. Takže z toho bych obavu neměl.
Ale souhlasím s tím, že použít mikrokontrolér na základní funkce (generování PWM pro serva/ESC) je takový "unixový" princip, z mého pohledu naprosto správný. Když chci naprogramovat nějaký skript v linuxu používající "cat" nebo "grep", taky si nenapíšu vlastní, ale použiju ty binárky dodávané v distribuci. Stejně tak řízení quadu. Základní věci ať mi dělají hotové komponenty, o kterých vím jak se chovají, že se chovají dobře a mají predikovatelné výstupy. Základní věcí je v tomto případě např. řízení motoru samotného (na to máme ESC) nebo generování PWM nebo dekódování PPM z RC řízení (na to se použije třeba to arduino). -
honzin (neregistrovaný)
Záleží na tom jaké máš požadavky na odezvu. Já osobně používám BeagleBone a zkoušel jsem na něm RT patch Linuxu. Beaglebone zpracovával data z IMU a ovládal motory (PWM).
Tady je výsledek.http://www.honzinovo.cz/projects/heli/os/realtime-os/
Odezva je do 1 ms.
PS: Stránky jsou značně nekompletní a napsány annglicky.
-
Jarda (neregistrovaný)
Všeobecně nad odborností elektrikářského textu oko celoživotního technika trochu zaslzí ;-). Článek je ale psán formou přitažlivou pro širokou obec čtenářů a navíc skutečná síla a složitost řešení spočívá v řídicím hardware a software, ne v drátech. Myslím, že by hodně lidí inspirovat k vlastním pokusům a to je dobře. Jen je potřeba opravdu nepodcenit možné následky nezvládnutého řízení nebo havárií - není to balsové házedlo a může zabít.
Jo - ten motor samozřejmě není klasický střídavý jako býval třeba u mlátičky, ale skutečně jde BLDC, tj. bezkomutátorový (někde se uvádí "s elektronickou komutací"). Se střídavým motorem má společné to, že se do jednotlivých vinutí postupně zapíná (a vypíná) proud, což provádí regulátor; tudíž jde vlastně o synchronní stroj.
-
INT (neregistrovaný)
Tak jsem popsal řešení bez Arduina :) Jde to.
http://www.djanku.cz/cs/clanek/raspberry-pi-regulace-multistar-turnigy
ČLÁNKY DO MAILU