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...

Problémy s atmega64

Atmega64 použitá v řídicím modulu mě zase trochu potrápila. Pořád jsem nemohl přijít na to, proč nefunguje ani jednoduchý program ovládající podsvětlení lcd. Pin spínající tranzistor zkrátka jakoby na nic nereagoval. Několikrát jsem překontrolovat nastavení všech registrů, fuse bitů a... Nic. Po řádné chvíli googlení se mi podařilo odhalit příčinu. Řešení je např. zde:

• http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=70713&highlight=m103c
• http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=63766&highlight=m103c

Za všechno může fuse bit m103c. Naprogramováním tohoto bitu (nastavením na nulu) se mikroprocesor uvede do režimu, kdy je kompatibilní se starším procesorem atmega103. Vše (téměř) funguje normálně - omezeno je jen několik funkcí. Mimo jiné lze například piny portu G používat jen jako vstupní atd. V datasheetu je tento kompatibilní mód dobře popsán, ale nikde ani slovo o tom, že je defaultně zapnutý.

By programming the M103C Fuse, the ATmega64 will be compatible with the ATmega103 regards to RAM, I/O pins and Interrupt Vectors as described above.

Stačí tedy jeden příkaz:

#avrdude -p m64 -c usbasp -U efuse:w:0xFF:m

a vše je rázem v pořádku. Atmega64 se pak chová (a hlavně funguje) jako atmega64 :-)

Stav projektu k 21.12. 2008

O víkendu jsem se pustil do oživování řídicího modulu. Napájení propojek a smd součástek, včetně procesoru, bylo otázkou chvilky. Horší to už bylo s programováním... Pořídil jsem si programátor usbasp, z obchodu na stavebnice.com. Programátor přišel rychle, ale docela mě překvapilo, že v něm nebyl firmware (na to jsem přišel celkem rychle). Firmware jsem tedy nahrál pomocí ponyprogu na mém starém počítači, který má paralelní port.

Ovšem programátor se pořád nechtěl bavit s modulem. Vyzkoušel jsem tedy komunikaci s již plně oživeným modulem pro ovládání motorků a ono to funguje. Po dlouhém bádání (opravdu dlouhém) se mi podařilo identifikovat chybu. V datasheetu atmega64 je na straně 306 toto:

Even though the SPI Programming interface re-uses the SPI I/O module, there is one important difference: The MOSI/MISO pins that are mapped to PB2 and PB3 in the SPI I/O module are not used in the Programming interface. Instead, PE0 and PE1 are used for data in SPI Programming mode as shown in Table 127.

Viz také obrázek:


Dosud jsem pracoval pouze s attiny2313, atmega8 a atmega16 u kterých jsou programovací piny MISO a MOSI totožné se stejnojmennými piny rozhraní SPI. Proto mě nenapadlo, že to u atmega64 bude jiné. Tak aspoň jsem zase o něco moudřejší :-) ATmega64 je v řídicím modulu použitý z toho důvodu, že je to nejlevnější procesor od Atmelu s dvěma UARTy. Jeden je potřeba na komunikaci s podřízenými moduly a jeden na komunikaci s počítačem. Samozřejmě je tu i možnost použít soft UART. Ten ale není tak spolehlivý.

Programátor usbasp jsem si vybral z toho důvodu, že je podporován programem avrdude, který je možné použít jak ve Windows (WinAvr), tak na Linuxu. A navíc nebyl moc drahý. Třeba se někomu bude hodit ukázka používaných příkazů. Parametr ponyser stačí přepsat na usbasp, port není potřeba zadávat a jinak je to stejné. Pro výpočet potřebných fuse bitů používám online AVR Fuse Calculator.

Jako IDE na Linuxu používám Eclipse 3.3 Europe. Do něj stačí nainstalovat plugin pro vývoj C/C++ (CDT) a plugin pro AVR. Potom je možné vytvořený projekt nahrát do mikroprocesoru přímo z prostředí Eclipse. Příjemným pomocníkem je AVR Device Explorer - v něm je seznam registrů, přerušovací vektory a další užitečné informace.

Ještě předtím než můžeme programovat přímo z Eclipse je však potřeba mít v systému crossdev a vytvořit si verzi gcc pro avrka. S crossdev budete mít téměř zaručeně celou řadu problémů :-) Doporučuji najít si howto přímo pro danou distribuci. Dále je potřeba (alespoň u mě - je to zřejmě nějaký bug) v adresáři projektu debug vytvořit následující link (aby si linker nestěžoval):

ln -s /usr/lib64/binutils/avr/2.18/ldscripts ldscripts

Potom je ještě potřeba umožnit přístup k programátoru i non-root uživateli. To zařídíme nejlíp pomocí UDEV. Stačí jednoduché pravidlo. V adresáři /etc/udev/rules.d/ jsem vytvořil soubor 97-usbasp.rules a v něm jsou dva řádky:

# USBasp programmer
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0660"

Pak už stačí jen pomocí příkazu udevadm control reload_rules donutit udev znovunačíst pravidla a i obyčejný uživatel může zvesela programovat...

DPS - ovládání motorů

Došlo mi, že tu vlastně ještě není schéma a deska modulu pro ovládání motorů.

Na schématu je vidět použitý procesor atmega8. Pro komunikaci po RS485 je použit obvod SN75176. Dále je na desce dvojitý h-most L298 (jeho použití možná nebylo zrovna nejlepším nápadem - musí se k němu připojovat vnější ochranné diody a ty zaberou hodně místa).



Hardware modulu umožňuje: číst stav dvou enkodérů, pomocí PWM řídit otáčky dvou stejnosměrných motorků (každý max. 2A), měřit proud, měřit teplotu motorů (konektory pro připojení dvou termistorů), komunikovat po RS485.

V současnosti už mám v modulu naprogramované čtení enkodérů a PID regulátor. Další fází bude implementace komunikačního protokolu.

DPS ke stažení
Program pro modul
Detailní popis modulu

DPS - řídicí modul

Dnes jsem dokončil návrh DPS pro řídicí modul. Na stránkách projektu si můžete přečíst detailní popis funkce tohoto modulu. Do nového roku mám velké předsevzetí - schémata začnu kreslit inteligentněji.
Protože budu potřebovat dva sériové kanály (jeden na komunikaci se slave moduly a jeden pro spojení s počítačem), použil jsem mikroprocesor atmega64. K desce také bude možné připojit joystick a tím ovládat robota přímo - bez počítače. Skoro celou DPS překrývá LCD - ten může být buď 16x4 nebo 20x4. Vpravo nahoře je vyvedeno SPI pro programování a jeden port procesoru. Zapojení tohoto konektoru je řešeno tak, aby na něj šly připojit nejrůznější již hotové školní moduly.
Diody u RS485 nejsou diody, ale transily - kvůli ochraně před ESD. A konektor CANNON15 pro připojení analogového joysticku bude samozřejmě v provedení 90˚, ale v Eaglu takový nemám a nechtělo se mi ho kreslit.

Jakmile se podaří desku oživit, začnu pracovat na implementaci komunikačního protokolu.

Odkazy:
Deska ke stažení.
Zapojení analogového joysticku.
Něco málo o využití gameportu.

Levné alfanumerické LCD v GME:
MC1604B-SYL (298 Kč), MC2004B-SYL/H (295 Kč).