Projekt: FreeRTos auf RP6

[SlyD]

Hallo Rolf,

sieht alles schon ganz gut aus - ich hatte nur leider noch keine Zeit mir alles genau anzusehen und zu testen, mache ich aber demnächst mal.
Ist aber auf jeden Fall eine gute Sache da einen PID Regler zu implementieren.


Zu der Frage im letzten Posting:
Im RP6 werden Reflexsensoren verwendet damit es mit der bestehenden Mechanik des CCRP5 Chassis kompatibel blieb.
(neue Pressformen kosten mehrere tausend Euro).


Auflösung != Genauigkeit.
Das der RP6 nicht auf 0.25mm genau fahren kann sollte offensichtlich sein und steht auch in der Anleitung.
Dennoch ist es halt die Auflösung der Drehgeber und kein "Mumpitz". Das wird ja auch für die Umrechnung der Geschwindigkeit in cm/s benötigt - wie willst Du das denn ohne diese Angabe bitte sonst machen?
Das an der Stelle mehrere Werte zwischen 0.23 - 0.25mm angegeben sind, wird in der Anleitung ausführlich erklärt. Die Ketten sind aus Gummi und haben Noppen (d.h. sie können sich unter Last etwas verformen und unterliegen Fertigungstoleranzen). Je nach Gewicht der Roboters, den Fertigungstoleranzen und sogar je nach Untergrund kann sich der Radius der "Räder" also etwas ändern, das muss man testen und dementsprechend einstellen.

Je Offroad tauglicher ein Roboterfahrwerk, desto ungenauer ist die Odometrie
Ein Kettenfahrwerk ist per Design (hoher Kettenschlupf beim Rotieren) nicht für präzise Fahrmanöver rein basierend auf der Odometrie gedacht. Dazu muss man externe Sensoren wie Gyro+Beschleunigungssensor verwenden.


--> Die Auflösung der Drehgeber wurde wegen der dadurch überhaupt erst möglichen Geschwindigkeitsregelung auf 625 Pulse
pro Umdrehung erhöht - von zuvor beim alten CCRP5 ganzen 4 Pulsen pro Umdrehung


MfG,
SlyD

[RolfD]

Hallo SlyD,
also testen... dafür sind in der Version da oben noch zu viel Macken drin. Ich werde aber demnächst eine Version mit kleinem Testprogramm rausgeben.. allerdings hat die Lib nicht mehr wirklich viel mit der RP6 Lib zu tun.
Thema Odometrie... also Rechenoperationen mit Kommazahlen (x * 0.25) sind immer komplizierter als z. b. ">>2" was hier bei 2 hundertstel Millimeter pro Puls vollkommen ausreicht. Wie du selbst sagst... die Odometrie an einem Kettenfahrzeug ist konstruktionsbedingt nicht sehr genau. Die Steigerung von 4 (RP5) auf 625 (RP6) Pulse macht natürlich schon viel aus. Eine weitere Verbesserung bringt nicht mehr so viel wie schon geschrieben - das dafür das Presswerkzeug geändert werden muss ist mir als Werkzeugmacher im Kunststoff-Formenbau klar. Daher weis ich aber auch, das es dafür keiner neuer Formen sondern nur Änderungen an den vorhandenen Formen bedarf - die nicht so teuer sind. Aber egal, einen echten Nutzen hätte es nur sehr beschränkt.

Mir ging es in der Abhandlung auch eher darum, zu klären was man von dem Antriebssystem im RP6 erwarten kann.. und was nicht. Wie ich auch schon erwähnte, würden elektrische Motorbremsen (GegenEMK) die Präzision auch noch mal deutlich erhöhen, das geht aber schnell zu Lasten der Batterie und des Getriebes. Im Grunde arbeiten Stepperantriebe nämlich auch nur deswegen genauer, weil sie dieses Prinzip exzessiv nutzen und haben meist noch den zusätzlichen Vorteil, das magels Getriebe kein Verschleiß entsteht. Beim RP6 lohnt es aus diesen Gründen einfach nicht auf Hundertstel zu rechnen - selbst wenn es ginge.
@Dirk
Ok aber das Umklemmen auf feste Versorgung macht nur Sinn wenn man den io Pin unbedingt anders nutzen will da es sonst das Gegenteil bewirkt, von dem was mal beabsichtigt war - Strom zu sparen.
Die powerON/OFF Befehle sinnvoll im Code unter zu bringen nutzt sicher mehr und wer bereit ist, den Pin umzufunktionieren kann sicherlich auch die Lib dahingehend "umschreiben". Ein "#define powerON() nop();" bzw gleiches für powerOFF() würd ja dann schon mal langen...
LG Rolf

