Atmega32: Aktueller Ausrichtung des Roboters falsch... Nur wieso ?

[oberallgeier]

... "Ich habe das schon verstanden, wer Ketten verwendet ist selber schuld" ...

Ich bin sicher manchmal recht spitzzüngig - hier hatte ich das keinesfalls so gemeint. Wenns so rausgekommen ist, dann entschuldige das bitte.

Die Odometrie lebt eben davon, dass ein eindeutig definierbarer Wälzkörper sich auf einer eindeutig definierbaren Linie - und das möglichst schlupflos - über die befahrene Fläche bewegt. Und die befahrene Fläche sollte eine Ebene sein, sonst wirds richtig kompliziert. Bei der Kette ist eben die abwälzende Linie nicht eindeutig definierbar.

Möglicherweise gäbe es eine Lösung durch einen Nach-/Mitläufer, ein Rad, das - ähnlich wie ein Messrad bei Autotests - neben der Kette (z.B. "unsichtbar" innen neben jeder der beiden Ketten) angeordnet ist.

[Ritchie]

Hallo,
danke für die Entschuldigung.

Ich Suche gerade weiter nach evtl. Fehler in der Mathe.

Klar ist mir auch, das Ketten nicht so optimal sind, wie es sich bei normalen Gummireifen zeigt.

Ich will nur derzeit die Mathefehler ausschliessen, bevor ich mit dem "Gyro" anfange, die Probleme einer Kette weiter einzuschrenken. Ich habe mich halt für eine Kettenfahrzeug entschieden und muss damit leben.

Gruss R.

[RP6conrad]

Wird diese CalculateOrientation() nur einmal pro PID Durchlauf aufgerufen, oder mehrmal ? Wird "deltaOrientation" zuruck auf 0 gesetzt oder aufaddiert ? Werden nStepsLeft und nStepsRight jeden mal auf 0 gesetzt ? Ich sollte in diese Richtung suchen. Eigenlich soll ihre Winkelaenderung einfach "nStepsLeft - nStepsRight" sein, naturlich dan mit signed int gerechtnet. Mit unsigned mussen sie dan erst prufen welche die grosste Wert ist, und dan auch das differenz bilden. Da ist keine notwendigkeit um das jeden PID Durchlauf zu machen, diese Winkelaenderung ist theoretisch unabhangig von gefahrene Strecke und soll immer proportional sein mit das Differenz L/R Pulsen
Hass du kwadratur encoder, oder muss du die Drehrichtung schatzen an Hand von die ansteurung von H-Brucken ? Da kan naturlich auch etwas schief gehen. Es scheint muir einfacher nstepsRight und nStepsLeft signed zu definieren, und an Hand von der Ansteurung von die H-Brucke dan diese nSteps HOch oder Runter zahlen. Dan passt auch das Differenz immer.

[Ritchie]

Hallo,

ich muss wohl nochmals die Hardware prüfen, ob mir der Sensor IC-MA (Hall Sensor), welchen ich hier das erste mal einsetze, nicht ein paar Streiche spielt.

http://www.ichaus.de/product/iC-MA

Hierbei sind folgende Fehlerquellen eine mögliche Quelle des Verhaltens:

- Schwankende Spanungsversorgung durch Motorlast während der fahrt könnte zu falschen Impulsen führen

- Magnetfelder erzeugt durch die Motoren (laut Datenblatt soll der Sensor das aber ausregeln, nur wer weiss ..), könnte auch falsche Impulsmeldungen erzeugen

Bis jetzt konnte ich keine Fehler in meiner Software finden! Die Berechnungen erscheinen mir korrekt.

@RP6conrad
ja, diese Routine wird nur einmalig aufgerufen, nachdem der PID Regler die Motorenansteuerung angepasst hat.
Die Ansteuerung und Auswertung der Richtung erfolgt anhand der Software. Daher die Auswertung von "m_DirectionFlagLeft == m_DirectionFlagRight". Sind beide Variablen gleich, erfolgt keine Rotation, sondern nur eine vorwärts oder rückwärtsfahrt.

"double deltaOrientation" ist nur in der Funktion "CalculateOrientation" gültig. Sie wird nur für eine Zwischenrechnung verwendet und addiert den ermittelten Wert auf die globale Variable "m_ActualOrientation". Diese Variable kann ich durch eine Visualisierung auf meinem Rechner während der Fahrt sichtbar machen. Hier sehe, das der Wert nicht korrekt ist.

Ich habe nicht die Möglichkeiten des Encoder ausgenutzt, das er mir die entsprechende Richtung angibt.
Ich gehe gehe davon aus, das wenn ich beide Motoren in der gleichen Richtung über das IC "vnh2sp30" ansteuere, das hier auch die korrekte Richtung durch den Motor erfolgt.

Gruss R.