Robotic rover video

Konečně (téměř) hotovo

Tak už před nějakou dobou jsem ukončil práce na bakalářce. Teď už mě čeká jen spousta odříkání a učení. Co je nového od minule? Nové moduly pro ovládání motorů (možná bude článek), regulátor ujeté vzdálenosti (na požádání z PC robot ujede zadanou vzdálenost), zprovozněný kompas, zrychlená komunikace (mezi moduly i s PC) a vychytaná spousta drobných chyb. K obhajobě BP se chystám natočit nějaké video, takže ho sem potom určitě dám. Níže pár posledních fotek z vývoje a odkazy na (zatím neobhájenou) bakalářskou práci a přílohy k ní.




Na tomhle místě v laboratoři jsem se něco naseděl a kolikrát se z toho zakouřilo už ani nepočítám... Ale co si tak pamatuju, zničil jsem 1x L6203, 1x programátor, vypařilo se několik cest na DPS... No zkrátka samá legrace :-)

Výše prosím ukázka displeje zobrazujícího stav regulátoru ujeté vzdálenosti. LS je ujetá vzdálenost pro levou stranu robotu (průměr ze vzdálenosti předního a zadního kola), RS to samé pro pravou stranu, LE a RE jsou odchylky (žádaná vzdálenost - aktuální), RD je požadovaná vzdálenost a ST je stav (READY / RUNNING). Zdá se, že to funguje docela dobře. Dodělat otočení o zadaný úhel jsem bohužel už nestihl. Kompas ale funguje, takže to nebude zas tak náročné.

BP Elektronická část mobilního robotu
Přílohy k BP (DPS, zdrojové kódy atd.)

Stav projektu k 20.3. 2009

Tak robot už je víceméně pohromadě. Proběhly první jízdní testy a přišlo se na závažné mouchy. Tak předně se robot nebyl schopný otočit na místě. A nebylo to jednou chybou, ale šlo o synergii chyb několika.

Předně byla chyba v programu a to v kódu modulu MotorControl. Byl špatně nastavený režim PWM. Místo režimu, kdy TOP odpovídá ICR1 tam byl 10 bitový režim. Takže místo 2500 byl vrchol čítače 1024, což znamená, že to muselo přetékat... Moc nechápu jak to mohlo fungovat, ale na stole se prostě chyba neprojevila, regulátor si s tím nějak poradil.

Druhý problém vězí v použitém h-můstku L298. Při proudu kolem 2A je na něm úbytek téměř 4V. To jsem bohužel zjistil až teď. S tímto budičem jsem pracoval už dřív, ale ne s takovými proudy a tak se tato nepříjemná vlastnost neprojevila. Pokusně jsme ji odstranili napájením robota z laboratorního zdroje cca 16 volty - čili na motorech pak bylo napětí 12V a robot se točil jak o život (ale jen chvíli - než zapůsobila ochrana proti přehřátí v L298). Zrovna teď pracuju na návrhu DPS nového modulu, tentokrát s unipolárními budiči L6203. Až bude hotový, dám sem opět schéma a DPS.

Při testování se naštěstí vyskytly i pozitivní okamžiky. Nechali jsme robota ujet rovně 750 cm a výsledek z odometrie byl 740 cm, což mi nepřipadá jako úplně špatné. Kolega má už také dobře zpracované ovládání joystickem. Funguje to opravdu perfektně.

Stav projektu k 11.3. 2009

Elektronika už má většinu plánované funkčnosti. Z těch podstatných věcí, které by měla umět a zatím neumí jsou to: ujet zadanou vzdálenost rovně, otočit se o daný úhel (na to je potřeba dopsat obsluhu pro kompas). Řídicí program v PC se už také rýsuje. Nyní je v něm možné ručně poslat paket vybraného typu a sledovat odpověď. V nejbližší době přibude pravidelné čtení dat z pohonů a ze senzorů. V další fázi pak bude možné ručně vytvořit mapu a budeme pracovat na tom, aby se v ní robot dokázal pohybovat. Tomu ale musí předcházet montáž modulů a senzorů na podvozek. Nyní je vše pro testovací účely řešeno systémem vrabčí hnízdo.


