Katarina
fandorama článek/blog
Další hračka od Parrotu, tentokráte čtyřtulka Bebop. Úloha je rozchodit sledování barevné čepice, jako to uměla stará AR Drone 2. Na první pohled je Bebop více profi — součastí balení jsou nahradní baterky, vrtule, GPS, full HD kamera, 8x výkonější počítač, 14 megapixels “Fisheye” foťák, uživatelsky polohovatelná kamera v intervalu 180 stupňů … no jsem zvědav jak to půjde z Pythonu . Blog update: 21/4 — Skrytá kamera a Nao
Toto je další z fandorama blogů o testování a prvních
zkušenostech tetokrát s Parrot Bebop drone
(pracovní název Katarina … říkal jsem si, že to bude hukot a chtěl jí
pojmenovat Katrina, ale pak
se mi jí zželelo, dávat jí do vínku tolik destrukce)
Chcete-li si přečíst celý blog o rozchození Katariny podpořte tento projekt.
Stejně jako minidronu Jessica zapůjčil
český distributor Parrotu. Díky
Zde je odpovídající fandorama link:
p.s. jsem zvědav, jestli Bebop české publikum zaujme, nebo mi náladu budou
muset zase zlepšovat Japonci (viz
Jessica github Stargazers)
Odkazy:
- Stránky českého prodejce: http://www.icornerhightech.cz/
- Parrot Bebop
- Parrot Bebop Drone Hacking
- ARDroneSDK3
Blog
31. leden 2015 — Hukot i bez létání
Dnes jsem Bebop/Katarinu poprvé zapnul. A byl to hukot . Zatím nikoliv od
vrtulí, ale nejspíše od chlazení řídícího počítače. Budí to respekt.
Aplikace Free Flight 3 (FF3) se mi odmítla nainstalovat na pracovní tablet
(prý pro nedostatek místa), ale na telefonu běžela. Raději jsem ji rovnou
upgradeoval — skoro to vypadalo, že ta starší verze podporovala pouze
Rolling Spider a'la Jessica a Jumping Sumo. První
obrázky z kamery krásné, ale kam se uložily zatím netuším.
Jako první příručku jsem použil Parrot
Bebop Drone Hacking. Potvrzuji, že i u Parrotu mají vývojáři rádi
číslo 42, tj. IP drony je
192.168.42.1. Fungoval telnet, podíval jsem se do ftp zóny a
přečetl si i pár NMEA vět z GPSky:
/ # cat /dev/ttyPA1 GNRMC,104229.986,V,0000.0000,N,00000.0000,E,0.00,N,00000.0000,E,NNN,00,,-18.0,18.0,,,V*64 GNGST,104229.986,,,,,,,*5C GNGSA,A,1,,,,,,,,,,,,,,,,1*1D GPGSV,3,1,12,01,84,173,31,07,66,244,1,63,176,,04,54,145,,1*6A
Celkem mne navnadil popis „černé skříňky”
(/data/ftp/internal_000/blackbox), která podle všeho obsahuje stejné
informace jako stará AR Drone 2 jen v trošku jiném formátu
(129 sloupců dat logovaných na 200Hz).
Klasická otázka: „jak to vypnout?” … viz
fórum pro nováčky —
stačí zadní tlačítko krátce zmáčknout.
Katarina se po spuštění FF3 chtěla rovnou automaticky kalibrovat. Předpokládám,
že je to sekvence jako u staré drony, tj. tanec ve vzduchu s otáčením o 360
stupňů. Na to teď tady není prostor, tak možná později venku.
Zkoušel jsem ještě, zda funguje video kanál jako dříve a zatím neúspěšně
(nefunguje ani port 5555, ani 5553 ani 43210).
6. únor 2015 — github
Musím přiznat, že psaní české verze mi jde nějak ztuha. Proč? No když jsem
zveřejnil i anglickou verzi, tak mi do dvou hodin přišel mail od Darryla
(amík?), že narazil na stránky spíše omylem přes Jessicu a
jak je to skvělé, že si s tím hraji a jak je SDK od Parrotu nečitelné atd.
Tady vůbec netuším, zda někdo Bebopa má a z nedávných zkušeností soudím, že o
to moc zájem není/nebude.
Ve zkratce: podařilo se mi s dronou navázat spojení, jsem schopen dekódovat
většinu zpráv co posílá, ale zatím jsem ještě nevzlétl ani nezískal
video/foto.
18. únor 2015 — viz anglická verze
Již moc nevěřím, že by prošel tento fandorama projekt. Aleš, kterému díky
za mail s komentáři, má asi pravdu, že je to relativně drahá hračka a moc
nadšených českých robotiků si jí nekoupí (25kkč s dálkovým ovládáním do 2km,
nebo 14kkč jenom Bebop samotný).
Nabídka navíc neustále roste (Aleš zmiňoval
ZANO,
s úspěchem na Kickstarteru), takže to je těžké.
Možná někteří z vás zaznamenali, že blog v angličtině obsahuje řádově více
informací … tak pro ty ostatní, kteří přišli později … viz anglická verze.
Katarina už umí číst video stream, na rozdíl od ARDrone2 je kombinovaný s
navigačními daty, umí potvrzovat přijaté zprávy a je skoro připravena na první
autonomní takeoff().
23. únor 2015 — Fandorama
To mi to Ondra zavařil!!! Už jsem za tu dobu zapomněl, že není
dobré dávat konec fandorama projektů na víkend. Banky
nefungují a čítač nezobrazuje aktuální stav konta. Katarinu jsem zrušil z
titulní stránky … a teď bych jí měl zase vrátit. Zatím netuším přání jejího
jediného stoupence.
Jaký je stav? S ARDrone3 už se lze létat s kódem na
githubu. Je to celkem adrenalinová
zábava. Přestože jsem v obýváku vyklidil nábytek, aby se dalo testovat, tak v
hover-stavu opakovaně „plavala” nalevo. Že je to opakovaně mi došlo až časem
— vyřešil to trim() před startem.
Příklad kódu:
robot = Bebop() robot.videoEnable() robot.trim() robot.takeoff() robot.land()
ARDrone3, na rozdíl od předešlé verze, pracuje trošku jinak s videem. Zatím co
na Heidi stačilo otevřít TCP spojení a číst, Bebop,
Rolling Spider a Jumping Sumo řeší vše přes jedno jediné
spojení. Video je opět posíláno v H.264 codecu, ale každý I nebo P frame je
rozkouskován až na 128 dílů velikosti cca 1kB. Je nutné se starat o jejich
setřídění a potvrzování. To je realizováno 128bitovým číslem, kdy přijaté díly
mají nastavenou jedničku. Tak toto mi už celkem pěkně funguje.
Video lze zatím přehrávat pouze off-line pomocí
play.py … není
zapojena žádná funkce, která by kousky skládala za letu a předávala procesu na
zpracování obrazu.
Ke droně se lze připojit také telnetem a ftp. Z toho co jsem viděl mne zatím
nejvíce dráždí adresář scripts … že by bylo možné přímo na dronu
uploadovat nějaké prográmky?! To by bylo něco.
O čem teď bloumám je rozpoznávání a sledování dvojbarevné čepice:
Nápady jsou vítané . Důležitá je určitě kombinace oranžové se zelenou, ale
jestli nejprve všechny pixely klasifikovat a teprve pak hledat přechody??
25. únor 2015 — Čepice a capdet.py
Dnes jsem zaspal, tak alespoň krátce …
Začal jsem experimentovat s detekcí dvojbarevné čepice. Používám pravidlo:
„když nevíš, zkus něco triviálního”, tj. koukám jak vypadají barvy čepice
vůči okolí.
Vzpomínám si, jak na workshopu Robotour
2014 Jirka mluvil o důležitosti klikacích nástrojů … a tak jsem si také
jeden vyzoušel
capdet.py,
který zobrazoval všechny výskyty dané barvy a po
drobné
úpravě i barvy z blízkého okolí definované poloměrem (spíše polovinou
strany krychle) rad=10.
Na této obrazovce (nerad dělám celoobrazovkový "PrintScreen", ale tady mají
smysl všechny čtyři okna), je vidět původní obrázek vpravo nahoře, jeho HSV
konverze vlevo nahoře, pak dosud naklikané barvičky a v pravo dole "terminal",
kam se vypisuji souřadnice a hodnoty barev. Troufnl jsem si rozlišovat zelenou
od oranžové: pokud je barevná složka v G větší než R a B, tak je to
zelená, jinak oranžová:
if col[1] > max(col[0],col[2]):
imgResult[mask] = (0,255,0) # green
else:
imgResult[mask] = (0,128,255) # orange
Za zmínku asi také stojí bitové operace nad NumPy polem, konkrétně
np.logical_and:
maskB = np.logical_and( imgB < col[0]+rad, imgB > col[0]-rad )
… toto vytvoří Boolean pole, kde True je pouze u prvků z daného okolí v
modré složce.
Jinak s NumPy maskou jsem si včera odpoledne trošku naběhl (bylo to na robotu
Husky a kód pro
Follow
Me, případně video). Ona ta maska z
vícerozměrného pole udělá jednorozměrné a operace jako arr[mask].min() jsou
v pořádku, ale běda u arr[mask].argmin(), která vrací index, kde se daný
minimální prvek vyskytuje:
>>> import numpy as np >>> a = np.array([2,0,3]) >>> a array([2, 0, 3]) >>> a.argmin() 1 >>> mask = a > 0 >>> a[mask].argmin() 0 >>> a[mask].argmax() 1
Je to pořadí prvku, které splňují danou masku. Rozhodně tedy pak není dobrý
nápad slepě usuzovat na pozici prvku z návratové hodnoty, když nevíte kolik
prvky bylo „odmaskovaných” …
Co se detekce čepice týče, tak jsem ještě přemýšlel, jestli by nestačilo hledat
oblasti s dominancí červené a dominancí zelené a jejich přechody. Ale to by asi
byly moc velké plochy??
Ještě jsem nezmínil proč to HSV
(hue-saturation-value). To je zatím příprava. Skoro v každém článku se
dočtete, že dělat min/max barev v RGB není dobrý nápad, ale že v HSV to dopadne
celkem rozumně. Možná si vystačím i bez toho, nevím.
26. únor 2015 — Kontury čepice
Dnes to není žádná krása (viz
diff),
ale nechť to jsou ty třísky co lítají při kácení lesa. Původní klikátko
capdet.py jsem teď „lehce” zašpinil několika natvrdo vybranými barvami
oranžové a zelené — ano, mohl jsem to číst ze souboru … a asi měl. Šlo mi o
to, abych rychle měl stále stejné zadání a mohl experimentovat.
Co tím hackováním zkouším? Myšlenka je následující:
- pro vybrané oranžové a zelené barvy vytvořím černobílou masku
- trošku jí nafouknu pomocí dilate, aby se mi spojili jednotlivé díly čepice
- hledám kontury, kde mne zajímají jen bílé objekty (s tím jsem si myslím už jednou naběhl, když byl daný objekt na hranici obrázku … no uvidíme … mluvím o oriented=True)
- pro danou vyplněnou konturu spočítám podíl oranžové barvy
Příklad:
Výsledky [plocha, počet oranžových, podíl oranžových]:
3139.5 1854 0.590539894888 51.5 3 0.0582524271845
Na první pohled to nevypadá špatně. Asi bych mohl odfiltrovat malé body pomocí
erode(), ale bojím se, abych nepřišel o „švy” čepice. Plán je vylepšit
klasifikaci barev a pak to pustit na testovací videa. Výsledkem by měly být
odhady na požadovaný podíl barev (59% mi přijde pěkné) a nějaké min/max
velikosti. V dalším asi mohu zkoumat pod-objekty, případně tvar čepice. To
asi ale nechám až narazím (viděl jsem včera v květinářství krásný protipříklad
barevných mističek pod květináč … to by Katarinu určitě spletlo).
Jinak z poznámek pod čarou — nepodařilo se mi rozumně nakreslit masku
kontury, tak jsem jí nejprve nakreslil do šedotonového obrázku a pak definoval
jako mask = tmpMask > 0. Ono by to asi šlo, ale ty bitové obrázky nutně
nefungují všude (pamatují Honzu a pokusy s RasPy na
SICK Robot Day 2014).
Co se mi ale zase celkem líbilo je počítání oranžových pixelů pro danou
oblast. Rozhodnutí, zda je pixel zelený nebo oranžový dělám porovnáním R a G
složky:
cmpRG = imgR > imgG orange = np.count_nonzero(np.logical_and( mask, cmpRG ))
kde mask je vybraná oblast kontury a imgR a imgG jsou výsledkem
cv2.split(img).
27. únor 2015 — Editace barev z videa
Včera večer jsem brousil nástroje. Nejprve jsem upravil hack s tabulkou barev a
předělal to na externí soubor
(diff),
který podporuje i komentáře a mix copy a paste barev s čárkami a '[' a ']'.
Poté jsem to skoro celé smazal a přeházel
(diff),
aby detektor byla pouze jedna jediná funkce a mohl jsem zkoušet chování na
videu. Barvy stále používám jako vzorky s okolím, tj. pole barev, které
nejprve v obrázku „vybarvuji”. Je to možná pomalé, ale umožňuje mi to lepší
editaci — mezerníkem zastavuji video, klikáním přidávám barvy a Backspace
odebírám poslední přidanou barvu. Barvy se vypisují do terminálu, takže je můžu,
když chci, snadno přidat do vzorového souboru
cap-colors.txt.
Konečně přes ESCape, lze program předčasně ukončit.
Asi největší problémy dělají tmavé barvy, resp. tam pro jejich okolí přibude
příliš mnoho kandidátů. Zvažuji, zda detekované jasné barvy pak ještě
nenafukovat „hraničními”, ale … není to teď kritické. Důležité je to
rozběhat za letu, to znamená poskládat a utřídit H.264 kousky a získat obrázek.
Na to ale budu muset zatáhnout do projektu Céčkovou knihovnu (použitá byla už
na Heidi-cvideo).
Dříve se mi nepodařilo OpenCV přesvědčit, aby akceptovalo postupně buffery s
daty :-(. Na druhou stranu jsem včera zjistil, ze i obyčejný JPEG snímek lze
otevřít jako video. Po pravdě IF jsem tam nakonec přidal
(kód),
protože video jsem chtěl rovnou spustit přehrávat, ale jednotlivé snímky
„pustit zastavené”.
Teď bych revidoval příjem videa. U každého je výpadek a následná duplicita
několika paketů, tak jestli tam nemám ještě nějakou chybu. Následně chybí i
několik snímků — že by Python nestíhal vyčítat data po síti? Nebo je třeba
posílat ještě nějaké extra časové známky??
1. březen 2015 — Víkendové testování
Přemýšlím, co z toho je zveřejnitelné. Vzpomínkám dominuje poslední start, než
v neděli začalo pršet: Katarina se vznesla, hodila assert (kterého jsem si
nevšiml), přesunula se nad svah a jabloně, udělala jarní řez bříze a spadla
vrtulemi směrem dolu. Asi. Byl jsem tak konsternovaný, že tento detail si už
pořádně nevybavím.
Když jsem kód opravil (ty asserty se hodí při ladění, ale v letu to fakt není
dobrý nápad)
(diff),
tak už lilo :-(, takže základní poletování nahoru a dolů jsem v reálu funkční
neviděl.
A co se tedy stalo? Drona poslala zprávu ARCOMMANDS_ID_PROJECT_COMMON = 0,
na kterou jsem měl assert, abych si jí všiml, až nějaká bude. A jak vidíte,
trvalo to skoro měsíc, než přišla první! Navíc její obsah mne dost zklamal:
02 7F 61 0D 00 00 00 00 05 07 00 D4 FF
tj. ARCOMMANDS_ID_COMMON_COMMONSTATE_CMD_WIFISIGNALCHANGED s popiskem
RSSI of the signal between controller and the product (in dbm). Ta hodnota
byla 1280 a vůbec netuším, co tím autoři chtěli říci.
Že se mírně odsunula nad svah mohla být zase nepřesná kalibrace, přeci jenom ta
tráva není úplně v rovině. Zvláštní ale bylo, jak se drona zvedla ještě více do
výšky — myslel jsem, že běží můj kód, ale spíše detekovala koruny stromů
sonarem/spodní kamerou a upravila to na 1 meter „nad”.
Přemýšlím, zda uploadovat to video … ona jedna z věcí, co jsem o víkendu
rozchodil bylo zapínaní automatického nahrávání, tj. i když jsem ztratil
komunikaci sama dál nahrávala co se děje
(autorecording
diff). Vtipné je, že na tom videu není pád vůbec vidět!!! Ta softwareová
kompenzace náklonu si s tím poradila. Už jsem to viděl na
tomto
videu, kdy drona dělá kotrmelce a z nahrávaného videa to nepoznáte …
Ne, není to publikovatelné … zas taková sranda to není (let trval 15s), sigh.
Ale přežila to a vypadá, že i bez větších šrámů … padla do trávy.
A co jinak? Začaly mi chodit GPS data, dokonce debug info o počtu satelitů
(diff).
„Indiáni” jsou v pořádku, tj. GPS souřadnice dávají rovnou smysl.
Udělal jsem také několik fotek pomocí drone.takePicture() — ukládají se
zase lokálně a mají rozlišení 4096x3072. V názvu souboru je datum a čas, který
se ale z GPS automaticky neupravuje, tj. 1/1/1970.
2. březen 2015 — metalog.now()
Dneska jsem nějaký unavený. Zadrátoval jsem do startovní konfigurace
nastavování času
(diff),
protože už mne štvalo, že je vše z roku 1970 a není tedy poznat co je nové a co
staré. Zlobilo nějak nastavování času — má tam být prý ISO-8601 formát, ale
asi zlobily milisekundy. Naformátoval jsem si to tedy po svém a už to funguje.
Zde je příklad snímku Bebop_Drone_2015-03-02T201736+0000_.jpg.
Možná za zmínku stojí to zjištění aktuálního času a data. Kdybych to používal
ze systému pomocí datetime.datetime.now() tak se mi rozbije přehrávání
logů. A na to jsem hrozně alergický . Řešení je logovat i každý podobný
dotaz (zavolám ho 1x, takže to není žádné drama) a nechal jsem třídu
MetaLog, aby se o to starala. A funguje to dobře.
Do gitu jsem také dal ignorování assertu při parsování dat
(diff).
Jestli jste četli report ze včerejška, tak tušíte proč. Ono ty asserty jsou
užitečné, ale jenom když si pak log v klidu přehrávám, tj. možná
try..except ještě obalím podmínkou, zda přehrávám … ale možná ne.
Začal jsem ráno také pracovat na integraci všech kousků (zatím jedno-vláknitě),
ale více o demo.py
až to začne něco dělat …
p.s. Pavel S. mi poslal video o
automatickém přistání Ardu Copter — jó, to by se mi také líbilo …
lepší než větve břízy.
3. březen 2015 — roll, pitch a yaw
Kdy já už se konečně naučím, co z toho je co? Dnes jsem lítal ve škole.
Nakonec jenom po budově a to ještě malinko, ale … nějaký mikro-progres je
snad vidět.
Začal jsem s triviálním testFying:
robot.trim() robot.takeoff() robot.flyToAltitude( 2.0 ) robot.wait( 2.0 ) robot.flyToAltitude( 1.0 ) robot.land()
Při prvním pokusu to spadlo ve funkci wait(). Volal jsem tam
self.update() bez parametrů, které ale byly vyžadované. Chytnout, otočit
vzhůru nohama (naštěstí do dvou metrů dosáhnu), fix a znova.
Při druhém letu to spadlo na klesání:
File "M:\git\ARDroneSDK3\katarina\commands.py", line 39, in movePCMDCmd
return struct.pack("BBHBBBBBf", 1, 0, 2, flag, roll, pitch, yaw, gaz, psi )
struct.error: ubyte format requires 0 <= number <= 255
No jo no, mají tam být znaménkové bity
(diff).
Jako další test jsem chtěl nahrát let chodbou. Nevím jaká je má skrytá
motivace, ale drona co systematicky prolétává koridory a straší děti mi asi
přijde cool . Ale chyba lávky. Nějak mi zlobí nahrávání videa. Když
jsem koukal přes telnet na velikost volného místa, tak vše bylo zaplněné —
asi ty pády programu z předešlých testů. Prostě to stále nahrávalo video, dokud
nedošlo místo??? Teď je vhodná chvíle na revizi všech logů …
Jo a ten titulek! Já si stále nepamatuji, co z těch třech slov je náklon
dopředu … mám i pocit, že na toto téma už je na robotice stažený pěkný
obrázek … tak nevím, asi myslím ten z
wikipedie. Ono když mi
Katarina systematicky uhýbala vlevo, tak jsem zkusil změnit druhý parametr a
pak už letěla skoro rovně vpřed.
První log bez videa — ani ťuk zajímavosti :-(. Tedy alespoň je vidět, jak se
mění rychlost, takže bude možné doplnit nějakou „pseudo-regulaci”.
Tak obráceně — poslední log se záznamem videa … prostě ho přestal v půlce
letu posílat, bez jakékoliv notifikace :-(. Tomu moc nerozumím.
4. březen 2015 — opraveno nahrávání videa
Ano, byla to samozřejmě moje chyba. Pustil jsem si teď dronu „na dobrou noc”
s tím, že jsem zrušil automatické spouštění videa ve startovní konfiguraci a
změnil to na ruční zapnutí při takeoff() a vypnutí u land(). Přidal jsem
testovací rutinu … a nic. Nic to nenahrálo, ale na
/data/ftp/internal_000/Bebop_Drone/media/ leželo divné video, které jsem
tam včera neviděl. Prostě po prvním startu se spustilo nahrávání a nahrávalo se
dokud jsem to nevypnul. Je tam tedy i krátký (poslední) let chodbou:
A jakou chybu jsem udělal? Pro zapínání a vypínání videa je enum, což ale
znamená 4 bajty :-( … a já tam měl jenom jeden bajt
(diff).
5. březen 2015 — OpenCV okno
Dnes jenom takový „štěk”, něco jako rada, že není dobré si svítit zapálenou
sirkou, aby jste zjistili, kolik máte v nádrži benzínu … prostě věděl jsem to,
přišel domu unavený, ale zkusil alespoň jednou odstartovat než bude moc pozdě
… a zapomněl na dříve „potenciální”, později „reálný” problém s otevřeným
OpenCV oknem přehrávajícím živé video.
Modří už tuší, co červení? Jo, to okno převezme focus, takže pak můžete mačkat
ANY KEY a žádný Emergency STOP se nekoná. Ono by stačilo si prohodit okna, ale
v těch pár sekundách (cca 1.5s) člověk moc racionálně neuvažuje. Reflex už
byl vystartovat po droně než narazí do topení a otočit ji vzhůru nohama. Teprve
pak mi došlo, v čem byl problém.
9. březen 2015 — video problémy
O víkendu bylo krásně a zbylo i trošku času na létání. Chtěl jsem znova zkusit
demo.py, které by
sledovalo kšiltovku. V první variantě Katarina vzlétne a jenom „pohybem
očí” sleduje cíl z místa. Ve druhé variantně se pak za cílem otáčí.
V realitě to bouchlo už při prvním startu:
File "M:\git\ARDroneSDK3\katarina\bebop.py", line 106, in update
data = self._update( createVideoAckPacket(data) )
File "M:\git\ARDroneSDK3\katarina\navdata.py", line 321, in createVideoAckPacket
assert fragmentsPerFrame < 64, fragmentsPerFrame # lazyness, to get started
AssertionError: 81
… ta lenost je hrozná věc . Navíc oprava byla hotova a vyzkoušena za pár
minut
(diff)
… ale ono dříve bych neměl testovací příklady. Tady byly a bylo jich hodně.
Hned další let přišel snímek 69, 74 a mám pocit, že jsem viděl i 92 dílků.
Vypadá to, že oprava funguje a dostávám celé i velké snímky (typicky
I-frame).
Co je tedy problém? Přestávalo mi chodit video. Podle logů jsem udělal 10
pokusů. Selhání u prvního pokusu je jasné — je fakt, že nahrávání se spustilo
a díky assertu už nevypnulo, tj. trošku delší 1.4GB video.
Druhé video chybí, ale podle časů ve jménech souborů vidím, že příkaz stop
video funguje. Stejně tak se i video průběžně posílalo ke zpracování. OK
Třetí video by bylo bývalo v pořádku, až na detail při přistání. Katarina
nalétala trošku na skleník (ano, po minulém víkendu jsem se poučil a
testuji jenom na „robo-louce”) a tak jsem přistál. Přistála ale asi do 10cm
trávy a nechtěla se vypnout. V logu jsou nepříjemné hlášky jako:
Altitude -0.50595164299
Asi by to chtělo trávu posekat nebo alespoň naučit Katarinu se vracet na
místo/základnu …
Po tomto pokusu jsem dronu zvedl a „zakroutil jí krkem” — ano myslím tím
otočením vzhůru nohama, emergency a STOP. Hele, jestli právě toto není důvod,
proč mi pak neposílá video??! Ne, v následujícím pokusu ještě pár (doslova, 2x
I-frame a 5+1 P-frame) snímků poslala. Je fakt, že 71-dílný snímek posílala ve
třech průchodech (normální, opravy a opravy oprav) a následující P-frame musela
také opravovat:
… Video 48 1 64 71 GPSDebugState, numSat = 8 Video 49 0 0 12 Video 49 0 1 12 Video 49 0 2 12 Video 49 0 3 12 Video 49 0 4 12 Video 49 0 5 12 Video 49 0 6 12 Video 49 0 7 12 Video 49 0 8 12 Video 49 0 9 12 GPSDebugState, numSat = 6 GPSDebugState, numSat = 6 GPSDebugState, numSat = 7 GPSDebugState, numSat = 7 GPSDebugState, numSat = 7 Video 49 0 0 12 Video 49 0 10 12 Video 49 0 11 12
… trošku to vypadá, že GPS status to rozhodí a pak už nepřišlo nic. Nikdy,
až do vypnutí a testu druhý den. Je tedy potřeba video znova povolovat?? I v
dalším logu na začátku vidím Video Enabled State 0 enabled (je to enum, kde
hodnota 0 znamená enabled), tj. vše by mělo být OK?!
Druhý den jsem přidal nastavování konfigurace, že jsem venku a používám
ochranný štít
(diff),
ale přišlo mi, že to stabilitě nijak nepomohlo.
Teď koukám na první pokus z neděle a tam je dokonce 101 dílků … jo, asi
bylo opravdu na čase přejít od 64-bit potvrzování na 128-bit. Je zvláštní, jak
je ten indoor fádní a bohatě si s 64 bity vystačí.
Ono to jenom vypadalo, že to funguje. Video přestalo posílat po skončení
takeoff(). Pak další dva starty nic a teprve po výměně baterky zase chvíli
pár snímků :-(.
Picture State Changed: 1 0
Co tím autor míní? A přišlo to cca 10x krátce po poslání příkazu k
odstartování. Nevím. Podle ARDrone3_commands.xml to znamená, že v
PictureStateChanged 1 if picture has been taken a ta 0 je Mass
storage id where the picture was recorded … ale já žádný snímek nedělal?!
Myslí automatický náhled pro video??
V tomto posledním pokusu se spojení „kouslo”. Přestaly chodit data. Aktuální
plán je odsunout video zpracování do vlastního procesu a přidat timeout na
spojení, i když zatím nevím co dělat pokud k němu dojde.
9./10. březen 2015 — Hledá se Bebop (Blansko)
Dnes jsem dostal první česky psaný mail od jednoho majitele Bebopa . Bohužel
možná bývalého :-(. Radimův Bebop totiž uletěl (na severu Blanska). Netuším
kolik lidí z této oblasti čte robotika.cz … asi 0.
Pokud přeci jenom někdo najdete Bebopa, dejte mi vědět a přepošlu mail majiteli
…
V první fázi mi zamrazilo, jestli nebyl řízen mým kódem … ale asi chyba
Free Flight 3. Spojení se přerušilo v náklonu a Bebop uletěl přes pole …
a po minutě asi došla baterka. Nebo si špatně definoval Home. Darryl také
psal: Since the latest Firmware update from Parrot, GPS, with the associated
"Return-To-Home (RTH)" feature have become unreliable/unusable, and has even
caused several "fly-a way's" according to the forum. It's hard to say exactly
where the issues are, either Firmware, or Free Flight App, but I have a
feeling it's actually the Free Flight App. … těžko říci, jenom papouškuji.
11. březen 2015 — Fórum - Holy Crap!
„Trošku” se trápím s tím H264 kodkem pro
Katarinu a tak jsem si dovolil (a to jsem si asi dovolil dost) pro zlepšení
nálady „hodit návnadu” na
britské fórum
Parrotu. Nešťastník se sháněl po dokumentaci a tak jsem ho odkázal na
github Katariny. No a před chvílí se
ozval EnderFFX, že to četl a dal na
americké fórum …
titulek „Holy Crap, Details about Bebop Protocol, did anyone notice ?”
… je čas jít se psem a spát.
15. březen 2015 — Oriented Roundel
Američan, Čech, Němec, Mexičan, Angličan, Francouz … možná to trošku
přerovnat a byl by to pěkný úvod k nějakému vtipu . Nedělám si iluze, ale
třeba se nakonec najde někdo na světě, kdo ten kód také zkusí. V každém případě
při vzpomínce na
Darrylův
komentář na americkém fóru se musím vždy zasmát (až to přejde v záchvat
kašle).
Něco nového? Poskládal jsem „dokument”
Parrot
Bebop Protocol — je to spíše přehled základních informací, co jsem
o Bebopu/Katarině zjistil. Asi je to lepší začátek než odkazovat na Pythonovský
kód, resp. takové doplnění, které v oficiálním SDK zatím stále chybí.
Víkend propršel a tak jsem udělal pár pokusů doma. Konkrétně se vracím k dva
roky starému problému přistání. Chci použít
Oriented
Roundel k definici přistávací základny. ARDrone2 ho automaticky detekovala
a posílala jeho pozici, ale pro novou dronu to bohužel neplátí. Nechci už
přepínat na spodní kameru (resp. mám pocit, že to u ARDrone3 vůbec nejde), tak
alespoň pár pokusů s
drone.moveCamera( tilt=-100, pan=0 )
Jenom pozorování, že dokud drona neodstartuje, tak stále posílá nulovou
rychlost a výšku, ale úhly jsou snad aktualizovány. V prvním testCamera(),
kdy jsem jenom sbíral obrázky data o pozici nebyly. A klasicky, když jsem
odstartoval, tak jsem zapomněl sklopit kameru dolu [ale jó, když jsem stáhl
videa a vše vypnul tak mi to došlo].
Přemýšlel jsem, kam takovýto kousek kódu dát. Až bude fungovat, tak asi nebude
úplně triviální a zároveň by to mohla být poslední scéna po běžném letu, nebo
jenom na nějaké tlačítko by se snažil chvíli hledat značku a teprve pak přistál
… Je to vlastně behavior z
tří-vrstvé
architektury, kterou jsme na přednáškách před mnoha lety doporučovali, ale
prakticky asi nikdy moc nepoužili. Tož adresář
behaviors (je
pěkné, že když na githubu do adresáře dáte README.md, tak ho automaticky
zobrazuje za seznamem souborů).
Kód
navigace
na krabici zatím nic nedělá. Volá na snímky osvědčený
MSER a pak
získané kontury aproximuje obdélníkem a časem i kruhem. Z trojkombinace
„klíčové dírky” by už snad vypadl jen jeden kandidát. No zatím mám problém ho
vůbec vidět.
Naházel jsem tři pokusy do jednoho videa,
jestli si chcete udělat lepší představu, co drona vidí, když se kouká (kamerou
směřující dopředu) směrem dolů . Možná značku trošku posunu a budu startovat
kolmo na oba symboly … ještě nevím. Nějaké nápady?
16. březen 2015 — BlackBox a NavData
To „zakázané ovoce” je vždycky problém … v případě Kateřiny Bebopové je to
modifikace souboru /data/dragon.conf. Jsou tam takové položky, kterým
prostě nelze odolat . Odkaz na
zdroj jsem dával už na začátku tohoto
blogu, ale včera jsem narazil ještě na zmínku na
americkém fóru a to už
bylo moc. Cvičně jsem nastavil jak blackbox_enable tak i navdata_enable
na true.
BlackBox fungoval. Vznikl soubor light_run_0, který během pár minut měl
53MB. Pak jsem zkoušel
blackbox_to_csv.py
(parametry nejsou úplně zřejmé … –csv <filename>). Vznikl podobně
veliký CSV soubor s 129ti sloupci: index, time_s, sensor_acc_raw_x_m_s2,
sensor_acc_raw_y_m_s2, sensor_acc_raw_z_m_s2, sensor_gyro_raw_x_rad_s,
sensor_gyro_raw_y_rad_s, sensor_gyro_raw_z_rad_s, sensor_mag_raw_x_mG,
sensor_mag_raw_y_mG, sensor_mag_raw_z_mG, phi_EST_rad, theta_EST_rad,
psi_EST_rad, gyro_filt_x_rad_s, gyro_filt_y_rad_s, gyro_filt_z_rad_s,
p_EST_rad_s, q_EST_rad_s, r_EST_rad_s, acc_x_EST_m_s2, acc_y_EST_m_s2,
acc_z_EST_m_s2, speed_horiz_x_m_s, speed_horiz_y_m_s, speed_horiz_z_m_s,
sensor_ultrasound_height_m, sensor_pressure_Pa, height_EST_m,
height_vision_m, sensor_vision_speed_x_m_s, sensor_vision_speed_y_m_s,
sensor_vision_speed_z_m_s, phi_REF_rad, theta_REF_rad, psi_REF_rad,
p_REF_rad_s, q_REF_rad_s, r_REF_rad_s, r_wanted_rad_s, motor_cmd_pitch,
motor_cmd_roll, motor_cmd_yaw, height_REF_m, height_REF_filt_m,
speed_z_REF_m_s, motor_cmd_height, motor_cmd_ff, motor_cmd_1_rpm,
motor_cmd_2_rpm, motor_cmd_3_rpm, motor_cmd_4_rpm, controler_state,
acc_bias_x_m_s2, acc_bias_y_m_s2, acc_bias_z_m_s2, gyro_bias_x_rad_s,
gyro_bias_y_rad_s, gyro_bias_z_rad_s, gyro_unbias_x_rad_s, gyro_unbias_y_rad_s,
gyro_unbias_z_rad_s, speed_body_x_m_s, speed_body_y_m_s, speed_body_z_m_s,
sensor_imu_ref_temperature_degC, sensor_imu_obs_temperature_degC,
sensor_barometer_temperature_degC, battery_dV, motor1_obs_speed_rpm,
motor2_obs_speed_rpm, motor3_obs_speed_rpm, motor4_obs_speed_rpm, BLDC_error,
BLDC_motors_fault, BLDC_status, BLDC_temperature_degC, calage_x_rad,
calage_y_rad, biais_pression_m, use_US, estimator_drone_position_m_x,
estimator_drone_position_m_y, estimator_drone_position_m_z,
estimator_psi_fused_rad, sensor_ultrasound_id, vision_indicator,
sensor_ultrasound_mode, magneto_bias_x, magneto_bias_y, magneto_bias_z,
magneto_radius, sensor_gps_flags, sensor_gps_latitude_deg,
sensor_gps_longitude_deg, sensor_gps_altitude_m, sensor_gps_speed_m_s,
sensor_gps_bearing_deg, sensor_gps_accuracy, sensor_gps_num_svs,
sensor_gps_used_in_fix_mask, heading_magneto_rad, magneto_calibration_state,
altitude_pression_m, altitude_pression_filt_m, dynamic_model_b,
dynamic_model_f0, dynamic_model_Cz, dynamic_model_rpm_eq, psi_VIDEOREF_rad,
airspeed_body_x_m_s, airspeed_body_y_m_s, airspeed_body_z_m_s, wind_body_x_m_s,
wind_body_y_m_s, wind_body_z_m_s, stateFlightPlan,
gpsDeviationPostionErrorLat_m, gpsDeviationPostionErrorLong_m,
gpsDeviationPostionErrorAlt_m, gpsLatitudeRelative_m, gpsLongitudeRelative_m,
gpsNorthSpeed_m_s, gpsEstSpeed_m_s, gpsDataOk, gpsNewValidData, battery_filt,
magneticDeclination_rad, magneticDeclinationLocked
No není to nádhera?!
Skoro bych řekl, že to jsou všechna data, jaká kdy posílala stará ARDrone2.
Proto ten muj „tik” s navdata. Pokud je drona schopna ukládaná data do černé
skřínky i posílat, tak by řízení mohlo být skoro 1:1. Ale zatím bez úspěchu.
Možná to chrlí na jiný port?? A možná i Jessica měla
podobné nastavení?
17. březen 2015 — Navdata zklamání
Tak to vypadá, že "navdata_enable" : true jenom zase ukládá nějaká data
přímo na droně. Vznikl soubor navdatasMykonos3 (70MB), ale je to vlastně
blackbox jenom textově, sloupce oddělené tabulátorem. Další zklamání jsem našel
na githubu: Access to
NavData. Nikolas od Parrotu tam potvrzuje, že ani Rolling Spider ani Bebop
navdata na 200Hz neposílají: If you refer to the full navdata/200Hz mode of
the AR.Drone and AR.Drone 2, this was a debug feature, which has been removed
in the new drones. :-(
18. březen 2015 — Kolečka a obdélníky
Dnes ráno jsem si trošku hrál se základními geometrickými tvary
(viz diff):
Přemýšlím, koho ten XP přístup, kdy nejprve to naprogramujete „špatně”, tj.
co nejjednodušeji, a teprve pak „pořádně”, tak rozčiloval. Jestli to byl
Zbyněk nebo kolegové v práci … nevím. Každopádně jsem měl málo času a tak
jsem to „schválně” naprogramoval „špatně”. Ale začal jsem psát i
unit
test, tj. superšpatné to zase nebylo .
A co jde? Je třeba najít značku přistávací plochy. Ta je kombinací kruhu a dvou
na sebe kolmých obdélníků. Zatím jsem z MSERu posbíral kandidáty, vybral si
takové, které alespoň ze 70% vyplňují nejmenší obklopující kruh či obdélník,
vyfiltroval duplicity a pak už jenom to rozhodnutí, co je a co není značka. A
tady jsem to zatím odflákl:
- když není ani jeden kruh nebo nejsou dva obdélníky, tak značka nenalezena
- jinak vrať spojnici středu prvního kruhu a druhého obdélníku
Možná se zeptáte, proč právě druhého obdélníku?! … protože jinak by ten
můj první unit test neprošel. Na druhou stranu už takto triviální
algoritmus by šel zapojit do zbytku navigačního kódu a kdybych byl hodně
drzý, tak s ním i odstartuji, abych nasbíral reálné protipříklady.
Jinak mám stále trápení s videem, které se po nějakém čase přestane posílat a v
dalších startech už vůbec nenaběhne :-(. Funguje pouze nahrávání, ale to pak
není vhodný vstup jako reference …
p.s. i v tak triviálním kódu lze udělat chybu (přehrávám si včerejší logy):
File "M:\git\ARDroneSDK3\katarina\behaviors\navbox.py", line 54, in matchCircRect
return (circles[0][0], rectangles[1][0])
IndexError: list index out of range
… opraveno.
20. březen 2015 — Sedm vteřin
Procházel jsem logy z úterního poletování a jediné co mi zatím přišlo podezřelé
je, že video se přestalo posílat vždy po sedmi vteřinách?! Počet snímků a
přenesených bloků byl různý a zhruba to odpovídalo okamžiku, kdy drona
vystoupala do 1.5m a přešla do „levitování”. Po přistání už video nenaběhlo.
Bylo nutné stroj vypnout a znova zapnout.
Chtělo by to další test, ale už je zase pozdě a není volný prostor. Když drona
jenom leží na stole, tak je schopná posílat video i několik minut (tedy
minimálně déle než 7 sekund). Je tam na 90% vazba na to létání, ale jaká?
Pro uklidnění jsem alespoň trošku vylepšil detekci přistávací plochy (viz
diff).
Konkrétně jsem chtěl ošetřit toto selhání:
Dosud jsem vybíral nejbližší obdélník velikosti průměru kruhu. Co jsem teď
doplnil je, že mne zajímá jenom podmnožina z okolí kruhu. Přidal jsem i pár
řádek na analýzu celého videa, místo jen jednotlivých snímků, a zpomalování
při úspěšné detekci … prostě to co se mi na podzim líbilo na SICK Robot Day
videu.
22. březen 2015 — PCMD @40Hz
Tak tento oříšek bych asi nerozlouskl :-(. V sobotu jsem přišel na způsob jak
nasimulovat výpadek videa bez létání (viz
diff).
Následně jsem test ještě zjednodušil
(diff),
tj. jakmile pošlu první PCMD příkaz, tak přijdu o video. A pak už se nevrátí
dokud Katarinu nevypnu a znova nezapnu.
Prima a teď jak to opravit?! Jsem rád, že jsem napsal na
ARDroneSKD3/libARCommands/issues
a k mému velkému překvapení mne dnes večer čekala odpověď:
When using the PCMDs, you should make sure that your send them with a fixed
frequency (we use 40Hz / 25ms in FreeFlight), even if you're sending the same
command every 25ms.
A change in the PCMD frequency is considered by the Bebop to be a "bad wifi"
indicator. In this case, the bebop will decrease the video bandwidth (up to a
"no video" condition if the indicator is really bad) in order to save the
bandwidth for the piloting commands. When the PCMD frequency become stable
again, the video bandwidth will rise again.
Pro neanglicky mluvící to ve zkratce znamená, že příkazy pohybu je třeba
posílat s pevnou frekvencí (Free Flight používá 40Hz) a pokud tomu tak není,
tak drona dojde k závěru, že je problém se spojením a minimalizuje počet
posílaných paketů až video vypne úplně.
To i vysvětluje, proč to fungovalo tak „na půl”. Když jsem stoupal do nějaké
výšky nebo letěl dopředu, tak to byl cyklus s pevným opakováním. Jak ale daný
blok skončil časování se rozbilo a už do vypnutí nenaběhlo :-(.
Napsal jsem malý hack s posílacím vláknem
(diff),
který Nikolasovu odpověď potvrzuje. Teď je třeba to nějak integrovat, aby šly
přehrávat logy a nepralo se více vláken o čítač u posílaných UDP paketů.
p.s. ráno mi došla ještě jedna hrozná chyba. Bebop protokol je trošku
„naruby”, kdy data ze senzorů přicházejí zřídka (5Hz) a je třeba posílat
často příkazy (40Hz) … a že jak mám update() smyčku „jako vždy”, čekej
na data a pak pošli příkaz, a to je zde špatně!
(fix).
Proč? Protože jako příkaz se počítá i potvrzení video paketu … a v kombinaci
s 40Hz mám konečně kompletní streamované video!
25. březen 2015 — Revize posílání příkazů
Zapojení vlákna posílajícího PCMD na 40Hz byla trošku otrava :-(. Ale je to teď
snad hotové
(diff).
Asi největší „problém” byla má neústupnost z deterministického přehrávání
logů … chtěl jsem jednak vědět jaké příkazy se přesně droně posílaly a dále
jaké příkazy jsem já předával z hlavního kódu k poslání. Je to zmatené? No,
když máte pevnou vysílací frekvenci a pošlete dva různé příkazy hned po sobě,
tak v závislosti na implementaci se pravděpodobně buď první ztratí nebo druhý
přijde do fronty a bude poslán „časem”. Vzhledem k tomu, že Katarina posíla
informace o stavu jen na 5Hz, tak asi nemá smysl chrlit řídící příkazy … a
navíc implementace bez fronty je snazší .
Do logovaných příkazů jsem přidal prefix INTERNAL_COMMAND_PREFIX a
EXTERNAL_COMMAND_PREFIX podle toho, jestli jsem příkaz já poslal externě nebo
samotné vlákno už mělo potřebu PCMD poslat. Externí PCMD příkazy také loguji,
ale pouze jako separátor, tj. jenom ověřuji, že daný blok sedí.
Malá perlička — celou dobu jsem posílal vadné PCMD!!! Příkaz pohybu se
totiž skládá z Booleanu (bajt) a čtyř dalších bajtů určující náklon nebo pohyb
nahoru/dolu, vpravo/vlevo. Poslední parametr je float (4 bajty) … a modří
už tuší, že na to je třeba dávat bacha, protože 5 není dělitelné 4 a tak se to
defaultně zarovná a celý příkaz má navíc tři bajty! On ten poslední parametr je
nepoužívaný (má znamenat azimut řídícího zařízení), takže jsou tam nuly a asi
to droně moc nevadilo. Minimálně příkazy akceptovala.
Když už mám oddělené posílací vlákno, tak jsem tam dodělal i to indexovaní
paketů v jednotlivých „kanálech”. Nyní je to poslední krok před posláním a
uživatel se o to už nemusí nijak starat. Tímto zmizely z navdata.py všechny
ty globální g_seq, g_seq2, g_seqAck, g_seqPongAck, g_seqVideoAck …
30. březen 2015 — Vybité baterky
V pátek jsem byl už nějaký vyřízený — ráno jsem oživoval
Arduino Uno s GPS a čtyřmi gyroskopy pro
jeden školní experiment, pak se snažil sepsat příklad pro dk863 ohledně
zpoždění videa a vznikl
video2stdout.py,
který streamuje Bebop video na stdout. Do toho v práci „záhada dvaceti
sedmi zákazů na španělské tranzitní křižovatce” … prostě bylo toho nějak
moc a těšil jsem se na víkend, až vysadím. Prostě programátor na baterky
Na toto téma mne celkem zaujalo
4.
doporučení Romana Staňka: v sobotu nepracujte . [Forbes nám minulý
týden poslal odkaz na článek
Lidem
nakonec pravděpodobně zakážou řídit auta, ale ten mne až tak nezaujal …
ostatně to tušíme všichni, když i
Apple
hledá robo-programátory a i spřátelené robotauto na tom již
pracuje na plný úvazek …]
Aby alespoň něco málo relevantního k Bebopovi, tak Vincent poslal link, jak
upravit nastavení komprese videa … minimálně musím ocenit jeho prezentační
schopnosti … jinak to je ten Francouz z vtipu před pár dny.
31. březen 2015 — Video Results Queue
Dnes to bylo dost přemáhání vstát a začít kódovat, do čeho se mi ani moc
nechtělo a pořádně stále nevím jak … integraci výsledků ze zpracování videa.
Nakonec jsem to udělal pomocí dvou Qeueue, kde zpracování (včetně
dekódování z H.264) probíhá v odděleném procesu. Změnil jsem tedy i význam
funkce setVideoCallback() — má teď dva parametry, kde první je funkce pro
zpracování video dat a druhá vrací poslední výsledek nebo None, pokud žádný
výsledek není
(diff).
Teď přijde ta zábavnější část na výsledky zpracování reagovat.
p.s. včera jsem ani nezmínil, že už existuje alespoň jeden člověk, který kód
Katariny nezávisle na mně zkusil. Soudím tak podle té
stížnosti na pomalost videa
… Linux (Ubuntu 14.04) … no doufám, že to trošku nastuduje, než zavolá
drone.takeoff()
1. duben 2015 — Navigace na přistávací plochu
Včera jsem dělal první pokusy udržet se nad přistávací plochou
(diff).
Venku fičelo, že by mi Katarina ulítla i zabalená v krabici, a trošku se to
projevovalo i v budově. Dávám tedy částečnou vinu průvanu, ale jen malou …
prostě to ještě nefunguje.
Důležitou změnou oproti předešlému sběru dat bylo logování výsledků zpracování
obrazu. Výsek z logu cv2_150331_155530.txt vypadá takto:
143 (2, None) 210 (32, None) 314 (62, None) 199 (92, None) 344 (122, None) 310 (152, None) 386 (182, ((236, 239), (231, 282))) 280 (212, ((204, 239), (200, 276))) 374 (242, None) 220 (272, None) …
Je hned jasné, že vzor přistávací plochy byl detekován pouze 2x a to ve snímku
číslo 182 a 212. Je také pěkně vidět, že I-frame je jeden z třiceti snímků
(32-2, 62-32,…). Počet cyklů mezi jednotlivými snímky je ale spíše zavádějící
… ono je to počet zpracovaných paketů, včetně video paketů, jejichž počet je
proměnný v závislosti na složitosti scény a pohybu kamery.
Obrázky jsem si uložil a pak ručně procházel. Konkrétně mne zajímaly snímky
časově sousedící s úspěšnou detekci:
Na obou snímcích je přistávací plocha evidentně viditelná. Problém u snímku
číslo 152 byl, že střed detekovaného obdélníku byl dál než dvojnásobek
poloměru. Po změně tolerance na 2.1 už prošel i snímek 242. U 272 byla zase
příliš velká deformace kruhu — vyžaduji, že 70% plochy jsou „černé body” a
tady bylo nutné posunout hranici na 64%.
Testoval jsem ve dvou sériích: 6 pokusů vzletu a přistání se stoupáním do 1.5 a
pak 8 pokusů s korekcemi. Jelikož už v první sérii se stávalo, že přistávací
plocha byla vidět pouze krátce po vzletu z výšky 1m, tak jsem i stoupání změnil
na „stoupání s korekcemi do strany”. Vtipný byl pokus
meta_150331_191314.log, kdy místo stoupání Katarina začala klesat! Je to i
pěkně vidět na video záznamu, ale drone.altitude stále stoupá :-(. Fakt mne
štvou, že už neposílají odděleně i data ze sonaru, kamery a barometru. Sigh.
Nevydržel jsem to a založil
libARCommands issue
#6.
p.s. na obhajobu Parrotu musím zmínit, že Radimovi
opravdu poslali nový kus …
p.s.2 nezmínil jsem, že pokud si chcete sami zkusit detekci, tak stačí zavolat
./navbox.py –test roundelnav_272.jpg
7. duben 2015 — Konec zápůjčky.
Přišlo to dnes trošku jak blesk z čistého nebe. Bebop/Katarina je potřeba na
nějakou předváděčku. Asi to není úplně konečná, ale částečně asi jo. Řeší se
tím účast na
Robotem
rovně 2015 (zbývá 7 dní do ukončení registrace!), potřeba dekódovat
složitější H.264 video …
Murphy se mi zase šklebí za zády — dnes jsem si stáhl
ardupilot-mpng a
paparazzi repository, protože o
víkendu jsem změnil názor na psaní nízkoúrovňového software pro řízení dron.
Po dlouhé době jsem se viděl s Ondrou a bavili jsme se, mimo jiné, o článku
Build
cargo drones, get rich a o tom, že existují alternativní SW pro hračky od
Parrotu … no možná je dobře, že dronu vrátím teď. Na skříni je zaprášená
Heidi a tam se to dá zkusit také … jen to nebude tolik
bolet.
S Ondrou jsme se také bavili o tom, že je pěkné, že moje práce ostatní zaujala
natolik, že si udělali
fork Katariny .
„Nu wot, što dělať. Děduška stárij i pojezd bystrij”.
16. duben 2015 — Remote Testing
Teď to teprve začíná mít pořádné „grády” . Programování bez drony.
Testovací oblast Mexiko: ...in México there are no rules to fly drones yet
(zones out of danger) and I have a big area. Zatím mám první logy včetně
videa končícího crashem. Ti dobrovolníci (zatím dva Aldo/Mexiko a
Charles/Francie) jsou odvážní … ale chtěli nějaké funkce a já nemám jak to
zkusit (tedy ten crash byl z nulté iterace testFlyForward). Začal jsem tedy
raději oddělenou větev DEVELOP a arénu pro kaskadéry najdete zde:
20. duben 2015 — Mexické video
Ze čtyř současných „testerů” je Aldo z Mexika asi nejaktivnější. Uploadnul i
video z první kolize:
Řešíme teď navigaci na Home, kdy lze zadat souřadnice, ale skončí to ve
stavu pending — tipoval bych, že ten příkaz bude nutné zadat ještě
jednou, ale nechal bych Parrotu ještě 24h na
odpověď.
Jinak jsem snad konečně vyřešil import z různých adresářů
(diff)
a to podle vzoru na
stackoverflow.
21. duben 2015 — Skrytá kamera a Nao
Tak jsme s Charlesem snad odladili počáteční inicializaci všech proměnných. Ono
to místo AllSettings totiž spíše chtělo AllStates. Tak nechť toto
(diff)
je první „vzdáleně odladěný” kód.
V posledním pokusu (meta_150420_173419.log) asi ještě běžela kamera,
Charles delá nějaké trackování barvy, a tak se z toho stala „skrytá kamera” s
pohledem do jeho kanceláře. Snímek sem doplním až po souhlasu Charlese. A co na
něm bylo? Humanoidní robot
Nao, pózující na
druhém stole . Tak se mi to hned spojilo s
Tanečně-performačním
konceptem postaveném na bázi robotického fotbalu., co jsem viděl před dvěma
týdny v La Fabrika.
Jinak v Mexiku prý prší, takže další NavigateHome test se zatím odkládá …
ono tedy ještě není jasné, co jsou nutné podmínky, aby to fungovalo — viz
Issue #7.