Raspberry Pi drone?

Alaplapok

Hobbibol szeretnek drone-t epiteni. Talan az egyszerueseg miatt eloszor hajot, aztan repulot. Vagy lehet, hogy rogton repulot. Nem is tudom. Azon gondolkozom, hogy Raspberry Pi-t vegyek-e ehhez, vagy valami mas kifejezetten drone lapot? Azt latom, hogy van servo vezerlo meg szenzorok is a R Pi-hez, sot, lattam komplett drone-oka is a neten, de nem feleslegesen nagy/eros erre ez a lap? Mondjuk a HD video kimenetre aligha lesz szuksegem. :) Lehet, hogy drone specifikus lapot kene keresnem? Ahogy irtam hobbi az egesz, szoval nem kell halalra kioptimalizalni, az R Pi-t pedig eleg flexibilisen tudnam hasznalni kesobb masra is. Viszont aggodom a meret/fogyasztas miatt. (A meret ugye nem csak a lap meretet jelenti, de a lap, plusz a ra dugott osszes szenzor, stb-t is.)

  • 9664 megtekintés

( sza2king v | 2014. 08. 29., p – 16:55 )

En valoszinuleg nem biznam egy RPi-ra repulo _teljes_ iranyitasat. Egy hajoval kulonosebb balesetnek kicsi az eselye, de ha egy repulo valik iranyithatatlanna, az meg kis meret eseten is tud balesetveszelyes lenni. Ahhoz, hogy egy repuloalkalmatossag stabil maradjon a levegoben, szerintem celszerubb valami real-time rendszert hasznalni.

De lehet, hogy tulparazom.

/sza2

Ahogy mondtam R Pivel is lehet valosideju elvileg, illetve talalni is mukodo megoldasokat a neten (marmint R Pi-re epulo drone-okat).

De mindegy is, egyre inkabb arra hajlok, hogy specifikus eszkozt kell venni, sot lehet, hogy eleve valamit keszen fogok venni. Igy a DIY dicsoseg elmarad, de biztosabb a kimenetel.

A kesz megoldas mellett tobb dolog is szol. Az egyik es talan legfontosabb, hogy biztosan mukodni fog, nem 3 osszetort gepen kell megtanulni, hogy mi a fontos. A masik, hogy eloszor arra gondoltam egy RC modellt faragok at, de abba egyaltalan nem biztos, hogy bele tudom pakolni az elektronikat, mert egyszeruen ennek nincs eleg hely a torzsben (repulorol beszelek). Es ha helyet sikerul is talalni neki, a sullyal, illetve a sulyeloszlassal meg mindig lehet gond.

Nem igazán az a kérdés, hogy képesek vagyunk-e IT rutinokat írni egy oprendszerbe, hanem a komplexitás a probléma. Egy komlex rendszer nagyobb eséllyel döglik meg, és aligha boot-ol be utána néhány ms alatt úgy, hogy a változók egy jól meghatározott körét használni tudja tovább.

Egész egyszerűen szét kell bontanod két rétegre: az egyik végzi az alapjel és a szabályozó paraméterek függvényében a szabályozást, a másik kellően bonyolult algoritmusokkal előállítja a szabályozási paramétereket és az alapjelet.

Pacemaker-be se akarj oprendszert rakni, mert itt nem megengedett a „kékhalál” illetve a kernel panic, az out of memory killer aktiválódása, a memory leak, a biztonsági rések.

Apropó, repülőgép. Ugye emlékszel arra a balesetre, amikor modell replőgép a nézők közé csapódott, s megölt egy házaspárt? Azonnal szörnyethaltak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ennel nyilvan olcsobban is ki lehet, hozni, de azert szamits ra, hogy nem filleres hobbi a modellezes. Ha megnezed az alkatreszek arait, csak a szervok, motorok par ezer forint korul vannak, de kell meg jo nehany mechanikus alkatresz, taviranyito, akku, stb. Ezeket otthon nem egyszeru megcsinalni, valoszinuleg edremesebb megvenni (mint otthon mondjuk fogaskereket marni).