Na fotce níže jsou k vidění dva moduly MotorControl. Na jednom z nich je bohužel už třetí atmega8. Pokaždé odešel pin OC1B (nebo A, teď nevím). Poprvé to bylo zřejmě díky nepořádku na stole (vznikl nějaký šlus), podruhé z neznámého důvodu. Pro jistotu jsem na všechny cesty mezi procesor a budič L298 umístil ochranné odpory 1k. Uvidíme, teď už snad procesor vydrží.


Na fotce níže je lcd zobrazující stav levého předního motoru. RS značí požadovanou rychlost, AS aktuální, LO zátěž motoru v procentech (činitel pwm), TM teplotu, CU proud motorem a DI ujetou vzdálenost. Jakmile bude elektronika nějak rozumně upevněná na podvozku, provedeme testy k určení přesnosti odometrie. Výsledky měření na stole vypadají zatím dobře :-)


Níže displej zobrazující statistiky komunikace s podřízenými moduly. SE je počet odeslaných paketů, RE značí počet přijatých, FE počet chyb rámce, BR počet špatně přijatých paketů (chyba CRC), TO počet timeoutů při příjmu a SY je počet chyb synchronizace.

Stav projektu k 6.3. 2009

Dnes jen stručně. Poslední z nezbytných modulů - SensMod je téměř hotový. Už se umí postarat o ultrazvuk i infračervená čidla - obojí kupodivu ukazuje téměř shodné hodnoty. Teď mě ještě čeká dopsání obsluhy pro kompas, který budeme používat pro otočení robotu o zadaný úhel. V souvislosti s kompasem - zatím počítáme s tím, že robot bude jezdit rovně a zatáčet o 90˚. Důvod je prostý - odometrie.

Zdrojový kód je, jako obvykle, na cvs, ale není to žádný zázrak. Na wiki projektu je již popsán způsob, jakým se PC dostane k údajům ze senzorů, zbývá ještě doplnit popis komunikace mezi MainMod a SensMod (je to ale téměř stejné).


Dále kolega zahájil práci na řídicím programu a provedli jsme nějaké testy komunikace mezi PC a elektronikou. Vše už je tedy téměř připraveno na první "jízdní" testy. Nejvíce práce zřejmě dá umístění všech senzorů a desek na podvozek :-)

Zatím to vypadá, že pro (budoucí) bezdrátové spojení použijeme XBee, právě studuju možnosti.

Test modulu MotorControl

Konečně se mi podařilo odladit poslední chybičky v modulu MotorControl a tak jsem natočil krátké video. Je na něm vidět jak modul zajišťuje plynulý rozjezd a zastavení. Omlouvám se za velice špatnou kvalitu.



Brzy už budu mít hotový i druhý modul a tak nastane čas pro první "jízdní" testy.

Stav projektu k 7.2.2009

Z Hobbyrobotu konečně dorazil podvozek MOB-03. Konstrukce je opravdu masivní a oproti prototypu, který jsem viděl u jednoho týmu na Robotour má nějaká vylepšení. Zatím mám pouze jeden modul MotorControl (ovládá dva motorky), takže joystickem ovládám jen jednu polovinu budoucího robotu. Modul M.C. se stará o čtení stavu enkodéru, plynulou akceleraci a měří proud motory.

Bohužel se potýkám s dvěma problémy. Na řádkovém lcd modulu MainMod mám udělané jednoduché menu a tlačítkem přepínám režimy zobrazení. Po startu modulu funguje ovládání joystickem normálně, ale po přepnutí menu odesílání požadované rychlosti začne zlobit. Snažím se na to přijít už třetí den, zřejmě je za tím nějaká magie (nebo nastavení gcc:)). Další problém je "cukání" motoru. Zatím se mi podařilo vypátrat, že nějak souvisí s probíhající komunikací - pokud do programu modulu zadám hodnotu požadované rychlosti napevno a modul odpojím od sběrnice, regulace je krásně plynulá, bez jediného škubnutí. Nezdá se, že by na to škubání mělo vliv přílišné vytížení procesoru. Pátrání pokračuje...


