Hát ez kurvanagy! 
A Hungarian team has created the first drones that can fly as a coordinated flock.
Tamás, elmeséled nekünk, hogy ez hogy volt? Két kávé közt ülsz szerényen és fejleszted a magyar skynetet? És egyben nagy grat!
4 hozzászólás
Ha már így meg lettem szólítva: ez már egy viszonylag régi történet - amikor hazakeveredünk Angliából, az ELTÉ-n kezdtem dolgozni a Biológiai Fizika Tanszéken, ahol pont akkor indult ez a kopter-projekt, én meg valamicskét értettem a programozáshoz, úgyhogy kézenfekvő volt, hogy bekapcsolódjak. Megvettük a koptereket egy német cégtől, és nézegettük pár hétig a hardvert meg a hozzá adott firmware kódját, hogy rájöjjünk, hol lehet ebbe az egészbe beavatkozni. Aztán vettünk még néhány Gumstix Overo boardot, valahogy összedrótoztuk őket a kopter eredeti vezérlő boardjával, pár hónap alatt megírtuk a vezérlő algoritmusokat a Gumstixre, et voilá.
Ennél persze nyilván kicsit bonyolultabb volt a dolog, de nem tudom, hogy a technikai részletek mennyire érdekesek. A lényeg az, hogy ezek kereskedelmi forgalomban kapható
Ennél persze nyilván kicsit bonyolultabb volt a dolog, de nem tudom, hogy a technikai részletek mennyire érdekesek. A lényeg az, hogy ezek kereskedelmi forgalomban kapható
drónok, a mi
hozzáadott értékünkmaga a vezérlő szoftver a flocking algoritmussal, és az illesztő board, ami összeköti a kopter eredeti vezérlő lapkáját a Gumstix-szel meg az egyéb perifériákkal, amiket ráaggattunk (magnetométer, giroszkóp, gyorsulásmérő, GPS satöbbi).
válasz
Tamás, a pozicionalashoz a gps választása a pontatlansaga miatt meglepett. Távoli dronok esetén persze tokjo, de közeli dronokat nem lehetett volna valahogy máshogy mérni egymáshoz? Csak kérdezem, mert ugye valahol említve volt, hogy a projekt korai szakaszában sok dron utkozott (amin azóta tullendultetek).
Haszprus, a rövid válasz az, hogy azért használjuk a GPS-t, mert azzal is össze tudtuk hozni a flockot A teljes történet meg az, hogy gondolkoztunk ultrahangos szenzorokon is, de akkor körbe kellett volna aggatni minden koptert szenzorokkal (mert egy szenzor csak egy adott irányba mér). Ez az egyik. A másik az, hogy az a szenzor, amit néztünk, az gyakorlatilag úgy működik, hogy az egyik lábát high-ba kell rakni, ekkor kiküldi a mérő jelet, és egy másik lábat addig tart high-ban, amíg nem érzékeli a visszhangot. Ez azt jelenti, hogy kell szenzoronként két GPIO tüske a Gumstixen: az egyik az, amit 1-be rántunk, amikor mérni akarunk, a másik meg az, amin mérni kell a visszaverődés idejét. Ennyi szabad GPIO láb sajnos nincs a Gumstixen.
Hosszú távon persze nyilván mi is szeretnénk rá rendes távolságmérőt tenni (illetve kamerát is), de ahhoz minden bizonnyal kell egy kis céláramkört is fejlesztenünk, ami csak a távolságmérők jeleivel foglalkozik, és a mért értékeket utána bepakolja egy SPI vagy I2C buszra, amit már a Gumstixről tudunk egyszerűen olvasni anélkül, hogy magának a Linux kernelnek kéne a távolságmérők lábainak a rángatásával foglalkozni.
A teljes történet meg az, hogy gondolkoztunk ultrahangos szenzorokon is, de akkor körbe kellett volna aggatni minden koptert szenzorokkal (mert egy szenzor csak egy adott irányba mér). Ez az egyik. A másik az, hogy az a szenzor, amit néztünk, az gyakorlatilag úgy működik, hogy az egyik lábát high-ba kell rakni, ekkor kiküldi a mérő jelet, és egy másik lábat addig tart high-ban, amíg nem érzékeli a visszhangot. Ez azt jelenti, hogy kell szenzoronként két GPIO tüske a Gumstixen: az egyik az, amit 1-be rántunk, amikor mérni akarunk, a másik meg az, amin mérni kell a visszaverődés idejét. Ennyi szabad GPIO láb sajnos nincs a Gumstixen.Hosszú távon persze nyilván mi is szeretnénk rá rendes távolságmérőt tenni (illetve kamerát is), de ahhoz minden bizonnyal kell egy kis céláramkört is fejlesztenünk, ami csak a távolságmérők jeleivel foglalkozik, és a mért értékeket utána bepakolja egy SPI vagy I2C buszra, amit már a Gumstixről tudunk egyszerűen olvasni anélkül, hogy magának a Linux kernelnek kéne a távolságmérők lábainak a rángatásával foglalkozni.
