Mäta Roll, Pitch och Yaw på en kub?

[Eelector]

Jag har en kub (ca 50cm i kubik) som jag med hjälp av en uC (troligen arduino) skulle vilja veta orienteringen på. (i absoluta tal, inte relativ rörelse)
Kuben kan vara både i rörelse och stillastående. Hur löser jag detta tro?

Med en accelerometer kan man få fram roll och pitch, men yaw verkar svårt...
Det finns ju digitala kompasser, men hur tillförlitliga är de när de inte står plant?
Finns det några andra sätt?

[barbarossa]

Du kan få ut allt med en 3-axlig accelerometer utom rotation runt linjen som skär sensorn och jordens masscentrum.

Edit: Du behöver ett gyro för yaw

[danei]

Ska du kunna göra det även i rörelse så krävs det någon typ av gyrofunktion också.

[Eelector]

Men får man absolut position från ett gyro? Får du inte bara relativ?
(just nu rör sig kuben x rotationer/s runt Z axeln)

[jonte_s]

Japp. När du integrerar gyrots "hastighetssignal" så får du en relativ position, vars fel blir större ju mer du integrerar. Därför behöver du (också) något som ger en absolut position, typ en kompass eller magnetometer.

[barbarossa]

Du får ut acceleration med en accelerometer och vinkelacceleration med ett gyro. För att bestämma position och vinkel måste du integrera och det gäller bägge sensorerna.

[barbarossa]

Vad J sa, eller någon form av nollningsfunktion.

[Eelector]

Jag gjorde en sökning och tror jag hittat en perfekt produkt för detta:
http://www.sparkfun.com/products/9623

Synd bara på priset, jag behöver rätt många...

Tack för de snabba svaren!!

[barbarossa]

Jag sa fel, gyrot mäter vinkelhastigheten. Du måste dock integrera ändå, men bara en gång.

[monstrum]

En 3-axlig magnetometer i kombination med en 3-axlig accelerometer kan ge dig absolut orientering i alla axlar, så länge du inte måste använda kuben på någon av de magnetiska polerna och så länge yttre acceleration är försumbar.

Måste du veta exakt orientering i varje tidpunkt, utan att rörelsen är känd så måste du även ha gyron.

[Eelector]

Tack för alla svar!

Jag har en liten relaterad fråga som jag tänkte passa på att ställa:
När jag väl fått fram orienteringen så behöver den överföras till en central server.
Tyvärr är den enda aktuella överföringsmetoden begränsad till en payload på endast 1 byte (!) per uppdatering.
Jag undrar därför om ni kan hjälpa till att komma på den smartaste och mest effektiva kodningen för att få med så mycket info som möjligt
på dessa 8 stackars bitar. Att få in en vektor med hjälp av endast 256 värden verkar rätt dödfött?

I enklast tänkbara form skulle den kunna bestå av vilken av de 6 sidornas normaler som är närmast norr resp. vilken som är närmast jordaccelerationen, dvs
Det ger ett slags snap to grid mot närmast "rätvinkliga" position.
Går det att få in mer tro?

[Walle]

Jag förstår inte riktigt, ska orenteringsdatat vara "steglöst", eller räcker det med att veta vilken sida som är ner och vilken som är mot norr?

Hursomhelst har du ju 256 olika kombinationer med din byte, därmed kan du specificera 256 olika lägen.

Om dutänker dig kuben liggande på ett plant underlag, och att den alltid har en sida vänd rakt mot norr (alltså det du kallar "snap to grid mot närmast "rätvinkliga" position") , så har den ju bara 24 olika states (6 sidor kan ligga mot underlaget, och i varje läge kan en av fyra sidor vara vända mot betraktaren, 6*4) Alltså har du fortfarande 232 olika orienteringar "kvar" som inte används. Effektiviteten i den dataöverföringen blir endast 9.3%, rätt illa om man bara har en byte att "leka" med

Men om du istället ökar på antalet "snäpp" till halvsteg, ja då får du helt plötsligt 208 olika lägen (om jag inte har tänkt fel, vilket dock är möjligt. 26 olika "sidor" (delar, eller vad man ska kalla det..fortsätter tanken nedan) kan vara nedåt, 8 olika kan vara mot norr, alltså 26*8=208), alltså en effektivitet i dataöverföringen på 81.25%.

Forts. från parentesen ovan: tänk dig en Rubiks kub. Den består av 26 stycken olika bitar (varav 6 stycken centrumbitar sitter fast i korset). Med "halvsteg"/halvsnäpp så skulle vilken som helst av de 26 olika bitarna vara "nedåt" (då får man ju räkna centrumbitarna som representant för att den sidan ligger plant mot underlaget).

Så helt klart går det att utnyttja dataöverföringen bättre. Bara du vet om det behövs eftersom det verkar vara lite hemligt

[monstrum]

Kan du inte skicka flera bytes i rad? Kanske skicka vektorerna bitvis eller på något annat finurligt sätt så att den första byten ger en väldigt grov uppskattning, sedan förfinas värdet efterhand som fler bytes trillar in.

[Eelector]

Tyvärr fungerar det inte att skicka flera bytes efter varandra eftersom det då skulle bli för låg uppdateringsfrekvens.

Walle: 45 graders steg skulle nog funka fint. Det verkar ju passa fint in i 1 byte.
Antar att det var något liknande detta du tänkte?


Hur hanterar man detta rent praktiskt tro? Jag får ju tre värden från sensorerna. Finns det något smart sätt att numrera "facetterna" i något slags lookup table?

[Walle]

Japp, det var sådär typ jag menade. Däremot tänkte jag nog fel, det blir 136 olika orienteringar. 53%

Vad är det för uppdateringsfrekvens vi pratar om? Finns det en vettig anledning att ha hög uppdateringsfrekvens, om "lägena" är så grova att det för det mesta ändå skickas samma byte? Jag menar, om du kunde skicka tre sekventiella bytes så skulle du få en upplösning på 256 lägen per axel, med totalt 16.777.216 olika möjliga orienteringar. Du skulle kunna få kommunikationseffektiviteten i 100%. Allt till en trade-off av en tredjedels uppdateringsfrekvens.

Japp, en lookup-table var det jag tänkte på.