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

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

Jednoduchý PI regulátor

Tak jsem se konečně pustil do programování PI regulátoru. Bohužel výsledek není zatím zcela ideální a to hlavně kvůli malému rozlišení enkodéru, který mám zrovna k dispozici a (zřejmě) kvůli použitým konstantám. Nicméně nějak to funguje. Kvůli nastavení konstant zřejmě budu muset zalistovat v sešitu ze SIS a trochu si to připomenout. Zatím jsem konstanty střelil (hódně) od boku a "ono to nějak funguje". Celý program je na stránkách projektu. Není to nic zázračného. Ovládá se to z počítače. Modul reaguje na přijaté znaky: + (přidá rychlost), - (ubere rychlost), 0 (zastaví) a * (reverz).




/* regulator */
ISR(TIMER1_OVF_vect) {

  static uint8_t pocit = 0;

  // 10 Hz
  if (++pocit==10) {

    diff1 = t_en1 - pt_en1;
    diff2 = t_en2 - pt_en2;
  
    pt_en1 = t_en1;
    pt_en2 = t_en2;
  
    pocit = 0; 
 
 }
 
    // klouzavy prumer odchylky
    e[0] = e[1];
    e[1] = e[2];
    e[2] = e[3];
    e[4] = (speed-diff2);
  
    int16_t pe = (e[0] + e[1] + e[2] + e[3] + e[4])/5;
  
    act = ((int16_t)(4*pe+0.9*sum)); 

 // nastaveni smeru podle znamenka akcniho zasahu  
    if (act>0) {
  
      C_SETBIT(INPUT4);
      C_CLEARBIT(INPUT3);
  
    } else {
  
      C_SETBIT(INPUT3);
      C_CLEARBIT(INPUT4);
  
  }

 // omezeni max. hodnoty
    if (abs(act)<=ICR1) OCR1B = abs(act);
      else OCR1B = ICR1;
     
    sum += pe;
    if (sum > 3000) sum = 3000;

}

Zde uvádím pouze kód samotného regulátoru. Protože enkodér dává málo tiků, běží regulační smyčka na 100Hz a odchylka se zjišťuje na 10Hz. Regulace je sice nic moc, ale na vyzkoušení to jakžtakž stačí. Z odchylky se počítá klouzavý průměr - kvůli omezení rázů.

Enkodér

Prozatím mám k dispozici motorek s enkodérem, který dává 100 impulzů na otáčku výstupní hřídele převodovky. Pokud tedy využiji čtyřnásobnou přesnost dekódování, dostanu 400 impulzů na otáčku. To je pro regulaci málo. Zatím tedy mám v nepájivém poli procesor (attiny2313) a lcd, na kterém zobrazuji počet tiků enkodéru a rychlost otáčení v cm/s.

Enkodér, který bude použitý v BP by měl mít 100 impulzů, ale na otočku motoru, což je při převodu 30:1 (GHM-16) 3000 impulzů na otáčku výstupní hřídele - a to pouze při jednoduché přesnosti. Při čtyřnásobné přesnosti je to už 12000 impulzů-tiků. S tím by se už mělo dát regulovat dobře. Níže uvádím odkazy, na kterých je zajímavé počtení o enkodérech, regulátorech apod.

Implementace regulátoru
Povídání o enkodérech
AVR - regulátor dvou motorků
Řízení pohybu, zpětná vazba
Enkodéry (princip funkce)

Takto primitivně vypadá čtení stavu enkodéru v programu - detekce nástupné i sestupné hrany:

// vzestupna hrana - ENA
if ((C_CHECKBIT(ENA)) && (!C_CHECKBIT(PENA))) {
if (C_CHECKBIT(ENB)) t_en++;
else t_en--;
}

// sestupna hrana - ENA
if ((!C_CHECKBIT(ENA)) && (C_CHECKBIT(PENA))) {
if (!C_CHECKBIT(ENB)) t_en++;
else t_en--;
}

// vzestupna hrana - ENB
if ((C_CHECKBIT(ENB)) && (!C_CHECKBIT(PENB))) {
if (!C_CHECKBIT(ENA)) t_en++;
else t_en--;
}

// sestupna hrana - ENB
if ((!C_CHECKBIT(ENB)) && (C_CHECKBIT(PENB))) {
if (C_CHECKBIT(ENA)) t_en++;
else t_en--;
}

// ulozeni minuleho stavu ENA
if (C_CHECKBIT(ENA)) C_SETBIT(PENA);
else C_CLEARBIT(PENA);

// ulozeni minuleho stavu ENB
if (C_CHECKBIT(ENB)) C_SETBIT(PENB);
else C_CLEARBIT(PENB);

}

ENA a ENB jsou pojmenování pro vstupní piny. PENA a PENB jsou pomocné bity.

Tento kód se vykonává v přerušení od timeru 0, s frekvencí 20kHhz, přičemž procesor běží na 8MHz. Frekvence vzorkování 20kHz se ukázala jako naprosto dostatečná pro čtení tohoto enkodéru. Otázkou dalšího pokusu bude, jaká frekvence je potřeba, pro čtení výše zmíněného lepšího enkodéru QME-01.

Pokud lze dekódování impulzů z enkodéru řešit lépe, budu rád, když mě na to někdo upozorní.

Modul MotorControl

První z celé řady modulů řídící elektroniky pro bakalářskou práci Mobilní robot na VŠPJ. Na wiki tohoto projektu najdete podrobnější popis funkcí modulu. Stručně řečeno bude mít na starosti ovládání motorů, čtení stavu enkodérů apod. V současné době je vyrobená a osazená deska, co nejdříve bude následovat její oživení a praktické ověření funkce. Zatím není co fotit, ani natáčet, ale dříve nebo později se tu objeví video, nebo fotky z testů modulu. Schéma a deska vytvořené v programu Eagle 5.3 jsou ke stažení taktéž na stránkách projektu.
Deska vypadá nějak takto:

Omluvte prosím sníženou kvalitu obrazu :-) Bohužel nemám foťák, tak jsem musel desku naskenovat. Na videu by momentálně byla vidět blikající LEDka.