Codierung für absoluten Winkelencoder

M

Michael Koch

Guest
Hallo,

eine knifflige Frage über die Codierung eines
Winkel-Encoders:

Der Drehwinkel einer Welle soll mit einem speziellen absolut
messenden Encoder erfasst werden. Im Gegensatz zum Gray-Code
soll aber nur EINE EINZIGE Code-Spur verwendet werden,
welche von mehreren Sensoren an verschiedenen Stellen
abgetastet wird. Wie beim Gray-Code soll sich immer nur ein
Bit gleichzeitig ändern. Das einfachste Beispiel ist der
normale Quadratur-Encoder mit 90° Auflösung:

Codespur: 0011 (jedes der 4 Segmente ist 90° lang)
Sensoren: SS (ein Sensor bei 0°, der andere Sensor bei
90°)
Das Ausgangssignal sieht nacheinander so aus: 00, 01, 11,
10.

Wie lässt sich dieses Prinzip auf höhere Winkelauflösung
erweitern? Das folgende Beispiel zeigt einen Encoder mit 20°
Auflösung:

Codespur: 000000000111111111 (jedes der 18 Segmente ist
20° lang)
Sensoren: SSSSSSSSS (9 Sensoren jeweils im
Abstand von 20°)
Das Ausgangssignal sieht nacheinander so aus: 000000000,
000000001, 000000011, 000000111, ... , 110000000, 100000000

Nun ist es natürlich ungünstig dass man dafür so viele
Sensoren braucht. Wir kommen zu der entscheidenden Frage:
Ist es möglich die Anzahl der Sensoren zu reduzieren, indem
man ein geeignetes Muster auf der Codespur verwendet und
indem man die Sensoren an geeigneten Stellen anordnet?
Die Codespur darf ein beliebiges Muster aus den Elementen 0
und 1 sein, und die Sensoren dürfen an beliebigen Stellen
angeordnet werden.
Wichtige Randbedingungen:
1. Es sollen sich niemals zwei Ausgangssignale gleichzeitig
ändern.
2. Der Drehwinkel muss immer eindeutig bestimmbar sein, d.h.
das gleiche Ausgangssignal darf nicht mehrfach vorkommen.
3. Es ist NICHT zwingend gefordert dass die Auflösung gleich
(360° / Codelänge) ist.

Es kann sein dass es gar keine Lösung gibt, d.h. für 20°
Winkelauflösung könnte die Lösung mit 9 Sensoren bereits
optimal sein.
Findet jemand ein Gegenbeispiel mit weniger als 9 Sensoren?

Ich bedanke mich für's Nachdenken, für alle weiterführenden
Hinweise, oder für den Beweis dass es keine Lösung gibt.

Michael
 
wie wärs damit:
ausgehend vom Gray-Code könnte man die Bits
hintereinander anordnen ... also ein Segment mit allen
Bits 0 ... das nächste mit allen Bits 1 ...
die Sensoren dann so weit auseinander, dass ein üblicher
Gray-Code erkannt wird

mal für 8 Zustände/ 3 Bits:
01100110 00111100 00001111
S S S

wenn ich mich jetzt nicht verzählt habe, dann bleibt die
Gray-Code Eigenschaft auch bei mehr Bits und auch
an den Grenzen erhalten! (je nur 1 Bit ändert sich)

.... allerdings bleibt nun das Problem, dass das ganze nicht
mehr eindeutig ist ... zu jedem Bitmuster gibt es nun
immer gleich drei Möglichkeiten

nach einer kurzen Drehung des Rades könnte man sich
jedoch für die plausible Lösung entscheiden und dann
wäre das ganze wieder eindeutig :))


aber irgendwie ohne Drehung fällt mir grad nix ein ..


bye,
Michael
 
Hallo Michael,

mal für 8 Zustände/ 3 Bits:
01100110 00111100 00001111
S S S
das ist ein interessanter Ansatz, aber wie du schon selber
geschrieben hast sind die Zustände leider nicht eindeutig:

000, 100, 110, 010, 011, 111, 101, 001,
000, 001, 101, 100, 110, 111, 011, 010,
000, 010, 011, 001, 101, 111, 110, 100

Es scheint so als ob man immer erst drei Schritte machen
muss bevor die Mehrdeutigkeit beseitigt wird.

Gruss
Michael
 
Hi Michael ..

mal für 8 Zustände/ 3 Bits:
01100110 00111100 00001111
S S S

