Android aplikace RoboNav

Pirx
Příspěvky: 127
Registrován: 24 úno 2013, 16:29
Kontaktovat uživatele:

Re: Android aplikace RoboNav

Příspěvek od Pirx » 06 pro 2017, 17:15

Kdysi jsem zakoupil za 150 USD vyvojove prostredi CrossStudio for ARM od Rowley ( http://www.rowley.co.uk ) a zacal pracovat na rade LPC od NXP. No a u toho jsem poslednich 8 let zustal.
Aktualne poruznu pouzivam LPC1759, LPC1765, LPC1768. Ve zminene ridici jednotce je LPC1765.

Z toho plyne, ze pouzivam GNU C "na hole zelezo". USB stack jsem upravil z prikladu od NXP, ktery byl puvodne pro Keil, fuzi senzoru pouzivam od pana Madgwicka ( http://www.x-io.co.uk/open-source-imu-a ... algorithms ) a zbytek je vlastni tvorba.

Komunikacni protokol mam svuj, opet dlouha leta pouzivany primitivni format binarniho paketu. Zatim nebyl duvod jej menit.
Poustim ho pres ruzne kontejnery (USB, TCP/IP, radio...).

Takze asi nic pro milovniky knihoven stazenych z netu ;-)

Na Odroidu pouzivam GNU C++, IDE KDevelop a OpenCV pro zpracovani obrazu, jako ostatne asi vsichni.
Bezi to pod Xubuntu.
Solder fumes makes you stronger!

Uživatelský avatar
Dex
Administrátor
Příspěvky: 886
Registrován: 16 úno 2013, 14:26

Re: Android aplikace RoboNav

Příspěvek od Dex » 06 pro 2017, 20:19

Díky za zajímavé info ;)

Prozradíš něco víc o tom protokolu? Jen pro inspiraci, nechystám se ho pak patentovat :D
"all your robots are belong to us"
robodoupe.cz | rxd.cz | codetory.cz

Pirx
Příspěvky: 127
Registrován: 24 úno 2013, 16:29
Kontaktovat uživatele:

Re: Android aplikace RoboNav

Příspěvek od Pirx » 06 pro 2017, 21:05

Protokol pochází z raných devadesátých let a je primitivnost sama. Nic k patentování ;-)
Je bytově orientovaný a jeden paket má následující strukturu:

Kód: Vybrat vše

| NextB_H | NextB_M | NextB_L | DevAddr | Cmd | (Data) | Checksum |
  • NextB – 3 byte (H,M,L) udávající počet následujících bytů paketu. Teoretická maximální délka paketu je potom 2^24 - 1
  • DevAddr – Adresa zařízení, primárně určená pro sítě RS485, ale je vyžadována a testována vždy bez ohledu na komunikační rozhraní
  • Cmd – Kód povelu, odpověď na požadavek z nadřízeného systému obsahuje stejný kód povelu (Cmd) jako vlastní požadavek
  • Data – Nepovinný blok datových bytů proměnné délky. Pokud nejsou vysílána data, následuje hned po bytu Cmd byte Checksum
  • Checksum – Kontrolní součet všech bytů paketu
Typický příklad paketu, kterým se Master dotazuje, zda je přítomen nějaký slave (kód povelu je 0x01 a datový blok se nevyskytuje):

Kód: Vybrat vše

| 0x00 | 0x00 | 0x03 | 0x01 | 0x01 | 0xFB |
Protokol je koncipován jako Master / Slave, aneb "Mluv jenom když jsi tázán". Další důležitou vlastností implementace tohoto protokolu je to, že je určen pro embedded systémy, kde jsou veškerá data statická a vše je známo v době překladu. Nepoužívá tedy žádné dynamické prvky, jako je např. alokace paměti, což dále přispívá v k jeho stabilitě.

Driver pro tento protokol ve formě konečného automatu je napsán jako platformově nezávislý. Protokol může běžet (a většinou také běží) na více rozhraních současně (UART, USB, Ethernet...). Stav automatu parsujícího protokol je vždy uložen ve struktuře, která popisuje příslušné komunikační rozhraní. Automat parseru protokolu je vždy volán po příjmu jednoho nebo více bytů přes dané komunikační rozhraní, nejčastěji v přerušovací rutině. Součástí příslušného uzlu jsou i komunikační buffery pro dané rozhraní.

Význam povelů je aplikačně specifický. Množina známých povelů je reprezentována seznamem #define konstant a je zpracovávána dalším stavovým automatem, kterému se pouze předá adresa struktury příslušného komunikačního uzlu s přijatým paketem.
Parser povelů na základě dat v uzlu vygeneruje odpověď, kterou uloží do bufferu uzlu a ve struktuře uzlu nastaví příznak požadavku na odeslání dat. Přerušovací rutina už se postará o zbytek.

