Wireless Robot Communicatie

Je kunt met de HT12D en de HT12E de wireless modules een adres geven.

Op 27 juni 2007 10:38:03 schreef WilToyo:
Je kunt met de HT12D en de HT12E de wireless modules een adres geven.

Is dan je eerste Byte je adres ? een PIC16F877A heeft volgens mij ook die mogelijkheid.

Het ging mij meer om wanneer gaat wie zenden als ze allemaal te gelijk zenden gaat dat niet goed.

Nee is puur hardware. Je ontvangers geef je een vast adres en met de PIC stel je het adres van de verzender in. Dus met een paar datalijnen zet je het adres van de decoder wat je normaal met dip switches zou doen.

maar dan verstuurd hij het adres mee met de data

Kan je geen token ring maken?
Je geeft alle robotjes een apart adres. Bv 1, 2 en 3. Als je ze aan zet identificeren ze zich op volgorde,
dus eerst nummer 1 zegt dat hij er is.
Als nummer 2 hoort dat nummer 1 er is wacht hij even en zegt dan dat hij er ook is.
Zo ook voor nummer 3.
Nummer 4 zal niet antwoorden zodat alle robotjes nu weten dat ze met zijn 3en zijn. Vervolgens zal nummer 1 zijn zegje doen. Dan zendt hij een speciaal commando uit dat hij klaar is en nummer 2 nu mag. Nu doet nummer 2 zijn zegje en zendt dan ook weer dat hij klaar is en nummer 3 nu mag. Idem voor nummer 3, maar omdat hij weet dat ze maar met zijn 3en zijn zendt hij uit dat nummer 1 weer mag. Zo kan je makkelijk een 4de robot introduceren.

Tijdens dat 1 robot zijn zegje doet kan hij met alle andere praten bv door te zeggen "aan robot 2 ik ben hier" en daarna "aan robot 3 ik ben hier". Maar ja kan ook verschillende dingen tegen ze zeggen (als ze bv verschillende functies hebben, wat je ook weer bekend kan maken tijdens de identificatie). Als robot 2 dan zijn zegje doet geeft hij eerst aan dat hij het zegje van robot 1 heeft ontvangen. Zo weten de andere dat wat zij gezegd hebben ook aangekomen is. Als hij hier geen antwoord op geeft dan zeggen ze het te volgende keer nog een keer. Net zolang tot ze bevestiging krijgen dat het ontvangen is.

Nu ik er zo aan denk je kan natuurlijk ook maken dat er een antwoord moet komen dat hij de token heeft ontvangen. Anders als 1 robot "kwijt" raakt (na het identificatie proces) zal het hele systeem plat liggen, omdat robot 1 geeft de token aan 2 maar omdat hij er niet is zal de token nooit meer doorgegeven worden. Zo hoef je ook geen oplopende ID's te hebben voor je robots (als bv robot 2 vandaag niet meedoet hoef je niet de ID's te gaan veranderen van robot 3, 4, etc). Bv door op een knopje te drukken begin je het identificatie proces. Die robot zegt hallo ik ben XX van tevoren ingesteld met dipswitches ofzo. Stuurt de token door naar XX+1. Die geeft geen antwoord. Stuurt de token door naar XX+2. Net zolang tot iemand antwoord. Bv "token ontvangen door XY". Nu gaat hij opzoek naar de volgende. Net zolang tot je alle ID's geprobeerd heb en alle robot's die er dus zijn zich bekent hebben gemaakt. Wie aanwezig is sla je op in een tabel en dan doe je weer hetzelfde als eerst.

Op 27 juni 2007 10:56:41 schreef DJJeroen:
maar dan verstuurd hij het adres mee met de data

Ja de HT12x zet je tussen de module en verzender/ontvanger.
De HT12x is trouwens wel parallel->seriel en seriel->parallel.