[SlyD]

Hallo,

dafür sind in der Version da oben noch zu viel Macken drin. Ich werde aber demnächst eine Version mit kleinem Testprogramm rausgeben..

OK.

also Rechenoperationen mit Kommazahlen (x * 0.25) sind immer komplizierter

Rolf, das kommt in der RP6Lib doch gar nicht vor!
Intern arbeitet die Lib rein mit Encoder Ticks, die Makros machen das Programm nur lesbarer.
Und die Makros werden schon vom Präprozessor berechnet und in Integer umgewandelt.
--> wenn man tatsächlich im AVR Programm die Einheiten konvertieren möchte, dann skaliert man das halt zuvor um Faktor 100.

Nachkommastellen hat man auch bei nahezu allen anderen möglichen Drehgeber Auflösungen bei gegebener Übersetzung und Raddurchmesser.
Es wird eher noch schlimmer. Immerhin hat man so exakt 625 Zähler pro Umdrehung und nicht 312,5 oder 208,333333 oder 156,25 oder sowas krummes

Selbst wenn sich zufällig alles für 1mm pro Tick ergeben würde: weicht der Raddurchmesser leicht ab, haste doch wieder 0,984mm :-/

Daher weis ich aber auch, das es dafür keiner neuer Formen sondern nur Änderungen an den vorhandenen Formen bedarf - die nicht so teuer sind.

Ne um das gescheit einzubauen wären schon noch ein paar weitere Änderungen gemacht worden wo man nicht so einfach die Form für das Chassis hätte ändern können.

was man von dem Antriebssystem im RP6 erwarten kann..

139 Euro sind gar nix im Robotikbereich. Ich hab schon mit professionellen Systemen (zig tausend Euro) gearbeitet und entwickle gerade selbst was in dem Bereich. Auch da hat man mit zig Problemen zu kämpfen und nichts ist genau, da muss sogar sehr viel mit Wahrscheinlichkeiten gearbeitet werden um die wahrscheinlichste Roboterposition zu bestimmen. Niemand verlässt sich dafür auf Odometrie, die ist für die Motorregelung da und als grober Anhaltspunkt, dass sich der Roboter bewegt.
Sobald man offroad fährt ist es damit eh vorbei.


139 Euro zahlt man bei richtigen Plattformen übrigens mal locker für einen einzigen Motor, ohne alles
Der RP6 ist für Hobbyanwender, Schüler und Studenten gedacht und daher möglichst kostengünstig gestaltet.


> das magels Getriebe kein Verschleiß entsteht.

Nur ist der Energiebedarf meist höher, die Teile sind recht schwer und werden unhandlich groß wenn das Drehmoment ähnlich
wie bei einem kleinen Motor mit Getriebe sein soll.
Der viel höhere Preis kommt auch noch dazu
Drehgeber braucht man auch da, es können ja Schritte verloren gehen.
Bringt fast nur Nachteile für einen Roboter wie den RP6.
Und sollte doch mal das Getriebe draufgehen (was schon einige Zeit dauern wird): Ersatz kostet bei Conrad 3,95 Euro inkl. Encoder Musterscheiben.

Die Bauteile im RP6 wurden nicht per Zufall ausgewählt

MfG,
SlyD

[RolfD]

Eine recht wichtige Info am Rande... für Leute die mit freeRTOS spielen...
Im Port ATMega323, welchen ich auch hier nutze, fehlt in portmacro.h eine definition für "portPOINTER_SIZE_TYPE"
Diese wird bei nichtvorhandensein einer Definition in FreeRTOS.h mit
#ifndef portPOINTER_SIZE_TYPE
#define portPOINTER_SIZE_TYPE unsigned long
#endif
gesetzt.
Um das zu verhindern (der ATmega32 hat ja nur ein 16 bit Pointer) sollte man daher
#define portPOINTER_SIZE_TYPE uintptr_t
in die portmacro.h und da in der Nähe von den /* Type definitions. */ setzen.
Zum einen beseitigt das 2 Warnings, zum anderen scheint sich das auf die Stackberechnung in pxTopOfStack aus task.c auszuwirken.