Szerintem 30k alatt valoszinuleg nem jon ki semmi (most nem beszelve a belterben hasznalhato, infras taviranyitasu modellekrol, amikkel 5 percet lehet repulni es iranyithatatlanok), de szerintem egy szazasba nagyon konnyen bele lehet szaladni.

/sza2

Persze. Kezdettől fogva azt hangoztatom, hogy kell egy mikrokontrolleres valós idejű szabályozás, valamint egy felsőbb réteg, ami a bonyodalmat adja bele, de már viszonylag kényelmes felületen kommunkál, hiszen nem kell a fordulatszám, nyomaték, pozíció függvényében hibajelet integrálni, PWM-et csinálni, csak elég annyit mondani, hogy legyen a gép nagyobb magasságban, vagy ilyesmi.

Az egy következő kérdés, hogy ezt a felsőbb réteget meg lehet-e csinálni, valamint érdemes-e megcsinálni mikrokontrollerrel, vagy erősen célszerű egy igen erős software-es támogatással rendelkező - kész függvénykönyvtárakra gondolok - oprendszert futtató gépre bízni ezt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_6201 v | 2014. 08. 29., p – 19:28 )

Vezérlő elektronika alap fogyasztása (szervó működés nélküli állapotban) mennyi legyen?
Önmagában a Raspberry Pi 400 mA körül fogyaszt (3,3V-on, ha nem kell az USB)
32 bites mikrovezérlő, ha neked 4 MHz órajel elég (szerintem szervóvezérlésre nem kell ennyi sem). Ekkor 2 mA (!!)-t vesz fel (persze ha nem lenne elég, nagyobb órajellel is járathatod).

Talán több munka mikrovezérlővel, C-ben szépen programozhatod. Viszont az eredmény:

* kis méretű NYÁK (és mindezt 1mm-es vékony, könnyű NYÁK-on)
* kicsi az alap fogyasztása a mikrovezérlős fedélzeti eszköznek, rádióvevőt is célszerű kisfogyasztásút keresni
* kicsi akkumulátor (kis tömeg, kis méret) elég az azonos üzemideig történő szervó elektronika táplálására

Végsősoron kisebb méretű repülőmodellre is feltehető, illetve jobban repül mert könnyű.
Rpi-vel dolgozva azt csak nagyobb modellre tudod felrakni.

Röviden: RPi helyett erre a célra mikrovezérlővel jobban jársz.

RPi-vel (+kiegeszitokkel) is megoldhato, hogy az atlagos drone meret megmaradjon, am tenyleg ha mar mast epit akkor meret novekszik es azzal majdnem mindent at kell dolgozni.

RPi-nek annyi elonye van kezdes szinten, hogy szinte minden vezerlot megoldhat ra az ember, meg esetleg ha igeny van ra akkor kozvetlen mentheti a felvetelt, nem kell meg az atvitellel szorakozni.

De amugy en is inkabb azt mondom, hogy ha ilyesmit csinal az ember, akkor MCU-val csinalja. Lehet kezdetben nehezebbnek tunik, de idovel jobban be fog valni ha kesobbiekben is keszit az ember ilyesmiket.

( Nyosigomboc v | 2014. 08. 29., p – 21:42 )

