2mm osička s šesti a s osmi enkodérovými proužky
This page is in my native language. The development of PocketBot2 robot is thoroughly described here. If you are looking for information about the PocketBot2 robot, please visit the english page.
In case you are deeply interested in the development details on this page, I would suggest you to use Google translator.Zanedlohou po dokončení první verze kapesního robota už na mém disku vznikla složka s názvem PocketBot 2. Postupně se v této složce scházely datasheety součástek, textové soubory s všelijakými poznámkami a odkazy, specifikace bluetooth, ale i jiné zajímavé dokumenty - no zkrátka cokoliv, co by se mohlo v budoucnu hodit pro vývoj dalšího robota.
Jak šel čas, složka nenápadně rostla a po dvou letech už bylo materiálu víc než dost. Za ty dva roky se toho spoustu událo; odmaturoval jsem, nastoupil na vejšku, realizoval jsem několikero projektů s mikrokontroléry (čímž jsem získal hromadu zkušeností), no a v neposlední řadě jsem taky konečně přihlásil PocketBota na nějaké ty soutěže, kde jsem sklidil plody své práce.
Taky bych třeba mohl zmínit, že v Rumunsku vznikla (za mé pomoci) kopie PocketBota, a to ještě víc jak rok před tím, než jsem navštívil Bukurešť.
Prázdniny utekly jako voda a najednou je tu září. Ale to pro vysokoškoláka není zas taková tragédie, do začátku zimního semestru zbývá ještě měsíc a za ten měsíc se toho dá spoustu stihnout. Třeba postavit dalšího robota - splnit si další sen.
Pravda je, že ke startu projektu PocketBot 2 se vlastně začalo schylovat už tak nějak v polovině srpna 2010..
Ptají se mě, proč vůbec chci stavět dalšího linefollowera.
PocketBot 1 se víceméně povedl, ale je tu pár drobností které mi na něm chybí. A co víc, tyhle detaily znemožňují účast na některých soutěžích, například soutěž Stopár na Istrobotu v Bratislavě nebo LineFollower Enhanced na RobotChallenge ve Vídni.
No ale hlavně toho robota dělám proto že mě to baví! :)
Takže, čím se bude PocketBot 2 lišit od první verze?
A co bude mít naopak společného s první verzí?
2010-09-07 Prototyp kvadraturního enkodéru ve skutečné velikosti. Na DPS je naletovaný miniaturní odrazový infrasenzor GP2S60 a nad ním se otáčí osička průměru 2mm. Do osičky jsou vyfrézovány drážky zatřené černou barvou. Po straně je přidaný fototranzistor BPX81, který poskytuje fázově posunutý signál.
2mm osička s šesti a s osmi enkodérovými proužky
Konstrukce kvadraturního enkodéru by byla, ale teď jak to otestovat? Nejprve jsem na jednoduchém obvodu vyzkoušel, že senzory opravdu reagují na černé proužky, zkrátka že celé zařízení vykazuje při otáčení osičky nějakou aktivitu.
Jenže z blikajících LED diod toho člověk moc nepozná, chtělo by to osciloskop. Ale proč vlastně? Vždyť mi stačí obyčejná zvuková karta! Běžná zvukovka má dva kanály pro záznam zvuku. Tak jsem vzal jack a připojil k němu fototranzistory, viz schéma.
Pak už jen pustit nahrávání a místo zvuku sampluju přímo stav senzorů, paráda. Není to poprvé co používám tenhle trik, na tomhle principu jsem založil IR protocol analyzer, program na automatické rozpoznávání protokolů dálkového ovladače.
Ale zpátky k enkodéru; na roztáčení osičky jsem použil vrtačku děr do DPS. S napětím jsem spustil nahrávání zvuku a nahrávku podrobil analýze. Výsledek mě nadchnul. Vrtačka točila kolem 18 tisíc otáček za minutu a ze senzoru lezl pěkný, téměř kvadraturní signál:
Trochu jsem si ještě pohrál s umístěním osičky a fototranzistoru, aby byl signál správně fázově posunutý o 90°. Pak jsem ještě zdokonalil testovací zapojení. Analogové komparátory IC1A, IC1B slouží ke zpracování signálu z fototranzistorů. Trimrama nastavím práh mezi světlým a tmavým proužkem, a na výstupu mám rovnou logický signál, 1 nebo 0. Bílá nebo černá. Výstup opět snímám zvukouvkou, která je pro jistotu od obvodu oddělená optočleny.
2010-09-08 Experimentoval jsem s nastavením prahu tak, aby byla střída signálu pokud možno 1:1. Místo vrtačky jsem osičku tentokrát roztáčel motorkem ze stavebnice Lego Technic, jehož rychlost jsem ručně ovládal PWMkem. Skutečná rychlost otáčení bude maximálně 25 otáček/s, což odpovídá rychlosti robota přibližně 60cm/s. Na volnoběh to bude samozřejmě více.
Níže na obrázcích už je obdélníkový, čistě digitální signál z analogových komparátorů. Použil jsem osičku s šesti proužky.
8 otáček za vteřinu
4 otáčky za vteřinu, opačný směr
25 otáček za vteřinu, opačný směr
Jak ale všechny ty elektrické komponenty dostanu do robota velikosti krabičky od zápalek? Kam se ty komparátory, kalibrační trimry a enkodérový čip jenom vejdou?
Na tuhle otázku jsem pochopitelně našel odpověď ještě před tím, než jsem se pustil do výroby prototypu enkodéru. Ta odpověď zní: Atmel XMega. Tento zázračný čip má integrovány:
Celá tahle nádhera v jednom pouzdře!
2010-09-09 Čipy XMega obsahují šifrovací jednotku a to je zřejmě důvod, proč se nesmějí vyvážet z USA. To je pro mě sice trochu komplikace, ale rozhodně ne nepřekonatelný problém.
2010-09-10 V obchodě Telel jsem nakoupil deset druhů vibračních motorků a podrobil je testování. Ukázalo se, že motorky ve starém PocketBotovi patří svým výkonem do střední kategorie. Některé motorky (číslo 1,3 a 10) jsou výrazně výkonnější než ty původní z PocketBota.
Nutno ale podotknout, že starý PocketBot nebyl v žádném případě slimák, uměl to rozjet až na 60cm/s. A tyhle motorky jsou příslib, že verze dvě bude ještě rychlejší.
Motorky jsem roztáčel baterií s napětím 4V. Osičku jsem z poloviny zabarvil černým lihovým fixem a k měření rychlosti otáčení jsem použil enkodér popsaný výše.
Naměřené rozměry mají jen orientační charakter, můžou se lišit (tak ± 0,1 mm). Stejně tak elektrické veličiny jsou jen orientační, byli naměřeny levným multimetrem nevalné kvality. To taky vysvětluje, proč u motorů 1 a 3 nebylo možné přesně změřit proud nad 200mA. U některých motorků jsou uvedeny dvě hodnoty odporu. Vysvětlím: Kupoval jsem dva kusy od každého druhu. pokud se odpor dvou stejných typů lišil, uvedl jsem oba. První hodnota se vztahuje k testovanému motoru.
Kód je označení, které bylo na pytlíku s motorky. Nejedná se o katalogové číslo Telelu a ani nevím co je vlastně zač. Prostě to co tam bylo jsem si poznamenal pro Strýčka Příhodu.
| id | foto | kód | průměr [mm] | průměr osičky [mm] | délka [mm] | délka včetně osičky [mm] | odpor [Ω] | proud bez zátěže [mA] | proud při zablokování [mA] | otáčky za vteřinu | otáčky za minutu | poznámka |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |  |
6800023 N881 |
5 | 0,8 | 12 | 15 | 12 | 53 | >200 | 975 | 58500 | Goliáš - velký výkon |
| 2 |  |
SXK1078450 T20 |
4 | 0,8 | 12,4 | 15,4 | 42 | 37 | 79 | 680 | 40800 | |
| 3 |  |
ERBSMC558/0303 | 4 | 0,7 | 13,6 | 15,5 | 10 | 70 | >200 | 1700 | 102000 | opravdu silný, trochu se zahřívá, netradiční konstrukce => pravděpodobně obtížná montáž do podvozku |
| 4 |  |
S070203 ERBSBKE90319/2R1 |
4 | 0,6 | 13 | 15,7 | 48 | 16 | 73 | 820 | 49200 | |
| 5 |  |
ERBSSXK1079043/4R1 T298 |
4 | 0,7 | 9,6 | 12 | 27 (35) | 38 | 96 | 1150 | 69000 | |
| 6 |  |
SXK1094849R1 T300 |
4 | 0,6 | 13,2 | 15,6 | 40 (48) | 23 | 75 | 660 | 39600 | |
| 7 |  |
ERBSR400001180 | 4 | 0,7 | 8,8 | 12,5 | 25 | 32 | 125 | 1075 | 64500 | Na svou velikost má pozoruhodný výkon |
| 8 |  |
4 | 0,6 | 13 | 15,8 | 50 | 17 | 70 | 560 | 33600 | drátky | |
| 9 |  |
2320 | 4 | 0,6 | 13 | 15,8 | 50 | 12 | 71 | 750 | 45000 | drátky |
| 10 |  |
6800063 | 4 | 0,7 | 11 | 13,7 | 18 | 25 | 160 | 1375 | 82500 | Velice výkonný, kandidát na motor do PocketBota 2. Momentálně však nejsou skladem a nevím jestli budou. |
| 11 |  |
4 | 0,6 | 13,4 | 15,8 | 49 | 16 | 71 | 720 | 43200 | stávající motorek v pocketBotovi (pro srovnání) |
2010-10-02 Nakonec se ukázalo, že vhodné motorky pro PocketBota nejsou v mobilech, ale někde jinde. Totiž u modelářů. Na veletrhu ModelHobby (kde jsem předváděl starého pocketBota) jsem koupil vzorky velmi výkonných ocasních motorků do miniaturních vrtulníčků. Motorky mají stejné rozměry jako ty z mobilu, ovšem daleko větší výkon. Veletržní cena: 20Kč/kus.
2011-01-16 update: Jedná se o ocasní motor MayFly
| id | foto | kód | průměr [mm] | průměr osičky [mm] | délka [mm] | délka včetně osičky [mm] | odpor [Ω] | proud bez zátěže [mA] | proud při zablokování [mA] | otáčky za vteřinu | otáčky za minutu | poznámka |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12 | |
MF3D-026 | 4 | 0,7 | 12,2 | 16,8 | 10 | 40 | >200 | 1000 | 60000 | drátky, vysoký výkon, motůrek z minivrtulníčku |
Miniaturní (jak jinak) kousek A3901 uřídí dva motory. Proud až do 400mA na motor, takže v pohodě zvládne všechny výše uvedené.
2010-08-31 Zvažoval jsem, že DC motory nahradím miniaturníma stepperama. To by mi poskytlo částečnou kontrolu nad pohybem robota, aniž bych musel nějak řešit enkodéry. Nakonec se ale ukázalo, že steppery v takové velikosti nejsou příliš výkonné a na pohon robota se nehodí.
miniaturní krokové motory (pravděpodobně z digitálních foťáků)
Thanks to Ale from Bangkok, who send me these nice stepper motors.
2010-09-19 Doposud jsem programy pro mikrokontroléry vyvíjel v AVR Studiu. Mělo to tu výhodu, že nebylo potřeba vůbec nic konfigurovat. Člověk zkrátka nainstaloval WinAVR (sada nástrojů pro programování mikrokontrolérů AVR v jazyce C) a AVR Studio už si všechny ty nástroje samo našlo. Jednoduché, rychlé a také bez nutnosti proniknout do věcí jako je linker nebo makefile. Což jsem tenkrát chápal jako dost velkou výhodu.
Na mff jsem přišel do kontaktu s vývojovými prostředími jako Visual Studio nebo NetBeans, a ty mě dost zhýčkaly. Někdo na všechny ty našeptávače možná nadává, ale mě se v tom prostě pracuje rychleji a hlavně pohodlněji než v prostém textovém editoru. Šetří to čas, když člověk kvůli každé méně používané funkci nemusí otvírat header file aby si ověřil pořadí parametrů. A třeba taková refaktorizace názvů metod a proměnných (kterou AVR Studio zná pouze pod názvem "Find and Replace") také zpříjemňuje život..
No takže zkrátka, rozhodl jsem se vyměnit AVR studio za Eclipse. Rozchodit v Eclipse podporu pro AVR není zrovna hračka, Hrabal jsem se v tom celé odpoledne, než se mi podařilo zprovoznit kompilování, debugování a progamátor AVR Dragon.
Takže ve zkratce můj boj s Eclipse, předkládám to jako souhrn několika postřehů:
2010-10-05 Už mi doma nějakou dobu leží součástky z Digikey. Je čas postavit z nich první prototypy jednotlivých částí robota. Navrhnul jsem několik modulů, které připojím k vývojové desce XMegy. Konkrétně to budou moduly pro H-můstek, senzor překážek, bluetooth a senzor čáry. Vše, včetně oné vývojové desky navrhnu a vyrobím sám.
Všechny desky se mi podařilo navrhnout jako jednostranné, takže jsem předpokládal, že jejich výroba doma v koupelně proběhne snadno a bez komplikací. Ostatně nějaké ty zkušenosti s leptáním už mám z minulých let. A tak jsem se do toho pustil. Ale to jsem ještě netušil, kolik dnů budu s výrobou DPS zápasit..
2010-10-08 První pokus - výroba fotocestou. Fail. Protože jsem nenašel žádné vhodné sklo, zatížil jsem předlohu plexisklem. Jak se ukázalo, nebyl to vůbec dobrý nápad. Po vyvolání desky zůstala na celé ploše spoje leptuvzdorná vrstva. Poučení: Plexisklo nepropouští ultrafialové světlo, a proto se nehodí k zatížení vzoru.
2010-10-11 Pokus 2 - opět fotocesta. Nakoupil jsem nový fotocitlivý kuprexit, tentokrát v GESu. Po osvícení a vyvolání na desce zůstaly skvrny, takže to vypadalo, že desky budou zase k ničemu. Zřejmě jsem se nechal napálit a koupil jsem nekvalitně udělaný fotocitlivý kuprexit. No ale aspoň jednu desku se mi podařilo zachránit retušováním. Takže úspěšnost 50%.
2010-10-12 Pokus 3 - fotocesta. Tentokrát jsem si pro další kuprexit zajel do GME. Předlohu jsem prosvicoval 15 minut horským sluníčkem. A po vyvolání mě čekalo nemilé překvapení - celá deska zůstala potažená leptuvzdornou vrstvou, jako kdyby na ní nedopadlo vůbec žádné světlo. V této chvíli už mě to vážně přestávalo bavit. Už jsem za kuprexit dohromady utratil víc, než kdybych si ty desky nechával někde vyrobit. A toho promarněného času!
2010-10-13 Pokus 4,5.. atd.. Tentokrát však změna strategie: výroba DPS nažehlováním toneru. Po předchozích neúspěších se mi doma nahromadily pokažené fotocitlivé desky. Vzpomněl jsem si na alternativní postup při výrobě DPS. Tento článek o výrobě DPS nažehlováním mi byl inspirací. V několika krocích jsem se však od popsané procedury odchýlil.
Postupoval jsem takto:
Ukázka plošného spoje vyrobeného nažehlením toneru. Konkrétně je to testovací deska pro mikrokontrolér XMega128A1 v pouzdru TQFP100 (toto pouzdro má užší piny než klasické TQFP). Na fotce vlevo je vidět nažehlený toner na kuprexitovou desku (nepovedený vzor).
2011-01-16 Tak, a je tu zkouškové. Měl bych se připravovat na zkoušky, ale jak už to tak bývá, v tomto období se člověk raději věnuje věcem, na které v semestru nezbýval čas - jen aby měl důvod odložit učení ještě o chvíli.. Takže jsem utekl od skript, abych doplnil tento deník.
To, že se tu tři měsíce nic nedělo rozhodně neznamená, že po celou tu dobu projekt spal! To vůbec ne, ba naopak! (Jen prostě nebyl čas o tom psát..)
2010-09-15 První prototyp senzoru pro rozpoznávání barvy čáry. Je složen z barevných LED a fotorezistoru. Mikrokontrolér postupně zapíná jednotlivé LED a měří množství světla, které se od povrchu odrazilo zpátky do fotorezistoru. Rozpoznání modré a červené čáry je založeno na poznatku, že červené světlo se špatně odráží od modrého povrchu a naopak, modré světlo je zas pohlcováno červeným povrchem. Na podobném principu fungují červeno-modré brýle pro stereovizi.
Testy ukázaly, že lze snadno rozpoznat rozdíl mezi černou, červenou a modrou čárou. S ostatními barvami je to horší; zelená, žlutá nebo hnědá jsou si z pohledu tohoto senzoru dosti podobné a těžko rozlišitelné.
Ještě je třeba zdůraznit, že barevné izolační pásky se jeví jako průsvitné pro infračervené světlo. Proto není možné použít samotnou modrou nebo červenou pásku pro vyznačení trajektorie, protože by ji IČ senzorový modul nerozpoznal (pro něj je páska průsvitná). Z tohoto důvodu je potřeba barevné úseky podlepit černou páskou. Pak funguje rozpoznávání barvy i detekce pozice čáry. V důsledku bude celá trajektorie vyznačena černou páskou a teprv určité úseky se vyznačí přelepením černé pásky modrou nebo červenou.
2010-09-17 První prototyp senzoru pro detekci překážek. Tři IR LED postupně vysílají modulovaný signál do třech směrů. Pokud se v některém směru nachází překážka, paprsek se odrazí zpět a je detekován IR přijímačem SFH-5110. Změnou střídy signálu je možné snížit dosah, na který detektor rozpoznává překázku. Tímto je možné (jen velmi přibližně) odhadnout vzdálenost překážky.
IR LED budou velice nízko nad povrchem, takže hrozí nebezpečí, že se parpsek odrazí od samotného povrchu, i pokud nebude přítomná žádná překážka. Obava částečně potvrzena testováním prototypu. Řešením je snížit dosah senzoru (?)
Navíc, tento modul bude využit i pro detekci vizuálního kontaktu mezi dvěma roboty. Každý robot bude mít podobné zařízení ještě v zadní části. Pokud se k sobě dva roboti sledující stejnou čáru přiblíží dostatečně blízko, navzájem se díky tomuto systému identifikují. (Každý robot bude za jízdy vysílat svůj jednoznačný kód a přijímat kódy ostatních "účastníků provozu"). Ve chvíli, kdy dojde k potvrzení vizuálního kontaktu, spojí se roboti pomocí Bluetooth a vyřeší potenciální kolizní situaci.
testovací zapojení na nepájivém kontaktním poli - mikrokontrolér ATmega8
2010-10-21 Vyrobil jsem dvě testovací desky pro mikrokontroléry ATxmega128A1 a ATxmega128A3. Každý port je vyveden na dvouřadý desetipinový kontektor, k těmto portům připojím další moduly.
Do mikrokontrolérů jsem pomocí zapůjčeného programátoru AVR Dragon nahrál bootloader avr-xboot. Dragona už jsem musel vrátit, nicméně díky bootloaderu teď mohu desky programovat pomocí obyčejného sériového převodníku.
testovací deseky pro mikrokontroléry XMega - pouzdro TQFP
2010-10-21 Prototyp senzorového modulu pro detekci pozice a barvy čáry. Pomocí čtyř fototranzistorů a pěti IR LED budu měřit odrazivost povrchu v osmi místech pod modulem.
Uprostřed modulu je senzor osvětlení obklopený barevnými LED, tímto budu detekovat barvu čáry.
Senzorový modul bude umístěn pouze několik milimetrů nad povrchem. Bude na vlastním tištěném spoji, a tento spoj připevním k hlavní desce pomocí mini-kolíkové lišty.
kalibrační deska pro senzorový modul - velikost odporů k fototranzistorům určím experimentálně
2010-10-21 Druhý prototyp detektoru překážek, který bude zároveň sloužit pro optickou komunikaci mezi roboty. Na tomto prototypu je vidět princip uchycení menší desky k té hlavní pomocí mini-kolíkové lišty. Z druhé strany plošného spoje nesoucího IR LED bude naletován senzorový modul.
2010-11-02 Důležitá událost z hlediska financování tohoto projektu: Materiál na PocketBota mi bude sponzorovat MFF.
2010-11-15 Klíčová součást vznikajícího robota! Pepa Vandělík mi vyrobil podvozek s enkodéry. Princip fungování zůstal stejný jako u prvního PocketBota; kolečko je přitlačováno k ose motorku pomocí neodymiového magnetu. Kolečka jsou z o-kroužků průměru 8mm. Součástí kolečka je buben s dvaceti enkodérovými pruhy. To znamená, že na jednu otočku kolečka enkodér zaznamená 40 tiků, tedy 1 tik na každých 625µm dráhy. (nebo, chcete-li; 16tiků na jeden centimetr)
Střídání tmavých a světlých pruhů je detekováno infračerveným reflexním senzorem GP2S60. Senzor je přiletován přímo k DPS, což přináší výhodu jednodušší montáže.
Motorky z vrtulníčku mají na své rozměry neuvěřitelný výkon, což je příslib toho, že PocketBot 2 bude daleko rychlejší než jeho první verze. (PocketBot 1 byl poháněn vibračními motorky z mobilního telefonu a dosahoval maximální rychlosti 0.6ms-1)
Jak vidno, nakonec jsme se vzdali myšlenky kvadraturních enkodérů, neboť přesná montáž dvou senzorů, které by poskytovali správně fázově posunutý signál, je při tloušťce enkodérového proužku 0.4mm příliš obtížná. Nicméně i s jedním senzorem lze dosáhnout uspokojivého rozlišení. Nevýhodou je, že není možné určit směr otáčení, toto budu muset pořešit softwarově.
kalibrační deska pro nastavení enkodérů
2010-12-17 Sestavena a otestována nabíječka. PocketBot bude napájen Li-Pol akumulátorem o kapacitě 190mAh. Nabíjení Li-Pol není žádná sranda, na internetu se to jen hemží varovnými videi vybuchujících Li-Pol článků.
Senhal jsem jednočipovou nabíječku MCP73837-FCI, která vyžaduje jen minimální počet externích komponent (a tedy je minimální šance že při sestavování něco zanedbám a následně mi článek shoří). V datasheetu je všechno hezky popsáno včetně ukázkových zapojení, jedno z nich jsem použil. Kromě blokovacích kondenzátorů je potřeba jen rezistor, kterým se nastaví nabíjecí proud. Nabíjecí proud je nepřímo úměrný velikosti rezistoru, v datasheetu je vzoreček, takže postavit funkční nabíječku vyhovující konkrétní aplikaci je triviální.
Já jsem tam dal místo rezistoru trimr, abych mohl snadno měnit nabíjecí proud. Ještě bych mohl zdůraznit jeden detail - nabíjecí čip má vstup pro teploměr, kterým kontroluje teplotu nabíjeného článku. Nicméně (podle datasheetu) není nutné teploměr používat. V takovém případě je ale potřeba zapojit místo teploměru rezistor vhodné hodnoty, jinak nabíječka odmítne nabíjet.
Potěšila mě indikace stavu nabíjení pomocí LED. Zkrátka - v jednom čipu je všechno co potřebujete k realizaci slušné nabíječky.
2010-12-25 Otestoval jsem bluetooth modul BTM330. Modul bude umístěn v zadní části robota, to znamená, že přímo z druhé strany bude přimontován podvozek. Měl jsem (celkem oprávněně) strach, že hliníkový blok a běžící motory umístěné hned na druhé straně plošného spoje přehluší rádiovou komunikaci.
Zprovoznil jsem modul v testovacím režimu (pomocí software od CSR) a oddychnul jsem si, když se mi podařilo připojit se mobilem k BT modulu na vzdálenost několika metrů. A to prosím anténu dělilo od běžících motorů jen pár milimetrů plošného spoje!
bluetooth modul - to napravo je SMD chip anténa
Každá z výše popsaných desek obsahuje nějakou funkční část robota. Když se to všechno složí dohromady, máme tu kompletní hw platformu pro PocketBota 2, na které už lze testovat software. Pointa celé věci je v tom, že robota do krabičky od sirek nechám vyrobit teprve ve chvíli, kdy budu mít jednotlivé moduly otestované a budu si jistý, že na nich není (po hardwarové stránce) co zlepšit.
Představte si tohle celé v krabičce od sirek. Tak to je PocketBot 2.
2011-01-28 Jsou dvě cesty jak realizovat bluetooth komunikaci. Nejčastěji se člověk setkává s BT moduly, které emulují sériový port. Vlastně je to taková bezdrátová sériová linka, kterou zajišťuje bluetooth protokol RFCOMM. Použití takového modulu je velice snadné, je to v podstatě úplně transparentní náhrada sériového kabelu. Z modulu vedou vodiče Rx, Tx do mikrokontroléru a v operačním systému se vytvoří virtuální sériový port, ke kterému lze přistupovat úplně stejně jako ke skutečnému.
Pak je tu druhá *hardcore* možnost - použít HCI modul (což je v podstatě jen rádiová část pro Bluetooth) a veškeré vyšší vrstvy bluetooth stacku implementovat v mikrokontroléru. To mimo jiné obnáší pročíst víc jak tisíc stránek Bluetooth specifikace. Na druhou stranu, HCI modul dává možnost realizovat úplně cokoliv, na co si vzpomenete.. Žádná omezení bezdrátové sériové linky propojující dvě zařízení. Najednou se otvírají možnosti broadcastingu a komunikace v rámci skupiny robotů. Propojení robotů do piconetu či scatternetu. A nebo například použití bluetooth HID profilu pro ovládání robota jakýmkoliv HID zařízením. (Většina telefonů podporuje HID profil sloužící k bezdrátovému ovládání kurzoru myši a několika kláves počítače. Takže teoreticky lze - bez instalace jakéhokoliv programu do mobilu - umožnit komukoli ovládat robota prostě tím, že se k němu mobilem připojí stejně jako se připojuje ke svému PC.)
Takže otázka zní: RS232 BT modul nebo HCI? Bezdrátový sériák, nebo skutečný bluetooth? Zkuste hádat jakou cestu jsem si vybral já. :)
Ono popravdě, na výběr jsem vlastně ani tolik neměl.. RS232 BT moduly jsou pro pocketBota příliš velké, takže jsem koupil miniaturní HCI moduly BTM-330. Tyhle HCI moduly mají ještě jednu výhodu, jsou tak o polovinu levnější než moduly emulující sériovou linku.
V počítači i v robotovi musí běžet nějaký bluetooth stack, tedy kus kódu, který aplikaci zpřístupní rozličné bluetooth protokoly. BT stack je tedy vrstva mezi HCI modulem a aplikací.
Rozhodl jsem se, že ovládací program pro robota naprogramuji v Javě. Podpora BT v Javě SE je přislíbená specifikací JSR-82. Je fajn, že že nějaká taková specifikace vůbec existuje, ovšem najít volně šířitelnou multiplatformní implementaci této specifikace není snadné. Po nějakém tom hledání jsem našel přesně to, co pro svůj projekt potřebuji: opensource stack Bluecove. Bluecove plně podporuje dva nejdůležitější BT stacky, totiž BlueZ na Linuxu a WIDCOMM na Windows. Za zmínku stojí, že Microsoft Windows Bluetooth stack (Winsock), NEPODPORUJE přímý přístup k L2CAP vrstvě z aplikace, takže je pro můj projekt zcela nepoužitelný. Přesto je ale Winsock v Bluecove částečně podporován, ještě vedle BlueSoleil stacku, ale ten je dost problémový.
Používání BT stacku z prostředí Javy je nádherně intuitivní a snadné. Napsal jsem pár řádků kódu a už jsem po chvíli bez obtíží posílal L2CAP pakety z jednoho počítače na druhý. Prostě paráda.
2011-02-09 Tak, teprve tady to začne bejt drsný. Juso, kamarád z bývalého Eurobotího týmu, mě nasměroval na lwBT stack. Tento open source stack je určený pro embedded zařízení a byl vyvinut jako síťová vrstva pro lwIP. Juso už částečně portoval lwBT na mikrokontroléry AVR, čímž mi značně usnadnil práci.
Stack lwBT testuji na osobním počítači, ke kterému mám přes sériák připojený HCI modul. Proč to dělám takto je celkem zřejmé, z mikrokontroléru bych totiž tak složitý kód nikdy nedokázal odladit. Stack lwBT očekává, že s ním HCI modul bude komunikovat protokolem H4. Protokol H4 je triviální a moc toho neumí, z principu je nespolehlivý, protože nezajišťuje žádné ověřování. To je také možná důvod, proč byl v HCI modulech BTM-330 místo H4 od výroby nastaven protokol BCSP.
Nastavení modulů lze měnit softwarem Casira BlueSuite od CSR. Je to ale dost zrádné, protože po přepnutí komunikačního protokolu z BCSP na H4 už se software nedokáže s modulem domluivit. Sice má ten software podporovat i rozhraní H4, ale mě se už nepodařilo k tomu modulu po přepnutí protokolu připojit. Skoro bych se vsadil, že bude problém někde v řízení toku. Chvíli jsem s tím neúspěšně experimentoval a pak jsem se na to vykašlal. Ostatně, modul se přepnul správně do H4 a začal komunikovat s lwBT stackem, takže Casiru už jsem k ničemu nepotřeboval.
Když jsem modulu poslal první HCI příkaz a dostal jsem odpověď, měl jsem z toho neuvěřitelnou radost. Ten první krok je vždycky nejtěžší. (Poznámka pod čarou: Byl to podobný pocit, jako když jsem před víc jak třemi roky začínal programovat mikrokontroléry: Živě si pamatuji ten okamžik, kdy se mi podařilo flashnout první kód do ATmegy162. Je to jako když člvěk přeskočí hlubokou propast plnou nástrah, jejichž existenci tušil jen podvědomě. Ale odteď už ví, že už nikdy nebude muset skákat takhle daleko, že odteď už může jít vycházkovým tempem a dojde kam bude chtít.. Protože už JE na té správné straně propasti.)
Takže hned co jsem zjistil, že si s modulem rozumím, začal jsem si hrát. Poslal jsem HCI paket nastavující jméno zařízení, povolil jsem scanování page a inquiry requestů a voalá - na obrázku vpravo vidíte výsledek :)
Vypadá to efektně, ale zatím se mi vlastně podařilo jen hrozně málo, ještě spoustu práce mě čeká; chci zprovoznit párování, L2CAP, SDP, možná taky ten HID.. Ale RFCOMM ne, ten mi je k ničemu. L2CAP bude pro přenášení paketů mezi robotem a počítačem lepší, protože zajišťuje encapsulaci paketů. Z tohoto hlediska by bylo použití RFCOMM krokem zpátky.
Dlouho jsem zápasil s lwBT stackem, po malých krůčcích jsem se posouval ke kýženému cíli - přenosu L2CAP paketů. S každou další objevenou chybičkou jsem do kódu pronikal hlouběji a hlouběji, až jsem dospěl k poznání, že kód lwBT stacku je dále neudržovatelný. Jistě by se mi L2CAP nakonec nějak rozchodit podařilo, ale jakmile bych chtěl stack rozšířit o broadcasting nebo HID, znamenalo by to opět spoustu práce a ladění.
Nicméně po těch všech útrapách s lwBT stackem jsem si osvojil BT specifikaci (všechno zlé je k něčemu dobré). Jednoho večera, když jsem do noci ladil konfiguraci L2CAP spojení, mi došla trpělivost. To už si snad ten BT stack můžu napsat rovnou sám a lépe! Než jsem se ale pustil do psaní vlastního stacku, udělal jsem znovu a důkladněji rešerši už hotových BT stacků.
2011-03-16 A skutečně jsem našel výborný stack pro moje potřeby: LUFA BT stack. Je to součást projektu LUFA, což je USB stack pro mikrokontroléry AVR. Narazil jsem na článek popisující úžasnou věc - že je možné připojit k mikrokontroléru běžný USB BT modul za pár dolarů a mít plnohodnotný bluetooth. Kdybych to věděl dříve, tak jednoznačně volím tuto cestu. Nicméně HCI moduly už mám nakoupené a ATXmega nemá HW podporu pro USB..
Studoval jsem Deanův kód BT stacku a byl jsem z něj nadšen. Přehledná struktura kódu, výstižné názvy proměnných a funkcí, srozumitelné komentáře.. Ale hlavně oceňuji úžasnou práci se strukturami! Srovnejte následující zápisy (vyplňování dat do paketu):
((uint16_t *)data->payload)[0] = pcb->scid; // lwBT
ResponsePacket.ConfigurationResponse.SourceChannel = ChannelData->RemoteNumber; // LUFA BT
Myslím, že tato ukázka stačí, abyste si mohli udělat o obou kódech obrázek. lwBT je C-čkový kód ze "staré školy" - je plný hranatých závorek a přetypování, místo kterých by se daly použít přehledné struktury.
Ale abych byl úplně objektivní, musím přiznat, že v lwBT má implementovány funkcionality, které v LUFA BT úplně chybí - například reassembling fragmentů ACL paketů. Dle mého názoru lze ale snadněji rozšířit LUFA BT o nové věci, než odladit ty už implementované v lwBT.
Takže; našel jsem ideální BT stack, ale je tu jeden drobný detail: s BT modulem komunikuje přes USB. Jenže já potřebuju UART. Způsob posílání HCI paketů přes USB se liší od toho jak se posílají HCI pakety po UARTu. Bude potřeba kód v určitém místě uříznout a naroubovat na vlastní interface UART HCI. Přestože je přenos dat přes USB vyspělejší než po UARTu (signály jsou oddělené od dat pomocí pipes), podařilo se mi pomocí drobných zásahů předělat stack tak, aby fungoval s UART HCI. Po dvou večerech práce jsem už úspešně posílal L2CAP pakety tam i zpět. Prostě paráda! :)
Mám z LUFA BT radost ještě z jednoho důvodu; v budoucích projektech použiju místo HCI modulu levný USB BT donge, takže plnohodnotný bluetooth vyjde jen na pár dolarů.
printf( ); na mikrokontrolérech2011-03-20 Posílat z mikrokontroléru čitelně formátované výpisy s čísly není nikterak snadné. Až doteď jsem čísla převáděl do ASCII reprezentace pomocí funcí itoa( ); zkrátka nic příjemného. Dnes došlo k zásadnímu zlomu. Objevil jsem, že lze přenastavit standartní céčkový výstup stdout tak, aby využíval pro výpis jednotlivých znaků libovolnou funkci. Tedy jednoduše mu akorát podstrčíte funkci, která posílá byty na UART, a od té chvíle můžete využívat printf v plné parádě. Jak se to přesně dělá se můžete podívat do projektu LUFA, konkrétně na soubor LUFA/Drivers/Peripheral/SerialStream.c. Podobně se dá přenastavit i vstup stdin.
2011-03-20 Dnes jsem portoval odladěný BT stack na mikrokontrolér ATXmega. Zběžně jsem provedl několik testů. Posílal jsem si do PC 32bytové L2CAP pakety; dokážu jich protlačit přibližně 100 za vteřinu, tedy přenosová rychlost se pohybuje okolo 3.2kBps. Pro mojí potřebu to akorát stačí. Do počítače budu totiž periodicky posílat stav senzorů a enkodérů, a aktualizace stavu robota stokrát za vteřinu je víc než dostatečná.
Ale stejně, přiznám se, že jsem o rychlosti bluetooth trochu jiné představy, a toto zjištění mě zprvu zklamalo. Když jsem se ale zamyslel nad tím, kde by mohlo být úzké hrdlo, v zápětí mi došlo, že HCI modul komunikuje s ATXmegou po UARTU (jen) na 38400 baudech. Je tu tedy ještě potenciál pro zvedání výkonu.. Zajímá mě to zejména z toho důvodu, zda je možné protlačit přes BT obraz z mini kamerky (to jsou mé plány do budoucna).
Potěšilo mě, že bluetooth na PocketBotovi má celkem slušný dosah (přes celou místnost), a to přesto, že je anténa umístěna přímo nad zapnutými motory. Modul BTM-330 žere přibližně 30mA při plném vysílacím vytížení a průměrně asi 3mA v klidovém stavu, což jsou vcelku rozumné hodnoty.
2011-02-19 PocketBot2 abstract for Infomatrix 2011 (PDF, 1.6MB) - obsahuje shrnutí z tohoto webu a první 3D vizualizaci PocketBota2, vygenerovanou v Eagle3D a vyrenderovanou v POV-Ray.
2011-02-13 S projektem PocketBot2 jsem postoupil do finále soutěže Infomatrix. Letos opět poletím do Bukurešti :)
první 3D vizualizace robota (zjednodušená,
senzorový modul bude na samostatné DPS)
2011-04-01 Jak už jsem zmínil dříve, PocketBota programuji v Céčku, ale ovládací aplikaci jsem se rozhodnul naprogramovat v Javě. To přináší trochu komplikace s výměnou dat mezi těmito dvěma programovacími jazyky. Bluetooth L2CAP pakety chodí jedna radost, teď je otázka, v jakém formátu má být jejich obsah. Jediná rozumná možnost je posílat čísla binárně. V několika projektech už se mi osvědčilo jednoduché a snadno udržovatelné řešení - strčit do paketu celou céčkovou strukturu naplněnou daty. Taková komunikace funguje bez problémů mezi C a C++ (jen je třeba použít packed struktury, kvůli tomu jak jsou zarovnány položky struktur v paměti). Kupodivu byla tato metoda průchozí i při komunikaci mezi C a Delphi, jak jsem si ověřil u PocketBota 1.
Ale v Javě je tomu jinak. Úplně jinak. Java zná jen objekty, o strukturách v céčkovém smyslu tu nemůže být ani řeč. Navíc ani nepodporuje některé datové typy pro Céčko běžné (unsigned int). Jak z toho ven?
Naštěstí existuje knihovna Javolution, která do Javy doplňuje možnost dělat spoustu věcí efektivněji. Já jsem šáhnul po třídě Struct, která implemetnuje klasickou céčkovou strukturu, se všemi rozličnými datovými typy.
Aby toho nebylo málo, ještě se ukázalo, že Céčko je s Javou nekompatibilní z hlediska endianity bytů. Nicméně i tohle šlo velice snadno v Javolution struktuře nastavit.
2011-04-02 Otestován senzorový modul, bezdrátová realtime vizualizace naměřených dat.
2011-04-03 Vizualizace ujeté trajektorie - funguje nad očekávání dobře.
2011-04-08 Narazil jsem na problém se senzorem pro detekci překážek a ostatních robotů. Můj původní záměr byl udělat senzor podobný tomu, co popsal popsal RNDr. Josef Hanzal v RobotRevue 09/2010. Akorát s tím rozdílem, že by mezi jednotlivými měřeními byly dlouhé pauzy, ve kterých bych poslouchal zprávy od ostatních robotů v blízkosti. V článku je uvedeno, že přijímač mění citlivost podle síly signálu a proto je třeba před každým měřením nechat přijímač pár milisekund "odpočinout". Po dlouhém experimentování s IR přijímačem můžu dodat: "Ano, ale nenechávejte přijímač odpočívat moc dlouho." Jak se ukázalo, pokud IR přijímač dlouhou dobu nic nepřijímá, velmi zvyšuje svojí citlivost. Takže pak dokáže detekovat i slabý puls odražený od stropu nebo vzdálené zdi, což není zrovna to, co bychom po detektoru překážek chtěli.
Zprvu to vypadalo, že detekce ostatních robotů prostě nemůže fungovat zároveň s detekcí překážek. Pulsy je potřeba vysílat vlastně pořád a na poslouchání není čas, protože pauzy mezi pulsy nesmí být příliš dlouhé, jinak přijímač zvyšuje svojí citlivost.
Dlouho jsem experimentoval s délkami pulzů, hodnotami rezistorů k vysílacím LEDkám i s hodnotou plnění modulovaného signálu. Až jsem nakonec dokonvergoval k nějakým magickým konstantám, pro které senzor vykazuje požadované chování - detekuje překážky a zároveň rozpoznává ostatní roboty. Experimentování s černou skříňkou není zrovna můj styl práce, ale tady už hold nic jiného nezbývalo..
2011-04-11 Navrhuju desku robota, mám rozmístěné všechny součástky a začánám routovat. Přímo uprostřed robota mi vybylo volné místo. Tak jsem tam plácnul akcelerometr :)
2011-04-15 Už mám téměř hotový návrh desky - toto je vizualizace (ještě mi zbývá namodelovat nějaké komponenty)
vizualizace PocketBota2 - senzorový modul není zobrazen
Dokončil jsem desky, toto je hlavní deska robota.
Z nedočkavosti jsem vyrobil papírový model robota, abych viděl jak bude vypadat ve skutečnosti.
2011-04-25 Mám problémy s programem pro robota, nejspíš tam mám race condition. Projevuje se to napříč celým kódem, vznikají dost kuriózní chyby. Příčina je ve schedulovacím systému, budu ho muset navrhnout jinak
2011-04-26 Hotové desky z Pragoboardu, s napětím jsem čekal jak dopadnou, všechno vrtání je v pořádku! Můžu se pustit do osazování. Musím si pospíšit, do soutěže zbývá devět dnů!
3x hlavní deska, 3x sensorový modul, 2x programátor, 4x nabíječka
Osazování desek bylo velmi pracné. Trvalo mi dost dlouho, než jsem naletoval XMegu. Cín se na některé pady nechtěl vůbec chytat. Pak jsem přišel na trik, jak tam ten cín dostat.
Popíšu jak letuju MLF pouzdra v domácích podmínkách. Používám postarší pájecí stanici (mikropájku) s tenkým hrotem, cín 0.5mm a kalafunu - to je základ. Letovat jsem se naučil sám metodou pokus omyl.
2011-04-29 Ukázalo se, že reflexní senzory jsou moc daleko od enkodérových bubnů. Je to tím, že desky jsou o trochu tlustší než ta u prototypu na kterém jsem to testoval. Vyřešil jsem to vyfrézováním větších otvorů pro reflexní senzory, takže jsem je mohl zapustit do desky. V budoucnu by pomohlo použít na DPS tenčí substrát (1mm).
2011-04-30 Robot sleduje černou čáru, jeho trajektorie je vykreslována v řídící aplikaci. Aplikace zároveň zobrazuje aktuální stav senzorů.
2011-05-02 Teprve dnes mi přišly poslední součástky na robota - SMD napěťové regulátory. Do soutěže zbývají tři dny! Doteď jsem tam měl provizorně regulátor v pouzdře TO92, ale ten pracoval max do 100mA, což už bylo velmi na pováženou.
2011-05-04 Narychlo jsem udělal plakáty. Tentokrát jsem nedělal velký A0 plakát (nebyl čas), místo toho jsem vytvořil několik menších plakátů formátu A3.
Oproti loňsku jsem letos udělal i letáček, který budu rozdávat místo vizitek.
2011-05-04 Před odletem jsem vůbec nespal, programoval jsem do půl čtvrté ráno. Potřeboval jsem ještě odladit sledování čáry a detekci barvy.
Pak jsem si sbalil věci. Beru s sebou kompletní výbavu, takže budu schopný opravit libovolnou část robota, v krajním případě dokážu postavit v Bukurešti celého robota znovu. Potom sprcha a na 15 minut jsem se natáhnul na postel, spíš jen jako rituál, abych ukončil jeden den a mohl začít další.
2011-05-05 6:00 - Tak, a je to tu, opět letím s tou krabičkou od sirek do Bukurešti. Přestupoval jsem ve Frankfurtu, měl jsem dvě hoďky na přestup a ztrávil jsem je - hádejte - programováním, nebo vlastně spíš testováním.
Na letišti Otopeni v Bukurešti jsem se potkal s Polákama a pak s Gruzijcema - známé tváře z loňska. Je to jako kdyby mezi dvěma ročníky soutěže uplynulo jen pár týdnů. V minivanu cestou z letiště jsme jen sršeli vtipem a vešekrá únava šla stranou. Zdařený začátek!
Dovezli nás do ISB, kde jsme si připravili stánky. Zítra začíná soutěž! Uvítací ceremonie jak loni, žádné překvapení. Myslím že nejen já jsem byl vyřízený z cesty, takže jsme se po přesunu do RIN Grand hotelu odebrali na pokoje a party jsme odložili na zítřek.
kráska z Ekvádoru, v pozadí stánek mého projektu
Ještě jsem kódil do půlnoci, potřeboval jsem dodělat uživatelské rozhraní k ovládací aplikaci. Nic kritického, ale přeci jen je to důležitá část pro prezentaci. Nějak mi v Javě blbnul Swing, vykreslování komponent hrozně lagovalo, takže jsem to nakonec předělal do AWTčka, což sice nevypadalo moc vábně, ale zas to fungovalo.
2011-05-06 40 hodin bez spánku se muselo nějak projevit, ráno jsem zaspal snídani. Autobus do ISB na soutěž jsem naštěstí stihnul, jen tak tak. Hned po příjezdu jsem se dozvěděl, že budu obhajovat svůj projekt jako první. To byla teda dost rána pod pás. Očekával jsem, že hardwarové projekty se budou obhajovat až druhý den soutěže (jako loni), neboť většinu HW projektů je potřeba odladit a otestovat po převozu.
Zabrala trocha diplomacie, takže jsem získal ještě tři hodinky času. Za tu dobu jsem dal dohromady prezentaci pro projektor a vyladil parametry PID regulátoru. Už jsem si ale nestihnul připravit co budu před porotou říkat. Nezbývá nic jiného než improvizovat; musím to dát z fleku.
Myslím, že tajemství úspěchu bylo zvolit správnou strategii při prezentaci. Měl jsem hotové základní věci - rozpoznávání překážek, čáry, barvy, odometrii, bluetooth.. Vůbec toho nebylo málo, nicméně původně jsem měl v v plánu ukázat mnohem víc. Další kusy robota jsem bohužel dodělat nestihnul, takže jsem tam předváděl jenom toho jednoho. Celou tu prezentaci jsem pojal jako předvádění nové "robotické platformy" která má spoustu možností (ukazoval jsem jednotlivé fungující části, hlavně to vykreslování trajektorie barevně bylo působivé). Zkrátka že ke všem částem je připravený ovladač a robot už jenom čeká na někoho, kdo napíše řídící program, který bude dělat něco zajímavého.
Zmínil jsem možnost komunikace více robotů a vzájemné vyhýbání se, pak také přesný pohyb díky enkodérům.. Zkrátka nebylo to ve stylu "mám robota a naučil jsem ho to a to" ale "navrhnul jsem něco co se dá vyrábět sériově, má to takové a takové možnosti a každý kdo si s tím bude chtít hrát může stavět na mých ovladačích, protože jsou opensource. Nabíječka a programátor jsou v ceně."
V porotě byli profesoři z technických škol, kde se běžně používají podobní roboti pro výuku (i my na škole máme roboty e-Puck). Takže jsem se trefil do černého - PocketBot je sice jen hračka, ale je vhodná ke vzdělávacím účelům. I přes to, že jsem předvedl jen málo z toho, co by robot mohl umět a co jsem chtěl do té doby stihnout, stačilo akorát vzít to při prezentaci za správný konec.
Porotci se mě ptali na spoustu věcí, měl jsem pocit že některými otázkami si mě spíš jenom chtějí proklepnout, jestli je to celé moje práce a zda tomu rozumím. Ani jednou jsem nezaváhal s odpovědí, znám naprosto každý detail svého robota. Větší radost mi dělaly otázky, ze kterých byl patrný zájem o projekt: jaké má robot možnosti a jak jeho části fungují. Někteří členové poroty se mě ptali i poté, co už začala prezentace dalšího projektu, tak moc je to zaujalo.. A od jednoho porotce jsem dostal vizitku - HIT. Wow. Udělal jsem na ně dojem.
Tím že jsem měl prezentaci před porotou z krku už hned na začátku soutěže, mohl jsem si zbylé dny parádně užít a uvolnit se v multikulturním prostředí.. Přes den jsem předváděl robota návštěvníkům i ostatním soutěžícím. Postupně přicházeli i porotci, jeden po druhém, ukazoval jsem jim detaily ze zákulisí projektu; prototypy a tak. Náhradních baterek jsem měl tolik, že bylo jasné, že se dříve unavím já nežli robot.
Prošel jsem si stánky ostatních soutěžících, prohlídnul jejich projekty, potkal známé tváře a seznámil jsem se s nováčky.
Pak nadešel večer, čas zábavy. Pozval jsem dvě slečny (soutěžící z Rumunska) do hotelového lobby baru na drink, Devi z Gruzie se k nám připojil.. Ale dost Ondřeji! Tohle patří do jiného deníku, ne sem! Odteď už budu psát jenom k věci - o robotovi a soutěži jako takové.
Rumunské upírky a český Honza (slečny soutěžily s filmem o upírech)
2011-05-07 Druhý soutěžní den probíhaly prezentace zbylých projektů, třetí den se konaly výlety, bohužel jsem ale zaspal odjezd, jsa unaven z nočního života.
2011-05-09 No a konečně, čtvrtý den se konala závěrečná ceremonie. Byl jsem velmi zvědavý, jaké místo mi porota udělila. Neměli to vůbec jednoduché, protože letos byly spojené kategorie High School a University Hardware Control. Navíc jsem byl loni Grand Winner, tak jsem byl zvědavý, jak se zachovají.
Ceremonie byla zahájena show s vlajkami - za každou zemi přišel na pódium vlajkonoš a pozdravil hlediště svým rodným jazykem. Potom poděkování porotcům a supervizorům, mezitím vystoupení rumunské dětské taneční skupiny, aby napnutou atmosféru ještě víc pošimrali.
No a pak už konečně vyhlašování medailí. Postupně vyhlašovali bronzové a stříbrné medaile napříč všemi kategoriemi. Tady je potřeba malé vysvětlení, jak funguje systém přidělování medailí na souteži Infomatrix. Je to dost nezvyklé, loni mě to velmi překvapilo. Věc se má následovně: Toto bylo finále soutěže Infomatrix. (V Rumunsku, v Mexiku a snad ještě v dalších zemích se konají kola ve kterých vybírají finalisty. V ČR žádné takové kolo není, takže finalisty vybírají jen na základě několikastránkového abstraktu a mluvené videoprezentace.) Medaili dostane každý kdo postoupil do finále. Všichni finalisti byli rozděleni do tří skupin - bronzové, stříbrné a zlaté medaile. Tedy každý kdo přijel do Bukurešti na finále měl medaili jistou, alespoň tu bronzovou. Nicméně finančně byly ohodnoceny pouze zlaté medaile (a letos vlastně výjimečně i stříbrné medaile dostaly nějaký finanční obnos).
Zlaté medaile byly v kategorii Hardware Control uděleny celkem čtyři.
Na prvním místě se umístil rumunský tým ze střední školy, měli prototyp dvoukolého vozítka typu Segway, s tímto projektem také soutěžili už loni. Znám toho kluka, protože se pravidelně potkáváme na všech soutěžích a přeju mu to, nakonec jsem přece nemohl být dvakrát Grand Winner.
PocketBot2 dostal druhé místo. Tady jsou kompletní výsledky Infomatrix 2011.
Poučen z loňska jsem si naplánoval odlet až na příští den, abychom to mohli večer řádně oslavit.
Infomatrix je naprosto mimořádná událost, má široký záběr témat a účastní se jí studenti z celého světa. Budou mi všichni chybět.
Jeďte tam taky! Ať je i v příštím ročníku soutěže reprezentant z ČR. Rád poskytnu bližší informace, neváhejte mě kontaktovat. Stojí to za to, věřte mi :)
zlaté medaile
2011-07-13 Vyměnil jsem O-kroužek na kolech za větší a ten jsem následně zbrousil, aby se zvětšila styčná plocha. Slibuji si od toho snížení prokluzů. Prokluzy mi totiž vadí při vykreslování trajektorie.
Na fotce vlevo jsou "pneumatiky" z různých druhů O-kroužků. Liší se materiálem a velikostí.
Zbroušený O-kroužek se mi osvědčil, robot má lepší jízdní vlastnosti a odometrie funguje při nižších rychlostech téměř na chlup přesně. Předčilo to mé očekávání.
Enkodéry na kolech pěkně fungují. Dosud jsem data z enkodérů využíval jen pro vykreslování trajektorie, po které se robot pohybuje při sledování čáry. Páskou vyznačená dráha se postupně vykresluje na obrazovce počítače, podle toho jak po ní robot jede.
To ale není hlavní důvod proč jsem do PocketBota umístil enkodéry. Především chci přesně řídit pohyby robota, nezávisle na čáře.
Řízení robota podle enkodérů jsem už programoval do Úmorníka. Ten měl ale kvadraturní enkodéry s 28000 tiky na otočku, což je nesrovnatelně více než kolik má PocketBot. Vzal jsem kód pro řízení Úmorníka, upravil hardwarově specifické věci (PWM pro motory a čtení enkodérů) a ještě jsem musel lépe navrhnout měření rychlosti pohybu, vzhledem k nižšímu počtu tiků na otočku. Také jsem se musel vypořádat s tím, že PocketBot nerozpozná směr otáčení kol. Po namáhavém ladění PID konstant se ukázalo, že kód pro přesný pohyb funguje na PocketBotovi stejně dobře jako na Úmorníkovi.
Robot umí vykonávat tři druhy pohybů: Jízda rovně, rotace na místě a jízda po kružnici. Každý druh pohybu má odpovídající parametry. U všech druhů pohybu jsou rozjezdové a dojezdové rampy (to znamená, že robot se rozjíždí a brzdí plynule).
StraightMovement(speed_in_mps, distance_in_m);
RotationMovement(speed_in_mps, angle_in_deg);
CircularMovement(speed_in_mps, angle_in_deg, radius_in_m);
Při návrhu pohybového subsystému jsem kladl důraz na to, aby funkce vykonávající pohyb byly neblokující. Jednotlivé pohyby jsou řazeny do fronty a vykonávány postupně. Výhoda tohoto řešení je v tom, že robot mezitím může dělat jiné výpočty, konkrétně obsluhovat komunikaci s počítačem přes bluetooth.
A jak to řízení pohybu vlastně funguje? Navrhnul jsem ho jako dvě regulační smyčky. První PID regulátor má na starost udržovat rychlost pohybu robota. Regulovanou veličinou je průměrná rychlost obou kol (což chápu jako "rychlost robota"). Vlastně je to průměr absolutních hodnot rychlostí kol. To proto, že když se kola točí stejně rychle proti sobě (robot se otáčí na místě), tak by průměrná rychlost kol byla nulová, ale to nechci (proč vysvětlím níže). Jenže taky nechci přijít o znaménko (stále rozlišuji rychlost vpřed a rychlost vzad, když robot couvá, má zápornou rychlost. Stejně tak když se točí na místě po směru hodinových ručiček, "rychlost" jeho pohybu je definována jako záporná.) Nejspíš to takhle zní uměle a možná trochu přitažené za vlasy, ale díky tomuto formalismu šlo celkem přirozeně sjednotit vykonávání všech tří druhů pohybů (jízda rovně, otáčení na místě, jízda po kružnici) tak, že jsou vykonávány jednou řídící funkcí, v jednom místě programu.
Jak je to možné? Ještě jsem nepopsal činnost druhého regulátoru. Pracovně mu říkám balance regulator. Ten udržuje poměr dráhy obou kol. Dělá to tak, že "přerozdělí" mezi oba motory plnění, které mu "předepsal" regulátor rychlosti popsaný výše. Pro jízdu rovně vyžadujeme poměr tiků na pravém a levém kole 1:1. A např. poměr 1:4 bude odpovídat jízdě po nějaké kružnici. V praxi to samozřejmě funguje obráceně, na základě poloměru požadované kružnice se vypočte potřebný poměr dráhy kol. V mikrokontroléru je poměr reprezentován podobně jako výše v příkladech, pomocí dvou celých čísel, které lze chápat jako zlomek (čitatel:jmenovatel). Je to z důvodu efektivity výpočtu, neboť regulační smyčku opakuji s frekvencí 200Hz. Připouštím také záporný poměr dráhy obou kol. V takovém případě se kola točí proti sobě. Takže poměr -1 zajistí otáčení na místě. To jakým směrem se robot bude otáčet je určeno znaménkem rychlosti.
2011-08-26 Abych mohl rychlost regulovat, musím ji nejdříve umět správně změřit. V Úmorníkovi jsem měřil počet tiků enkodérů (ds) za jednotku času (dt). Nic překvapivého, to zní přímo jako z definice rychlosti. Fungovalo to dobře, protože enkodéry v Úmorníkovi dělaly desetitisíce tiků na otočku kola. Jenže u PocketBota se ukázalo, že se 40 tiky na otočku už je potřeba zacházet trochu jinak. Najednou se vynořily otázky, jak velké zvolit dt (jak dlouho má trvat "jednotka času"?). Jak ji zvolit, aby se vypočtená rychlost dala považovat za okamžitou rychlost? A co když bude dt moc malé? Pak se kvůli nízkému počtu tiků na otočku začnou projevovat nepříjemné diskrétní vlastnosti enkodéru a rychlost se bude měnit po skocích.. A to už dle selského rozumu není zrovna dobrý vstup pro PID regulátor..
Šel jsem na to tedy z druhé strany. Začal jsem měřit, jak dlouho trvá, než robot ujede jednotku dráhy. Tedy ds byl jeden tik enkodéru, dt jsem měřil timerem. Čas dt lze změřit velmi přesně, neboť u Xmegy lze výstup komparátoru přímo provázat s timerem (input capture) pomocí Event systému. Změřený čas má rozlišení 16bitů, což už se tváří krásně spojitě, narozdíl počtu tiků enkodéru s nízkým rozlišením. Má to ale i stinnou stránku, jak už vás možná napadlo, špatně se tím měří nízké rychlosti, ba co hůř, úplně nejhorší je když se robot nepohybuje vůbec. Já jsem se s touto nepříjemnou vlastností vypořádal timeoutem: Pokud nepřijde do určité doby další impuls, prohlásím že robot stojí. Zamýšleli jste se, jak funguje počítadlo na kolo? Úplně stejně.
Samozřejmě jsem musel otestovat na robotovi, jestli tahle metoda měření rychlosti dává použitelné výsledky.
Test měření rychlosti - graf
Do grafu jsem vynesl vypočtenou okamžitou rychlost v milimetrech za veřinu (osa y) pro každý tik enkodéru (osa x). Protože světlé a černé pruhy enkodéru mají rozdílnou šířku, je vidět, že rychlost se vcelku pravidelně střídá, je různá pro sudé a liché tiky. To lze snadno spravit, stačí průměrovat poslední dva časy. Okamžitá rychlost spočtená z posledních dvou časů je vynesena oranžově. Což už vypadá vcelku rozumně, to se bude řídit pěkně.
2011-09-02 Přišel jsem na zajímavou věc. Doposud jsem při sledování čáry nastavoval u motorů přímo plnění (PWM). Tedy když se robot vychyloval z čáry, u jednoho motoru jsem ubral výkon aby se na čáru vrátil. Jenže když teď mám na robotovi enkodéry a dokážu přesně měřit a regulovat rychlost, možná by stálo za to místo plnění přizpůsobovat rychlost otáčení kol podle pozice čáry. Hlavně jsem si od toho sliboval, že rychlost sledování čáry nebude ovlivněná stavem baterie. Ukázalo se ale, že když řídím přímo rychlost kol, robot podává při sledování čáry daleko lepší výkon. Domnívám se, že je to tím, že rychlost robota je víceméně stále stejná na všech úsecích trati. Dokud jsem nastavoval pouze plnění, na rovných úsecích robot příliš zrychlil a poté vystřelil v zatáčce.
Do budoucna plánuji využít data z enkodérů ještě fikaněji: Robot si zapamatuje první kolo trati a v dalších už bude vědět co ho čeká; ve kterých úsecích může zrychlit a ve kterých má raději zpomalit.
2011-10-22 Robot detekuje barvu čáry. Spolehlivě rozpoznává černou, modrou a červenou. Na červených úsecích zpomaluje a na modrých ví, že může bezpečně zrychlit. RGB data ze senzoru barvy převádím do barevného prostoru HSV a v něm potom určuji barvu porovnáním vzdálenosti odstínů (hue). Černou poznám podle světlosti (value).
2011-10-23
Dneska byl můj šťastný den. Bluetooth komunikace byla až do teď poruchová,
čas od času se prostě přerušilo spojení. Nedocházelo k tomu sice příliš často,
ale když už, tak mě to dost vytáčelo. Hlavně z toho důvodu, že jsem vůbec netušil, kde je chyba.
Teď už to vím. Chyba byla v robotovi, mohl za to malloc (jak jinak, v céčku, že..).
To že malloc není reentrantní už jsem si na vlastní kůži vyzkoušel dříve,
a hodně rychle jsem ho vyndal ze všech interruptů, aby byl volán vždy jen z jednoho (main) vlákna.
Nicméně stejně mě ten malloc zradil. Popíšu tady jak a proč jsem alokoval paměť, a taky
proč by se mělo takovýmto řešením obloukem vyhýbat. Nechť je to výstraha pro ostatní.
Takže, vezmu to trošku ze široka. PocketBot posílá do počítače různé druhy paketů. Všechny pakety mají stejnou hlavičku (typ paketu, checksum, délka) a za ní následuje payload, obecně různě dlouhá data.
Mallocem jsem si alokoval na heapu prostor pro paket, do něj jsem nasypal data a pak zavolal funkci která paket dokončila (spočítala checksum) a odeslala.
Po odeslání se paměť zase uvolnila pomocí free. Tohle se dělo při odesílání každého paketu, přibližně 20x za vteřinu.
Jenže čas od času paměť jaksi došla (asi kvůli fragmentaci?) a mikrokontrolér se zpravidla resetoval. Skoro bych se vsadil, že se potkal stack s heapem
začaly se dít ošklivé věci..
Jaké z toho plyne poučení? Na mikrokontrolérech se vyhýbat mallocu obloukem, protože způsobuje chyby které se velmi těžko odhalují.
No ale jak to teda udělat? Kde vzít tu paměť pro nově vzniklý paket? Odpověď je prostá. Na stacku. V některých případech je malloc
nenahraditelný, ale zrovna u odesílání paketů potřebujeme paměť jen po dobu kdy se vykonává daná funkce. Níže je příklad, jak alokovat na zásobníku:
void SendPocketBotStatePacket(void) {
// alokujeme paměť na zásobníku
uint8_t packet_mem[sizeof(packetHeader_t) + sizeof(pocketBot_state_t)];
// pro pohodlí budeme pracovat přímo s hlavičkou paketu, vytvoříme si pointer
packetHeader_t * packet = (packetHeader_t*)&packet_mem;
// nastavíme vlastnosti paketu
packet->payloadLength = sizeof(pocketBot_state_t);
packet->type = 0x01;
// zkopírujeme data do paketu
*((pocketBot_state_t*) packet->payload) = pocketBot_state;
// spočte checksum a odešle paket
SendPacket(packet);
} // v místě opuštění funkce se zároveň uvolní alokovaná paměť na zásobníku
Toto asi nebude pro céčkaře žádné překvapení. Za zmínku ale určitě stojí jedna věc, kterou céčko umožňuje. V tomto příkladě je velikost potřebné paměti
známa už v době překladu, je to velikost jistých struktur zjištěná pomocí sizeof. Ale pokud bychom předem nevěděli, kolik paměti potřebujeme,
můžeme v hranatých závorkách použít jakýkoliv výraz. Vůbec to nemusí být konstanta známá v době překladu. Kompilátor to zařídí tak, aby se při volání funkce
udělalo na stacku tolik místa, kolik zrovna potřebujeme. To je úplná senzace. Tato vlastnost je unikátní pro céčko, protože v C++ už nic takového možné není.
Tady jeden jednoduchý příklad:
void test(int size) {
// velikost pole je předána jako parametr funkce, tedy v době překladu je ještě neznámá
char mem[size];
// tohle vypíše náhodné znaky z vrcholu zásobníku, protože pole není nijak inicializováno
for (int i=0; i<size; i++) {
printf("%d ",mem[i]);
}
} // po opuštění funkce se paměť na zásobníku uvolní
Myslím, že tohle je konstrukce kterou by měl každý céčkař znát.
2011-10-23 Zatěžkávací zkouška - PocketBot2 vydrží na jedno nabití jezdit po čáře půl hodiny. Jakmile klesne napětí baterie pod 3.3V, přepne se do úsporného režimu. Nabízí se srovnání s první verzí PocketBota, ten vydržel jezdit po čáře až 40 minut. PocketBot2 je energeticky hladovější než první verze, za což může především bluetooth. Po celých třicet minut jízdy čile komunikoval s počítačem, zasílal data z enkodérů, senzoru barvy a akcelerometru.
Nejlepší způsob jak prezentovat robota (a vlastně i jakýkoliv jiný projekt) je natočit k němu videoklip. Lidi nemají čas prokousávat se hromadou textu popisujícího, co robot umí a jak to dělá. Chtějí tu informaci hned. Chtějí vědět, o co vlastně jde. Teprve potom, co si udělají prvotní představu, jich možná pár zabrousí i k popisu nějakých těch technických detailů..
Jeden obrázek vydá za tisíc slov, jedno video vydá za tisíce obrázků.
Ještě předtím než jsem vzal do ruky kameru, už jsem měl v hlavě přesnou představu, jak by mělo výsledné video vypadat. (Napsal jsem si k tomu dokonce scénář a točil jsem podle něj, abych na nic nezapomněl.) Rozhodl jsem se zopakovat některé motivy, které se osvědčily před třemi lety v prvním prezentačním videu PocketBota. Konkrétně úvodní vyjmutí robota z krabičky a pak zvýrazňování jednotlivých součástek ve schématu. Co se týče kvality, rozhodnul jsem se pro nekompromisní Full HD 1080p. Takže, od začátku jsem přesně věděl, co chci. Zbývalo jen najít vhodné prostředky, kterými svou ideu zhmotním. Byla to cesta plná slepých odboček, a proto ji teď popíšu, aby další nemuseli zbytečně bloudit. (Navíc to taky trochu píšu kvůli sobě, protože člověk rychle zapomíná na postupy, které přeci jen nedělá denně..)
Nejlepší zařízení pro záznam videa, které jsem měl v té době k dispozici, byl mobil Galaxy SII. Je až neuvěřitelné, jak dobře vypadá video natočené objektivem o velikosti špendlíkové hlavičky. Chloubou Galaxy SII je natáčení Full HD videa, takže to co z mobilu vypadlo, bylo nad očekávání použitelné. Jenže to mělo jeden háček a tím byla zmíněná miniaturní velikost objektivu. Aby video dobře vypadalo, bylo třeba scénu pořádně nasvítit.
Zprvu jsem spoléhal na denní světlo a vyčkával jsem, až se obloha rozjasní. Jenže podzimní počasí sluníčku moc nepřálo, takže jsem si nakonec ze školy zapůjčil dvě 500W halogenová světla na přisvětlení. Světla bylo najednou v pokoji tolik, že jsem si musel nasadit sluneční brýle. Přímé nasvětlení nepřipadalo v úvahu kvůli tvrdým stínům, tak jsem před reflektory umístil bílý papír na pečení, který světlo pěkně rozptýlil. Nejprve jsem scénu nasvětloval oběma reflektory přímo, přes rozptylovací papír. Video bylo sice krásně ostré i při rychlém pohybu robota, ale objevovaly se na něm nežádoucí tmavé pruhy, zřejmě artefakt zapříčiněný 50Hz ze zásuvky. Proto jsem jedno světlo namířil odrazem od stropu; pruhy zmizely, ale při rychlém pohybu už bylo video rozmazané. Nemám sice rád kompromisy, ale tady jsem musel ze svých požadavků ustoupit. Přeci jenom je to jen mobil, nemůžu od něj očekávat kdovíco.
nasvětlení scény, místo stativu jsem použil držák pro navigaci do auta
Krom natáčení skutečného robota jsem ještě potřeboval synchronně zaznamenávat dění na obrazovce. V řídícím programu se zobrazoval aktuální stav senzorů a vykreslovala se trajektorie robota. Do prezentačního videa jsem potřeboval složit video z kamery se záznamem z obrazovky. Každý kdo někdy něco takového zkoušel, mi dá za pravdu, že to není žádná hračka.
V prostředí Linuxu existuje celá řada screen-capture prográmků. Na důvod, proč je jich tolik, jsem přišel v celku záhy; žádný z nich nedělá totiž přesně to, co od něj uživatel potřebuje, a nebo to dělá špatně. Takže klasický problém, máme spoustu programů na záznam obrazovky, který z nich to ale opravdu umí? (Myšleno: produkuje výstup v požadované kvalitě, tedy bez vynechávání snímků). Vyzkoušel jsem snad všechny a nakonec jsem zůstal u XVidCap, který uměl ukládat jednotlivé snímky v PNG, zvládal víceméně obstojně 30fps a navíc byl upřímný (rozuměj: sdělil uživateli, kolik snímků vynechal, protože nestíhal zaznamenávat. Velmi užitečná informace, lepší než když na to člověk přijde teprve při postprocessingu videa.) Stejně mě však u některých záznamů zradil a výsledek byl nepoužitelný (černé čtverečky v obrazu, někdy i nerespektování požadovaného fps).
Celkové shrnutí: Záznam obrazovky na linuxu je tragédie. Když člověk pátrá, proč to nefunguje, chtě nechtě se noří do hlouby X Window System. Ale kde že jsme to začínali? Potřeboval jsem jenom rychle natočit 30fps záznam obrazovky. Achjo.
Co si budeme povídat, nechtěl bych to natáčet znovu. Aby klip vyšel, musely naráz zafungovat všechny tři složky procesu: robot, kamera a záznam obrazovky. Bylo potřeba postupně: zapnout reflektory osvětlující scénu, nastavil kameru, navázat spojení s robotem, nastavil záznam obrazovky v počítači, zapnul nahrávání na kameře i v počítači a konečně spustit činnost, kterou měl robot vykonávat.
V praxi to vypadalo takhle:
Natáčel jsem to celý víkend. Nejhorší je práce s nástroji, na které se nemůžete spolehnout. Tohle už nikdy víc.
Střižna pro prostředí Linux. Člověk se podívá na feature list, prohlídne screenshoty a už se těší, až bude moci s tímto softwarovým balíkem pracovat. Nadšení opadne celkem záhy, když aplikace po první minutě práce crashne. Mohla to být blbá náhoda, řekne si jeden. Ale nebyla, Kdenlive padá s železnou pravidelností. To člověka naučí ukládat si práci v každém kroku. Zkusil jsem v tom cvičně sesynchronizovat video robota se záznamem z obrazovky. Abych na Kdenlive jenom nenadával, rozmanité volby překrývání vrstev videa mě v celku nadchly. Jenže pak jsem přišel na to, že v podstatě neexistuje nic jako template pro titulky a popisky, takže bych třeba i jen hloupou velikost a řez písma musel měnit u každého titulku zvlášť. Ortel: nezájem. Pro svou práci potřebuju něco univerzálnějšího.
Jste programátor? Potřebujete sestříhat video na snímek přesně? Nebaví vás práce s lagujícím GUI? Pak je AviSynth ideální nástroj pro vás. AviSynth není nic víc než frameserver, který zpracovává váš skript. Ve skriptu složíte dohromady jednotlivé klipy, proženete je filtry dle libosti, doplníte o titulky a hudbu. Všechno v textové formě, s možností deklarování vlastních funkcí a úžasnou udržovatelností. A protože váš skript je vlastně jen návod jak z klipů sestavit video, je možné ho pohodlně verzovat GITem, jako jakýkoliv jiný zdrojový kód.
Dovolím si jedno trefné přirovnání: AviSynth je pro střih videa to samé jako LaTeX pro sazbu textu.
Plná síla skriptovacího jazyka AviSynth se projevila při zvýrazňování jednotlivých částí robota ve schématu. Kdybych to měl dělat ručně třeba v Kdenlive (případně v MovieMakeru nebo v čemkoliv jiném..), tak se uklikám, nemluvně o tom, že pokud bych se rozhodnul změnit animaci textu nebo trochu víc rozostřit pozadí, musel bych změnu dělat na každém místě zvlášť. Z toho by programátorovi vstávali vlasy hrůzou na hlavě. V AviSysnth je to otázka jedné funkce, která dostává jako parametr jméno komponenty, kterou chci zvýraznit. Najde si potom odpovídající předpřipravené průhledné PNG a vykreslí ho na rozmazané schéma. Hotovo; krásně, elegantně, udržovatelně.
AviSynth je úžasný nástroj který nemá konkurenci. Jak už to tak ale bývá, je tu pár zádrhelů se kterými je nutné počítat:
DirectShowSource pro vložení klipu. Pokud skládáte víc takto načtených klipů přes sebe, tak náhled videa nebude frame-accurate, videa si utečou (jedno bude hrát rychleji než druhé) a je pak nemožné videa sesynchronizovat. Použij místo toho FFVideoSource, to zaručí, že snímky půjdou u obou videí synchronně.ffmpeg.exe -i presentation.avs -vcodec libx264 -sameq "output/x264_1080p.avi") Enkódované video se však pokaždé v nějakém místě zaseklo. Zkoušel jsem všechny možné kodeky, pak i různé kombinace verzí AviSynth a ffmpeg, i jiný počítač a operační systém. Nic nepomáhalo.
Video bylo celé hotové, jenom nešlo vyexportovat!
Po celodenním boji jsem celé věci přišel na kloub: Problém byl v pluginu SubtitleEx pro vkládání titulků. Titulků mám ve videu spoustu, používal jsem je naprosto korektním způsobem, ale zřejmě jinak, než si představovali tvůrci toho pluginu. Takže s každým vykresleným titulkem se alokovaly prostředky grafické knihovny, které se ale nikdy neuvolnily (jednotlivé části videa jsem oříznul dříve, než titulek zmizel). V jednu chvíli pak už nebylo dost prostředků pro vykreslování titulků a AviSynth umřel na dereferencování null pointeru, bez jakékoliv chybové hlášky. Bug jak hrom. Více v diskuzi, včetně postupu, jak to řešit.
Dalo by se říct, že tohle je chyba autorů (externího) pluginu SubtitleEx. Jenže z diskuze je patrné, že stejnou chybou trpí i nativní funkce Subtitle v AviSynth.
No, každý program obsahuje alespoň jednu chybu.Dodělal jsem chybějící modely některých součástek. Eagle3D je moc pěkný skript do Eagle. Snadno se do něj přidávají vlastní součástky. Trochu oříšek bylo zkombinovat několik desek do jednoho modelu. V PocketBotovi jsou celkem tři desky (senzorový modul, bluetooth modul a hlavní deska). Desky modulů jsem navrhnul zvlášť v Eaglu, vygeneroval jsem jejich 3D model do PovRaye a ten jsem potom vložil do hlavní desky jako jednu součástku. Eagle3D i PovRay jsou tak dobře navrženy, že to nebyl žádný problém.
Z hotového modelu jsem pak nechal vyrenderovat dvě desetivteřinové animace, pohled shora a zezdola. To bylo celkem 600 snímků ve Full HD, renderování trvalo osm hodin na dvoujádru 2.5GHz.
prezentační video, full HD
2011-12-03 PocketBot2 - the matchbox-sized robot - zveřejněna nová stránka o projektu, v angličtině.
2012-02-15 Rychlost robota při sledování čáry nemusí být konstatní. Přímo se nabízí, aby robot na rovných úsecích zvýšil svou rychlost a naopak před obtížnými zatáčkami patřičně zpomalil a mohl je projet, aniž by vyletěl z dráhy. Pokud si dráhu vyznačuji sám, je to jednoduché, složité úseky označím červenou páskou a robot hned ví, že má na daném místě zpomalit. Ale na soutěžích ve sledování čáry (RobotChallenge, Istrobot..) je potřeba to řešit jinak. Během kvalifikace má robot několik pokusů na projetí závodní dráhy. Bylo by pěkné, kdyby si při první jízdě dráhu projel hezky pomalu a zapamatoval si "profil trati". V dalších jízdách by už pak věděl, kde ho čekají ostré zatáčky, překážky či přerušení dráhy a naopak kde jsou rovné úseky, na kterých to může pořádně osolit.
Pravidla soutěží takové chování buďto nijak neomezují (RobotChallenge) nebo přímo navrhují (Istrobot). Jediná podmínka je, že všechen processing musí být v robotovi. Já jsem si zatím udělal takový proof-of-concept algoritmus na záznam trati, zatím jen jako aplikaci v PC postavenou na mojí Javové knihovně pro ovládání PocketBota z počítače.
Jsou různé způsoby jak trať popsat, já jsem si, čistě ze zvědavosti, vybral složitější řešení, které je však podpořené aspoň nějakou teorií.
Takže nejprve trocha té teorie: Ideálně bychom chtěli zaznamenat křivost trati v každém jejím bodě. Poloměr křivosti je dobře definovaný matematický pojem a souvisí s tzv. oskulační kružnicí, která určitou křivku v daném bodě dobře aproximuje (mají shodnou první a druhou derivaci).
V praxi je to jednodušší než v matematice, oprostíme se od spojitosti a nahradíme to nějakou dobrou diskrétní aproximací: Trať rozkouskuju na rozumně malé úseky (delta = 1cm) a představuju si, že tyto úseky jsou vlastně části kružnic (s různým poloměrem). Pro každý úsek spočtu poloměr, tedy vlastně jeho převrácenou hodnotu (to bude křivost trati. Rovný úsek má křivost nula.)
Takto uložený profil trati snadno použiju pro výpočet rychlosti robota v dalších kolech; rychlost robota bude záviset na křivosti úseku před robotem. Je to v celku triviální a v praxi to víceméně funguje, až na jeden detail, a tím jsou prokluzy koleček. Bude tedy potřeba do toho ještě přimíchat nějaký pravděpodobnostní algoritmus, který si poradí s akumulující se chybou.. TODO.
V grafu je vynesena křivost trati (osa y) v závislosti na dráze (osa x, v cm).
Barevně jsou vyznačeny jednotilvé pokusy, rychlost robota 15, 25 a 35cm/s. Je vidět že už při trochu vyšších rychlostech dochází k prokluzům a bude potřeba dělat nějaké korekce.
Podle pravidel je čára v rovném úseku přerušená v délce 10cm. Stačí tedy detekovat "zmizení" čáry, tedy situaci kdy čára byla zhruba uprostřed a najednou je pryč. V takovém případě robot pokračuje rovně, dokud čáru opět nenajde.
Je potřeba rozlišovat, jestli čára zmizela "z prostředka" modulu nebo "z kraje". Pokud nastal druhý případ, pak to znamená že robot překmitl a musí se začít otáčet tak, aby čáru opět nalezl.
2012-03-02 Bezkontaktní detekce překážky pomocí modulovaného IR světla bohužel nefunguje moc spolehlivě, od té doby, co jsem udělal změny ve funkci Proximity sensoru tak, aby umožňoval detekci ostatních robotů a komunikaci s nimi. Proto jsem sáhnul po jednom starém triku: Virtuální nárazník. To je fikaný a spolehlivý způsob jak detekovat překážku v cestě na základě údajů z enkodérů. Funguje to takto: po nárazu (!) do překážky se robot nemůže dále pohybovat, ač se o to motory usilovně snaží. Takže stačí detekovat situace, kdy jsou zapnuté motory robota, ale podle údajů z enkodérů se kola netočí.
Toto řešení, ač se může zdát jako dost brutální (vůči překážce či robotovi), má, kromě spolehlivosti, ještě jednu velkou výhodu: Robot se nárazem vždy srovná kolmo k překážce, takže objížděcí manévr vyjde pokaždé stejně.
2012-03-01 Poster na RobotChallenge, vytvořený během pár hodin úpravou starého posteru pro PocketBota. Použitý software: Trial verze Adobe InDesign. Když člověk potřebuje udělat nějaký prezentační materiál rychle a kvalitně, neobejde se bez komerčního software. Na tohle opensource nástroje prostě nemají. Vzhledem k tomu, že poster dělám tak jednou do roka, úplně mi stačí, když bude Adobe vydávat novou trial verzi každý rok.
PocketBot2 poster (PDF, 12.5MB)
2012-03-10 Na soutěži RobotChallenge jsem se účastnil s PocketBotem2 ve dvou kategoriích - Line Follower Enhanced a Freestyle. V disciplíně Line Follower Enhanced musí roboti ujet vyznačenou trať v co nejkratším čase. Aby to nebylo příliš snadné, na trase je překážka, které se robot musí vyhnout, a v jednom místě je vodící čára přerušená a robot projíždí tunelem, ve kterém jsou odlišné světelné podmínky. Vzhledem ke svým rozměrům se PocketBot2 v závodění na čáře mohl rychlostí jen stěží vyrovnat větším robotům, kteří zvládali bezmála patnáctimetrovou trať pod deset vteřin. PocketBot2 zdolal trať bez obtíží za pěkných 27 vteřin a kvalifikoval se do soutěže, což se ne každému linefollowerovi podařilo.
Napínavější pro mě byla Freestyle exhibition, ve které týmy i jednotlivci prezentovali různorodé projekty. Témata projektů byla rozmanitá, od systémů založných na rozpoznávání obrazu přes rotační LED display až po originální bambusové konstrukce robotů.
Já jsem předváděl, co všechno PocketBot2 umí; například vykreslování trajektorie, po které se robot právě pohybuje, na obrazovku PC. Divácky nejatraktivnější byla demonstrace systému krátkodosahové optické komunikace. Tři roboti PocketBot2 jezdili po vyznačení trati v obou směrech, takže se vzájemně potkávali. Když došlo k setkání dvou robotů, identifikovali se, předali si zprávu a pak se otočili a pokračovali v opačném směru. Putující zpráva byla znázorněna rozsvíceným oranžovým světlem. Vždy jeden z robotů, nositel zprávy, svítil oranžově, dokud zprávu nepředal dalšímu. Princip je to jednoduchý, ale vypadá to efektně. Roboti se sice na okruhu otáčejí a jezdí pořád sem-tam, ale zpráva (oranžové světlo) koluje po trati stále ve stejném směru.
Na soutěži jsem v podstatě bez ustání mluvil - vysvětloval jsem návštěvníkům a porotcům jak roboti fungují a odpovídal na spoustu dotazů. Už první den soutěže jsem úplně přišel o hlas, takže večer jsem nebyl schopný vydat ani hlásku. Svůj podíl na tom mělo také to, že ještě den před tím jsem lyžoval ve Špindlu, odtud jsem jel přes noc - s krátkou zastávkou v Praze - rovnou do Vídně, ale jaksi jsem nepočítal s nachlazením.. Druhý den soutěže jsem byl tedy úplně němý, takže místo prezentace na pódiu jsem pustil video.
Můj projekt se shledal s velkým ohlasem u veřejnosti i odborné poroty, která mi udělila první místo. Obhájil jsem tedy titul z předloňska. Tehdy jse vyhrál v kategorii freestyle se svou první verzí PocketBota.
První místo ve freestyle kategorii
2012-04-21 It was a nice run, Kevin. Had to close out some day. Nobody wins them all...
Trpělivost přináší růže. Knihovna pro řízení PocketBota nefungovala na Androidu, protože verze 2.3 v Samsungu Galaxy SII nepodporovala L2CAP bluetooth layer (docela ostuda pro vývojáře, protože po tomto rozhraní volá spoustu programátorů). Strávil jsem s tím několik dnů, než jsem dospěl k závěru, že rozchodit L2CAP na Androidu prostě v tuto chvíli možné aniž by si člověk musel kompilovat vlastní jádro.
2012-04-28 Aktualizoval jsem na nový Android 4.0 Ice Cream Sandwich. Ze zvědavosti jsem tam nahrál dřívější kód a ono to, světe div se, začalo najednou fungivat! Rozchodil jsem L2CAP a vzápětí celou knihovnu i na Androidu!
2012-04-28 Účastnil jsem se FreeStyle exhibition i závodění na čáře. PocketBot2 si vedl velmi dobře a umístil se na 4. místě ve sledování čáry.
Video ze závodů - PocketBot2 na dráze skoro není vidět. Startuji ho elegantně přes Bluetooth pomocí mobilu.
2012-05-11 PocketBot2 v televizi! Pro netrpělivé: od 14:40 tři minuty věnované mému kapesnímo robotovi. Ale pokud to shlédnete celé, uvidíte i mého dalšího robota, co jezdí po hladkých křivkách.
2012-05-24 Odevzdal jsem svou bakalářskou práci Centralized Multi-Robot System (PDF, 18.2MB). Nenechte se zmást názvem, je to o návrhu software pro PocketBota2. Abych ukázal, že roboti mezi sebou dokáží skutenčně interagovat, naprogramoval a otestoval jsem dva ukázkové algoritmy:
Tři roboti jezdí po okruhu a když se potkají, vymění si zprávu, otočí se a pokračují opačným směrem. Jeden robot je nositelem zprávy (svítí mu oranžová LEDka). Když potká jiného robota, zprávu mu předá. V důsledku tak oranžové světýlko putuje stále stejným směrem, byť se roboti neustále otáčejí. Navíc, roboti dokáží rozpoznat jiného robota od překážky. Pokud se jim v cestě objeví překážka, objedou ji. Pokud je tam jiný robot, otočí se.