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

[v-g]

Du har hamnat i ett klassiskt dilemma nogrannhet vs omfång stor nogrannhet minskar omfånget och vice versa.

En sak jag lärt mig är att man får bestämma sig för var man "oftast" ligger och anpassa sig efter det dvs lägga optimala området över spannet där du kommer ligga.

[squiz3r]

Hmm.. Okej.

Jag har börjar bygga om hårdvaran nu så att jag får bättre upplösning, vilket också ger snabbare uppdateringsfrekvens (Hmm, De två sakerna brukar ju kämpa emot varandra, inte med varandra ) dock till bekostnad på att sensorn får ett tuffare jobb, men det ska nog fungera bra tror jag!

[v-g]

Det är lite synd att alla rotationsencodrar ska gå så förbaskat trögt

Mixtra du jag tror du får till det.


Just ja kom på det med den andra lösningen som jag skrev ovan, får man inte nog stor upplösning sätter man bara två sensorer och vips så är upplösningen fördubblad (gäller att ena sluter då andra bryter osv.) Man kan även få ut riktningen då.

[victor_passe]

Men ta en vanlig mus med scrollhjul, På många av de jag har öppnat så sitter det en metallbit i scrollhjulet som gör att det snäpper till positioner, tar du bort det så rullar det fint och fritt. Och då får du 2 st 90Grader fasförskjutna signaler.

[arvidb]

Med reservation för att klockan är ohemult mycket och att jag är rätt trött eftersom jag inte kan sova p.g.a. värmen...

Jag har stött på samma problem som du - då gällde det funderingar kring en servostyrning där jag bara hade tillgång till encodersignalerna från motorn men behövde en bra approximation på hur snabbt motorn snurrade, även i låga hastigheter. Tyvärr har detta legat på is nu i ett antal år; när jag får ihop min fräs nångång i framtiden så behöver jag ta upp det igen för att få igång motorerna...

I vilket fall, tipset jag fick av ett riktigt mattesnille på KTH var att använda Richardson-extrapolering. Nu har jag inte satt mig in i detta, men om vi har något mattesnille här som kan förklara hur man gör så vore det intressant!

[hcb]

Kan du inte vid en lämplig hastighet byta mellan att mäta antal impulser per tidsenhet och att mäta tiden mellan två pulser? Men det blir kanske krångel vid bytet?

[Andax]

Ett sätt att få bättre positionsupplösning för att skapa bättre hastighetsuppskattning vid riktigt låga hastigheter är att faktigt försöka få ljuset mer ofokuserat eller på andra sätt få en mjukare flank (inte filtrera tidsmässigt, för du vill ha en signal som varierar mjukt som en sinus när du roterar enkodern sakta) sen kopplar du dina två sensorer (0 och 90 grader) till ADC på picen och omvandlar. Då kan du mha av förhållandet mellan dessa mätvärden interpolera fram högre upplösning.
Det är så man gör med sk. analoga kvadraturenkodrar. (engelska "analog quadrature encoder", alt "sin/cos encoder"). Med den metoden finns det enkodrar där man har flera 100-tusen steg per varv!

Sen kan man ju använda en magnetisk encoder (har använt en till min inverterade pendel), t.ex. från austriamicrosystems. De har en ny med 14-bitars upplösning (16384 steg per varv). ELFA har en liknande med 12 bitars upplösning: 73-215-32

[squiz3r]

1-Juli-2009 - Bättre precision!

Idag har jag fortsatt byggandet för att få bättre precision på sensorn....

...Men först, jag glömde ju visa hur jag satte fast elektroniken. Jag satte en M3 skruv genom plastsaken, sen limmade jag fast LEDn och kontakten där jag kopplar in fototransistorn i muttern med smältlim. Detta är bara tillfälligt, och det är alltså lätt att plocka bort utan att det blir några smältlimsrester kvar.




Efter en lång stunds funderande och rotande bland de olika kugghjulen lyckades jag bygga ihop detta, det ger en utväxling till 1:3, alltså att encoderdisken snurrar 3 gånger snabbare än hjulet som driver den. Detta gör ju också att jag får 3 gånger så bra upplösning, och 3 gånger så bra uppdateringsfrekvens.




Det fungerade jätte bra, 816,6Hz här, och inga problem med deformerade signaler eller nått!
816,6Hz / 7 * 60 = 6999,5 RPM på encoderdisken
6999,5 RPM / 3 = 2333 RPM (På hjulet)
2333 RPM * 2tt * 11 / 1000 / 60 = 2,68 m/s
2,68 m/s * 3,6 = 9,7 km/h


Men, tro inte att jag nöjer mig med detta! Nästa sak jag gjorde va att fräsa ut en ny disk, denna gången med 42 hål! Det är 6 gånger fler än vad jag hade innan (7), vilket kombinerat med föregående förbättring ger 18 gånger högre upplösning (~0,3mm / sträck), och 18 gånger högre uppdateringsfrekvens (1633 ändringar / sekund vid 10km/h)!


Jämförelse med den gamla disken. Dock körde jag kressen på lite för högt varvtal tror jag, så det smälte lite vilket gjorde att hålen blev lite större än vad de borde vara... Ska göra en ny sen, men jag tror jag gör lite färre hål då... (se nedan..)


Satte på den nya disken på modulen...


Men efter massa justering av sensorn och LEDn så fick jag ändå inte bättre signal än såhär... Så det behövs nog lite större hål.. (Här får jag en VPP på 1,2v..)



