Projekt: FreeRTos auf RP6

[RolfD]

Wieder mal eine Woche rum... was hat sich getan?
Eine ganze Menge... Mein Versuch die Geschwindigkeit des RP6 an Hand von Flankenwechselzeiten in den Encodern zu messen (wie im Nachtrag II im letzten Post noch gehofft) schlug leider grandios fehl. Das lag wohl hauptsächlich daran, das durch diverse CLI/SEI Befehle letztlich die Timer nicht mehr für so genaue Zeitmessungen taugen - aber auch weil der Messzyklus selbst widerum alles andere blockiert. Was ich jedoch nicht probiert habe, ist die Zykluszeit durch reines Zählen einer Var und anschließender Berechnung der CPU Zeit zu ermitteln. Letztlich ist ein Antrieb wie im RP6 durch seine Trägheit und Getriebespiel aber auch nicht dafür gemacht, genauer als vielleicht mit 10 oder 20 Encodersignale zu arbeiten. Man stelle sich nur vor, man wolle den RP6 anfahren und exakt 2mm bewegen... also 8 Encodersignale weit.
Genau so Mumpitz ist aber auch dann eine Definition von:

//#define ENCODER_RESOLUTION 0.23
//#define ENCODER_RESOLUTION 0.235
#define ENCODER_RESOLUTION 0.24
//#define ENCODER_RESOLUTION 0.25

denn bei 4000 Encodersignalen auf 1 Meter liegt der mögliche Fehler (0.25-0.23) hier bei 0.02 pro Schritt oder 20 mm auf 1 Meter. Der Kettenschlupf auf glatten Böden ist garantiert größer und bei Radien ist es eh vorbei. Es ist daher vergebene Liebesmühe, an dieser Baustelle weiter Zeit zu investieren. Der Gewinn an Genauigkeit steht nich mal in Relation zum Mehraufwand der daraus folgenden Berechnung. Zum Nachrechnen: 0.02 * 4000 / 4 = 20, also Fehlerrate * Pulseprometer = 80 Pulse .. oder 20 mm... pro Meter!!!
Dabei ist der RP6 sogar nicht mal sooo schlecht mit seiner Opto-Mechanik, alte Mäuse hatten üblicherweise eine Auflösung von ca. 10 Pulse pro mm, statt 4 wie beim RP6. Nur warum hat man im RP6 nicht auch sowas verwendet...? Ok bringen würde es kaum was denn die Stellgenauigkeit an den Motoren würde damit wenig besser. Die Möglichkeit Geschwindigkeiten im Bereich unter 15mm/sec zu fahren würde sich schon verbessern.

Also verrichtet nun wieder der PID Regler seinen Dienst - inzwischen auch zuverlässig und ohne wirre Berechnungen zwischendurch. Die Messzeiten für die Speed und damit auch die Regleraufrufe wurden von 200 ms (5/sec) auf 125ms (8/sec) herrabgesetzt, dies hat die Genauigkeit dann doch auch etwas erhöht. Es gibt nur noch zwei Move und 1 Stop Befehl, die alles erledigen. Sie gehen Threadsave mit der Motorhardware um so das sich 2 Tasks ggf. nicht gegenseitig in ein Movement pfuschen und es gibt noch viele weitere Änderungen. Die Dinge im einzelnen zu beschreiben macht hier wenig Sinn, ich werde bei Gelegenheit mal ein Wiki Beitrag dazu schreiben. Aktuell sieht der Resourcenverbrauch so aus:
Program Memory Usage : 12556 bytes 38,3 % Full
Data Memory Usage : 1785 bytes 87,2 % Full
Besser als bisher gedacht und befürchtet sag ich da...

Was ich mich aber schon die ganze Zeit frage... denn es geht mir ja nicht nur drum, die Lib RTOS fähig zu machen sondern auch zu verbessern...
Überall steht, man muss vor dem Einsatz der Motoren powerON(); aufrufen... es gibt sogar Forenbeiträge, wo es sich als Fehler ergab, das Leute das vergaßen... warum ist aber noch keiner auf die Idee gekommen, powerON(); in den Move Befehl der Lib rein zu setzen und nach Beendigung des Moves mit powerOFF(); wieder abzuschalten?
Mal davon abgesehen das es Strom spart, verhindert es zudem Fehlfunktionen und lange Gesichter...

Naja ich hoffe gegen Ende kommende Woche mal wieder ein Snapshot mit einer Demo der Fahrsteuerung posten zu können. Eine ruckelfreie 8 zu fahren klappt jedenfalls schon wunderbar und der Bot fährt nun auch stabil von 5-10 mm/sec (20-40 Pulse/sec) bis 250mm/sec (1000 Pulse/sec)
Wer das hier aufmerksam gelesen hat http://www.rn-wissen.de/index.php/RP6#Encoder , weiss das das garnicht geht...

Etwa 50 Segmente pro Sekunde ist auch die geringste gerade noch regelbare Geschwindigkeit (das variiert aber etwas von Roboter zu Roboter).

2 Pulse pro 1/8 sec bzw. 16/sec reichen dem PID schon. Das sag ich mal mit Galileo Galilei...
Und sie dreht sich doch!
Zumindest bei meinen beiden RP6er.
LG Rolf