Robotem rovně 2014
fandorama reportáž
Tento 6. ročník se koná 17. května 2014 v Písku - Palackého sady. Pravidla zůstávají stejná jako loni. Připomínáme, že registrace je nutná a končí 30. dubna 2014. Blog update: 19/5 — Husky na RORO14
Pokud máte zájem, aby na tomto místě vznikala reportáž z přípravy
Heidi a/nebo FireAnta a následné soutěže,
tak podpořte tento projekt. Výsledná částka pokryje půlku nákladů na cestu
Praha-Písek.
Soutěž „Robotem rovně” by zároveň bylo místo prezentace a zakončení dvou
dalších projektů:
Jinak Heidi za ten rok trošku vyspěla, a tak by letos mohla:
- regulovat rychlost letu
- rozpoznávat cestu pomocí OpenCV2 z I-frame
- pokusit se o vyhýbání se překážkám
Byl by to zároveň „proof of concept” na
Robotour 2014, která se bude konat letos na
podzim v Plzni, kde nově přibude kategorie „bezpečnostních dron” (zároveň
„bezpečných” ve smyslu, že čtyřtulka musí mít ochranný kryt na vrtule, „fail
safe” mechanizmy při kolizi, váhový limit, omezená výška do 2m, omezená
rychlost do 2m/s a pod.).
Odkazy:
- Detaily tohoto projektu: https://fandorama.cz/projekty/921778164/robotem-rovne-2014/
- Stránky organizátorů: http://www.kufr.cz/
Blog
15. duben 2014 — rr_drone.py aneb drona vzhůru letí …
Nejprve díky Tondovi za podporu tohoto
fandorama
projektu. Mám pak trošku pocit placené reklamy , ale je to prý podpora
i dalších zmiňovaných blogů. Tak děkuji .
Na soutěž „Robotem rovně” (RR) plánuji vyrazit s více roboty. Zatím jsem
registroval
FireAnta, ale asi dojde i na Isabelle (Jakub?), Eduro (Tomáš?) a Husky
(Sylvio?) … . No v reálu snad alespoň ten mravenec se připlazí.
Dnes celkem fičelo, ale nedalo mi to a vyzkoušel jsem
rr_drone.py.
Naštěstí nejprve v hale … a chovala se divně. Místo aby se držela v jedné
výšce, tak stále mírně stoupala. U přistání šla naopak dost natvrdo. A důvod?
Když průměrujete dvě čísla tak je od sebe neodečítáte, není-liž pravda? Ostatně
viz
diff.
Rozdíl vzdáleností podle sonaru a kamery prostě vycházel stále kolem nuly, a tak
se Isabelle snažila stále stoupat. Fixed.
Venku jsem pak letěl/sbíral data na „ne úplně rovné cestě” , ale byla
blízko a byla vyšší pravděpodobnosti, že hned nespadne do jezírka nebo neskončí
v keřích.
Co mne mile překvapilo byl fakt, jak se Isabelle urputně bránila. Někdy
propadla i skoro metr a v jednu chvíli letěla stále šikmo, aby kompenzovala
vítr. Nemilé překvapení byl naopak GPS modul. Nahrávání videa šlo automaticky na
Flight recorder, tedy na USBčko, ale možná se to dá nějakým vhodným
příkazem přesměrovat a přesto sbírat GPS data.
p.s. ptal se Ondřej Pilát z
XCS
týmu, jestli opravdu máme 200Hz update pro navdata … a máme. Viz výsek z
src_cv2_140415_194510.log, kde bylo dummy zpracování obrazu a zhruba 200
updates mezi I-frame (chodí každou sekundu):
233 ((0, 83573), None) 198 ((30, 84551), None) 190 ((60, 85529), None) 202 ((90, 86507), None) 178 ((120, 87485), None) 198 ((150, 88463), None) 204
23. duben 2014 — Schody
Přemýšlel jsem, co byl nějaký výrazný prvek včerejšího testování a bylo to asi
létání po schodech . Já vím, mám trénovat let rovně a místo toho si létám
esíčko a teď schody! Fungovalo to ale velice pěkně a efektně — asi je to
ještě kompenzace „mindráku z letošní Vídně” …
… no nic, co létání rovně?
Na githubu je
teď verze, která vyřízne pás 100 až 200 pixelů vysoký (teď je tam myslím 120,
kdy výška obrázku je 720), použije modrou složku pro přechod na šedotónový
obrázek, aplikuje muj oblíbený
MSER a
vybere min/max obdélníky, které mají zároveň výšku pásu a nedotýkají se levého
a pravého okraje.
Chcete si to zkusit? IF YES THEN stačí si stánout obrázek z minula a zavolat
./rr_drone.py img czu-curve.jpg
a ve výsledku byste měli vidět něco jako
TODO je redukce konvexního obalu MSERu jenom na lichoběžník, 3D projekce na zem
a konečně zapojení navigace letu podle přímky … zbývají 3 úterky do
soutěže.
28. duben 2014 — Perspektiva
Připravuji kód pro výběr navigační přímky a je pěkné, jak už první příklad
ukazuje, že je to špatně
Na těch dlaždicích je to moc pěkně vidět. Půlení rovnoběžných stran tedy není
dobý nápad — jak to má být správně? Předpokládám průsečík v nekonečnu a pak
půlení úhlu??
Ještě raději zopakuji, jak lichoběžník vznikne: z obrázku vyříznu pás a udělám
průsečík s detekovanou cestou — je to tedy projekce kosočtverce (a nikoliv
obdélníku).
29. duben 2014 — Levý hák
Odstartovat s kódem, o kterém jsem věděl, že má vážné trhliny, rozhodně nebylo
rozumné. Ale bylo publikum a chtělo vidět „krev” . Isabelle odstartovala,
dobře detekovala cestu a nabrala levý hák ostře do růží. Skoro bych řekl
„podle očekávání”. Čtyřtulce se nic nestalo a vznikl minimálně dobrý
referenční test. A kde byla chybka? Kupodivu to nebylo znaménko (i když jedno
tam asi bylo), ale násobení. Úhel byl několik miliónů a to už trošku napovídá.
Ještě FOW (Field Of View) jsme upravili — všechny změny před druhým (řádově
rozumnějším) pokusem jsou
zde.
30. duben 2014 — Výpadky videa
Včera jsem byl nějaký unavený, takže ten „status odstaveček” byl věru krátký.
Koukal jsem ještě na další pokusy a to mne asi dorazilo a šel raději spát.
U druhého letu (nejlepší pokus) po pár sekundách skončilo video, konkrétně po
38 snímcích. Přehrávání u toho snímku končí a log lze přehrát bez assertu.
Zbytek cesty se navigoval podle detekce ze snímku 38:
Nebo k tomu radějí přistoupit pozitivně a „hle, to je krásná ver0”? V
každém případě obnova video spojení implementovaná po letošní Vídni
nefunguje.
Třetí let byl asi nejvtipnější. Drona vzlétla, ale vypadalo to jak když si
vybrala jinou cestičku a zamířila na plácek, kde si dvě studentky dělaly
piknik. Dobré záběry, ale … co to sakra bylo? No, jak v druhém pokusu vypadlo
to video, tak ve třetím se dostahovávalo. A Isabelle navigovala podle starých
dat. Ve Vídni jsme pro tento případ měli zastavení (to stažení je relativně
rychlé) a když se posune v čase zase do reálu, tak naviguje dál. Jakube, měl
jsi pravdu — tuto část jsem z airrace_drone.py nepřenesl :-(.
NAVI-ON !DANGER! - video delay 160.082946 FRAME 72 [1.2 4.6] [(503, 578), (510, 469)] (0.8977528144549725, 0.024611520844053544, 0.766) 262.424 (1.0207614581498383, -1.7768862929708948) (1.1361521627969986, -3.4558749555702755) !DANGER! - video delay 159.638248 FRAME 74 [1.2 4.6] 2 !DANGER! - video delay 159.184693 FRAME 76 [1.2 4.6] 4 !DANGER! - video delay 158.716245 FRAME 78 [1.2 4.6] 2 !DANGER! - video delay 158.093225 FRAME 80 [1.2 4.6] 2 !DANGER! - video delay 157.51412 … !DANGER! - video delay 124.121726 FRAME 158 [1.2 4.6] 2 !DANGER! - video delay 15.198639 FRAME 0 [1.2 4.6] 0 …
Čtvrtý pokus trošku vypadal, jak když přepnete do „režisérského módu”
(director mode). Čtyřtulka snímala startovní plochu z různých směrů a vypadalo
to celkem pěkně … skoro jako by se rozhodovala, kterou cestou se vydat (byli
jsme na křižovatce). Ale dlouho to nevydrželo:
FRAME 52 [2.7 -1.4] [(900, 461), (824, 560)] (-3.252789472485516, 3.8145583780710717, 0.328) 206.489 None (-13.199188759011353, 2.6472388724510463) Traceback (most recent call last): File "M:\git\heidi\rr_drone.py", line 271, inlauncher.launch( sys.argv, RobotemRovneDrone, competeRobotemRovne ) File "M:\git\heidi\launcher.py", line 82, in launch task( robotFactory( replayLog=replayLog, metaLog=metaLog, console=console ) ) File "M:\git\heidi\rr_drone.py", line 214, in competeRobotemRovne refLine = Line(start, end) File "M:\git\heidi\line.py", line 41, in __init__ self.angle = math.atan2( end[1] - start[1], end[0] - start[0] ) TypeError: 'NoneType' object has no attribute '__getitem__'
Nedefinovaný start. Navigační linie v obrázku šla moc vysoko (mimochodem úplně
špatná detekce) a průsečík roviny země s polopřímkou pohledu tedy neexistoval.
Další TODO.
Zmíněné dvě opravy naleznete
zde.
6. květen 2014 — Výpadky videa2
Dneska to byla zase klasická ukázka, kdy Isabelle létala pěkně, i si poradila s
nápory větru, ale když teď vidím na základě jakých instrukcí letěla, tak to
byla zase klika :-(. Tři pokusy, výpadek videa už při prvním pokusu. U
druhého pokusu chvíli navigace z předešlého videa (zpozdění 137s), pak pěkně
srovnání na cestu, ale následuje zase výpadek a půlku cesty letěla naslepo.
Poslední pokus byl spíše „emergency” (zase ze starého videa a vítr čtyřtulku
sebral hned těsně nad zemí).
Z oprav asi za zmínku stojí kalibrace Field of view (z 120 na 70 stupňů) a otočení
znaménka u pravolevého náklonu (viz
diff).
7. květen 2014 — Detekce cesty
Je nejvyšší čas se pustit do analýzy detekce cesty. Úplně na začátku jsem chtěl
ukázat, proč modrá je (nejen pro blázny) dobrá … a neukázal. Tak teď a jestli
je to vůbec pravda:
b,g,r = cv2.split( frame ) cv2.imwrite( "red.jpg", r ) cv2.imwrite( "green.jpg", g ) cv2.imwrite( "blue.jpg", b )
… ale jo. Celkem bych věřil, že ten kontrast je v modré složce větší než v
jiných.
Hmm, ty modré „lichoběžníky” (tady spíše náhodné čáry) jsou zavádějící a
původní kontury, resp. konvexní obal MSER bodů, mají daleko lepší vypovídající
schopnost:
„Ta maličká ta je má ...” a ostatní nechci. Obecně to asi platit nebude, ale
s nějaký pravidlem začít musím. ono nejlepší pravidlo by bylo „Ta maličká,
dva metry široká, ta je má ...”, ale v této chvíli zatím nechci kombinovat
data z IMU drony (možná to je chyba). Současný algoritmus snímek ignoruje,
pokud je detekována více jak jedna plocha.
cv2.cv.ContourArea() mi nějak nepasuje a vlastně už MSER samotný mi vrací
jednotlivé body … tj. stačí se zeptat na počet bodu. Podle očekávání pravidlo
nejmenší plochy není dokonalé:
V prvém případě jsem měl plochy (počty pixelů) 39095, 49150 a 67883. Zde je to
pak 45771, 5180. Zkusit kdo je blíž „očekávanému počtu pixelů”?? Nebo
definovat spodní limit?
Spodní limit je jednodušší a možná i smysluplnější. Použil jsem nakonec 20000
pixelů. Je to řádově lepší, ale hotové to tím není:
U tohoto obrázku si myslím, že cesta „odteče” na křižovatce a bylo by třeba
jí detekovat i v jiném pruhu. Ale to až příště. (ref
video_rec_140506_191944.bin:106)
Popisované úpravy najdete v tomto
diffu.
8. květen 2014 — Orientace cesty
Včera mi Jakub psal: Ahoj, udělal jsem teď tři rychlé testy. Martine, něco
je špatně . Zdá se že Isabelle jde úplně pryč od detekované cesty (kolmo?).
Logy už jsem ti poslal přes úschovnu... a opravdu, když jsem si logy
přehrával, tak 100% seděli s mým kódem a bylo na nich vidět mnoho
„autoportrétů týmu” . Už jsem dlouho nic neuploadoval na YouTube, tak
zde je video jak se Isabelle otočí na Jakuba
a Milana.
Kde je problém? On byl vlastně už vidět z výpisů, ale na obrázcích nikoliv:
NAVI-ON FRAME 16 [0.8 -8.6] (4.4266189937885905, 7.142610292657869) (1.6267252692682286, 2.953988921841683)
První se vypisuje souřadnice startu a pak souřadnice cíle. Ano, na pořadí zdá
se záleží . Start je tedy relativně daleko (čtyřtulka právě odstartovala,
takže bude mít pozici okolo (0,0)) a cíl blízko. Když jsme létali do osmičky na
Robot Challenge, tak jsem navigační
přímku (teď už vím, že spíše navigační polopřímku) filtroval a otáčel. V
rr_drone.py zatím ne.
Tak nejprve jsem doplnil
kreslení
šipek:
Co možná není jasné z toho videa je teď zřejmé
z obrázku. Je srandovní jak ten mozek vidí tu 2D šipku v perspektivě špatně
velikou — raději jsem si otočil obrazovku, abych sám sebe přesvědčil .
To je hrůza, já snad budu muset začít ten text cenzurovat …
rr_drone_test.py
nefungoval a teď mám pocit, že zase znaménka u projekce a angleFB jsou
špatně. Jak jsou v reálu ty náklony jen malé a vybírám z obrazu pás ve spodní
části, tak to asi funguje. Tj. zase na obrázcích je vidět pěkně detekovaná
čára, ale ono to podle ní nutně nemuselo navigovat!
Opraveno.
13. květen 2014 — Miss Agro
Myslel jsem, že zítra (středa) uděláme nějaké testy v davu v rámci akce
Miss Agro, kterou CZU organizuje. Když ale vidím
loňské foto, tak tam je tolik lidí, že cesta by vůbec nebyla vidět a navíc je
to dneska!. Sigh. Ale areál školy je velký, tak nějaké alternativní cesty
na létání najdeme … on-line přelet na finalistkami to letos nebude .
Teď také koukám, že nějak vázne dokumentace. Přidělal jsem o víkendu ještě
detekci
cesty ve více pruzích — nějak se mi nepodařilo numpty/cv2 přesvědčit, jak
udělat hlubokou kopii pole/obrázku (z offline dokumentace), tak jsem nastrkal
objekty ke kreslení do proměnných a vykreslil to až nakonec. Je to zatím
zakomentované (řádka 86), protože chybí logika jak z více variant vybrat tu
správnou.
Motivace je možná dobře vidět na loňském snímku z Písku:
ale je tam také vidět, jak že to moc nefunguje. A na toto se fakt těsím = pěkný
Freud, těším+děsím
Bude třeba nastavit minima počtů pixelů pro každý pruh zvlášť a zkusit
verifikovat šířku cesty. Jdu se raději zklidnit nad včerejšími logy od Jakuba
…
Na tomto snímku vidíte, jak by to správně mělo fungovat . Do zpracování jde
pouze video snímek, tj. drona neví, jak moc je nakloněná a které pruhy jsou už
nad horizontem. Horní šipku by tedy následně měla automaticky vyhodit, protože
její projekce jde do nekonečna.
Koukal jsem na další snímek:
a původně jsem tam neviděl černé kontury … tak jsem si myslel, že je to zase
tou kopií (kdyby to někdo potřeboval, tak je to
numpy.copy),
ale byla tam
špatná
podmínka.
Proč tedy nevybral tu spodní konturu? Limit na počet pixelů :-(. Místo 18000 je
třeba klesnout na 16000 nebo nějak zapojit znalost výšky a náklonu. Timeout,
musím do práce.
14. květen 2014 — 3D filtr
Včera to bylo zase hrozný! Lítali jsme s oběma čtyřtulkama a Heidi si dělala co
chtěla. Video bylo několikrát (nebo snad dokonce pořád?!) nezdravě opožděné a
tak se Heidi stále zastavovala. Nevím. Štvala mne.
Z nových testů jsem udělal jenom jeden s jinou rychlostí (místo 0.8m/s na
1.5m/s), ale asi to zase vrátím do původního stavu. Při výpadku spojení to letí
posledním příkazem a to není moc dobré.
Co teď řeším a proč jsem to začal zase sepisovat je „3D filtr”. Mám několik
kandidátů na cestu, ale není jasné, kterého vybrat. Ještě včera jsme používali
nejmenší plochu větší než daný limit. V závislosti na náklonu a výšce je ale
plocha cesty tak proměnná, že jeden limit je nedostatečný.
Jedna varianta by byla nějak do zpracování snímku protlačit z jaké pozice je
snímán (3D + náklony), ale to zase zkomplikuje synchronizaci dvou procesů a moc
se mi do toho nechce. Druhá varianta je vracet více kandidátů a v hlavním kódu
si teprve pomocí 3D projekce vybrat.
Koukal jsem na pár obrázků a nechal si vypisovat detekovanou šíři cesty.
Vyhozený byl např. tento jinak rozumný obrázek se správnou detekcí
(video_rec_140513_180844.bin:34):
Detekované šířky jsou:
[(767, 579), (360, 578), (524, 489), (698, 460)] REJECTED widths: 3.8 3.9 7.4 4.7
tj. po projekci pravého horního rohu s měřením vzdálenosti k levé přímce
dostanu 7.4m?! To je skoro dvojnásobek reálné šířky cesty! Moc se mi nechce
věřit, že by chyba měření výšky a náklonu udělala takovou paseku??
Vstupní parametry pro projekci jsou: (-3.1525994360406795,
-1.1213406574656708) 1.4665 3.79687652125 0.0712094334814 -0.0561123354516,
tj. výška 1.46m, náklon nahoru (?!) zhruba 4 stupně, a náklon vlevo 3.2
stupně.
(-9.043579953053138, -8.70631669109345) (-12.820723270934755, -6.689504888466439) (-61.03586262236623, -40.26915282190969) (-21.498864905484425, -18.5210259777622)
Dělá to ten špatný odhad náklonu celé drony. Pokud řeknu, že je 0, tak třetí
bod je už zase normální:
(-7.124169028205442, -6.234964796173863) (-9.360980211620252, -4.6969344704294596) (-16.291562047991906, -10.007530067910539) (-11.346115599603664, -8.892110308117724)
Závěr: kolem horizontu rozhodně se šířkou cesty z obrázku moc nepočítat.
15. květen 2014 — Poslední release
Dnes už jen heslovitě …
- vyhazování špatné perspektivy, oprava opravy
- filtrování šířky cesty,
- podmíněné přijetí nově definované referenční linie,
- větší korekce v Z-ové ose pro výšku nad 2.5m (Heidi vystoupala až do 4.216m a proti větru neměla šanci)
- stahování starého videa před startem (max 20s) a možnost vypínání zpracování obrázků
- patch pro vypnutý video processing
16. květen 2014 — Husky (24h do soutěže)
Dnes by měl Sylvio přívézt robota Husky.
Tak snad se nám ho podaří přes oběd rozchodit, aby dokázel jet rovně. Pokud ano, tak výsledek
naleznete zde.
17. květen 2014 — Klapky na očích
Heidi uletěla v nejlepším pokusu 228 metrů! A jak to dokázala?
… ((960, 390779), []) 185 ((990, 391790), [((348, 579), (1001, 576), (917, 460), (452, 460))]) 192 ((1020, 392768), [((292, 579), (865, 562), (776, 460), (390, 460))]) 192 ((1050, 393746), [((319, 579), (964, 563), (867, 460), (394, 460))]) 2 ((1080, 394724), []) 2 ((1110, 395702), [((422, 530), (953, 565), (811, 460), (500, 460))]) 55215
… má to být 200Hz, tj. divný výpadek (jak mezi dvěma výsledky jsou jenom dva
tiky) a pak 55215x nic! To znamená 55215/200/60.0 = 4.6 minut výpadku
videa, kdy Heidi letěla úplně naslepo! Prostě klika jako blázen. Mé tajné
přání proletět bránou radia Blaník (cca po 100m)(*) Heidi překonala více jak
dvojnásobně . Alespoň z navdata si toho byla sama vědoma:
Landing … (-202.16880935608188, -55.03197118620995, 1.154)
(x,y,z) při požadavku na přistání … podle čeho ten Jakub létal?! Měl tam jiná
znaménka … viz níže … souřadnice by měly být od (0,0) pro start a směr by
měl být dán kompasem. Orientace X-ová na východ a Y-ová na sever.
…
Divné je, že ve výpisu žádný video timeout není. Čím více o tom přemýšlím,
tím jsem více přesvědčen, že to skončilo z nějakého jiného důvodu. Tipoval bych
čtení I-frame? Na druhou stranu se zastavil i video preview kanál a to by
zase ukazovalo na dronu … divné. A navíc Jakubovi se to na Linuxu neděje.
Když dva dělají totéž, není to totéž
Heidi i Isabelle létaly se stejným základem, ale bylo tam i pár odlišných
detailů. Vedle trošku jiných OpenCV verzí a operačních systémů jsem já u Heidi
změnil šířku cesty na změřených 4.35m a Jakub nechal u Isabelle 3.0m. Já jinak
používal kód jak byl v pátek v gitu, Jakub použil experimentální verzi se dvěma
pruhy a přednastavil si referenční linii podle homologačního letu. Ještě Heidi
měla posunuté limity tolerance při počítání projekce, Isabelle nikoliv.
Průběh celého dne bylo pěkné hecování . Začínali jsme oba cca na 20m, pak
překonali loňský rekord Heidi (něco přes 30m), pak myslím 55m. Pak Isabelle
našla chybu — počítání průsečíků rovnoběžných přímek vrací None, ale u
použití výsledku toto nebylo ošetřeno
(fixed).
Ve třetím kole Isabelle tak trošku parodovala Heidi z loňska. Stočila to vpravo
a lehce osekala tamní smrk. Důvodem byla nízká tolerance u referenční linie.
Přednastaveno bylo 20 stupňů a 2m. Problém byl ty 2m, ale teď už mi to jako
zřejmé nepřipadá — uvidíme, jestli pošle Jakub v pondělí logy. V každém
případě 2x cestu úspěšně detekovala, ale v obou případech návrh zamítla, že se
příliš liší od původní reference.
V posledním kole Isabelle uletěla přes 70m a „vykolejila” jí jedna cestička
vlevo. Je možné, že zde hrál roli ten limit 3m místo 4.35m. Na druhou stranu
když čtyřtulky letěly hodně u kraje cesty, tak v používaném video-pásu druhý
kraj cesty vůbec neviděly. A konečně díky lidem kraje cesty v úvodní sekci
nebyly vidět snad nikdy.
Autorem fotografií je Zdeněk Kakáč — doufám, že brzy doplním další (bylo jich
více jak 2GB). Díky moc .
(*) podle této fotky soudím, že jsem se spletl — bylo to Rádio Rock
19. květen 2014 — Husky na RORO14
Dokumentace den před soutěží trošku vázla . Teď bych tedy doplnil pár
podrobností. Sylvio opravdu Husky přivezl, ale k mému velkému překvapení hned
po obědě zase odjel zpět do Francie. Zápasil jsem ten den ještě s
FireAntem řízeným přes Bluetooth a tak na
„programování” velkého robota došlo až večer. Husky má nějaký problém s
napájením a tak jsem zase otravoval naše HW oddělení. Ondra objevil částečně
vypadlý konektor od zapínání s klíčkem, ale asi to nebyl jediný problém (i v
Písku se napájení chovalo nějak divně a po pár ujetých metrech indikátor
ukazoval poloviční baterku).
Koukali jste na
soutěžní
kód? Je tak „rozsáhlý”, že ho sem skoro můžu pastenout
import time
from clearpath.horizon import Horizon
from clearpath.horizon.transports import Serial
horizon = Horizon(transport=Serial, transport_args={'port':'/dev/ttyUSB1'})
horizon.open()
while True:
horizon.set_differential_output(30, 30)
time.sleep(0.5)
horizon.close()
Prostě jsem posílal 30% výkonu na oba motory a tím to skončilo. Ignoroval jsem
jak odometrii, tak kompas, stavy tlačítek a ještě by se určitě našlo něco
užitečného. Startováním robota jsem zaúkoloval Christiana z Dánska (autor
cafe-neu-romance.com). Prostě to jezdilo pouze
na STOP tlačítko.
Vedle zatím nejasného problému s napájením jsem měl i problém s konektivitou.
Musel jsem se na robota po zapnutí přihlásit, sestřelit běžící ROS (aby mi
uvolnil komunikační linku) pomocí sudo service husky-core stop a pustit
./rr.py. Tento triviální úkol mi často trval i několik minut a tak Husky
musel často startovat až mezi posledními.
Co se jízdy týče, tak Husky zatáčel mírně vpravo. Nechtěl jsem to řešit, takže
bylo nutné robota vhodně natáčet, aby dojel o trošku dál.
Robota Husky budu mít cca měsíc, do soutěže Field
Robot Event, která se koná 17/6/2014. Pokud by vás zajímalo něco více o této
kanadské komerční platformě, tak jsem vyvěsil další fandorama
projekt.