Får gå o fräsa ut en ny disk nu...

[squiz3r]

Andax: Den sensorn verkar ju smidig, men den är ju dyr, pratar bara SPI (vill ha I2C), och det känns som om det är lite svårt att få den fungera bra? (Med magneten och sånt)

Och det där andra låter som om det är svårt, då måste man väll få en fin sinuskurva ut från sensorn?

arvidb: Kollade på det (wikipedia, Richardson_extrapolation), och jag förstod inte så mycket...

hcb: Förstår inte vad det skulle göra för nytta, vid det första alternativet har man en fast uppdateringsfrekvens, som är den lägsta man kan behöva (alltså så dålig som möjligt) och vid det andra alternativet så låter man uppdateringsfrekvensen justeras efter hur sakta den behöver vara (Kan alltså gå ner lika mycket som första alternativet, men ligger annars bättre till än den). Så då blir det ett enkelt val, andra alternativet, för mig.. Eller har jag missat nått?

[v-g]

Den finns även i en analog variant som man kör in på a/d omvandlaren och sen en med PWM.

Men verkar ju fungerar rätt bra nu ändå som jag tippade

[squiz3r]

Annalog utgång känns inte som om det är så säkert om man ska mäta sträcka? Till hastighet kanske det fungerar...

Jo, Jag ska experimentera vidare med min variant, egentligen hade jag velat växla upp den ännu mera... För att öka varvtalet verkar inte vara några problem alls för encodern, dock att göra fler "linjer" (=hål) på encoderdisken verkar bli lite problematiskt...

Det finns bara två problem med att växla upp den mer (om jag lyckas med det utan att bygga om den...) och det första är att det kommer bli stressigt om jag ska hinna med att skicka seriell data mellan alla interrupt (Jag hade tänkt koppa in flera sånna här sensorer till samma PIC), och det andra är att den övre legoaxeln snurrar redan nära 10kRPM vid 10km/h, det betyder att om jag dubblerar utväxlingen så blir det 20 000 RPM för en liten legoaxel!! (Dock verkar ju den ny byggda delen i POM plast göra att det klarar sig bättre, men vi får se!...

[v-g]

Nja kan nog bli svårt i 10k RPM men i övrigt är det som en potentiometer fast utan beröring. Kör den själv om du kollar acctanksövervakning under signaturen.

Frågan är ju om du behöver så hög upplösning som du nu verkar ha

Kruxet är att om du tex backar så ryker ändå allt iom att kugghjulen glappar, detta sker inte om hjulet så att säga direktdrivs.

[squiz3r]

Nä, Om jag har en sån sensor så behöver jag ju inte ha utväxling på den, då kan jag ju montera den direkt till hjulet! Då blir det max runt 2kRPM.

Visst går utgången från 0-5v på ett varv? Enligt databladet kan den ändra utspänningen med 200v/ms, alltså 40 varv per ms i så fall. Då blir det: 40 varv * 1000ms * 60sek = 2 400 000 RPM som den klarar max . Kan det stämma!?

Jag kollade igenom din tråd, och den verkar ju vara skit smidig! Om jag ha ett hjul som är 20mm i diameter, då blir omkretsen 125,6mm. Den sensorn gav 200 steg per kvartsvarv enligt din tråd, antar att det är på en PIC med 10-bitars ADC och Vref = 5v? I så fall blir det 800 steg per varv, vilket skulle ge en upplösning på 125,6mm/800steg = 0,157 mm/steg. Och det räcker för mig! Jag undrar bara hur lång tid det tar för ADCn på PICen att mäta ett värde?.. Men det kan ju inte vara några problem att mäta 500 ggr/sek eller nått sånt?

Jag är riktigt sugen på en sån sensor nu... Men jag har ingen lust att beställa från ELFA, dem är dyra, och jag är emot dem eftersom jag aldrig använt något liknande innan.

Ingen som har någon/några liggandes? (Man borde kunna hitta dem mycket billigare än ELFA?? De är ju inte direkt kända för att va billiga.. )

"Frågan är ju om du behöver så hög upplösning som du nu verkar ha"
Nä, Upplösningen behöver jag egentligen inte ha, det är bara högre uppdateringsfrekvens jag är ute efter!

Mvh. Danne

[v-g]

Hur snabbt A/Dn kan mäta beror ju på vilken PIC du har så det är nog bara RTM och räkna på det hela som gäller där.

Kolla filmen så ser du skalan på ett ungefär.

Stämmer bra med PICens specar ja. Det är en 18f2221.

Har tyvärr bara en endaste sensor och den används. Kanske finns nån liknande på Farnell där ska ju en sambest gå iväg ikväll

[arvidb]

Jag fick tips av en bekant om följande metod:

Låt s vara sträckan som roboten tillryggalägger mellan två pulser/flanker. Låt t(n) vara tidpunkten för senaste pulsen och t(n-1) tidpunkten för näst senaste. Robotens fart v kan då uppskattas till v = s/(t(n) - t(n-1)). Låt t vara nuvarande tidpunkt. Om t - t(n) > t(n) - t(n-1), d.v.s. om tiden sedan senaste pulsen är större än tiden mellan senaste och näst senaste pulsen, används istället uppskattningen v = s/(t - t(n)).

Det hela beror ju lite på vad du ska ha hastighetsuppskattningen till - ska du använda det för en servoloop för att finreglera låga hastigheter fungerar det nog inte.