Nincs semmi baj az RPi-vel, jo ilyen celra. Ha kiegeszited plusz uC-kkel, annal inkabb. Ha teszel melle egy (vagy ket) filleres atmega8-at, at tudod kuldeni neki a vezerlest, esetleg a gyorsulasmerot es egyeb erzekelok kezeleset is ki tudod szervezni.
Real-time: Arduinoval csinalnak ilyeneket, pedig ott sokkal kisebb szamitasi teljesitmeny all rendelkezesre (igaz, az allandoan). Ha nem marad ki tul nagy idoszelet (vagy real-time kernelt teszel ra), nem lesz nagy baj. A klasszikus PPM ugy mukodik, hogy minden szervonak/ESC-nek 20ms-enkent adsz 1-1 impulzust (aminek a hossza 1 es 2 ms kozt lehet). Ha ennyi idonkent kapsz annyi prociidot, hogy kiszamold es atadd a uC-nek, hogy ezeket tovabbkuldje, mar ugyanott vagy, mint a hagyomanyos radiok. Ha van rajta HW-es PWM csatornabol annyi, ahany szervod+ESC-d van, akkor meg enelkul is biztonsaggal mukodhet.
Repulonel nem szoktak fly-by-wire-t alkalmazni (az inkabb multikoptereknel divat), marpedig amit tavolrol, szemre, kezzel (emberi reakcioido gyorsasagaval) tudsz vezetni, azt az RPi is tudni fogja.
A RPi fogyasztasa - hacsak nem valami konnyu vitorlast akarsz - mindegy. A keszulo tricopterem motorjaiba darabonkent 20A-t bele lehet kuldeni, de meg egy 1 meter koruli, kisebb motoros repulogepnel is realis a minimum 10A. Ehhez kepest az, hogy az RPi felvesz 5V-rol 400mA-t az alatt a 15-30 perces repido alatt, nem tunik veszesnek.

A meret es a felesleges suly lehet problema. De ez a repulod meretetol is fugg. Ha elbir ennyi plusz tomeget feleslegesen, es el tudod helyezni a gepben/gepen valahol a lapot, akkor nem lehetetlen.
A hagyomanyos kialakitasu es meretu (szoval nem a nano) Arduino nyak-ja sem sokkal kisebb a RPi-nel.

Az igazi kerdes az az, hogy miert akarsz RPi-t reptetni, es hogy ehhez mennyit vagy hajlando hackelni.

--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.

( uid_17626 | 2014. 08. 29., p – 21:45 )

Arduino? Ha a súly is számít akkor nano. Ha pedig sok mindent tud majd a drone, akkor mega.

( sza2king v | 2014. 08. 29., p – 22:57 )

Celszeru lenne azt tisztazni, hogy a repulo alatt mit ertesz, valamit ami repul (pl. quadrocopter (forgoszarnyu)) vagy egy repulogepet (merevszarnyu).

Utobbi esetben, en is elkepzelhetonek tartom, hogy mukodjon egy RPi-jal. Bar a szervok vezerlesehez szukseges ms-os jel (raadasul tobb, szerintem minimum 4 csatorna), eseten meg itt is okozhat gondot. Az, hogy real-time a kernel, meg nem jelenti azt, hogy eleg gyors is lesz (attol lehet real-time egy rendszer, hogy egy adott dolgot lassan, pl. 1mp-en belul kezel le, ha ez van specifikalva, csak lehet, hogy az adott eszkohoz ez nem eleg).

Egy quardocopter eseten vannak ketsegeim, hogy egy Raspberry, minden extra kulso vezerlo nelkul fel tudja dolgozni a szukseges szenzorok (leginkabb gyorsulas mero es giroszkop) jeleit es idoben be tud avatkozni a motorok oldalan.

/sza2

( locsemege v | 2014. 08. 30., szo – 12:06 )

Egy ilyen vezérlést, szabályozást szerintem több egymással kommunikáló alrendszerrel volna jó megcsinálni, így sza2king fórumtárssal értek egyet. Egy olyan bonyolultságú rendszer, mint az RPi, és a rajta futó oprendszer, nem igazán alkalmas valós idejű problémák biztonságos kezelésére. Mi van akkor, ha egy bug miatt elhasal az alkalmazás, netán az egész oprendszer? Mi a helyzet a valóban realtime problémákkal?