das ist ein interessanter Ansatz, aber wie du schon selber
geschrieben hast sind die Zustände leider nicht eindeutig:
das ist richtig - obwohl es ein Gray Code mit 3 Bit ist, sind es
24 Positionen die man mit 3 Bits natürlich nicht abzubilden
kann ... nötig wären ld(24) also 5 Bits bzw. Sensoren

mich hat das ganze nicht losgelassen und ich habe angefangen
zu suchen - am Ende numerisch ;-) ... und für 6 Sensoren
hab ich einige Lösungen gefunden ...

also - obigen Gray code auf dem Kreis und
Sensoren an den Positionen
[B(i) B(i+8) B(i+16) B(i+1) B(i+2) B(i+12)]

das liefert die Muster:

0 0 0 1 1 1
1 0 0 1 0 1
1 1 0 0 0 0
0 1 0 0 1 0
0 1 1 1 1 0
1 1 1 1 0 0
1 0 1 0 0 0
0 0 1 0 0 0
0 0 0 0 1 1
0 0 1 1 1 1
1 0 1 1 1 1
1 0 0 1 1 1
1 1 0 1 0 0
1 1 1 0 0 1
0 1 1 0 0 1
0 1 0 0 0 0
0 0 0 0 0 0
0 1 0 0 0 1
0 1 1 0 1 1
0 0 1 1 1 0
1 0 1 1 1 0
1 1 1 1 1 0
1 1 0 1 0 1
1 0 0 0 1 1


sind alle eindeutig :))
die hinteren drei ändern sich später aber wild ... und wenn du
beide Drehrichtungen brauchst, dann wirst du sie auch später
noch brauchen ... (Positionen 8-10)
nur die ersten drei Bits erfüllen die Bedingung nicht zu "springen"


okay - jetzt das ganze noch für ein paar mehr Schritte:
16er Gray Code liefert 64 Positionen

B = [0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 ...
0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 ...
0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 ...
0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1];


funktionieren würden Sensoren an den Positionen
[B(i) B(i+16) B(i+32) B(i+48) B(i+2) B(i+6) B(i+45)]

auch hier: die ersten 4 sind Gray-Code Symbole ...
die hinteren drei für die Startposition ...

0 0 0 0 1 0 0
1 0 0 0 0 1 0
1 1 0 0 0 1 0
0 1 0 0 1 0 1
0 1 1 0 1 0 1
1 1 1 0 0 0 1
1 0 1 0 0 1 1
0 0 1 0 1 1 0
0 0 1 1 1 1 0
1 0 1 1 0 1 0
1 1 1 1 0 0 0
0 1 1 1 1 0 1
0 1 0 1 1 0 1
1 1 0 1 0 0 1
1 0 0 1 0 1 1
0 0 0 1 0 1 0
0 0 0 0 1 1 0
0 0 0 1 1 1 0
1 0 0 1 1 0 0
1 0 0 0 1 0 0
1 1 0 0 0 0 0
1 1 0 1 0 0 1
0 1 0 1 0 0 1
0 1 0 0 0 0 1
0 1 1 0 1 1 1
0 1 1 1 1 1 1
1 1 1 1 1 1 1
1 1 1 0 1 1 1
1 0 1 0 0 1 1
1 0 1 1 0 1 0
0 0 1 1 0 1 0
0 0 1 0 0 1 0
0 0 0 0 0 0 0
0 0 1 0 0 0 0
0 0 1 1 1 0 0
0 0 0 1 1 0 0
1 0 0 1 1 0 0
1 0 1 1 1 0 0
1 0 1 0 1 0 0
1 0 0 0 1 0 0
1 1 0 0 1 0 0
1 1 1 0 1 0 1
1 1 1 1 0 0 1
1 1 0 1 0 0 1
0 1 0 1 0 1 1
0 1 1 1 0 1 1
0 1 1 0 0 1 1
0 1 0 0 0 1 1
0 0 0 0 0 1 1
0 1 0 0 0 1 0
0 1 1 0 0 1 1
0 0 1 0 0 1 1
0 0 1 1 0 0 0
0 1 1 1 0 1 0
0 1 0 1 1 1 1
0 0 0 1 1 0 1
1 0 0 1 1 0 0
1 1 0 1 1 1 0
1 1 1 1 1 1 1
1 0 1 1 1 0 1
1 0 1 0 1 0 0
1 1 1 0 1 1 0
1 1 0 0 0 1 1
1 0 0 0 1 0 1