Op 27 juni 2007 11:24:51 schreef xantus:
Kan je geen token ring maken?
Je geeft alle robotjes een apart adres. Bv 1, 2 en 3. Als je ze aan zet identificeren ze zich op volgorde,
dus eerst nummer 1 zegt dat hij er is.
Als nummer 2 hoort dat nummer 1 er is wacht hij even en zegt dan dat hij er ook is.
Zo ook voor nummer 3.
Nummer 4 zal niet antwoorden zodat alle robotjes nu weten dat ze met zijn 3en zijn. Vervolgens zal nummer 1 zijn zegje doen. Dan zendt hij een speciaal commando uit dat hij klaar is en nummer 2 nu mag. Nu doet nummer 2 zijn zegje en zendt dan ook weer dat hij klaar is en nummer 3 nu mag. Idem voor nummer 3, maar omdat hij weet dat ze maar met zijn 3en zijn zendt hij uit dat nummer 1 weer mag. Zo kan je makkelijk een 4de robot introduceren.

Tijdens dat 1 robot zijn zegje doet kan hij met alle andere praten bv door te zeggen "aan robot 2 ik ben hier" en daarna "aan robot 3 ik ben hier". Maar ja kan ook verschillende dingen tegen ze zeggen (als ze bv verschillende functies hebben, wat je ook weer bekend kan maken tijdens de identificatie). Als robot 2 dan zijn zegje doet geeft hij eerst aan dat hij het zegje van robot 1 heeft ontvangen. Zo weten de andere dat wat zij gezegd hebben ook aangekomen is. Als hij hier geen antwoord op geeft dan zeggen ze het te volgende keer nog een keer. Net zolang tot ze bevestiging krijgen dat het ontvangen is.

Nu ik er zo aan denk je kan natuurlijk ook maken dat er een antwoord moet komen dat hij de token heeft ontvangen. Anders als 1 robot "kwijt" raakt (na het identificatie proces) zal het hele systeem plat liggen, omdat robot 1 geeft de token aan 2 maar omdat hij er niet is zal de token nooit meer doorgegeven worden. Zo hoef je ook geen oplopende ID's te hebben voor je robots (als bv robot 2 vandaag niet meedoet hoef je niet de ID's te gaan veranderen van robot 3, 4, etc). Bv door op een knopje te drukken begin je het identificatie proces. Die robot zegt hallo ik ben XX van tevoren ingesteld met dipswitches ofzo. Stuurt de token door naar XX+1. Die geeft geen antwoord. Stuurt de token door naar XX+2. Net zolang tot iemand antwoord. Bv "token ontvangen door XY". Nu gaat hij opzoek naar de volgende. Net zolang tot je alle ID's geprobeerd heb en alle robot's die er dus zijn zich bekent hebben gemaakt. Wie aanwezig is sla je op in een tabel en dan doe je weer hetzelfde als eerst.

Dat is een goed idee. Als je iets zend met z'n zender ontvangt elke ontvanger die in de buurt is het zelfde.

hallo ik lees mee met dit topic maar zelf vraag ik me af waarom jullie dit (HT12x ic) tussen den zender willen zetten dit is tog gewoon een usart.dus dan kun je deze ook tog gebruiken van de pic.

En zijn er ook goedkoper vorm van de ER400TRS vind ze best
duur?

Als je er geen decoder/encoder tussen zet dan heeft de draadloze deurbel van de buurman nog invloed op je schakeling

Op 27 juni 2007 12:28:06 schreef weerstandje:
hallo ik lees mee met dit topic maar zelf vraag ik me af waarom jullie dit (HT12x ic) tussen den zender willen zetten dit is tog gewoon een usart.dus dan kun je deze ook tog gebruiken van de pic.

En zijn er ook goedkoper vorm van de ER400TRS vind ze best
duur?

Bij farnell kosten se 29 euro ex btw is nog te doen.

Als je er geen decoder/encoder tussen zet dan heeft de draadloze deurbel van de buurman nog invloed op je schakeling

Maar dit probleem bijlft tog, want nu kunnen er ook tog bitjes om vallen.

Bij farnell kosten se 29 euro ex btw is nog te doen.

