Robotika.cz » Soutěže » IARC » 2013

IARC 2013

Autor: Martin Dlouhý, 2013-03-03

létající fandorama blog ...

Šance na vítězství IARC jsou malé, ale čím dříve začneme, tím budou větší … takže stejně jako u AirRace bych blog začal raději hned. Pár dní od zveřejnění fandorama projektu jsem to už nevydržel a pořídil si AR Drone 2.0, tak zde můžete sledovat i mé první autonomní létající pokusy (aktualizace plus mínus každý druhý den). Předem se omlouvám za texty bez korekcí.

Úvod

Na přání jednoho z fandorama přispěvovatelů doplňuji ještě tento úvod (už po skončení projektu). Na první pohled totiž není jasné, zda se jedná o blog z AirRace nebo z IARC … a bylo to obojí. Fandorama projekt AirRace měla být taková „předehra”, která ale nevyšla. Jiné zahájení jsem ale nevymyslel (soutěž je ideální — dobře definovaný cíl a termín) a tak když prošla fandorama reportáž z Robot Challenge 2013, tak jsem do AirRace šel sám.

Ještě bych zmínil (do budoucna), že váš přispěvek nemusí být obří, aby se projekt dal do pohybu. Je to náznak, že by jste rádi viděli „jak to dopadne”, případně chtěli vidět české barvy na nějaké nové soutěži. Kdyby např. každý návštěvník robotika.cz poslal 100Kč, tak IARC 2013 prošel za 3 dny …

3. března 2013

V pátek, den zveřejnění projektu, jsem procházel jednotlivá YouTube videa s klíčovým slovem „iarc”. Přiznám se, že bylo trošku depresivní se koukat na průběh nejlepších týmů, kdy robot vletěl do budovy, pak bylo nějaký čas slyšet hučení, rána a hrobové ticho. Pokud si to stejně chcete vychutnat, tak zmiňované video je zde. Jedná se o nejlepší pokus Michigan Teamu, nejlepšího v roce 2012. Na druhou stranu např. při testování autonomního mapování MAAV Teamu a návrat na základnu k žádné kolizi nedošlo.

O trošku více povzbudivěji vypadají výsledky páté mise. Hned v roce vyhlášení 2009 jí vyhrál tým z MIT a to je pravděpodobně i důvod, proč je Mise 6 podobná té předcházející. Zájemcům doporučuji MIT prezentaci, i když kvalita videa je dost mizerná:

Pěkné je jejich prezentační video z diydrone blogu:

5. března 2013

Ta nula je hrozně depresivní, ale potvrzuje to komentář jednoho fandorama přispěvovatele AirRace — není moc jasné co za to čtenáři webu robotika.cz dostanou. Dobrý pocit, že podpoří někoho jiného a jemu se bude v robotice dařit?

Pokud pro řešení IARC soutěže použiji AscTec Pelican v ceně někde přes 5000EUR, Hokuyo laser v ceně přes $5000 … tak kolik českých nadšenců může pokus zopakovat? U AirRace byla větší šance, že případný návod „jak na to” užije i někdo jiný. Má tedy smysl jít ještě náročnější cestou a pokusit se vyhrát IARC s běžně dostupným strojem jako je AR Drone v ceně do 8000kč? Možná by se našlo dost zájemců, které by chtěli naučit svůj stroj autonomně létat z jednoho pokoje do druhého a zpět? Už jsem v neděli uvažoval, že si dronu koupím a pokusím se o „prove of principle”, ale … má to smysl?

6. března 2013 — nákup AR Drone 2.0

Zlomek se u tohoto projektu stále nezměnil, ale … dnes ráno prošel Robot Challenge 2013 fandorama projekt a motivoval mne si AR Drone 2.0 pořídit. Teď je na nabíječce … přeci jenom 12min letu ku 90min nabíjení je trošku nepoměr. Doporučený volný prostor 4x4m také úplně neodpovídá volnému místu na chodbě či kuchyni. Tak zítra.

7. března 2013 — první TakeOff

Po pravdě „takeoff” jsem chtěl zkusit už včera večer na největší volné ploše v bytě … už chápu, proč se postelím někdy říká letiště. Přestože se pracovní tablet k Droně připojil, tak aplikace AR.FreeFlight 2.0 na stisk tlačítka „Piloting” hlásila: Wi-fi not available, please connect your device to your AR.DRONE. Na webu jsem našel, že podobný problém měli už jiní, ale reset tlačítka jsem se bál, protože zase někde psali, že po něm následuje automatická kalibrace s loopingem ve vzduchu … něco, na což tady, ale fakt není žádné místo. Přestěhoval jsem nábytek, resetoval Dronu a … situace jako před tím. Nešlo se připojit.

Tentokrát jsem už věnoval trošku více pozornosti úvodní hlášce: ,,Please free up storage space on your device to correctly use AR.FreeFlight'', o které jsem si předím říkal, že potřebuji místo jen na ukládání videa/fotek a na to že je času dost … ale smazal jsem tedy jednu kopii Navigátora a naběhlo to .

Je už celkem pozdě, tak akorát vhodný čas na studium: https://github.com/venthur/python-ardrone…

