Neues vom RP6RTOS
Hab mal meine Entwicklungsumgebung angehängt, wer mit dem Atmel Studio 6 arbeitet, müsste die Projektfiles aufkriegen und compilieren können. Das Make tuts nicht.
Ebenfalls dabei ist ein Hexfile mit dem ich grade Motorfunktionen teste. Das Ding soll aktuell einen Halbkreis rechts rum mit R=300mm fahren. "movecirc" heist die "neue" Rotate funktion in der RP6Lib. (die Motorbefehle für den RP6 fand ich schon immer grausam.. versucht mal ohne ruckeln eine 8 abzufahren... oberer Radius 300mm, unterer 400mm..)
Warum poste ich das? Nun ich hab ja schon mal versucht die Umgebung zu posten und habs nu mal bissel abgespeckt.. docus raus usw. Jetzt passts.
Warum ist das für euch interssant? Hmmm... weil ich immer noch hoffe, Leute zu finden die Interesse daran haben und mit entwickeln - aber auch um zu zeigen das der RP6 sowas kann.
Wer sich die Unterschiede der bisherigen RP6 Lib und der in dem Zip anschaut, sieht das sich viel im Bereich Motoren, Timer und IRQ getan hat. Es gibt allerdings noch einige Schwierigkeiten so das der Code nicht einfach 1:1 anderweitig verwendbar ist. Starke Änderungen gibt es z.B. bei den Motorbefehlen, es wird letztlich nur noch 2-3 Befehle geben die aber zusammen mehr können als alles was bisher da war.
Es magelt allerdings an Bewegungspräzision - was ich hoffe bald noch deutlich verbessern zu können. Zur Zeit komme ich auch nur auf 50mm/sek Speed, angeblich sollen es bis 250mm/s sein. Das Ganze ist also als große unfertige Baustelle zu verstehen. Leider wird die RTOS Fassung der RP6Lib auch eher nicht quellkompatibel zur alten Version - schon allein weil sich durch Optimierungen neue Möglichkeiten ergeben. Siehe move und movecirc. Dort konnte ich min. 10-20 Variablen und jede Menge code einsparen.
Die Statistik sagt zur Zeit:
Program Memory Usage : 12974 bytes 39,6 % Full
Data Memory Usage : 1815 bytes 88,6 % Full wobei 1,5KB für den RTOS Heap drauf gehen... da wird sich auch noch was tuen.
Darin verbaut ist nun FreeRTOS, RP6Lib_neu mit RP6uart und das kleine main Programm (mit 2 Tasks, prv_task_RP6System wandert später so oder ähnlich in die RP6Lib, task_main ist mit der Funktion main gleich zu setzen, in meiner main wird nur das OS initialisiert).
Also falls Ihr Interesse habt... die Files habt ihr nun.
Schön wäre z.B. wenn jemand das Make File zum laufen bringen kann oder vielleicht jemand das Timersetup durchgeht.. ich vermute das da noch ein (Denk)Fehler sitzt.
Genaue Infos dazu geb ich dann noch.
LG Rolf
Nachtrag I: In movecirc muss uint16_t radius auf int16_t radius geändert werden damit er auch rückwärts Kurven fahren kann. Die Berechnung negativer desired_speed-Werte scheitert sonst an dem unsigned int. Radien werden da wie Distanzen aber grundsätzlich positiv angegeben. Nur Speeds und der Winkel auf dem Radius als ->Bogenmaß, als Ersatzangabe für L/R sind signed.
Nachtrag II: Also die Geschichte mit dem PID Regler ist zwar technisch interssant (Koppelung bzw. Nichtlienarität von ist/soll der Encoder-Counter gegen PWM Pulsweite) aber nicht zielführend und vor allem zu kompliziert. In der nächsten Version wird der aufwändige PID Regler wieder entfernt und ich probiere einen direkten, an die Encoder bzw. Zählimpulse gebundenen Soll-Folger per 1KHz TimerISR. Das ergibt wieder eine Art Rampensteuerung, evtl. aber mit optionaler GegenEMK so das eine Beschleunigung elektrisch gesehen von 0 bis 100% bzw. 0 in materialschonenden 400ms erfolgen kann. Da die PWM dann nur in 1/400stel Schritten per ms geändert wird, sollten die Lastkurven recht gleichmäßig sein und es nicht zu "rütteln" im Zahnsatz kommen. Dies erlaubt dann hoffentlich eine Genauigkeit bis auf 1 bis max. 2 Encodersignale oder 0,25 bis 0,5 Millimeter. Man kennt solche Steuerungen von Hobbyfräsen o.ä. Das sollte den benötigten Code zur Motorsteuerung dann noch mal radikal reduzieren (bis jetzt nur 2 Zeilen in der ISR pro Kette). Ggf. wäre dann sogar eine Berücksichtigung der elektrischen Motorenlast machbar um die leider nicht ganz äquivalente Zahnradbelastung in garantierten Grenzbereichen zu halten - was natürlich wieder etwas Code kostet. Die Notwendigkeit eines Tasks "Motion" entfällt damit. Dann ist alles an "Ungenauigkeiten" nur noch dem Kettenschlupf bzw. Untergrund zu zu schreiben - was ich gern noch mit einem "Schlupfparameter" ähnlich wie bei der Encoderresolution kompensieren möchte, welche man sogar optional verändern könnte wenn z.b. ein Kompass oder ein Maussensor als genaue Messreferenz vorliegt.
Zitieren
Lesezeichen