dit valt inderdaad nog wel te doen.

Daarom moet je ook een protocol maken en bevestig geven. Als je alleen HT12x ic ertussen zet en je zend net als er iemand aanbelt wordt het niet ontvangen. Je moet dus iets van terug meldingen hebben wil je zeker weten dat het goed ontvangen is. Maar hoef moet niet verplicht iets van een aparte chip hebben voor encoding. Je kan dat ook in de pic zelf doen. Met adres geef je aan naar wie heb moet en met de parity zoekt de andere uit of het goed is. Er is zelfs een manier om uit je corrupted data + parity de goede data weer te halen (staat ergens op wikipedia). Maar of je daar genoeg rekenkracht voor heb (naast alle andere functies) weet ik niet.

Dit was het Hammin code. Zie ook Reed-Muller code en Reed-Solomon code

Nog even terug komen op jouw verhaal Xantus, als robot 1 iets verzend naar de andere robots gaan die allemaal een bevesting geven en dat zal ook niet goed gaan.

Het zal nog best lastig zijn om een goed protocol op te zetten.

Die encoding kun je dus ook door pic laten doen gewoon de eerste byte is je adres en misschien de 2e ook.

@Xantus

Is helder zo.

Ik was al bang dat het niet helemaal duidelijk was. Ik bedoelde zo:
....Initalisatie stuk klaar (iedereen geweest robot 1 begint).....
Robot 1
-Send.to.Robot2.commando.parity
-Send.to.Robot5.commando.parity
-Send.token.to.robot2
Robot 2
-Send.token.recieve.to.robot1.parity
-Send.command.recieved.robot1.parity
-Send.to.Robot3.command.parity
-Send token.to.robot3.parity
Robot 3
-Send.token.recieve.to.robot2.parity
-Send.command.recieved.robot2.parity
-Send.token.to.robot4.parity
Robot 4
-Send.token.recieve.to.robot3.parity
-Send.token.to.robot5.parity
Robot 5
-Send.token.recieve.to.robot4.parity
-Send.command.recieved.robot1.parity
-Send.to.Robot4.command.parity
-Send.token.to.robot1.parity
en zo verder