A gyors beavatkozást igénylő szabályozásokat, teszem azt, PID-szabályozókat, PWM-eket mindenképpen mikrokontrollerekkel oldanám meg. Ezek programját C-ben vagy assembly-ben volna jó megírni. Ezek valóban csak a feladatot valósítanák meg mindenféle sallang nélkül. Itt nincs kernel, nincs memória management, nincs védett mód, csak a hardware és az azt vezérlő kód. A szabályozó paraméterek és alapjelek persze jöhetnek már a mikrokontrollerrel kommunikáló felsőbb szintű vezérlés felől, azaz egy böszme nagy oprendszerrel ellátott RPi felől, s a mérési eredményeket is ebbe az irányba kommunikálnák a mikrokontrollerek.

Ha döglés van, watchdog újra boot-olja az oprendszert, a mikrokontrollerek az utolsó alapjel és szabályozási paraméterek alapján viszik tovább a gépet. Ráadásul szabályozva, hiszen a szabályozó hurkot értelemszerűen a mikrokontrollereknek kellene megvalósítani, a felsőbb szintű vezérlés csak a paramétereket és alapjelet szolgáltatja.

Ha a mikrokontroller döglik - ne tegye, de ha mégis -, a watchdog nagyon gyorsan feléleszti, itt az újraindulás lényegesen gyorsabb, mint az oprendszer esetén. Talán néhány ms. A kommunikáció olyan legyen, hogy bárhol félbehagyott kommunikáció esetén is legyen szinkron. Teszem azt, ilyen az i2c start feltétel, vagy valamilyen huzalozott VAGY kapcsolattal megvalósított dedikált vonal, amely jelzi, hogy kommunikáció eleje van. Lényeg az, hogy bárki, akár a mikrokontroller, akár az oprendszer bármikor éled fel, azonnal egymásra találjanak a kommunikációban, amely természetesen CRC-vel védett, címzett, keretezett csomagokban történik.

A mikrokontrollerek meg tudják különböztetni, hogy power on reset, brown out reset, vagy watchdog reset volt, így megoldható, hogy egyes változókat watchdog reset után nem inicializálunk, így watchdog után, de még kommunikáció előtt úgy szabályoz tovább, mint watchdog előtt.

Ezek mind olyan dolgok, amelyet egy oprendszerrel közvetlenül nem lehet.

Megjegyzés: erőműveket sem PC-vel vezérelnek, hanem duplikált mikrokontrolleres kártyákkal, de ezen kártyákkal PC-vel tartják a kapcsolatot. Ha megdöglik a PC, az erőmű jár tovább, legfeljebb nem lehet módosítani rövid ideig, hogy mondjuk a szinkrongenerátor gerjesztésének megváltoztatásával néhány MVAr-sal több meddőteljesítményt vállaljon magára a blokk. :)

Észrevétel a CRC-hez. 8 bites nem elegendő, hibás csomagnak 1/256-od valószínűséggel ugyanaz lesz a CRC-je, 0.39 % viszont túl nagy érték. Velem már fordult elő olyan, hogy elkerekedett szemmel néztem, hogyan jutott el hibás csomag egyik helyről a másikra, amikor azt ki kellett volna dobnia.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ráadásul a 32 bites mikrovezérlők idejében a CRC16 számítása már kevésbé problémás.

Háron itthon is kapható 32 bites mini-board az ismerkedéshez:

http://www.mikroe.com/mini/pic32/ - MIPS M4K
http://www.mikroe.com/mini/stellaris/ - ARM Cortex M4
http://www.mikroe.com/mini/stm32/ - ARM Cortex M4

Hazai kereskedő: http://www2.chipcad.hu/tartalom.aspx?hir=1210 (másik kettő: MINI-32 Board ára --> Kapcsolódó termékek)

En most egy Silabs EFM32LG942F128-cal szorakozom (igazabol egy olyan chip-pel amiben ez az MCU van + radio). Ez egy M3-as, de szerintem teljesitmenyre valoszinuleg ez is eleg.