aber leider auch hier: für 64 Positionen (6Bit)
brauche ich 7 Bit ... das ist noch nicht das
Optimum :-(



bye,
Michael
 
Hallo Michael,

also - obigen Gray code auf dem Kreis und
Sensoren an den Positionen
[B(i) B(i+8) B(i+16) B(i+1) B(i+2) B(i+12)]

das liefert die Muster:

0 0 0 1 1 1
1 0 0 1 0 1
...

sind alle eindeutig :))
die hinteren drei ändern sich später aber wild ... und wenn du
beide Drehrichtungen brauchst, dann wirst du sie auch später
noch brauchen ... (Positionen 8-10)
nur die ersten drei Bits erfüllen die Bedingung nicht zu "springen"
Es müssen aber alle Bits die Bedingung erfüllen, sonst kann
das Ganze schief gehen wenn die Code-Scheibe am Anfang
zufällig genau an einer Grenze steht. Zum Beispiel ändert
sich im obigen Beispiel das erste und das fünfte Bit, aber
es ist nicht vorhersehbar in welcher Reihenfolge. Das heisst
dass an dieser Stelle vier mögliche Kombinationen vorkommen
können:
0 0 0 1 1 1 alter Zustand
1 0 0 1 1 1 möglicher
Zwischen-Zustand
0 0 0 1 0 1 möglicher
Zwischen-Zustand
1 0 0 1 0 1 neuer Zustand

Entsprechend müsste man an allen anderen Übergängen auch
alle möglichen Kombinationen betrachten, auch wenn diese nur
kurzzeitig vorkommen können. Und unter all diesen
Möglichkeiten darf keine mehrfach vorkommen.

Gruss
Michael
 
Michael Koch schrieb:

Entsprechend müsste man an allen anderen Übergängen auch
alle möglichen Kombinationen betrachten, auch wenn diese nur
kurzzeitig vorkommen können. Und unter all diesen
Möglichkeiten darf keine mehrfach vorkommen.
Der Ansatz, mit der üblichen Quadraturcodierung, also zwei versetzte
Auswertungseinheiten, bei denen über die Abfolge der Übergänge die
Richtung ermittelt wird, sollte auch hier Informationen über die
Drehrichtung geben können. Damit wäre der Bereich Richtungserkennung
abgeschlossen.
Ein geeignetes Codierungsmuster sollte nun sowohl vorwärts als auch
rückwärts in zwei Schieberegister getaktet werden, wobei die Drehrichtung
bestimmt, welches Register auszuwerten ist und ob ausreichend viele Bits
nach Drehrichtungsänderung eingelaufen sind.
Die Bitabfolge ist ja hier schon diskutiert worden, wobei ich sie im
Detail nicht nachvollzogen habe.

Vielleicht hilt ja dieser Ansatz weiter...

Gruss Udo


Gruss
Michael
 
Michael Koch:
Codespur: 000000000111111111 (jedes der 18 Segmente ist
20° lang)
Sensoren: SSSSSSSSS (9 Sensoren jeweils im
Abstand von 20°)
Das Ausgangssignal sieht nacheinander so aus: 000000000,
000000001, 000000011, 000000111, ... , 110000000, 100000000
Ich haette ein Beispiel mit einer Aufloesung von 15° und 6 Sensoren
anzubieten:

Codespur: 011100000001111111111100
Sensoren: S...S...S...S...S...S...

Das liefert die Codeworte:

000111, 100111, 100110, 101110,
001110, 001111, 001101, 011101,
011100, 011110, 011010, 111010,
111000, 111100, 110100, 110101,
110001, 111001, 101001, 101011,
100011, 110011, 010011, 010111

Die Worte in der 1. und 3. Spalte besitzen je drei '1'-Bits.
Die Worte in der 2. und 4. Spalte besitzen je vier '1'-Bits.

Wenn zwischen den Sensoren statt 4 Bit nur 3 Bit auf der Codespur
laegen, dann waere die Gray-Bedingung bereits nicht mehr erfuellbar.
Fuer eine 18-bittige Codespur sehe ich also schwarz.


Aber vielleicht kannst Du etwas mit einer 36-bittigen Codespur
(also 10° Aufloesung) anfangen?

Codespur: 000011000000011111111111110001111000
Sensoren: S.....S.....S.....S.....S.....S.....

Codeworte:

000111, 001111, 001101, 001100, 101100, 101110,
001110, 011110, 011010, 011000, 011001, 011101,
011100, 111100, 110100, 110000, 110010, 111010,
111000, 111001, 101001, 100001, 100101, 110101,
110001, 110011, 010011, 000011, 001011, 101011,
100011, 100111, 100110, 000110, 010110, 010111