Napájení robotu budou zajišťovat dvě 4Ah 6V pb aku. Dvě z důvodu rozložení hmotnosti - a taky mi bez užitku ležely doma. Na fotce je vidět uložení aku ve vnitřnostech MOB-03 a upevnění pomocí součástek ze stavebnice Merkur.


Dnes jsem také v Eaglu dodělal DPS pro modul SensMod, který bude obsluhovat senzory. Jeden modul umožňuje připojit jedno servo a jeden sonar SRF-05, čtyři taktilní senzory (tlačíka:)), šest čidel s analogovým výstupem (Sharp) a čtyři senzory komunikující po I2C.

Letsmakerobots.com

Objevil jsem zajímavou stránku - letsmakerobots.com - často jsou to projekty typu "my first robot", ale některé stojí za povšimnutí. Projel jsem téměř všechna videa a abych nemusel později znovu hledat ta zajímavá, dám je i sem. Po kliknutí na jméno robota se můžete dozvědět další podrobnosti na původní stránce.

Multipurpose Robot: XRB3





Edward



ForfraBagfra

Tento kousek je zajímavý svou konstrukcí - způsobem zatáčení.



RC Car managed by Java leJOS NXJ

Robot navigovaný pomocí GPS. Video je hrozné, ale popis vypadá dobře - mrkněte.



360bot - Stepper motors are cool!

Infračervený radar :-)



easy-made manipulator

Manipulátor - skvělá podívaná.




Robot Wall Racers

To nejlepší na konec - víceméně blbinka, ale musí to být skvělá zábava!

Komunikace po RS485

Konečně se mi podařilo zprovoznit komunikaci mezi moduly. Pro tento účel jsem navrhl jednoduchý komunikační protokol, respektive knihovnu. Zatím funguje v zjednodušené verzi. Mám totiž hotové jen dva moduly, takže mě ještě nic nedonutilo zprovoznit MPCM (Multi-processor Communication mode).

Takto (zatím) vypadá obsluha komunikace v řídicím (master) modulu:

while (1) {

// vytvoření a inicializace pole dat
uint8_t data[30], i;
for(i=0; i<30;i++) data[i] = i*2;

// vytvoření paketu
makePacket(&comm_state.op,&data,30,P_ECHO,10);

// zakázání příjmu
CLEARBIT(UCSR1B,RXEN1);

// přepnutí na vysílání
C_SETBIT(RS485_SEND);

// poslání prvního bytu - ostatní se vysílají automaticky
sendFirstByte(&UDR1,&comm_state);

// čekání na odeslání paketu
while(comm_state.send_state != PS_READY);

// přepnutí na příjem
C_CLEARBIT(RS485_SEND);

// povolení příjmu
SETBIT(UCSR1B,RXEN1);

comm_state.send_state=PS_READY;

// čekání na odpověď
while(comm_state.receive_state != PR_PACKET_RECEIVED && comm_state.receive_state!=PR_TIMEOUT);
comm_state.receive_state = PR_READY;

}

Nejprve se vytvoří pole dat o 30 prvcích. To se potom uloží do paketu, odešle a čeká se na příjem paketu, nebo na timeout. Na lcd se vypisují statistiky komunikace: počet odeslaných paketů, přijatých, paketů s vadných kontrolním součtem, počet chyb rámce, počet timeoutů. Za pomocí těchto údajů jsem provedl test - viz níže. Knihovna bude po doplnění o MPCM ke stažení na stránkách projektu.

Takto vypadá obsluha komunikace v podřízeném (slave) modulu:

