Funderingar kring ir-navigeringsutrustning
baron3d skrev:Den enda information du kan få om du har två fyrar är vinkeln, INGET mer!
Vinkeln till vad? Vad är problemet, ingen verkar förstå. Rita en bild eller förklara bättre vad du menar.Om jag vet vinkeln till två föremål med kända positioner så kan man räkna ut min egen position (om vi befinner oss i planet). Givetvis, om vi befinner oss i rummet så kan jag anta oändligt antal positioner på en "cirkelkant" (vet inte det rätta namnet). Om jag bara orienterar mig planet så finns det bara två punkter kvar och eftersom roboten aldrig är upp-och-nervänd så finns det bara en punkt kvar.
Zeal mfl, så här ligger det till:
Roboten kommer inte mäta fyrarnas vinklar utan sin egen vinkel ut fyrarnas ögon. I flyget kallar vi detta QDR (se wiki). För att detta ska vara möjligt så kommer fyren vara utrustad med en massa irdioder som sänder med olika pwm-duration. Därför vet roboten vilken vinkel den har iförhållande till fyren. Se första posten för en bild.
Har funderat lite på det här med olika pwm-frekvenser på fyrarna och filtrering av dem. Finns det avstämda ir-mottagare som reagerar på något annat än 38khz till rimligt pris (inte mer än 50kr)? I så fall skulle det ju vara extremt enkelt att slippa uppfinna hjulet en gång till! Har letat lite på elfa men de verkade inte ha något..
Sedan det här med att räkna ut robotens koordinater:
Är en pic lämpad för att räkna ut robotens position (+ heading) några gånger per sekund (5-10) baserat på att man kör med 10* mellan varje ir-diod och sedan mata ut svaret via rs232?
Om vi sedan fortsätter: För att pic-processorn ska veta var det finns hinder så måste man programmera in deras positioner i pic:ens minne (alt. separat eeprom) och sedan låta den plotta en rutt runt dessa hinder för att ta sig till en plats baserat på var den är för tillfället. Ganska likt en sådan gps man brukar ha i bilar. Hur mycket av det här pallar en pic, är det värt att ta fler och låta dem samarbeta eller går det bra ändå?
Självklart beror detta på hur stort rum man tänkt sig att vara i och hur mycket hinder det finns i det. Kommer nog bli hyfsat många punkter att hålla koll på. Men det jobbigaste är nog att räkna om koordinater till grader (och tillbaka) där det är krävs att man kan räkna sinus. Kan nog bli en tabell där iof.
Mitt förslag: En pic räknar ut robotens position + heading och lägger ut denna på portarna (port a+b = 65536 möjliga punkter på kartan och port c till heading) som sedan en annan pic läser av och kollar att det stämmer med kursen som den ska hålla. Denna ska då ha tillgång till kartan och räkna ut denna kurs för att det ska vara hinderfritt. Sedan skickar denna vidare ett styr-kommando till en pic som kör själva roboten. Och detta ska göras minst 10ggr/s. Anledningen till att detta ska uppdateras ofta är ju för att roboten ska hinna svänga innan den har kört rakt in i vardagsrumsbordet. Alternativt kan picen som kör roboten få en kurs + tillgång till robotens heading så blir det nog en stabilare kurshållning.
[/b]Vad tycker ni?
Edit, gör en fortsättning:
Gjorde en bild i sketchup och hittade ett problem till. Titta:
Hela det gula området skulle bli en position för roboten, och det är väldigt mycket för stort. Den har helt enkelt ingen aning om var den är då. Lösningen skulle vara en fyr till, och de tre ska stå i en likbent triangel för att det ska bli optimalt. Detta innenbär självklart en avstämd irmottagare till med skiljd modulering från de andra 2 (=svårare att hitta). Problemet är att det är ännu jobbigare för min uC att räkna ut sin position baserat på 3 vinklar...ser ut att bli en propeller som får göra jobbet iställer för en pic ändå(?).
Roboten kommer inte mäta fyrarnas vinklar utan sin egen vinkel ut fyrarnas ögon. I flyget kallar vi detta QDR (se wiki). För att detta ska vara möjligt så kommer fyren vara utrustad med en massa irdioder som sänder med olika pwm-duration. Därför vet roboten vilken vinkel den har iförhållande till fyren. Se första posten för en bild.
Har funderat lite på det här med olika pwm-frekvenser på fyrarna och filtrering av dem. Finns det avstämda ir-mottagare som reagerar på något annat än 38khz till rimligt pris (inte mer än 50kr)? I så fall skulle det ju vara extremt enkelt att slippa uppfinna hjulet en gång till! Har letat lite på elfa men de verkade inte ha något..
Sedan det här med att räkna ut robotens koordinater:
Är en pic lämpad för att räkna ut robotens position (+ heading) några gånger per sekund (5-10) baserat på att man kör med 10* mellan varje ir-diod och sedan mata ut svaret via rs232?
Om vi sedan fortsätter: För att pic-processorn ska veta var det finns hinder så måste man programmera in deras positioner i pic:ens minne (alt. separat eeprom) och sedan låta den plotta en rutt runt dessa hinder för att ta sig till en plats baserat på var den är för tillfället. Ganska likt en sådan gps man brukar ha i bilar. Hur mycket av det här pallar en pic, är det värt att ta fler och låta dem samarbeta eller går det bra ändå?
Självklart beror detta på hur stort rum man tänkt sig att vara i och hur mycket hinder det finns i det. Kommer nog bli hyfsat många punkter att hålla koll på. Men det jobbigaste är nog att räkna om koordinater till grader (och tillbaka) där det är krävs att man kan räkna sinus. Kan nog bli en tabell där iof.
Mitt förslag: En pic räknar ut robotens position + heading och lägger ut denna på portarna (port a+b = 65536 möjliga punkter på kartan och port c till heading) som sedan en annan pic läser av och kollar att det stämmer med kursen som den ska hålla. Denna ska då ha tillgång till kartan och räkna ut denna kurs för att det ska vara hinderfritt. Sedan skickar denna vidare ett styr-kommando till en pic som kör själva roboten. Och detta ska göras minst 10ggr/s. Anledningen till att detta ska uppdateras ofta är ju för att roboten ska hinna svänga innan den har kört rakt in i vardagsrumsbordet. Alternativt kan picen som kör roboten få en kurs + tillgång till robotens heading så blir det nog en stabilare kurshållning.
[/b]Vad tycker ni?
Edit, gör en fortsättning:
Gjorde en bild i sketchup och hittade ett problem till. Titta:
Hela det gula området skulle bli en position för roboten, och det är väldigt mycket för stort. Den har helt enkelt ingen aning om var den är då. Lösningen skulle vara en fyr till, och de tre ska stå i en likbent triangel för att det ska bli optimalt. Detta innenbär självklart en avstämd irmottagare till med skiljd modulering från de andra 2 (=svårare att hitta). Problemet är att det är ännu jobbigare för min uC att räkna ut sin position baserat på 3 vinklar...ser ut att bli en propeller som får göra jobbet iställer för en pic ändå(?).
Senast redigerad av eriikh 24 november 2007, 21:21:51, redigerad totalt 2 gånger.
Ultraljudssensor http://www.elfa.se/elfa-bin/dyndok.pl?l ... =12390.htm
går att modulera 10-65KHz, en fyr i övre bandet och en i lägre borde vara lätt att filtrera....
bara ett alternativ....
går att modulera 10-65KHz, en fyr i övre bandet och en i lägre borde vara lätt att filtrera....
bara ett alternativ....
-
JimmyAndersson
- Inlägg: 26578
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
varför bara ir?
om man gör det lite bakvänt kan man välja olika optisksa frekvenser för varje fyr
gäller bara att hitta filter som matchar lysdioderna
ir , rött, och blått borde vara långt ifrån varandra nog för tre fyrar
vill man ha mera så grönt och gult och kanske en ir i annan våglängd
uv dioder funnes ju med
eller kanske bara en fyr, med kombination ljus ljud, vinkel med ljus och avståndet med ultraljud, synca det med ljuspulsen så vet man ju hur långt bort det är
om man gör det lite bakvänt kan man välja olika optisksa frekvenser för varje fyr
gäller bara att hitta filter som matchar lysdioderna
ir , rött, och blått borde vara långt ifrån varandra nog för tre fyrar
vill man ha mera så grönt och gult och kanske en ir i annan våglängd
uv dioder funnes ju med
eller kanske bara en fyr, med kombination ljus ljud, vinkel med ljus och avståndet med ultraljud, synca det med ljuspulsen så vet man ju hur långt bort det är