Jsem se nějak rozepsal :lol:
Solder fumes makes you stronger!

Uživatelský avatar
Dex
Administrátor
Příspěvky: 886
Registrován: 16 úno 2013, 14:26

Re: Android aplikace RoboNav

Příspěvek od Dex » 06 pro 2017, 21:19

Díky za vyčerpávající odpověď :D

Počítám správně, že můžeš poslat až cca 16 MB v jednom paketu? Čili na poslání nového firmware stačí jeden paket ;)

Jakým způsobem počítáš ten checksum?

Btw třeba to Aleše nějak inspiruje při návrhu obecnějšího formátu komunikace.
"all your robots are belong to us"
robodoupe.cz | rxd.cz | codetory.cz

Pirx
Příspěvky: 127
Registrován: 24 úno 2013, 16:29
Kontaktovat uživatele:

Re: Android aplikace RoboNav

Příspěvek od Pirx » 06 pro 2017, 21:40

Dex píše:
06 pro 2017, 21:19
Počítám správně, že můžeš poslat až cca 16 MB v jednom paketu? Čili na poslání nového firmware stačí jeden paket ;)
Hehehe... Čekal jsem podobnou poznámku :D
V reálu to kdysi vzniklo proto, že bylo potřeba posílat po sériáku (RS232, RS485) v jednom paketu balík 16384 x 4 byte dat.
Samozřejmě, že různá fyzická rozhraní s tím naloží po svém (USB, Ethernet) a vypalování FW je lépe dělat po menších kouscích ;)

Checksum je opravdu prostý součet:
- Při sestavování paketu sčítám byty do osmibitové proměnné (unsigned char). Tím se mi automaticky zahazuje přetečení.
Z výsledku potom udělám záporné číslo (buď vynásobím -1 nebo (pro assemblerovou implementaci) provedu negaci a přičtu +1).
- Při příjmu paketu opět stejným způsobem sčítám byty včetně kontrolního součtu. Pokud vyjde nula, je vše OK.

Jak říkám, primitivismus...
Solder fumes makes you stronger!

Uživatelský avatar
Dex
Administrátor
Příspěvky: 886
Registrován: 16 úno 2013, 14:26

Re: Android aplikace RoboNav

Příspěvek od Dex » 06 pro 2017, 22:24

Slovo "privitimismus" má možná trochu hanlivý podtext a zbytečně ;) Jak jsem pochopil, používáš to úspěšně už mnoho let a funguje to. Mě se to náhodou líbí ;)

Nedochází mi úplně jasná jedna věc - ten checksum neposíláš jako záporné číslo že ne? To * -1 udělá až příjemce, aby se mu lépe počítalo, že?
"all your robots are belong to us"
robodoupe.cz | rxd.cz | codetory.cz

Pirx
Příspěvky: 127
Registrován: 24 úno 2013, 16:29
Kontaktovat uživatele:

Re: Android aplikace RoboNav

Příspěvek od Pirx » 06 pro 2017, 23:41

Tím "primitivismem" jsem myslel hlavně to, že to není CRC nebo něco podobného, takže to moc nechrání.

Právě naopak, posílám záporné číslo, aby příjemce nemusel v tom přijímacím fofru dělat nic jiného než tupě sčítat. Zdarma mu pak v optimálním případě vyjde nula, kterou snadno otestuje.
Při sestavování paketu bývá více času.

Je třeba vzít v úvahu, že první verze protokolu běhala na procesoru Z80 :lol:
https://cs.wikipedia.org/wiki/Z80
Přešel jsem na něj z i8080 a nemohl jsem si jej vynachválit. Těžká nostalgie takhle zvečera ;)
Solder fumes makes you stronger!

Uživatelský avatar
gilhad
Příspěvky: 160
Registrován: 29 kvě 2015, 00:36

Re: Android aplikace RoboNav

Příspěvek od gilhad » 07 pro 2017, 03:53

Ja zatim stavim svoje pokusy okolo I2C (nebo spis Arduino Wire / twi - coz je vlastne skoro totez, jen to neni registrovana obchodni znacka)

Ma to tu vyhodu, ze pro kazde zarizeni na sbernici muzu pouzit jinou komunikacni sadu prikazu (a mam je zapouzdrene v objektu - jeden typ zarizeni = jeden typ objektu, takze pak volam motory[LEVY]->getActualSpeed()) a ze soucasti protokolu je i (nepovinna) odpoved tazaneho zarizeni, takze muze byt na sbernici vic masteru a ptat se jedne periferie na ruzne veci a odpovedi se jim nepomichaji. Zaroven muze byt i master "periferii", ktere podrizene jednotky muzou posilat "interrupty", jako ze se prehraly, nabouraly, nebo maji jiny problem.