p.s. málem bych zapoměl … koupil jsem si ještě náhradní baterii (to je jedna z prvních otázek, které pokládáme při robotických soutěžích: „jak dlouho vám vydrží baterie?” a „máte náhradní?”). Kupodivu ani toto není úplně triviální, protože nabíječka a tedy i baterie nejsou kompatibilní s předešlou verzí AR Drone! Alza je vůbec nenabízí a u iStyle jsem za 590kč koupil poslední, rozbalenou :-(.

9. března 2013 — představení Heidi

Robot si zaslouží jméno. Když jsme začínali, tak jsme si vymysleli pravidlo dívčích jmen s rostoucím počátečním písmenem: začalo to od Aleny (Eurobot 2001) a cíl byl dostat se až k Sirael, což bylo rok na to jméno MFF robotického týmu. Vývoj se rozštěpil (geograficky) a tak pod rukama Sirael vznikla Barbora, Cecilka, Dana, Ester a druhý tým (Short Circuits) vyplodil roboty Berta, Clara a Daisy. Štafetu Sirael pak převzal Kamil se svýma robotama Hana, Irena a létající Jarmila(?). O Short Circuits se teď stará Pavel.

Už si nevzpomenu na robota od E, ale jako ukázka jednoduchého robota z Merkuru vznikla Fatima a pak šplouchadlo Gerda. RobSys v roce 2007 nechtěl přejmenovávat Eduro na Helenu(?) a u té to asi skončilo. Trošku dlouhý úvod na to, abych řekl, že si myslím, že je čas robota pojmenovat od H, nemyslíte? Pěkných jmen o H je více, ale když vidím tu lehkou konstrukci co může lítat ve výšce, tak mi to nějak asociuje s názvem filmu Heidi, děvčátko z hor… no neviděl jsem ho, ale název jsem slyšel mnohokrát.

Tak už k věci, co AR Drone 2.0 umí, jaké má senzory a jak se liší od AR Drone první generace? Asi nejlepší je začít přímo u zdroje a stáhnout si SDK 2.0 (vyžaduje registraci). Že to vývojáři neměli před půl rokem lehké a nedočkavě vyčkávali a se dočtete zde. Po oficiálním vydání SDK 2.0 se mnoho věcí vyjasnilo. Naše Heidi tedy má:

6 DOF, MEMS-based, IMU (gyra a akcelerometry, stejné jako první generace)
3-osý kompas (magnetometer, nově u 2.0)
sonar na měření výšky do 6m
tlakový senzor pro doplnění měření výšky (nově u 2.0)
HD (720p-30fps) kamera vpředu
QVGA (320*240) 60fps kamera směřující dolu
master USB pro ukládání videa a připojení externí GPS

S Heidi se komunikuje přes WiFi a to na čtyřech portech. DHCP vám dá IP adresu, typicky 192.168.1.2 a drona samotná má 192.168.1.1. Ovádá se pomocí AT příkazů na UDP portu 5556 a „navdata” vysílá na UDP portu 5554. Navdata vedle stavu senzorů obsahují i informace o poloze detekovaných tagů pro Augmented Reality (rozšířenou realitu).

Video se nově od verze 2.0 vysílá na TCP portu 5555 a to v H264 (MPEG4.10 AVC) formátu. V provozu je ještě TCP ,, control port'' pro přenos důležitých dat, u kterých by ztráta mohla být fatální.

10. března 2013 — logování dat

To byl prima den, tedy konec dobrý všechno dobrý, ale … taková mentální slepota :-(. No nic, pěkně od začátku. Logovat vše, co se s robotem děje, je jeden z nejdůležitějších předpokladů k úspěchu, resp. nutná podmínka. Jen z logu se dozvíte, co se přesně stalo a jen tak se v ladění dostanete dál.

Jak už jsem psal včera, Heidi vysílá „navdata” na UDP portu 5554, ale má to hned několik háčků. Aby vám drona poslala nějaká data, tak si o ně nejprve musíte říci. V dokumentaci najdete „To receive Navdata, you must send a packet of some bytes on the port NAVDATA_PORT of host.”, ale co jsou ty „some bytes”?? Na forech (k předešlé generaci AR Drone) najdete, že to musí být konkrétně 0x01 0x00 0x00 0x00.

Posílání „navdata” je ale ještě provázané s AT příkazy na „command portu” 5556. Konkrétně po připojení baterek drona posílá pouze stav a kontrolní součet. V první fázi jsem ale nechtěl z PC rovnou posílat AT příkazy, šlo mi o logování stavu zatím co s dronou létám ručně. Data jsem ukádal, ale když jsem je pak parsoval, tak první dvě zprávy byly v pořádku, ale pak už se druhá stále opakovala. Celý den jsem hledal chybu v komunikaci, ale chyba byla v parsování binárních dat, chá, chá…

packet = open(sys.argv[1], "rb").read()
offset = 0
for i in xrange(5):
  print "offset", offset
  offset = parseNavData( packet[offset:] )

Funkce „parseNavData” vrací kam až se ve čtení packetu dostane … už vidíte, proč to vždy přečte jen první a pak několikrát druhý blok dat z drony??

Jinak potvrzuji, že drona spolupracuje pouze s jedním zařízením, takže vše musí být z PC…

12. března 2013 — parsování dat

První pozorování z parsování nasbíraných dat bylo, že něco jiného jsem logoval, když jsem Heidy od začátku pouštěl ze svého programu, a něco jiného, když jsem před tím zkoušel Free Flight aplikaci na Android. Po zapnutí a vyslání „pár bajtů” (stále nevím, jestli je jedno co pošlu nebo sekvence "\x01\x00\x00\x00" je důležitá) na NAVDATA_PORT 5554 už začnou chodit téměř prázdné pakety=hlavička a blok 0xFFFF, který obsahuje kontrolní součet.

Na vyslání AT příkazu "AT*CONFIG=%i,\"general:navdata_demo\",\"TRUE\"\r" % seqNr už začne chodit základní informace obsahující náklon, výšku, stav baterky atd. Chybí ale informace z kompasu, který v první generaci AR Drone nebyl. Musíte si je totiž vyžádat přes konfigurační AT příkaz s "general:navdata_options". Aternativa je ještě místo "TRUE" u "general:navdata_demo" použít "FALSE". Dokumentace slibuje „send all the available information which contain many debugging information that are useless for everyday flights”, ale možná to bude přesně to, co v první fázi potřebujeme.

Chvíli mi trvalo najít správný tag (číslo) pro NAVDATA_MAGNETO_TAG … v Céčku to mají totiž poskládané jako makra v souboru „navdata_keys.h”, takže si musíte odpočítat řádky. Konkrétně NAVDATA_MAGNETO_TAG=22. Hrubá data z kompasu mi ještě nedávají moc smysl - předpokládám spíše špatné parsování float hodnoty než vliv zavíracího magnetu pro horní kryt drony. Prostě další detail k poladění.

Ještě bych zmínil NAVDATA_VISION_DETECT_TAG, od kterého si slibuji posílání pozice detekovaných nálepek (jsou také součástí balení). Tato data sice chodila se základním "navdata_demo", ale detekce je defaultně vypnutá a tak zatím dostávám 0 objektů. Správný příkaz pro konfiguraci nejspíše bude "detect:detect_type","10" (?).

No nic, přepnu do vývojového módu (do prvního ostrého testu v Rakousku zbývá 10dní). Na závěr bych rád poděkoval dalším fandorama příspěvovatelům: prošel další projekt reportáž z Robotem Rovně a IARC projekt už se odlepil od nuly . Dostal jsem i dotaz/komentář: „Martine, musím říci, že bych byl fakt docela zvědavý, co bys dělal, kdyby se ty peníze sešly” … odpověď je ale jednoduchá … udělal bych vše pro to, abych v Americe vyhrál. Další šance už nebude. Tak přeji pěkný den.

14. března 2013 — první autonomní pokusy

Včera jsem zkoušel naostro následující kód:

drone = ARDrone2( replyLog )
drone.wait(3.0)
drone.takeoff()
drone.wait(2.0)
drone.land()
drone.wait(3.0)
drone.halt()

V rámci jednoduchosti nepoužívám (zatím) vlákna a příkazy jsou blokované. Před každým vysláním AT příkazu se vždy čeká na navdata paket. Tedy i funkce wait() je blokující — prvním mi má dát trošku času na přeběhnutí z kuchyně do chodby, ve druhé by drona měla být 2s ve vzduchu a třetí je na uklidnění po přistání.

Inspiraci pro API jsem použil z python-ardrone. Celkem se mi kód Bastiena líbil, ale mám s ním pár problémů:

nepodporuje AR Drone 2.0
doporučuje používat Psyco, ale „Psyco is unmaintained and dead. Please look at PyPy for the state-of-the-art in JIT compilers for Python.” a pro Python 2.7 ho už nikdo nepřipravil
jsou použité některé funkce (select.select), které mi na Windows neběží.

Psal jsem autorovi, jestli plánuje v tomto projektu dále pokračovat, ale zatím jsem bez odpovědi.

Tak jak testy navdata_130313_190907.log.gz, navdata_130313_192343.log.gz, navdata_130313_193719.log.gz a navdata_130313_194126.log.gz dopadly? V prvním pokusu žádná reakce, ale to jsem tak trošku tušil — v dokumentaci píší, že AT*REF pro vzlet je třeba volat opakovaně dokud z navdata není jasné, že drona vzlétla. V druhém pokusu jsem ho tam tedy 20x a alespoň reakce, že se vrtule několikrát otočily. Pro další pokusy jsem tam v kódu dal 40x opakování a poprvé se k mému překvapení zase nestalo nic a podruhé by se snad i drona odlepila od země, kdybych do chodby včas došel. Pak nastal večerní timeout — v této fázi ještě nechci moc prudit sousedy.

Pro případné zájemce jsem poslední log dal i na web. Je to pár sekund pokusu a má to zabalené cca 64kB. Mimochodem v tomto je Python krásný. Místo f=open(logFilename,"wb") jsem do kódu dal f=gzip.open(logFilename,"wb") a bylo to vše co bylo potřeba k desetinásobnému zmenšení logů .

Už mne zase svrbí prsty a připravil bych další pokusy … tak jen závěrečná poznámka, že ten replyLog je nepovinný parametr. Když je None, tak jedeme naostro a v opačném případě se přehrává již existující log.

p.s. s tím zjednodušováním jsem to přehnal, konkrétně navdata pakety chodí v závislosti na zvoleném módu. Používám teď debug (všechny data) a z „They [navdata] are sent approximatively 15 times per second in demo mode, and 200 times per second in full (debug) mode.” … takže 40x je zhruba 0.2s, yeap.

16. března 2013 — AirRace (verze 0)

Přesně za týden je soutěž AirRace a já ještě nemám funkční ani verzi 0 :-(. Včera a předevčírem to bylo v práci peklo, které se protáhlo do brzkých ranních a pozdních večerních hodin (něco jako když vám odejde záloha zálohy) a na hrátky s Heidy tedy nebyl čas ani síla.

Ve Vídni chci soutěžit s co nejjednodušším algoritmem. Nechystám přidávat žádné další senzory, modifikovat image na droně nebo zpracovávat video stream. Chtěl bych použít API s AT příkazy a navdata strukturou jak je k dispozici všem, co si AR Drone 2.0 koupí. Ještě raději připomenu „definici” verze 0: „co nejjednodušší program, pomocí kterého robot získá jeden bod”. Loni by to stačilo dokonce na vítězství.

Varianta 1 — odometrie

Toto je asi dost naivní, ale zkusit se to musí. Prostě podle časů a rychlostí si odpočítat uletěnou vzdálenost a třeba to tu jednu osmičku (= jeden bod) dá .

Varianta 2 — Absolut Control mode

AR Drone 2.0 má nově mezi senzory i 3D kompas. Díky němu Parrot nabízí i takzvaný „Absolut Control mode”. S ním můžete dronu ovládat nezávisle na natočení, prostě jak nakloníte svůj smart phone tak se nakloní i čtyřtulka k vám nebo od vás. Nelítal bych tedy vždy špičkou vpřed, ale zachovával bych natočení na sever. Na rozdíl od varianty 1 by tato měla udržet alespoň absolutní orientaci osmiček.

Varianta 3 — color tags

Temný pohled na tag přední kamerou

V základním balení je vedle létajícího stroje i pár pomůcek pro Augmented Reality („rozšířenou reality”). Konkrétně je zde šest oranžo-žluto-oranžových pásků a černobílý obrazec jako přistávací plocha. Pásky mají sloužit k označení vaší drony pro virtuální letecké bitvy, ale … možná půjdou použít i pro navádění po osmičkovém obrazci.

Představoval jsem si šesti-segmentovou digitální osmičku, kde v každém křížení by byl vhodně orientovaný tag. Možná by dokonce musel být na nějakém podstavci. Přiložený obrázek z drony jsem získal ve vodorovné pozici ve vzdálenosti 170cm a výšky pouze 40cm nad zemí. Je fakt, že čtyřtulka bude většinu času nakloněna dopředu, takže to možná nebude nutné řešit. Konečně šíře záběru 90 stupňů vypadá dostatečná.

Varianta 4 — oriented roundel

Druhá AR varianta je použít vzor přistávací plochy. Tip mi poslal Tomáš Krajník — AR Drone 2.0 má nový letecký mód HOVER_ON_TOP_OF_ORIENTED_ROUDNEL, který drží čtyřtulku nad přistávací plochou a navíc v daném natočení. Heidi by tedy mohla „hopkat” nad několika xerox kopiemi vzoru nebo použít jeden centrální a natrénovat si otočky s daným poloměrem po a proti směru hodinových ručiček.

Implementační poznámky, resp. aktuální stav

Heidi autonomně vzlétne, chvíli levituje, nebo jaký by byl správný překlad pro „hover”, a přistane. Je to vlastně ten útržek kódu, co jste viděli minule. Přidal jsem tam: parsování času, AT*FTRIM na kalibraci před startem a malou update smyčku v konstruktoru ARDrone2 (aby byla validní informace o čase). Zatím mi ale nechodí žádné detekované vzory. Buď je špatně konfiguruji, nebo drona konfiguraci nezpracuje, nebo musím používat video stream, aby se tím vůbec zabývala. Nebo něco jiného. Nevím. Asi dobrý tip je od Jardy Halgašíka a to použít „velkej demo program” z SDK 2.0 a ověřit, že to HW všechno funguje, případně si odposlechnout, co se tam posílá. Je to hlavně pro linux a nechce se mi to zatím moc po windows kompilovat/rozcházet, ale možná na to dojde …

p.s. jen poznámka, že ono i ta varianta 1 možná bude netriviální. Když jsem Heidi nechal chvíli v předsíni levitovat, tak se mi po chvíli „sama od sebe” otočila o 90 stupňů. Vysvětluji si to vzorem dlaždic a špatně nakalibrovaným kompasem, ale možná i tam čeká nějaké překvapení.

p.p.s.s. Tomáš Krajník ještě zmiňoval, že baterku 2.0 lze koupit od Czech Computers (dráž, ale mají ji na skladě)

17. března 2013 — funkční detekce tagů

Konečně mi v navdata přišel alespoň jeden detekovaný tag. Ještě jsem ho pořádně nestudoval, jestli je to opravdu ten, který Heidi předhazuji, ale stejně to považuji za průlom, tak to raději rozepíšu hned, než to bude samozřejmost. [Na fórech najdete spousty problémů, ale těch i „trapných” řešení už málo … toto patří spíše k těm „trapným”]

Cíl byl prověřit, jak to s tou konfigurací je. V dokumentaci píšou, že na TCP portu 5559 se posílají kritická data a je možné si celou konfiguraci vypsat přes příkaz AT*CTRL: The drone configuration parameters can be retrieved by sending the AT*CTRL command with a mode parameter equaling 4 (CFG_GET_CONTROL_MODE). To jsou zkoušel a nic. Někde jinde ještě psali Ack control command, send AT command: "AT*CTRL=0., takže jsem zkoušel drone.update("AT*CTRL=%i,4"), kde %i je doplňované sekvenční číslo příkazu. Nefungovalo.

No a teď to trapné rozuzlení (asi nejlepší hit jsem dostal z javadrone, což jsou podobné pokusy v Javě, ale zatím jen pro starou verzi AR Drone): AT*CTRL příkaz má ještě druhý parametr (0) a zapomněl jsem tam ukončovací znak \r. Ale ani to by nefungovalo. Důležitá byla třetí oprava a to, jak drona pracuje s AT*CONFIG příkazy. Ty jsou totiž potvrzované a je třeba každý řešit odděleně. Tím, že jsem si zapnul posílání navdata [self.update( "AT*CONFIG=%i,\"general:navdata_demo\",\"FALSE\"\r" )] a config příkaz nepotvrdil, tak už všechny další příkazy byly ignorované. Je tedy třeba ověřovat 6tý bit v headeru navdata (ACK) a po potvrzení ho smazat příkazem self.update("AT*CTRL=%i,5,0\r") # ACK_CONTROL_MODE=5. A je to. Pak už je to jak když se protrhne přehrada. Konfigurace lze z CONTROL_PORTu přečíst (config.txt zde je moje, pokud by někoho zajímala) a když si něco nastavíte a pak jí znova celou vyčtete, tak dané parametry se alespoň změní . Tagy to však stále nedetekovalo.

V dalším kroku jsem zkusil otevřít a číst VIDEO_PORT 5555, jestli to není nutný předpoklad pro detekci AR prvků. Není. Viděl bych to na 3 zakopané psy, konkrétně:

"detect:detect_type","10" … CAD_TYPE_MULTIPLE_DETECTION_MODE=10 místo CAD_TYPE_VISION_V2=13
"detect:detections_select_h","15" … je to bitová maska, tak nastavením více bitů snad nic nezkazím, dříve jsem používal 8
"detect:detections_select_v_hsync","2"

Nastavení té synchronizace bylo zásadní. Pokud ji nenastavíte, tak je tam 0, což asi znamená nic nedělat.

Závěr — je možné začít s experimentováním s variantou 1-4 a zároveň už všechny prvky budou detekované nebo alespoň se budou sbírat data, jak moc ta detekce droně funguje.

p.s. včera mi přišel ještě povzbuzující mail od Jardy Halgašíka, že tento blog četl, a že si myslí, že už samotná odometrie by na jednu osmičku měla stačit. Poslal odkaz na vlastní pokusy popsané na svém blogu a je tam asi i spousta dalších zajímavých informací …

Letecké katastrofy 1. díl (navdata_130317_152253.log.gz)

Tak už jsem to rozflákal :-(. Přesně jak popisují všechny příručky. A ten scénář jednou naživo viděl v AscTecu před dvěma lety. Detekce AR tagů nefungovala, tak jsem začal testovat létání. Co jsem zatím nepochopil je přechod stavů čtyřtulky. Při vzletu se má podle dokumentace opakovat příkaz dokud se stav nezmění z CTRL_TRANS_TAKEOFF=6 na CTRL_FLYING=3. Prapůvodně jsem tam měl čekání 2.5s, pak 4s a v době kolize 10s. Heidi se zvedla do cca 1m, ale pak se opřela o skříň a stoupala dál až ke stropu. Následoval pád na čumák, zlomení levé ochranné obruče a všechny LEDky byly červené. První teorie je, že se drona moc naklonila, přesáhla bezpečnostní limit a systém si sám zavolal EMERGENCY a motory vypnul. Možná více napoví „černá krabička” tedy log.

První pohled na konec logu ukazuje „'altitude': 751, 'ctrl_state': 4”, tj. podařilo se přejít do CTRL_HOVERING=4, což se mi s 4s stoupáním nepodařilo. I výška 0.75m je OK, takže otázka je, zda to už je v pádu nebo se ztratil konec logu.

Výpisem jenom CTRL stavů dostávám:

286 CTRL STATE 2
1230 CTRL STATE 6
1060 CTRL STATE 4

takže přechody byly 2->6 a 6->4. Do stavu 4 se robot dostal v čase 6.1s od příkazu k odstartování. Další 4s tedy ještě chybně dostával příkaz TakeOff …

Je v datech vidět jak robot stoupal?

Průběh výšky v metrech

Pěkné, tj. podle senzorů si myslel, že není ani 1m vysoko a přitom byl ve výšce stropu, který je cca 2.6m. To bude zase ten nešťastný tlakoměr, možná jemný průvan a moje chyba, že jsem nezměnil defaultní nastavení na INDOOR? Kdybych změnil bezpečnostní výškový limit na 2m, tak by to evidentně nepomohlo.

Teď jsem rád, že jsem nechal všechny zprávy zapnuté ("general:navdata_demo","FALSE"), protože další podezřelý je kamera. Chodba je tmavá a tak si tam svítím. Drona si tedy sama generovala ostrý stín, který mohl zmást její odhad výšky … to be continued.

19. března 2013 — Emergency STOP tlačítko

Velké červené tlačítko je snad nejdůležitější součást robota. Jenom díky němu zabráníte zničení drahých senzorů, nemovitého majetku a vašeho vztahu s přítelkyní. Ono se vždy něco pokazí a časem si na to vypěstujete instinkt. Jak je tedy možné, že Heidi nic takového neměla?!

Před dvěma dny jsem si ještě nebyl 100% jistý, co by přesně to tlačítko mělo dělat. U létajícího robota je možností hned několik: Emergency — vypne motory a stroj se zřítí na zem, Land — automatické přistání, Hover — stroj zůstane levitovat ve vzduchu.

Nemohl jsem se rozhodnout. Navíc vím, že v případě problému člověk nemá čas přemýšlet. Prostě je třeba něco rychle zmáčknout a teprve v následující sekundě se možná rozhodovat, co přesně je třeba dělat. Po nedělním pádu, kdy drona byla vlastně v „bezpečném” hover stavu mi došlo, že ani jedena z variant by v danou chvíli nepomohla. Bylo už moc pozdě. Něco jako když nárazník hlásí kontakt, tak dupnutím na brzdu už kolizi nezabráníte. Ale použitím brzdy následky nemusí být tak zlé. Závěr? Odpověď zná každý letecký modelář: „musíte mít učitele s dalším ovladačem.”

Testování

Včera večer jsme poprvé pořádně testovali. Mluvím v množném čísle, protože za to děkuji Honzovy z Eduro Teamu, který nabídl na testování volné skladové prostory jeho manželky. Místnůstka byla sice malá (17m2), ale bylo tam teplo (venku tou dobou sněžilo) a byla pod zemí, tj. nikomu v okolí motory drony nevadili ani po 21h.

Abych navázal na úvodní Emergency STOP … dopsal jsem ráno do kódu konzoli, kterou jsem zapojil do nejhlubší update() rutiny a pokud zmáčknete libovolné tlačítko, tak vyletí výjimka a vnější try..except přejde do ManualControl režimu. Na konzoli jsem vlastně implementoval jenom Land, nic jiného jsem zatím v reálu neodzkoušel.

Při testování člověk ztratí celkem dost optimismu, ale je zase blíže realitě . První testy byly s konzolí, tj. jestli opravdu autonomní program přeruší a robot předčasně přistane. To fungovalo, i když ještě pár detailů bych tam změnil. Ten večer jsem manuální režim použil snad 30x. V logu to bohužel není úplně dobře vidět — ještě prozkoumám, jestli AR Drone 2.0 nemá v sadě nějaká „uživatelské tlačítka”. Mám totiž pocit, že jsem tam něco takového zahlédl.

Jakmile se Heidi dotkla zdi, tak jsem automaticky v panice mačkal SPACE a přistával (mimochodem, kdyby jste rychle potřebovali indoor ochranný kryt, tak jsem ho včera koupil u Alza.cz … hmm, nemohl jsem ho přes hledání najít, tak jsem musel do historie prohížece a „není dostupné” tj. asi jsem zase koupil poslední kus). Ten rozlámaný jsem ještě nezalepil.

V prvních testech jsem se chvíli snažil detekovat a navigovat na „oriented roundel”. Nepodařilo se mi to. Možná, že nutná podmínka je úspěšná detekce a teprve pak lze přepnout navigační mód?? Chtěl jsem udělat něco jako na tomto videu, ale zatím neúspěšně.

Pak došlo na létání a těch copy & paste chyb a nedůsledné čtení dokumentace … klasika. Abych to zrekapituloval, pohyb ovládáte pomocí následujícího AT příkazu: "AT*PCMD=%i,1,"+ "%d,%d,%d,%d"%(f2i(leftRight),f2i(frontBack),f2i(upDown),f2i(turn)) + "\r". Pokud chcete mít robota v hover stavu, tak místo 1 tam dáte 0 (to byla první chyba, copy&paste z hover() a zůstala tam 0 … robot se spíše pohnul průvanem a já se už chystal otáčet znaménka směru pohybu).

Druhá zásadní věc je použití f2i funkce, kterou jsem převzal z python-ardrone:

def f2i(f):
    "Interpret IEEE-754 floating-point value as signed integer.
    Arguments:
    f -- floating point value
    "
    return struct.unpack('i', struct.pack('f', f))[0]

Vypadá to, že všechny AT příkazy pracují pouze s inty, takže je potřeba float přetypovat na int a poslat.

Pak už se robot začal pohybovat a když při testu „leť vlevo a pak vpravo” letěl 2x vlevo, tak jsem opravil poslední (?) copy & paste chybu ve znaménku.

Asi největší zklamání byla neopakovatelnost pokusů. Hover dost plave (pokud pod sebou nemá ty výrazné černo bílé navigační znaky) a časovaný pohyb vpřed uletěl typicky třetinovou vzdálenost při pohybu vzad. Čekám tam ještě zádrhel v parsování času, protože z jednoho logu to vypadalo, že zpět dostal 320 příkazů vzad zatím co příkazu vpřed jen 220. Analýze logů se tedy budu věnovat dnes.

20. března 2013 — procházení logů

Tak jo, chyba v parsování času byla celkem zřejmá (výpis po sobě následujících navdata paketů):

TIME	758.47611	0
TIME	758.47611	0.52568
TIME	759.00179	0
0x5ecf3c4a
0x5ecf3c4a
0x5ee00ea9
'0b10111101100 11110011110001001010'
'0b10111101110 00000000111010101001'

Toto není v dokumentaci, ale přímo ve zdrojovém kódu:

uint32_t time; /*!< 32 bit value where the 11 most significant bits represents the seconds, and the 21 least significant bits are the microseconds. */

Hmm, tak nevím, proč tam plýtvají tím 21. bitem :(. Prostě jsem počítal s 20bity na microsekundy, tj. když budu ignorovat fakt, že 1s nemá 1048576 microsekund a s 5% chybou mohu žít, tak stačí číslo pouze podělit (1<<21). Nestačí. Prostě 20. bit bude vždy nula a v mém případě to tedy občas skákalo o 0.5s. Stejně tak jsem si říkal, že není třeba řešit přetečení sekund, že baterky (1<<11)/60. = cca 34min nevydrží, ale … je 10min je odhad na čas letu. Škoda, toto bych asi API vytknul, ale je mi jasné, že to nikdo kvůli zpětné kompatibilitě už měnit nebude.

To přetečení mne trošku znervózňuje, tak jsem ještě koukal na poslední log, než jsem vyměňoval baterky: TIME 1947.416625 0xf3665b71L tj. jestli počítám dobře, tak zbývá 1.5min do přetečení … to není dobré. Ošetřeno.

Tato vlastně triviální chyba vysvětluje problémovou opakovatelnost. 0.5s manévr mohl trvat libovolnou dobu od 0s po skoro 1s v závislosti, kde se časový skok nacházel. Není divu, že i uletěná vzdálenost podle toho vypadala.

Altitude a (vx, vy, vz)

Drobná chyba v oficiální SDK 2.0 — ve struktuře _navdata_demo_t píšou u altitude komentář /*!< UAV's altitude in centimeters */ … nevěřte tomu. Je to v milimetrech. Stejně tak není moc jasné v jakých jednotkách je vx,vy,vz (/*!< UAV's estimated linear velocity */). V obou případech lepší info najdete na https://github.com/AutonomyLab/ardrone_autonomy, tj. ta rychlost by měla být v mm/s. Divné, že nejvíce se při startu mění x-ová souřadnice …

21. března 2013 — tým

Tým považuji pro úspěch v robotické (ale i jiné) soutěži za to nejdůležitější (viz robotické desatero). Na AirRace ho nemám a to je zatím asi největší chyba. Tedy není to úplně pravda — pondělní a včerejší testování s Honzou bylo právě „týmové testování” a za to díky .

vzor pro létání do čtverce

Jak se týmová práce v testování autonomních létajících robotů projeví? Jeden člen týmu má ruku na emergency tlačítku zatím co druhý čtyřtulu odhání od radiátoru, zdí a podobných ošklivostí. Asi nejlepší příklad byla moje chyba v pythonu, kdy jsem zapomněl jeden „self”. Program skončil, ale Heidi letěla dál. Přešla do „bezpečného” hover módu, který ale trošku plave … a co teď? Honza už se naučil lovecký trik: dronu ve vzduchu chytil a převrátil na záda. Ta přešla do emergency módu a motory vypnula … tak kdyby jste to také někdy potřebovali .

Včera ráno jsem upravil kód tak, že při stisku libovolného tlačítka místo ručního ovládání drona rovnou přistane. To byl vlastně jediný scénář, který jsem v pondělí používal, tak jsem to trošku zjednodušil … a chyba lávky. Během přistání drona stále vykonává poslední příkaz a tak by byl třeba ještě detail, který jsem v manuálním ovládání v pondělí měl: pokud není stisktnuté žádné tlačítko, tak přejdi do hover() na 0.1s. Důsledkem tohoto nedostatku Heidi udělala pár kotrmelců při nárazu po letu do strany.

Co jinak? No není to moc růžové, resp. je to spíše černé. Heidi měla světlé chvilky, kdy obletěla čtverec 1x1m, ale měla daleko více temných chvilek, kdy byla naprosto mimo :-(. Vliv může hrát nevýrazný vzor na koberci, stíny, za kterýma se honí, železný radiátor, cirkulace vzduchu … čert ví. Tak jsem zvědav, co nás čeká za překvapení ve Vídni.

Ještě stále se mi nepodařilo rozchodit navigaci na „roundel”. Koukal jsem znova do SDK 2.0 a

v dokumentaci píšou „semi-autonomous mode”, takže z toho soudím, že je ještě nutné něco ovládat ručně
v Céčkových zdrojácích je to složení bitů 1=pozice, 1<<1=orientace … a dosud jsem používal jen 2

Teď mám teorii, že je třeba droně posílat leť rovně, aby vůbec vykonávala navigaci na značku … a když značka není, tak poletí rovně??

p.s. vypadá to, že během 3h testování čas několikrát přetekl (baterky jsem vyměňoval jen jednou)

p.p.s.s. souřadnice X dopředu, Y vpravo, Z nahoru, směr otáčení 'psi' po směru hodinových ručiček. Rychlost 'vz' (rychlost v z-ové souřadnici je (zatím) vždy 0 … dal jsem tam assert, což asi není úplně dobrý nápad

22. března 2013 — odjezd

Dnes jen telegraficky. Včera večer jsem ještě trochu testoval v podzemních garážích a podařilo se mi dronu rozlomit vejpůl :-(. Kdyby vám někdo říkal, že jí můžete chytit za letu a otočit na záda … nevěřte mu, nestojí to za to. Honza, jako robo-mechanik, dobře věděl, že jí musí držet za tělo. Já, jako programátor, jí klidně vzal za vnější kryt … a bylo to. The End

Proč jsem se do toho vůbec pouštěl? Ještě to stále nechápu, ale vypadá to, že mi začala padat kombinace python-pygame. Nevím, nerozumím tomu, co se přesně stalo. Program, který už jsem pouštěl poněkolikáté, zamrzl (2x). Poprvé drona neodstartovala. Tak jsem to měl nechat a jít domu, ale … podruhé odstartovala, ale řídit se nedala.

Tak pln optimismu dnes sám odpoledne vyrážím směr Vídeň … že jsem se do toho pouštěl …

Ještě pár včerejších poznatků:

automatická navigace na „roundel” nefungovala ani když jsem to zkoušel s kombinací letu vpřed.
na webu jsem našel novější SDK 2.0.1 (zajímavé asi hlavně pro ty, co by chtěli vyvíjet Android aplikaci)
pásku na opravu rozlomených krytů, lze koupit např. zde … teď to budu lepit.

To je dnes asi všechno. Držte mi palce.

24. března 2013 — Air Race contest

Z práce jsem v pátek utekl dříve a do Vídně do hostelu dorazil okolo 20h. Hostel je sice cca 8km daleko od místa soutěže, ale na druhou stranu tam jsou všichni robotici pohromadě. Paradoxně mne uklidňoval randál z testování asi velkých sumo robotů, protože pak jsem neměl problém létat s Heidi i dost po večerce. Poslední log je navdata_130322_232451.log.gz …

Dali mne na 6-lůžkový pokoj s matfyzákama a když jsem v recepci říkal, že ti teprve vyráží z Prahy, tak jsem netušil, jak blízko jsem byl pravdě. Dorazili až po jedné hodině ráno, takže nikomu nevadilo, že jsem vyklidil nábytek a testoval v cca 3mx3m prostoru.

Večer jsem hlavně dělal úklidové drobnosti, na které na soutěži nebude čas a klid. Vyhodil jsem z kódu pygame a použil systémově závislou funkci msvcrt.kbhit. Stačí mi jenom signál, že má drona přistát a i když se v sobotu ukázalo, že pád programu měla na svědomí spíše wifina ve windows, tak to jednořádkové volání je určitě jednodušší.

Dále jsem ošetřil emergency stav. Parrot to má trošku zvláštně řešené. Je potřeba volat „toggle” funkce, takže pokud drona byla v normálním stavu, tak jí převedete do emergency. Už mne přestalo bavit zakomentovávat volání reset() funkce a koukal jsem tedy na 31.bit v navdata paketu. Stále to nefunguje 100% (možná je třeba kontrolovat jestli se někde změnil nějaký bit??), ale aniž neustále upravujete kód, tak napodruhé už drona odstartuje. Dodělal jsem ještě výpis stavu baterky při startu a podmíněné volání hover() pouze pokud je ve stavu CTRL_FLYING=3.

V sobotu ráno jsem si pak naprogramoval vlastní navigaci na značku. Nechtěl jsem se rovnou vrhnout do kombinace náklonů a otáčení, takže to jsou tři oddělené funkce, kdy se Heidi snaží opravit x-ovou, pak y-ovou souřadnici a konečně úhel [teď je 5:47am a venku zase sněží … to bude pěkná cesta domu].

Testování navigace jsem nechal až na místo konání soutěže a celkem to fungovalo. Spodní kamera kouká spíše dozadu a nevím přesně pod jakým úhlem, takže pokud je značka za robotem, tak jí robot vidí. Pokud je značka před robotem, tak má smůlu a nevidí nic.

V soutěži samotné jsem nakonec klasicky tuto novou navigaci už nepoužil. Chtělo to dodělat ještě „pumpování”, kdy v případě, že drona značku nevidí, tak vzlétne výš a pak jí snad uvidí. Další „detail” k řešení by byly náklony, kdy se pohled z kamery výrazně změní a bylo by třeba tento fakt kompenzovat.

V aréně při soutěži v prvním pokusu dala jeden oblet, ale bylo to jen tak tak. Dotek sloupu nebo sítě znamená konec a dotkla se na startovní čáře. Z logů teď vidím, že jsem v deseti minutách stihl udělat 8 pokusů. Nejlepší byl poslední, kdy první osmičku proletěla čistě, ale pak tak přestřelila, že jsem ji před dotekem sítě zastavil. Zbyňka jistě potěší následující obrázek

nejlepší pokus

Ano, stále používám 10let starý základ vieweru na Eurobota 2003, kdy se hrálo na šachovnici … jen jsem vypustil z-ovou souřadnici a náklony.

Z obrázku je také vidět, že detekce značek nebyla vždy úspěšná (růžové fleky). Robot se nejprve odsunul cca 1m vpravo od startu a tak by mu to hledání ani moc nešlo. Značek bylo 9 - mřížka 2.6m 2x4 + startovní pozice.

chvile na 1. místě

Závěr? Jsem moc rád, že jsem se přes fandorama rozhoupal si AR Drone 2.0 koupit, vyhecoval se v čtrnáctidennímu programovacímu sprintu a získal alespoň jeden bod na AirRace. Plán byl samozřejmě vyhrát a tak přesvědčit ostatní, že má smysl i IARC, ale …

Ještě přikládám chvilkový moment slávy jak to dopadlo si pak nechám na reportáž z Robot Challenge 2013.

Tady bych asi IARC blog pauznul — co bych studoval dál je možnost „virtuálního nárazníku”, tedy jestli je z dat možné poznat, že se robot opírá o překážku a takto by mohl bez dalších senzorů přeletět z jedné místnosti do druhé. Počkám s tím ale až se zvedne částka nad 1000.

30. března 2013 — CV Drone

Čas běží a zatímco stav účtu na fandorama.cz se může kvantově během hodiny změnit, na vývoj a testování extra měsíc kouzlem nepřidáte. Navíc mne minulý týden potěšilo mnoho lidí, když mi řeklo, že můj blog se zájmem sledovalo … . Je čas vyndat zase Heidi z krabice a ve zbývajících 14ti dnech jí nechat autonomně létat po bytě a pokusit se sebrat něco ze stolu … hmm …

Včera jsem zviditelnil reportáž z Robot Challenge, kde jsou zmíněni soupeři a výsledky AirRace. Je jasné, že na IARC bude potřeba použít kameru a tak jsem si cvičně stáhl CV Drone, který používal ruský tým Sirin. Chvilku to trvalo, a když jsem pak viděl, co všechno se stahovalo, tak mne to ani nepřekvapilo … spousty binárních DLL knihoven a pod. Na druhou stranu zde byly připravené projekty pro Visual Studio 2005, 2008, 2010 a 2012, a tak opravdu stačilo podle readme.txt zmáčknout F7 na build a F5 na puštění programu.

No nic to neudělalo, protože jsem neměl zapnutou a připojenou dronu (mimochodem doporučuji před každým puštěním programu raději ověřovat síť přes ipconfig). Teď ji chci zapnout, tak raději nejprve pohled do zdrojáků, aby mi náhodou v kuchyni na stole neodstartovala.

Tak jo, vypadá to rozumně - test.sln je jednoduchá konzole s ručním ovládáním, SPACE na vzlet/přistání, 'C' na změnu kamery, ESC konec … jen nevím, co se stane, když zmáčknu ESC a Heidi bude ještě ve vzduchu. Podle

if (KEY_PUSH('C')) ardrone.setCamera(++mode%4);

soudím, že jsou 4 kamerové módy a z

cvShowImage("camera", image);
cvWaitKey(1);

usuzuji na tu integraci s OpenCV. Řízení přes

ardrone.takeoff();
ardrone.move3D(vx, vy, vz, vr);
ardrone.landing();

také vypadá přímočaře (jednotky jsou podíl maximálních hodnot, tj. ovládá se -1..1).

Moje představa finálního programu je kombinace C(++)/Python, kdy zpracování obrazu a asi i TCP video kanálu by byla oddělena v C. Uvidíme.

pohled na ledničku

OK, funguje , ale ty módy jsem rozlišil jenom dva … prozkoumám po snídani.

1. duben 2013 — Virtuální nárazník

Přiznám se, že mám trošku psychický blok, který mi brání zopakovat první katastrofický scénář ze 17. března 2013, kdy se mi prvně Heidi rozlomila. Na druhou stranu potřebuji do kódu zapojit nějaké ochranné reflexy. Pustím se do toho, ale jak říkám, podvědomě to stále odkládám …

O co jde? Chtěl bych na létajícím stroji zprovoznit něco jako máme na kolových robotech a nazýváme to „virtuální bumper” (nebo nárazník). První úspěchy jsme s ním slavili v roce 2002, kdy to byl klíčový prvek vedoucí k vítězství v Cleaning Contest ve Švýcarsku. Zde za extra senzory byly trestné body a Berta měla pouze přední nárazník, enkodery a slabé motory. Pokud tedy do něčeho narazila, třeba při couvání, tak se zasekla. Motory se snažily jet, ale robot se nepohnul. Toto je situace, kdy „virtuální nárazník sepne”, tj. robot si „uvědomí”, že mu to nějak nejde, že tam asi bude překážka a změní poslední prováděnou akci.

U létání je to trošku jiné. Zatím jsem viděl tři různé scénáře. Jeden z předsíně (crash: logs\130317\navdata_130317_152253.log.gz), kdy se Heidi o překážku opřela, naklonila se a začala stoupat. Tehdy jsem to chtěl zachránit přerušením spojení (velmi naivní), takže nemám log celého pádu, ale už náklony z logu jsou velké: ve stupních (-7.862, -16.006, 77.695), kde poslední číslo je nezajímavý heading. Zde by tedy virtuální bumper mohl fungovat jako verifikace, že max(abs(angle)) je větší než nějaký limit. Pro srovnání ještě obrázek z létání ve Vídni — drona se snaží držet náklon a rychlost se tedy průběžně mění. V aréně to bylo 5 stupňů a při brždění (hover) to přetočila do protisměru na 10 stupňů. Z grafu je i pěkně vidět, že Heidi startovala šikmo s drobným náklonem vpravo.

náklony při létání osmičky ve Vídeňské aréně

Druhý scénář nastane, když drona narazí nějakou vrtulí. Už při prvním testování u Honzy mne „kousla” (odstrkával jsem ji od zdi) a hned na to se motory zastavily. Pozná se to ze stavového bitu v uint32 headeru, kde konkrétně bit 22 je ARDRONE_CUTOUT_MASK. Dojde k tomu ale i když vrtule opře o vnitřek indoor krytu, což možná bude komplikovat moji teorii „leteckého virtuálního nárazníku”.

V třetím scénáři se drona od zdi odrazí jako ping-pongový míček. Ještě budu hledat, ve kterém logu to přesně bylo, ale možná to bylo automatické přistání, kdy před tím drona letěla do boku a tak ve volném letu pokrčovala.

Při procházení logů jsem koukal i na stav bitu 19: ARDRONE_ANGLES_OUT_OF_RANGE. Je to případ, kdy je Heidi na zádech, a motory se vypnou. Celkem mne překvapilo, jak je ten bezpečnostní limit nastaven vysoko. Seplo to až u 85 stupňů. Mimochodem, AR Drone 2.0 umí i looping, kdy tuto ochranu předpokládám vypíná … ale to jsem ještě nezkoušel.

2. duben 2013 — ping-pong

Nakonec jsem včera náraz do zdi zkoušel asi 3x (jeden 19s pokus jsem i natáčel, ale asi to moc nestojí za to ho hned uploadovat … možná později). Ve všech pokusech nastal případ typu 3, kdy se Heidi od zdi odrazila a znova se do ní snažila narazit. Z úhlů bych to já nepoznal, ale v záznamu z akcelerometrů je vidět, alespoň na natáčeném pokusu, pěkný zub. Drona letěla relativně pomalu (0.1* control:indoor_euler_angle_max = 2.0943952e-01 … což je asi 1.2 stupně, teoreticky), ale na mapování místností by tato rychlost asi stačila.

úhly

hrubá data z akcelerometru

Intention to compete

Napsal jsem amíkům, že tým robotika.cz zvažuje účast na IARC 2013. Přibalil jsem k tomu i dva dotazy, zda je možné používat magnety na nabrání USB disku a jak moc vadí, když létající robot naráží do zdi. Odpovědi mne potěšily:

magnety je možné používat a většina týmů to tak dělá
do zdi je povolené narážet, ale stroj musí zůstat ovladatelný

Moje současná představa verze 0, kterou bych se snažil zprovoznit do fandorama deadline (14. dubna 2013), je následující:

průlet oknem čistě na odometrii — start by byl z černobílé značky, aby se drona ve vzduchu srovnala, a při troše štestí by 1x1m díru mohla trefit
v samotné budově by „uklízela” jednotlivé místnosti s 1m rastrem — zdi jsou na sebe kolmé, celkově 33x18m = 594m^2, to je při 10 minutách zhruba 1m^2/s
primární senzory by byly akcelerometry a gyroskopy na detekci kolize se stěnou
při detekci stolu (překážky podle spodního sonaru) by Heidi analyzovala obraz spodní kamery a pokusila se na USB disku přistát. Na jedné noze by měla magnet a na druhé zavěšené falešné USBčko tak, aby se přistáním samo mechanicky uvolnilo

4. duben 2013 — Deaf sonar

Včera večer jsem zkoušel v předsíni létání od zdi ke zdi a moc to nešlo. Proud vzduchu v koutech je tak silný, že se to pere s malým úhlem pro létání. Větší úhel ale znamená větší rychlost a větší náraz … ale asi na to dojde.

Za zmínku stojí třetí pokus (navdata_130403_194400.log.gz), kdy Heidi odstartovala, ale cca v 50cm šla sama od sebe hned na přistání a všechny LEDky svítily červeně. Z logu jsem vyčetl stav 0x8fa20094, kde 31. bit znamená Emergency a nově 21. bit „Ultrasonic sensor : (0) Ok, (1) deaf”. Prostě přestal fungovat sonar! Je fakt, že byl senzor o cca 1mm zastrčený (že by ty nárazy?) a po lehkém promačkání byly zase senzory zpět a drona fungovala, ale …

Z dat v logu je asi zajímavá část v _navdata_raw_measures_t, kde je poměrně hodně magických proměnných spojených se sonarem:

uint16_t  us_debut_echo;
  uint16_t  us_fin_echo;
  uint16_t  us_association_echo;
  uint16_t  us_distance_echo;
  uint16_t  us_courbe_temps;
  uint16_t  us_courbe_valeur;
  uint16_t  us_courbe_ref;
  uint16_t  flag_echo_ini;
  uint16_t  nb_echo;
  uint32_t  sum_echo;
  int32_t   alt_temp_raw;
  int16_t   gradient;

Asi trošku francouzštiny?? Tipoval bych první a poslední echo … pak dlouho nic a pak počet použitých měření a jejich součet. Proměnná alt_temp_raw pak vypadá jako momentální odhad vzdálenosti v milimetrech a v tom pokusu, kdy se to pokazilo, klesla suma na 0 a při počtu měření 3 to vzdal.

Vedle krátkého testování jsem včera ještě pročítal dokument http://iarc.angel-strike.com/IARC_Arena_Construction.pdf. Dobrá zpráva je, že místnosti jsou montované z krychlí o straně cca 2.5m. Tj. vedle kolmosti jsou rozměry místností a koridorů násobkem 2.5m, což může zjednodušit lokalizaci.

Jsou ale i špatné zprávy: vedle stolů bude v místnostech i další kancelářský nábytek, sloupy a větráky! Větrák jsem viděl v záznamu z mise 5 a bohužel se dostal i do mise 6. A co drobný průvan udělá s dronou v místnosti už jsem viděl ve Vídni. Možná dojde na přepnutí do OUTDOOR módu a detekci větru (ve Vídni to nepomohlo). Prostě zbývá ještě spousta zábavy

7. duben 2013 — první pokus o sebrání USB disku

Je neděle, sněží. V pátek poskočil stav fandorama účtu o 1000kč a rozhoupalo mne to si objednat extra senzory, které mi na první pohled (při srovnání s cenou AR Drone 2.0) přišly celkem drahé. Dva sonary a USB <-> I2C převodník za cca 2000kč … a možná ani nepůjdou připojit … uvidíme. Měla by to být alternativa k verzi 0 s bouráním do stěn, která se zatím moc neosvědčila.

magnet od dveří

Včera jsem místo na počítači dělal na zahradě (doporučuji), ale to mi nebránilo si ve volných chvílích hrát s magnetama, provázkem a USB diskem . Asi bych si měl zopakovat fyziku ze střední školy, jak je to s těma siločárama. Opravdu dva plíšky okolo relativně slabého magnetu dokážou divy. A když je to celé volně na provázku tak se magnet „samo naviguje” na konektor USBčka. Na druhou stranu se trošku bojím ten provázek na Heidi přivázat — vedle rizika namotání na vrtuli asi bude i vadit spodní kameře a celý stroj už nebude vyvážený. To je plánovaný poslední test a snad to nebude „salto mortale”.

Test 1 — minimální výška

V prvním testu chci ověřit jak se Heidi chová, když jí nutím pohybovat směrem dolu, přestože je už dost nízko. Prográmek je následující:

drone = ARDrone2()
drone.takeoff()
drone.moveDown( 3.0 )
drone.land()

Tj. vzlétni, pohybuj se 3m dolu (což by nemělo jít) a přistaň.

Test 2 — přelet přes stolek

Druhý pokus by měl ověřit jak si drona poradí s „teréními nerovnostmi”, když jí měření vzdálenosti k zemi skočí o 30cm. Předpokládám, že v kombinaci s IMU tuto změnu vyhodnotí jako překážku. Mělo by to být následně vidět na datech ze sonaru. Zase jen doufám, že mi neuskočí do lustru.

Test 3 — sebrání USBčka

Poslední test by byl s magnetem na provázku a pokusem sebrat USBčko. Zatím nevím, zda bude lepší ho přivázat na jednu přistávací nožičku nebo na indoor kryt. Asi zkusím oboje.

Výsledky

Tovární nastavení control:altitude_min = 50 … chtěl jsem napsat nefunguje, ale ono asi funguje! Nějak jsem si vsugeroval, že je to 50cm, ale ono je to 50mm: Minimum drone altitude in millimeters. Should be left to default value, for control stabilities issues. Což je fajn, můžu se tedy pokoušet přistávat i blízko podlahy/stolu. S dronou jsem v prvním testu několikrát narazil na zem (jemně) … a tak to tedy bylo podle očekávaní.

Druhý test odkládám na větší prostor … ono totiž už i u prvního Heidi několikrát narazila i bokem a to nikam neletěla.

Zkusil jsem alespoň narychlo i třetí test, co to udělá. Místo na úchyt se samo nabídlo — pověsil jsem ho Heidi jako náhrdelník na krk a pak teprve nasazoval indoor kryt. Byla z toho trošku nervozní, ale vzlétla a přestože měla zůstat na místě, klesat 0.5s a přistát, tak se ve druhém pokusu na mne vrhla (cca 2m vpřed). Jsem zvědav na data. Teď mám nějaké povinnosti, tak pokračování asi zítra (?).

9. duben 2013 — záporná výška

Koukám konečně na víkendové logy a první pozorování je, že výška 4294967.295 „je nějaká divná” . Asi to není úplně běžný stav, ale je ho možné dosáhnout. Také jsem se divil, co jsem si napsal sám k prvnímu logu vs. co jsem napsal na web trosku se odsunul cca jak pise, jen v y-ove to bylo mene a narazil na zem. Pristani bylo tvrde v cca 30cm se trosku zvedl do vysky … prostě, budete-li parsovat základní navdemo data, tak použijte struct.unpack_from("IIfffifff", data) … chyba byla i v původním python-ardrone.

Koukal jsem ze zvědavosti i do Céčkových zdrojáků SDK a už tuším, na jakém základě jsem si vsugeroval, že těch 50 je 50 centimetrů:

typedef struct _navdata_demo_t {
…
  int32_t     altitude;               /*!< UAV's altitude in centimeters */
…

i když jsem to „věděl” a psal jim na nějaké fórum, že to mají špatně okomentované. V každém případě je to v milimetrech a může to být i záporné.

záporná výška

Procházím další logy a ty průběhy jsou dost podobné. Dobu nic, pak skok z 0.0 na cca 0.25m, vzlet do 0.8m, usazení do 0.7m, klesání a oscilace pro měření pod 0.2m.

Ještě jeden graf z pokusu s přivázaným magnetem na přední kameře drony v kombinaci s ctrl_state (děleno 5, by obě křivky byly dobře vidět):

přistání s magnetem

Na všech pokusech se závažím je vidět „M-průběh”. Tj. zase vyletěl cca do 80cm, ale pak místo srovnání na 70cm propadl cca na 50cm. Teprve když znovu vystoupal (tady dokonce na 90cm), tak považoval start za úspěšný. Následuje 0.5s klesání a pak přistání vedoucí až do -40cm!

10. duben 2013 — nové senzory

Včera dorazily nové senzory od Snail Instruments, konkrétně:

Na první pohled vypadají rozumně, i když teď už chápu Tomášův komentář: „Jsi nějak omezený velikostí a hmotností? U toho USB-ISS bych asi odpájel konektor a napájel tam rovnou kablík.” Na té drobné destičce je totiž velký USB B konektor, jaký býval u USB tiskáren, a pro zapojení do AR Drone 2.0 nebudete chtít použít ani nabízený 0.5m kabel.

Rozchození pod windows nebylo tak triviální, jak jsem si původně představoval :-(. Zkusil jsem to slepě v Pythonu, z nově vzniklého COM19 přečíst verzi a nic:

>>> import serial
>>> com = serial.Serial('COM19', 19200)
>>> com.write(chr(0x5A))
>>> com.write(chr(0x01))
>>> com.read(3)

Tak jsem chtěl zkusit nabízený demo program, ale ten vyžaduje „MICROSOFT .NET FRAMEWORK 4”, který potřebuje 1.6GB volného místa a to nemám (a kdybych měl, tak nedám). Příklad zase chce „Visual C# Express 2010”, který též nemám. Na to, že chci zapsat 2 bajty a přečíst 3 mi to přijde trošku overkill …

Nicméně cesta existuje … USB-ISS Test.csproj lze otevřít i ve starém Visual Studiu a při kompilaci hlásí Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5". … zkompilovat to ale jde, pustit též, COM19 otevřít nejde … protože ho mám otevřený v Pythonu, ok … a je to . Found USB-ISS Version 4, Serial #00006479. Tak ještě proč to nefunguje v tom Pythonu?

Zatím vidím dva rozdíly: 1) nenastavuji dva stop bity, 2) neposílám to naráz … ale snad ani jedno by v tomto případě nemělo vadit?? Google napoví: Using the SRF02 Ultrasonic Ranger with Python (pyserial) a to funguje. Je tam asi nastaven timeout, jak dlouho se čeká po úvodním 0x5A, i když to v dokumentaci zatím nevidím. Fungující program tedy vypadá takto:

>>> import serial
>>> com = serial.Serial('COM19', baudrate=19200, parity=serial.PARITY_NONE,
           stopbits=serial.STOPBITS_TWO, bytesize=serial.EIGHTBITS, timeout=1 )
>>> com.write(chr(0x5A)+chr(0x01))
>>> com.read(3)

a na výstupu dostanete třeba jako já '\x07\x04@'.

Další krok je to rozchodit na Heidi. Jako první asi použiji nápovědy z fóra Adding sensors to an AR Drone 2.0.

12. duben 2013 — magnet a lsusb

Včera jsem byl Heidi představit Ondrovi se Zbyňkem a až mne zaskočila Ondrova první reakce: „Proč tam máš proboha tak velký a slabý magnet?” Věnoval mi dva malinké, na které USB Flash Disk doslova skočil cca do 5cm výšky … jo, jo, žádné složité uchopovací mechanismy, řeší to magnet na provázku. Včera jsem i viděl dronu poprvé USBčko nabrat — byl to jeden pokus z deseti a natočené to nemám (na druhou stranu mám dva svědky) … jako proof of concept myslím dobré.

Tématem pro včerejší „robotický čtvrtek” bylo něco zjistit o připojení dalších USB zařízeních a případně je rozchodit. Zkoušel jsem jednak připojit GPS GNS 5860 z práce a pak dříve zmiňovaný USB-ISS.

Dobrá zpráva je, že fungoval telnet i ftp. Sice jenom z mého notebooku, ale to mohlo být tím, že jsem z něj před tím dronu ovládal a tak ostatní spojení zamítala (?). U ftp ještě trošku matoucí bylo číslo portu. Na webu jsem viděl zmiňované 5551, ale to je pouze pro update firmware. Lepší je klasický port 21, kde naleznete soubor „police-notice.html.gz” (GNU LESSER GENERAL PUBLIC LICENSE) a adresaře „boxes” a „usb”. Na Heidi disku je to mapované ve stromě do adresáře /data/video/. Fungoval jak upload tak download, tak alespoň nějaká dobrá zpráva.

Špatná zpráva pak je, že USB zařízení nejsou vždy rozpoznaná a není pro ně nainstalovaný driver. Co je nutné udělat, aby „lsusb” vypsal i nově připojené zařízení zatím s jistotou nevím. Když to dobře dopadne, tak dostanete:

# lsusb
Bus 001 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc.
Bus 001 Device 001: ID 1d6b:0002
# lsusb
Bus 001 Device 003: ID 04d8:ffee Microchip Technology, Inc.
Bus 001 Device 001: ID 1d6b:0002

kde první příklad je GPS a druhý je převodník na USB (konektor je jenom jeden, takže po odpojení prvního zařízení a připojení druhého).

Zatím jediná cesta vypadá na cross-compilation s návodem např. na http://paparazzi.enac.fr/wiki/AR_Drone_2/GPS, ale na to už včera nezbyla síla. Driver přímo ke stažení jsme zatím nenašli.

… ehm, asi bych měl teď už začít pracovat … pokračování doma …

16. duben 2013 — The END

„Vzdal jsi to příliš brzy” mi, mimo jiné, řekl Ondra minulý čtvrtek a to ani nevěděl, že jsem to po dobu fandorama projektu vzdal hned několikrát…

Poprvé jsem to vzdal, když jsem vyplňoval formulař a vyskočilo mi, že zbývá 45 dní. Bylo to po neúspěšném AirRace projektu, na který ale bylo jen 5 dní. V obou případech to vycházelo 1000Kč/den, což mi přišlo nereálné.

Podruhé jsem to vzdal, když jsem koukal na videa z předešlých ročníků a viděl poloprázdnou tělocvičnu (resp. asi malou sportovní halu), trápící se studenty a takovou všelijakou konstrukci Potěmkinovi budovy. Nic, co by připomínalo třeba Eurobot před deseti lety. Spíše jsem si vybavil SICK Robot Day.

Potřetí jsem to vzdal, když jsem studoval dostupné materiály vítězného MIT týmu páté mise. Psali, že kamera byla téměř nepoužitelná a tak se opírali především o laserový dálkoměr za $5000, což při dnešním kurzu vychází zhruba na 100000Kč. Zároveň mi nebylo jasné, proč se nezúčastnili i šesté mise, kterou by asi rovnou vyhráli.

Čtvrté zaváhání asi bylo po drobné diskusi se ženou, když jsem jí soutěž líčil … a od té doby jsem IARC už raději moc nezmiňoval . Holt vidí lépe souvislosti a zároveň mne zná a ví, že to nebyl jen vtip.

Pátý pád do deprese nastal ve čtvrtek večer, kdy jsem zjišťoval aktuální ceny letenek a kurz dolaru. Srpen je nejvyšší sezóna a tak mi nejlevnější zpáteční letenka pro jednu osobu vyšla na 29 125 CZK + 20000Kč za registraci … prostě náklady bez ubytování, stravování, půjčení auta už vycházely na 80000Kč.

Fandorama projekt skončil, ale přesto jsem to ještě nevzdal úplně. I tak vám moc děkuji za podporu — nasbírala se zatím nejvyšší částka, posunula se zatím nejvyšší jednorázová platba a mne jste vyhecovali k dalším krokům, do kterých se mi třeba 2x moc nechtělo .

Pokud bych nyní měl ocenit šance na vítězství, tak bych místo toho raději odhadoval šance na splnění mise. Těžko říci, jak jsou na tom soupeři, ale mají několik let náskok a stejně jako ve Vídni co stačilo loni na vítězství už nemusí být dostatečné letos. Přijde mi, že se to s AR Drone 2.0 a pár senzory (celkově do 10000Kč) realizovat dá. Možná je dokonce výhoda, že je Heidi 3x lehčí než MIT stroj a v extrému by bylo možné rovnou nasadit tři čtyřtulky zapojené do společné sítě, jak o tom psal Jarda Halgašík (nepouštěl bych se do toho, ale když už by se človek nudil, tak toto by asi byl další krok, jak prohledávání budovy urychlit).

Tak ta čísla? Šance asi 10% a přesunul bych to z „Mission Impossible” do škatulky „Mission Possible”. Ignoruju-li soupeře, tak při nákladech 80kkč a vítězství 800kkč ($40000) to vypadá 50:50 … ale náklady budou vyšší a dokončená mise ještě není vítězství. Na druhou stranu věřím, že to letos někdo dokončí a tipoval bych nějaký čínský tým, tj. když nevyrazit teď, tak už nikdy …

Tento blog končí … kam dál? Vypsal jsem další fandorama projekt na RoboOrienteering a pokud se nějak rozjede, tak bych tam asi sepisoval další pokusy se senzory a testování venku. Heidi už je přihlášená na soutěž Robotem Rovně do Písku, i když tam v prvním kole plánuji kód jako

drone = ARDrone2()
drone.takeoff()
drone.moveForward(380)
drone.hover(1.0)
drone.land()

… ty metry musím upřesnit.

p.s. teď čtu maily a je mezi nimi i jedna prosba, abychom místo vracení částky z ukončeného IARC projektu ji rovnou přesunuli na RoboOrienteering, takže už se to odlepilo a můžeme létat dál

------------ THE END ------------

kontaktní formulář