Hastighetsmätare till robot (Med eget släphjul)

[Gimbal]

Som redan har sagts, är inte det bästa att helt enkelt räkna alla pulser från hjulet och med jämna intervall läsa av den räknaren. Då får du hastigheten vid varje avläsning oavsett om du kör fort, sakta eller står stilla. Det är alltid en fördel att få datan i jämn takt.

[hcb]

squiz3r: det är möjligt att jag både tänkt fel och missförstått ditt problem, men vad jag menade var att du beroende på hastighet skulle växla mellan att mäta tiden mellan två pulser (vid låga hastigheter, för att få acceptabel uppdateringsfrekvens), och att mäta hur många pulser det går per tidsenhet (för att klara höga hastigheter).

[squiz3r]

Gimbal och hcb: Det jag inte förstår är varför jag ska mäta med en fast tidsbas istället för att bara mäta en period? Vad finns det för fördelar med det? Den enda jag kan komma på är att möjligen skulle det vara extremt lite smidigare att ha samma tid mellan interrupten, men det är inget som spelar roll för mig.

hcb: Jasså, du tänkte på att man skulle klara högre hastigheter om man mäter med konstant tidsbas? Men även om jag bara mäter tiden för en period så är det inga problem, kör jag i 10km/h som är maxhastighet har jag ca 800Hz på den signalen, och det är inga problem för PICen som klockar på i 20MHz .

v-g: Nu är jag helt övertygad om att jag måste ha en sån sensor! (Eller kanske några fler!) De skulle ju lösa alla mina problem.. Då är det ju enkelt att mäta både sträcka, hastighet, och riktning. Måste ju finnas någonstans!

[squiz3r]

Jag kollade på Farnell, beställningen har tydligen inte gått iväg än, och den enda jag hittade där var AS5134. Den skulle nog fungera bra, dock lite overkill med alla utgångarna, men jag har ingen lust att betala 60kr + MOMS (75kr) plus en massa frakt för den.. Jag får väll helt enkelt fortsätta labba med min encoder disk istället...

[Gimbal]

Du räknar väl ändå pulser för att få sträckan? Då känns det naturligt att med jämna mellanrum plocka hastigheten från körd sträcka. Men det har sina för och nackdelar så det hänger lite på vad du ska göra med hastighetsinformationen.

[squiz3r]

Jag tänkte så här:
* Vänta på att en ny period startar
* Sätt på timern på´att räkna (ha interrupt ifall timern får overflow..)
* vänta på att perioden tar slut
* Stoppa timern och spara värdet (=hastigheten)
* Sätt på timern igen
* Öka distansvariabeln med ett.
* LOOP

Då får jag alltså min hastighetsvariabel som innehåller hastigheten i 14-dels omkretsar per uS, och min distansvariabel som innehåller sträckan i 14-dels omkretsar. KLART! Kan det bli enklare?

Men sen är ju problemet att jag behöver ha hög uppdateringsfrekvens även vid låga hastigheter, och oavsett vilken av de här två sätten jag mäter på så blir det ingen skillnad på det... Utan det är sensorn som sätter stopp för det.

[v-g]

Sensorn är mycket bra och det enda jag ångrar är att jag inte har fler. Som sagt det är som en potentiometer fast trådlös avkänning. Tex kan man tänka sig att känna av styrning på en radiostyrd bil enormt enkelt eller en styrpanel där man ställer genom att vrida reglage som då kan styra genom plexi eller liknande mao 100% vattentätt om man nu behöver det.

Enda abret är att sensorn för största noggranhet kräver att magnetens "mitt" är centrerat över känselcentrum (som finns väl definerat i databladet) detta kan bli knivigt om inte sensorkortet (typ som mitt) sitter fritt från det stora kortet, alternativt om man tänker sig noga för genom hela processen. Dvs måttar redan i eagle.

Trist att det inte fanns på Farnell. Lägg det på komihåglistan till nästa ELFA (kan aldrig ligga långt fram i tiden )

[Gimbal]

Jag tänkte så här:
* Vänta på att en ny period startar

Nästa period startar väl när den första slutar, eller tänker du hoppa över en?

Varför behöver du hög uppdateringsfrekvens?

[squiz3r]

"Nästa period startar väl när den första slutar, eller tänker du hoppa över en?"
Jodå, visst gör den det, det är ju bara första gången, dvs när jag startar PICen som jag måste vänta på det.

"Varför behöver du hög uppdateringsfrekvens?"
Säg att jag säger åt roboten att köra i 2000mm/min (0,12 km/h), också har jag som nu en uppdateringsfrekvens på 800Hz vid 10km/h, det skulle alltså bli 9,6hz uppdateringsfrekvens då... Och det skulle ju bli väldigt hackigt!

Helt enkelt för att jag vill att roboten ska kunna hålla en jämn fart vid både höga och låga hastigheter.

[Gimbal]

ok, du ska ha den för motorstyrningen (borde du då inte ha en givare på varje motor, gissar på den vanliga 2-motor modellen). Ser nu att mäthjulet ska sitta i mitten av roboten, dvs om du roterar på plats får du inga signaler alls, motorstyrningen kör då utan feedback?

Men hursomhelst, ca 10 Hz på fartåterkoppling i krypkörning borde vara helt ok.

[squiz3r]

Jag tror inte det ska behövas sensorer på hjulen, i alla fall inte en så länge. Man vet ju ungefär hur mycket motorerna ger på olika PWM nivåer, om man tex står stilla enligt den passiva sensorn, men har 100% duty cycle på motorerna så kan man ju gissa att man sitter fast på nått vis..

Nästa steg efter att jag har fått detta att fungera är att sätta på en 90graders förskjuten sensor också, och komma på hur jag ska lösa det.

Sen hade det ju varit kul ifall man kunde mäta hur mycket man svänger också, hur det nu ska gå till...

[squiz3r]

Nu ska jag åka på semester...... Vilket betyder; Ingen elektronik på knappt 1 vecka!!

Önska mig lycka till nu...

[Electricguy]

men vafan squzz3n, man tar ju me sej labbet när man åker på semester brukar ja göra iaf eller ja, en liten del av det iaf..