while(1) {

// přepnutí na příjem
C_CLEARBIT(RS485_SEND);

// čekání na příjem paketu
while(comm_state.receive_state != PR_PACKET_RECEIVED);

// rozhodnutí podle typu paketu
switch(comm_state.ip.packet_type) {

case P_ECHO: {

C_FLIPBIT(LED);

// vytvoření ECHO paketu
makePacket(&comm_state.op,&comm_state.ip.data,comm_state.ip.len,P_ECHO,0);

// zakázání příjmu
CLEARBIT(UCSRB,RXEN);

// přepnutí na odesílání
C_SETBIT(RS485_SEND);

// odeslání prvního bytu
sendFirstByte(&UDR,&comm_state);

// čekání na odeslání paketu
while(comm_state.send_state != PS_READY);

// přepnutí na příjem
C_CLEARBIT(RS485_SEND);

// povolení příjmu
SETBIT(UCSRB,RXEN);

comm_state.send_state = PS_READY;

} break;

} // switch

comm_state.receive_state = PR_READY;

}

Řídicí modul zatím umí jen posílat a přijímat pakety, bez toho, aby s nimi cokoliv dělal. Slave modul zase reaguje jen na pakety P_ECHO, které pošle zpět. Pro test mi to ale stačilo.

rychlost přenosu	úspěšnost echa [%]	Chybovost příjmu [%]
9600	75	14
14400	79	13
38400	89	5
76800	97	2
250000	98	0

Nastavoval jsem různé rychlosti přenosu a měřil úspěšnost echa (přijatých/odeslaných*100) a chybovost příjmu (chyba crc/přijatých*100). Kupodivu se výsledky zlepšovaly se zvyšující se rychlostí. Čekal jsem spíše opačný výsledek.

Graf úspěšnosti echa:


Graf chybovosti příjmu:

Atmega8 - USART

Dneska mě pro změnu vypekla atmega8 v modulu MotorControl. Během dopoledne jsem napsal poměrně univerzální knihovnu pro plánovaný komunikační protokol. Pak jsem celé odpoledne zjišťoval, proč nemůžu přenést mezi dvěma moduly ani jeden jediný byte. Na elektronice je prostě okouzlující ta různorodost chyb. Člověk píše program, škrábe vlasové spoje mezi cestami na desce, opravuje přerušené cesty... No zkrátka sranda. A hlavně je naprosto geniální to, že chyba může být buď v programu, nebo v návrhu elektroniky, nebo v provedení (studeňák atd.), nebo může vznikat kombinací několika chyb (nejlépe z různých jmenovaných oblastí). To je pak zábava :-)

Aby ten zápisek byl k něčemu, zkusím popsat v čem byl zakopaný pes. U atmega8 totiž sdílí registr UBBRH a UCSRC stejnou adresu. Pokud zapisujete do jednoho z těchto registrů, rozhoduje hodnota bitu URSEL o tom, do kterého z nich se bude zapisovat. Viz. citace z datasheetu (strana 152):

The UBRRH Register shares the same I/O location as the UCSRC Register. Therefore some special consideration must be taken when accessing this I/O location.

When doing a write access of this I/O location, the high bit of the value written, the USART Register Select (URSEL) bit, controls which one of the two registers that will be written. If URSEL is zero during a write operation, the UBRRH value will be updated. If URSEL is one, the UCSRC setting will be updated.

Takže jak má správně vypadat nastavení USARTu?


// 9600bd, 8n2
UBRRL = 103;
UBRRH = 0;

UCSRA = (0<<U2X)|(0<<MPCM);
UCSRB = (0<<UCSZ2)|(1<<TXCIE)|(1<<TXEN)|(1<<RXEN)|(1<<RXCIE);
UCSRC = (1<<URSEL)|(1<<USBS)|(0<<UMSEL)|(0<<UPM1)|(0<<UPM0)|(1<<UCSZ1)|(1<<UCSZ0);


Zdánlivě hloupost, ale trochu mě to potrápilo...