@Slyd

139 Euro sind gar nix im Robotikbereich.

Ich weis das man da auch sehr viel mehr ausgeben kann... mir gehts auch nicht um die Qualität des RP6... die ist ok.
Wer stabilere Ritzel braucht, kann sich ja bei nem 3D-Druckdienst im Web Titanzahnräder anfertigen lassen... die kosten inzwischen auch nicht mehr so viel mehr als die Plastikräder vom großen C.
--

Dann muss ich ein Fehler in eigener Sache korrigieren... bei den Berechnungen für die ENCODER_RESOLUTION entstehen Fehler im Bereich von 2 10ntel.. nicht 2 100stel pro Enc.-Step. Da dies doch nennenswert mehr als oben berechnet ist, sollte man die Berechnungen entgegen meiner Aussage oben mit ENCODER_RESOLUTION ausführen und nicht nur einfach >>2 rechnen.

Ansonsten arbeite ich weiter an der Geschichte... nachdem ich feststellte, das die Writechar Funktion den Prozessor in der ISR blockt bis der UART frei ist "while (!(UCSRA & (1<<UDRE)));" , hab ich nun erst mal den Ersatz der UART Funktionen durch gequeute ISR Übertragung vorgezogen. Bei der Fehlersuche bin ich auch auf portPOINTER_SIZE_TYPE gestoßen. Der PID Regler tuts... wobei ich da bald am verzweifeln war... aber egal... die move und movecirc Funktion auch nachdem ich da noch paar Fehler fand.
Bis jetzt ist aber noch nichts so Reif, das man es zeigen kann.. daher .. und auch wegen eines PC-Virus den ich mir die Tage einfing.. dauerts noch bissel bis zur nächsten Veröffentlichung des aktuellen Quellcodes.

LG Rolf

[Max Web]

Hallo RolfD,

wieder einmal ein klasse Projekt!
Wie ist denn der momentane Stand?
Sehr praktisch wäre ein Versionsverwaltungssystem wie SVN/Git etc: So geht kein Code durch Viren verloren und alle am Projekt Interessierten können jederzeit den aktuellen Code einsehen.

Grüße,

Max

[RolfD]

Hallo Max, leider schleift es etwas aber ich bin ansich noch dran.
SVN/Git (warscheinlich über Surgeforge) überleg ich mir nach der ersten wirklich vorzeigbaren Release.
Zur Zeit versuche ich die UART Lib anzupassen und da gibts noch ein Problem .. danach kann das aber mal begutachtet werden.

LG Rolf

[RolfD]

Ich werde das Projekt erst mal auf Eis legen, ich hab leider grade zu viel anders um die Ohren als das ich da z.Z. effektiv dran arbeiten könnte. Als Zusammenfassung kann ich jedoch sagen, das RTOS auf der Base läuft und bei 500 Ticks/sec auch eine gute Performance bringt.
Allerdings scheint es da ein Problem mit dem Port für den Atmega32 in Verbindung mit Interrupts zu geben, welches ich seid einiger Zeit erfolglos versuche zu jagen. Da ich z.Z. kein JTAG/ISP Debugger habe, ist es aufwändig und ein Fischen im Trüben.
Für die meisten dürfte freeRTOS auch zu komplex und klobig sein, als das es sich lohnt da so mehr Zeit zu investieren. Es gibt jedenfalls diverse einfache Scheduler, die vermutlich besser (weil kleiner) für den RP6 geeignet, und einfacher zu handhaben sind. Als Empfehlung sei z.b. mal Nano OS genannt. (wo ich auch schon weiter gekommen bin als mit freeRTOS) http://sourceforge.net/projects/nanoos/

Aus einem "Abfallprodukt" der Arbeit mit dem freeRTOS entsteht jedoch z.B. grade ein Eigenbau Gerätetreiber Konzept für den RP6 bzw. ATmega32, welches nicht an freeRTOS oder sonstige OS'e gebunden ist. Es dürfte auch für die RP6Lib Nutzer interssant sein.

Wenn also jemand am freeRTOS weiter machen möchte, nur zu... irgendwann werde ich mich auch wieder dran setzen.
LG Rolf