Bei eigenen Konstruktionen solltest Du darauf achten, nur Codeworte
einzubauen, deren Bitmuster sich nicht wiederholen. Die Worte '100100'
oder '101010' sind zum Beispiel ungeeignet.


Noch viel Spass beim Herumkniffeln!

Mirko Liss
 
Hallo Mirko,

Aber vielleicht kannst Du etwas mit einer 36-bittigen Codespur
(also 10° Aufloesung) anfangen?
das ist ja ein ganz phantastisches Beispiel, genau das was
ich gesucht habe! Und man braucht nur 6 Sensoren für 10 Grad
Auflösung, gegenüber 18 Sensoren die ich nach meiner
trivialen Anordnung gebraucht hätte.

Jetzt verrate mir nur noch eins: Wie bist du so schnell
darauf gekommen?
Gibt's da irgendeinen Trick um eine geeignete Codespur zu
finden?

Bei eigenen Konstruktionen solltest Du darauf achten, nur Codeworte
einzubauen, deren Bitmuster sich nicht wiederholen. Die Worte > '100100' oder '101010' sind zum Beispiel ungeeignet.
Logisch, das war mir auch schon klar geworden.

Tausend Dank,
Michael
 
Michael Koch:
Jetzt verrate mir nur noch eins: Wie bist du so schnell
darauf gekommen?
Bei diesen kurzen Codes lohnt es IMHO nicht, Matrizen aufzustellen oder
Gleichungssysteme zu loesen. Ich habe sechsstellige Bitmuster nach der
binaeren Quersumme geordnet, also:

0: 000000 ist ungeeignet.
1: 000001
2: 001100, 101000 aber: 100100 ist ungeeignet.
3: 000111, 001101, 101100 aber: 101010 ist ungeeignet.
4: 001111, 101100 aber: 011011 ist ungeeignet.
5: 011111
6: 111111 ist ungeeignet.

Alle anderen Bitmuster koennen durch Rotation aus diesen Mustern
gebildet werden.

Das erste Codewort ist (ziemlich) frei gewaehlt: 000111
Dadurch ist auch das siebte Codewort bestimmt: 001110

Da sich zwei aufeinanderfolgende Codeworte in genau einem Bit
unterscheiden, folgt auf ein Codewort mit drei '1' Bits eines mit zwei
oder vier '1' Bits. So kann man ausgehend vom ersten und siebten
Codewort die Worte zwei bis sechs ausknobeln. Falls man gerade ein
Brett vorm Kopf hat, hilft eine KV-Tafel weiter.

Aus den ersten sechs Codeworten erhaelt man durch Rotation den Rest des
Codes.

Gibt's da irgendeinen Trick um eine geeignete Codespur zu
finden?
Man kann sie aus den ersten Codeworten ablesen.

Das erste Codewort:
0.....0.....0.....1.....1.....1

Das 2te: .0.....0.....1.....1.....1.....1
Das 3te: ..0.....0.....1.....1.....0.....1
Das 4te: ...0.....0.....1.....1.....0.....0
Das 5te: ....1.....0.....1.....1.....0.....0
Das 6te: .....1.....0.....1.....1.....1.....0

ergibt die
Codespur: 000011000000011111111111110001111000


Gut's Naechtle,

Mirko Liss
 
Hallo Mirko,

danke für die ausführliche Beschreibung, jetzt hab ich das
Prinzip vertanden, und auch gleich eine 48 Bit lange
Codespur für 6 Sensoren gefunden.

Gruss
Michael

0.......0.......0.......0.......0.......1
..0.......0.......0.......1.......0.......1
...0.......0.......1.......1.......0.......1
....0.......1.......1.......1.......0.......1
.....0.......1.......1.......1.......1.......1
......0.......0.......1.......1.......1.......1
.......0.......0.......0.......1.......1.......1
........0.......0.......0.......1.......1.......0

000000000001100000111100011111110000111111111110

000001
000101
001101
011101
011111
001111
000111
000110
000010
001010
011010
111010
111110
011110
001110
001100
000100
010100
110100
110101
111101
111100
011100
011000
001000
101000
101001
101011
111011
111001
111000
110000
010000
010001
010011
010111
110111
110011
110001
100001
100000
100010
100110
101110
101111
100111
100011
000011
 

Welcome to EDABoard.com

Sponsor

Back
Top