A protoze tam krome zeme, hodin a dat navic vedu i napajeni, tak se snadno pridavaji dalsi zarizeni, jako treba LCD, nebo dalsi senzory, protoze kdyz tam vedou draty, tak tam vede i napajeni.

Vzhledem k objemu urcitych zbytnych dat (prave ty zobrazovace typicky) asi budu mit takovych sbernic nakonec vic, jednu pro veci dulezite, kde pujdou "strategicke prikazy" pro cele podrizene celky a dalsi sbernice pro veci zbytne, kde se bude cvicit s multiplexory pro LCD, posilat obrazova data na OLED a podobne nekriticke, lec objemne veci. (stejne se chystam si casem udelat "I2C graficke karty" - proste Arduino, ktere dostane prikaz "nakresli panacka tamhle" a veskere cviceni s prenosem dat OLED displeji si uz obstara samo, za svoje CPU cykly, svojema pinama a s bufferovanim spritu ve vlastni RAM, zatimco ridici MCU bude uz resit neco zcela jineho.

Pirx
Příspěvky: 127
Registrován: 24 úno 2013, 16:29
Kontaktovat uživatele:

Re: Android aplikace RoboNav

Příspěvek od Pirx » 07 pro 2017, 08:31

Jenom doplnim - popsany protokol je "high level", ve kterem se prenasi uz jenom predzpracovana data ze subsystemu (Lidar, sonary, IMU. motory). Nizka uroven beha podobne, jak popisuje gilhad, akorat misto objektu pouzivam globalni struktury.
Solder fumes makes you stronger!

MartinL
Příspěvky: 119
Registrován: 24 úno 2013, 14:13

Re: Android aplikace RoboNav

Příspěvek od MartinL » 07 pro 2017, 09:14

Tak také trošku popíšu svoje řešení:
Se vznikem prvního robota pro Eurobot vznikla i potřeba komunikace mezi více mikrokontrolery. V té době jsem používal výhradně AVR a jako hardwarovou vrstvu jsem použil osvědčenou RS485. Tak jsem navrhl (resp. upravil) jednoduchý protokol:

Kód: Vybrat vše

================================================================================
  Datový rámec:
  
  ADDR  LENGTH  DATA       CRC8
   1B    1B     1 - 255B   1B
================================================================================
Původně jsem využíval prima možnost 9. bitové komunikace UART na AVR (umí to nastavit přerušení jen při příchodu znaku s nastaveným 9. bitem), snižovalo to výrazně zatížení uC, ale bohužel se to blbě monitorovalo z PC.

Časem jsem přešel na 8. bitový přenos:

Kód: Vybrat vše

================================================================================
  Datový rámec:
  
  SYNC  ADDR  LENGTH  DATA       CRC8
   1B    1B    1B     1 - 255B   1B
================================================================================
Tohle funguje bez problémů, pokud je relativně spolehlivý přenos. Když jsem si začal hrát s bezdrátem a občas se něco ztratilo, nebo jsem testoval výpadek zařízení (vypnutí a zapnutí), tak se projevil nedostatek v tom, že se i v datech může vyskytnout znak SYNC a pak se to nemusí vždy správně chytnout. Proto jsem do realizace přidal ještě escapování znaku SYNC a timeout pro doručení celého paketu. Sice tím přibyla trocha režie, ale je to velmi odolné vůči chybám. Aktuálně používám hw vrstvu Uart s budičem CAN (není nutné řešit přepínání směru).
Komunikace je Master-Slave (dotaz odpověď), takže není nutné řešit nějaké kolize. Master má adresu 0, slave max. 127 (zkoušel jsem také variantu, kde slave v odpovědi posílá místo adresy master svoji adresu s nahozeným 7. bitem). Kontrolní součet je počítán jako CRC8, v některé variantě jsem použil jen XOR.

Když jsem realizoval jeden modul, u kterého jsem předpokládal, že bude připojen přes Uart nebo I2C, pro zjednodušení jsem upravil význam dat tak, aby se to chovalo víceméně stejně na obou hw vrstvách. Tzn. v ADDR 0. bit říká read/write a první byte DATA je adresa, ze které se bude číst/zapisovat.

Poslední variantou byla úprava protokolu pro kolegu Jiříčka k realizaci domácí automatizace, po moření se s nějakou arduino knihovnou na některém z loňských robodoupat (bohužel nemám odezvu, zda bylo použito). Tam bylo doplněna varianta zařízení Posluchač (adresa 255), který se do komunikace nezapojuje, ale vše poslouchá (pro možnost zobrazování).

Odpovědět

Kdo je online

Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 1 host