Nemsokara hivatalosan is megjelenik ez a valtozat (EZM32 neven), igy egy tokban elerheto lesz egy aranylag eros kontroller egy sub GHz radio (ado + vevo), minimalis kulso alkatreszigennyel.

A fejlesztoi kornyezet Eclipse alapu, Win/Lin/Mac ala elerheto. A programozas megy gyarilag beegetett soros es / vagy USB bootloaderrel (tehat nem kell hozza draga programozo, sot, szoftver sem, en pl. minicom-mal hasznalom (igaz, a debug igy nem mukodik, csak a program letoltese)).

A Farnell-nel lehet kapni is, szerintem az ara sem elvetemult. Vagy kar minta is rendelheto a gyartotol:-)

/sza2

( saabi v | 2014. 08. 30., szo – 22:01 )

A Parrot cég AR.Drone 2.0 gépét az alábbi specifikációnak megfelelő rendszer vezérli:

AR.Drone 2.0 on-board technology gives you extreme precision control and automatic stabilization features.
1GHz 32 bit ARM Cortex A8 processor with 800MHz video DSP TMS320DMC64x
Linux 2.6.32
1Gbit DDR2 RAM at 200MHz
USB 2.0 high speed for extensions
Wi-Fi b,g,n
3 axis gyroscope 2000°/second precision
3 axis accelerometer +-50mg precision
3 axis magnetometer 6° precision
Pressure sensor +/- 10 Pa precision
Ultrasound sensors for ground altitude measurement
60 fps vertical QVGA camera for ground speed measurement

A piacon kapható quadcopterek vezérlői közül az AR.Drone 2.0-é a fejlettek közül való, ha nem a legfejlettebb. Tudja ezt egy RBπ?
Amúgy meg: http://lmgtfy.com/?q=raspberry+pi+quadcopter :-D

Ave, Saabi.

Miért ne tudná egy RPi? Olyan programot írsz rá, amilyet akarsz. Szenzor nyilván kell hozzá, de amikor a gépembe alaplapot vettem, akkor sem tettem fel azt a kérdést, ez az alaplap tudja-e az 1680x1050-es felbontást. Ezzel csak azt mondom, hogy az RPi csak a számítógép, amin fut az oprendszer, s fölötte az alkalmazások, nyilván egy rakás szenzor kell még hozzá.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( junior013 | 2014. 09. 02., k – 08:33 )

A téma nekem is felkeltette az érdeklődésemet, így utána néztem, mire is fogom költeni a fizetésem egy részét az elkövetkező hónapokban.
Nekem ez tetszett meg: http://copter.ardupilot.com/ - Arduino alapú multicopter vezérlés open source szoftverrel.
Bár, én programozni nem tervezem (egyelőre).

( winben | 2014. 09. 02., k – 11:04 )

Én is szívesen csinálnék valami kis pi vezérelte járművet.
Mondjuk hajót.
Csak ahhoz víz kéne a közelben. Meg egy ráérős gépész haver is.

(egyébként sub.)

-------------
There's no place like 127.0.0.1

( Seaweed | 2014. 09. 02., k – 14:36 )

Igaz ez microdrone kategoria, mert terhet azt nem sokat bir el. Majd egyszer ha nagyon raerek ilyet szeretnek:

http://www.bitcraze.se/

(Mar csak azert is mert nativ linuxos vezerlo szoftvere van :D)

( nevergone v | 2014. 09. 02., k – 16:09 )

Nem tervezek ilyesmit építeni, csak eszembe jutott: RPI helyett egy kiszuperált okostelefon nem lenne elég? Igaz, hogy jóval kevesebb a csatlakozási pont rajta, viszont alapból van rajta kamera, jár hozzá külső áramforrás és a számítási teljesítménye is nagyobb. Kikapcsolt kijelzővel és hálózattal még az üzemidő sem lenne vészes.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…