Zo zal maar 1 robot tegelijk praten. Je zal natuurlijk altijd het probleem houden van corrupted data hier zal je dus goed rekening mee moeten houden (voor bij de commando's die hier gevoelig voor zijn). Als een commando niet aankomt is het nog niet zo erg. Stuur je hem de volgende keer weer. Maar als je token verkeerd gaat is al moeilijker. Wat als je token wel aankomt, maar de melding dat hij aangekomen is (om wat voor reden dan ook) niet. Stuur je hem opnieuw heb je kans dat je opeens 2 tokens heb. Stuur je hem niet heb je kans dat het netwerk stopt. Beide manieren kunnen vervelende gevolgen hebben waardoor je netwerk plat ligt.

Maar vooral Hamming distance en Hamming code zijn interessant om aandacht aan te besten. Code alleen als je er geen plaats voor heb in je PIC maar distance vooral. (Hamming kan maar 1 bit herstellen, maar ik dacht dat er ook een manier was zodat je meerdere bits kon herstellen. Kan dat hellaas niet meer vinden)

[Bericht gewijzigd door xantus op woensdag 27 juni 2007 13:07:27 ]

waarom heb je bij Robot 1 send.to.robot5 dan moet robot 1 al weten dat er 5 robot's zijn.

Op 27 juni 2007 12:36:21 schreef DJJeroen:
[...]

Bij farnell kosten se 29 euro ex btw is nog te doen.

Waarom koop je niet van die 2.4Ghz modules?
25 euro bij Voti. Er zit een antenne op en je kunt ze aansluiten op een pic (en ze zijn nog best klein ook)

Daarnaast zitten er 6 data pipes op die IC's per pipe kun je over 1 kanaal communiceren met 1 ander ic. Je hebt dan het probleem van botsingen opgelost.

Daarnaast kun heb je de beschikking over (ik geloof) 80 kanalen (er moet er wel een paar vrij zijn) helaas moet je de 2.4Ghz band wel delen met wifi bluetooth en de magnetron.

Sparkfun heeft ze ook

Voti: http://www.voti.nl/winkel/p/HF-NRF24LS.html
Sparkfun: http://www.sparkfun.com/commerce/product_info.php?products_id=153

En er zijn al mensen die het met een pic hebben aangestuurd
Zie: http://www.diyembedded.com/ ("nRF24L01 tutorials 1-3 for the PIC completed" )

Op 27 juni 2007 13:17:55 schreef surge_me:
[...]

Waarom koop je niet van die 2.4Ghz modules?
25 euro bij Voti. Er zit een antenne op en je kunt ze aansluiten op een pic (en ze zijn nog best klein ook)

Daarnaast zitten er 6 data pipes op die IC's per pipe kun je over 1 kanaal communiceren met 1 ander ic. Je hebt dan het probleem van botsingen opgelost.

Daarnaast kun heb je de beschikking over (ik geloof) 80 kanalen (er moet er wel een paar vrij zijn) helaas moet je de 2.4Ghz band wel delen met wifi bluetooth en de magnetron.

Sparkfun heeft ze ook

Voti: http://www.voti.nl/winkel/p/HF-NRF24LS.html
Sparkfun: http://www.sparkfun.com/commerce/product_info.php?products_id=153

En er zijn al mensen die het met een pic hebben aangestuurd
Zie: http://www.diyembedded.com/ ("nRF24L01 tutorials 1-3 for the PIC completed" )

Zeer interesant voor SPI. ff goed kijken.

Op 27 juni 2007 13:13:19 schreef DJJeroen:
waarom heb je bij Robot 1 send.to.robot5 dan moet robot 1 al weten dat er 5 robot's zijn.

....Initialisatie stuk klaar (iedereen geweest robot 1 begint).....

Maar je kan ook 1 master die dus bepaald wie wanner praat (net als hierboven). Maar hij geeft dan steeds de token door. Dus als robot 1 klaar is zegt hij dat tegen de master en die zegt dan weer dat robot2 mag praten. Iedereen praat dan ook tegen de master en die herhaalt het dan. Hij onthoud dus ook voor wie het command eigenlijk is. Voordeel is dat als 1 robot uitvalt dat je je token niet kwijt bent. Maar je moet altijd een initalisatie proces hebben als je een variable aantal robots heb. Anders weet je niet wie er allemaal zijn.

Misschien niet relevant maar wel interessant. Voor de TUE hadden we een project waarbij 12 robot's samen een planeet moesten ontdekken. Hierbij hadden we het master systeem erin gezet. Hierbij was steeds de middelste robot de master (wat handig is omdat je dan je bereik vertweevoudigd ) Deze stond dus stil en alle andere reden (verplicht) random rond en stuurde via het token systeem info naar elkaar via de master. Waaronder de positie. Hierbij werd gekeken door de master wie het meest in het midden stond. Als dat een andere was werd die de master en ging de oude master verder als slave. Zo kan je eigenlijk redelijk effectief een gebied ontdekken en als er een robot uitvalt (omdat hij leeg is ofzo) is dat geen groot probleem omdat de master hem dan gewoon overslaat. En ieder robot heeft een batterij sensor zodat als de master leeg is het overgeeft aan een andere. Want een master netwerk zonder master werkt ook niet. Je zou dan ook kunnen maken dat hij naar een oplaad station gaat. Maar dat hadden wij toen niet. Hierbij zat ook een initialisatie proces. Dit duurde 10min waarin iedere robot zei waar hij was, etc, maarna de master werd bepaald en het ontdekken begon. Hierbij werkt ook gekeken hoeveel robotjes er waren omdat het best kon zijn dat er opeens een minder of meer was.

Op 27 juni 2007 13:37:18 schreef xantus:
[...]
[...]

Maar je kan ook 1 master die dus bepaald wie wanner praat (net als hierboven). Maar hij geeft dan steeds de token door. Dus als robot 1 klaar is zegt hij dat tegen de master en die zegt dan weer dat robot2 mag praten. Iedereen praat dan ook tegen de master en die herhaalt het dan. Hij onthoud dus ook voor wie het command eigenlijk is. Voordeel is dat als 1 robot uitvalt dat je je token niet kwijt bent. Maar je moet altijd een initalisatie proces hebben als je een variable aantal robots heb. Anders weet je niet wie er allemaal zijn.
[afbeelding]

Misschien niet relevant maar wel interessant. Voor de TUE hadden we een project waarbij 12 robot's samen een planeet moesten ontdekken. Hierbij hadden we het master systeem erin gezet. Hierbij was steeds de middelste robot de master (wat handig is omdat je dan je bereik vertweevoudigd ) Deze stond dus stil en alle andere reden (verplicht) random rond en stuurde via het token systeem info naar elkaar via de master. Waaronder de positie. Hierbij werd gekeken door de master wie het meest in het midden stond. Als dat een andere was werd die de master en ging de oude master verder als slave. Zo kan je eigenlijk redelijk effectief een gebied ontdekken en als er een robot uitvalt (omdat hij leeg is ofzo) is dat geen groot probleem omdat de master hem dan gewoon overslaat. En ieder robot heeft een batterij sensor zodat als de master leeg is het overgeeft aan een andere. Want een master netwerk zonder master werkt ook niet. Je zou dan ook kunnen maken dat hij naar een oplaad station gaat. Maar dat hadden wij toen niet. Hierbij zat ook een initialisatie proces. Dit duurde 10min waarin iedere robot zei waar hij was, etc, maarna de master werd bepaald en het ontdekken begon. Hierbij werkt ook gekeken hoeveel robotjes er waren omdat het best kon zijn dat er opeens een minder of meer was.

ja ook een idee wou eigenlijk ook een basis station maken waar ik ook commandos in kan geven.

Maar hoe bepaalde jullie dan de positie en hoe verzende jullie de data (welke hardware)?

Op 27 juni 2007 13:17:55 schreef surge_me:
[...]

Waarom koop je niet van die 2.4Ghz modules?
25 euro bij Voti. Er zit een antenne op en je kunt ze aansluiten op een pic (en ze zijn nog best klein ook)

Daarnaast zitten er 6 data pipes op die IC's per pipe kun je over 1 kanaal communiceren met 1 ander ic. Je hebt dan het probleem van botsingen opgelost.

Daarnaast kun heb je de beschikking over (ik geloof) 80 kanalen (er moet er wel een paar vrij zijn) helaas moet je de 2.4Ghz band wel delen met wifi bluetooth en de magnetron.

Sparkfun heeft ze ook

Voti: http://www.voti.nl/winkel/p/HF-NRF24LS.html
Sparkfun: http://www.sparkfun.com/commerce/product_info.php?products_id=153

En er zijn al mensen die het met een pic hebben aangestuurd
Zie: http://www.diyembedded.com/ ("nRF24L01 tutorials 1-3 for the PIC completed" )

Die dingen kunnen alleen of zenden of ontvangen

Op 27 juni 2007 15:21:17 schreef DJJeroen:
Die dingen kunnen alleen of zenden of ontvangen

Het is een tranceifer, dus zenden en ontvangen in 1 chip, dus wat is het probleem?

Op 27 juni 2007 15:21:17 schreef DJJeroen:
[...]

Die dingen kunnen alleen of zenden of ontvangen

Nee hoor, je kunt prima een 2 weg verbinding opzetten en met de datapipes kun je er zelfs 6 met elkaar laten communiceren.
Voor de Bascom gebruikers onder ons heb ik een application note gemaakt voor de nRF24L01.
http://www.mcselec.com/index.php?option=com_content&task=view&…

Omdat ik in de datasheet las dat je heb in Tx mode moet zetten of RX mode.