Softwarekonzept für autonomen Roboter

[pemiso]

Hallo Forum,

nach vielen Prinziptests mit Motorsteuerungen und Sensoren bin ich dabei, einen Rasenmährobbi aufzubauen.

Für die Motoransteuerung mit DualMc33926 habe ich für Arduino Routinen entwickelt, die auf Richtungs- und Geschwindigkeitsänderung hin eine sanfte Korrektur ohne Beschleunigungs- und Stromspitzen bewirken. Momentan arbeite ich im Testbetrieb mit Delays. Das führt dazu, dass die Motoren natürlich dummerweise immer nur mit entsprechender Zeitverzögerung nacheinander angesteuert werden. 1. Ziel ist, aus dem loop beide Maschinen quasi zeitgleich zu steuern, wobei die jeweilige Richtungs- und Geschwindigkeitsanpassung "im Hintergrund" laufen soll. Das werde ich dann wohl per Interrupt machen müssen.

Aus diversen Beiträgen habe ich entnommen, dass vom Grundgedanken her folgendes anzustreben sei:

Interrupts liefern Zustände einzelner Sensoren. Diese werden in Zustandsvariablen für den loop-Zugriff verfügbar gemacht.
Beispiel: Sonar liefert Abstand vorn < 10 cm, hinten, rechts und links frei.

Im Loop werden abhängig vom Systemzustand Reaktionsroutinen aufgerufen. Diese müssten dann Schlussfolgerungen aus den Parameterkombinationen ziehen und als Reaktion andere Parameter ändern.
Beispiel: loop erkennt Kollosionsgefahr und setzt die Geschwindigkeitsvorgabe beider Radantriebe auf 0.

Interruptroutine der Motorsteuerung erkennt, Zielwerte weichen von aktuellen Werten ab und setzt die neuen Vorgeben an den Motoren um.

Sonarinterrupt liefert Abstand vorn < 7 cm, hinten, rechts und links frei.

Loop leitet Wendemanöver ein.

...

Zu den beschriebenen beispielhaften Anforderungen kommen weitere Peripherieauswertungen: LCD-Ausgabe, ArduinoManager remote control, Bedienpanelauswertung Folientastatur, Bumperkontakte, IR-Signale zur Navigation, Regensensor, Messung der Akkukapazität, Messung der Stromaufnahmen der Antriebe insbesondere des Mähwerks, Regensensor, Radencoder zur ODOmetrie-Navigation.

Was mir fehlt, ist das Wissen über das Zusammenspiel zwischen loop und Interruptroutinen zur Quasiparallelisierung. Konkret am Beispiel der Motorsteuerung: solange Istwerte mit den Zielwerten (Zustandsvariable) nicht übereinstimmen, muesste eine Interruptroutine für jeden Motor im z.B. 1 ms-Takt anspringen, um Übereinstimmung herzustellen. DAZWISCHEN aber wird weiterhin der loop ausgeführt.

Ihr seht, ich nähere mich dem Thema auf eine möglicherweise umständliche Art. Ich glaube jedoch, dass diese Prinzipüberlegungen Kernproblem eines jeden Robbi-Projektes seien müssten und somit ein allgemein beschriebenes beispielhaftes Konzept viele beflügeln würde.

Aber vielleicht habe ich einfach nur nicht gründlich genug bei der Suche gewesen und es gibt bereits solche Beiträge.

Ich freue mich über jeden Beitrag, der mein Unwissen schmälert

Danke und frohes Schaffen ...

[PICture]

Hallo!

Was mir fehlt, ist das Wissen über das Zusammenspiel zwischen loop und Interruptroutinen zur Quasiparallelisierung.

Es sollte Programmamlaufdiagramm (PAD) dabei helfen. Nur als Beispiel: http://www.rn-wissen.de/index.php/PI...ramm_.28PAD.29 .

[oberallgeier]

... fehlt ... das Wissen über das Zusammenspiel zwischen loop und Interruptroutinen ...

Mein Gefährt ist kein Rasen(der)mäher, das ist deutlich kleiner. Egal, die Regelungsproblematik ist vergleichbar. Natürlich gabs im Anfang eine Art Diagramm wie PICture meint, später wurde das aktualisiert. Sah während der Entwicklung ungefähr so aus (klick mal).

Dort siehst Du auch unter "Der Ablauf sieht in einem simplen Diagramm damit so aus:" wie ich alternierend die Regelungsroutine für je einen Motor aufrufe, pro Motor aber mit 100 Hz.

Geregelt wird bei mir IN der ISR - weil ich die Dauer der Routine kenne und im Raster so schnell bin, dass ich andere Routinen nicht störe. Deshalb rechne ich die Regelung auch ausschließlich interger. Direkt unter dem Codebeispiel siehst Du meine Geschwindigkeitsmessung - die aber eine inverse Geschwindigkeit ergibt, sprich: Zeit pro Weg. Und im dritten Codefenster des Links steht >meine< Regelungsroutine.

Die Regelungsparamter für den P I D-Regler habe ich durch Messung der Sprungantwort ausgelegt, siehe z.B. hier (klick wieder) und anderswo im Thread (gibts reichlich *ggg*). Dazu kam natürlich für den K-Wert die Messung der Geschwindigkeit in Abhängigkeit des Ansteuerwertes des Motors (=PWM-Wert). Das wurde wegen des späteren Rechenaufwandes natürlich linearisiert.

Du siehst - alles läuft hintereinander ab. ABER - die Motorzeitkonstanten bei meinen Gefährten liegen - im System - bei rund zehn Millisekunden, da ist bei der Regelung das 100-Hz-Raster ausreichend. Zumal die Geschwindigkeitsmessung mitunter NICHT viel schneller Ergebnisse herschaufelt.

Ein Fahr-Video zeigt den sauberen Geradauslauf - und auch die saubere Funktion bei anderen Manövern.

Im ganzen Thread sind immer wieder Auslegungsfragen behandelt, wie gesagt meine Lösung. Und es ist ein langer Thread

Viel Erfolg

[RoboHolIC]

Ihr seht, ich nähere mich dem Thema auf eine möglicherweise umständliche Art.

Ich denke: Nein, denn wenn man es nicht so macht, kommt allzu leicht ein BER heraus. (Hmm, vielleicht doch besser: BBI)

Ich glaube jedoch, dass diese Prinzipüberlegungen Kernproblem eines jeden Robbi-Projektes seien müssten und somit ein allgemein beschriebenes beispielhaftes Konzept viele beflügeln würde.

Bestimmt, aber es kann auch Spaß machen, selber drauf zu kommen; kostet halt Zeit, sich das zu erarbeiten. Dann hat man aber auch was gelernt.
Im übrigen gibt es mehrere Wege, ein Ziel zu erreichen. Bei meinem asuroiden Erstling habe ich alles, was einer zyklischen Bearbeitung bedarf, in die ISR gepackt. Abgearbeitet muss es so oder so werden. Was dort automatisch, also im Hintergrund, arbeitet, muss in der LOOP, also der Bewegungs- oder Ablaufsteuerung, den Reaktionen auf Umweltereignisse, nicht mehr explizit angestoßen werden. Das ähnelt ein wenig der Aufgabenteilung zwischen Stammhirn (Lebenserhaltung, Reflexe) und Großhirn (Planung, Strategie, Denkfehler *hüstel*). Man könnte die ISR in einem solchen Zuschnitt auch ganz treffend als Hardwaretreiber++ bezeichnen.
Das Gesagte bezieht sich allerdings auf einen Achtbitter mit nicht-priorisierbarem Interruptkonzept. Wenn ein Controller an dieser Stelle flexibler ist, hat das auch wieder gewisse Rückwirkung auf die mögliche Softwarestruktur.

[pemiso]

Hi PICture,
danke für die schnelle Antwort. Natürlich ist in Ablaufplan ein weiterer Schritt, sobald es in die Details und in Richtung Umsetzung geht (ein Bild sagt mehr als 1000 Worte). Das Drama ist: soweit bin ich noch nicht - ich habe noch die Verständnisprobleme beim "zeitlichen Verschränken" der verschiedenen Aktionen.

Softwareentwicklung eines grösseren Systems ist - wenn man wie in meiner Situation - nicht aus reichem Erfahrungsschatz im Bereich der zu lösenden Detailprobleme schöpfen kann, ein ständiges Pendeln zwischen "bottom up" und "top down" Sicht, um Prinziplösungen zu finden und zu verifizieren, sie ins Konzept einzupassen und wenn ok, weiterzugehen zum nächsten Detail ...

Z.B. Encoderauswertung: wenn ein Anstieg auf einem Digitalpin einen Impuls signalisiert, könnte der in einer Variablen hochgezählt werden und Interruptroutine ist beendet. Das passiert automatisch, wenn Signaländerungen / Impulse kommen. Im Loop muss dann zur Kopie des Zählerstandes Interrupt ausgeschaltet, die Kopie des Zählerstandes erzeugt und Interrupt reaktiviert werden. Das ist dann ein Prinzipbaustein.

Vielleicht hast Du doch Recht und ich dokumentiere erst einmal grob, meine Prototypanforderung. Damit kann ich mich bei Detailfragen verständlicher machen und schrittweise verfeinern.

Danke auch an oberallgeier. Diese Antwort hilft mir, wenn ich das alles so überfliege, beim Grundverständnis in die richtige Richtung - nämlich auf weitere Fragen Ich werde das alles mal genauer anschauen.

Irgendwo tauchte die Frage nach der optimalen PWM-Frequenz zur Motoransteuerung auf. Mit den Arduino Standardwerten bekomme ich beim Hochdrehen im unteren Bereich zunächst Pfeifen, bevor der Motor hochdreht. Mein Gefährt mit ca 18 kg Masse ist natürlich auf mit 2x 24V/1,5A 1:90 untersetzten Radantrieben kein Selbstläufer.

Danke erstmal und einen schönen Abend ...

[oberallgeier]

... die Frage nach der optimalen PWM-Frequenz zur Motoransteuerung ...

Die kommt (immer) recht massiv. Hier (klick) habe ich mal für kleine Motoren eine Frage gestellt, das wurde diskutiert, aber es gibt auch Hinweise für die größeren Oschis.

... Antwort hilft mir, wenn ich das alles so überfliege ... werde das alles mal genauer anschauen ...

Überfliegen ist gut, "alles genauer" ... bloß nicht. Kostet manchmal zu viel Zeit, lieber nach Anregungen vom Überfliegen nen eigenen Weg suchen, testen, Erfahrung auswerten ...

... ich dokumentiere erst einmal grob, meine Prototypanforderung ...

Genau - dann weiß man (manchmal) wo und warum man etwas ändert.

[pemiso]

Hallo RoboHolIC,

dann interpretiere ich als 1. Ansatz: das am häufigsten auftretende Ereignis z.B. Rad-Encoderimpuls wird genutzt, um einen Interrupt auszulösen. In der ISR erfolgt die Umrechnung in zurückgelegte Wege, neue x-/y-Pos, es wird geprüft, ob Richtungen und Geschwindigkeiten der Radantriebe nachgesteuert werden müssen (Vorgabewerte aus Systemzustandsvariablen) und es können dann durchaus auch andere Sensoren abgefragt werden?

Dann muss ich mir jetzt mal ein Testprogramm in der Richtung basteln ...

Danke ...

[oberallgeier]

.... Rad-Encoderimpuls wird genutzt, um einen Interrupt ... Umrechnung in zurückgelegte Wege ...

Langsam, langsam! Überleg mal, was Dein Interrupt bedeutet. Entweder zählst Du die Encoderimpulse in einem bestimmten Zeitraster oder Du misst die Zeit zwischen zwei Endoder-Interrupts.

So - was bedeutet ein Encoder-Interrupt? Dass seit dem letzten ein BESTIMMTER Weg zurückgelegt wurde ¹⁾. Also brauchst Du (hatte ich) da nicht extra Wege berechnen, wenn Du beim Regelungsansatz statt "Meter" das Längenmass "Abstand zwischen zwei Encoder-Interrupts" zu Grunde legst. Ist nur ne andere Einheit, aber keine andere Größe!

Und wenn Du diese Einheit nimmst, dann hast Du beim "Entweder" die - abgeleitete - Einheit Wege pro Zeit(raster) und beim "oder" die Dimension Zeit pro Weg (und das ist eine inverse Geschwindigkeit - die kann die Regelung bei entsprechendem Ansatz auch verarbeiten).

Etwas überlegen hilft manchmal aufwendige(re) Be-/Rechnungen zu vereinfachen.

¹⁾ Das gilt natürlich nur theoretisch - da gäbs noch nen eher unbekannten Schlupf und solche Unartigkeiten. Der Alptraum jedes Odometrie-Fuzzies.

[pemiso]

nach meinem Verständnis muss der Prozessor doch angestossen werden, um überhaupt einen Impuls zählen zu können, oder ein extra Zählerbaustein zählt sie und wird bei Abfrage im festen Zeitraster wieder genullt???

[oberallgeier]

nach meinem Verständnis muss der Prozessor doch angestossen werden, um ... zählen zu können ...

Ohhh - mein Prozessor läuft, wenn ich im Saft gebe, die Fuses ok sind usw. mehr Anstoß braucht der nicht. Aber Du meinst vermutlich, dass Du dem Prozessor irgendwie Dein Encodersignal "mitteilen" musst. Oder nicht?

Das Geheimnis heißt z.B. externer Interrupt, dann natürlich auch "Timer/Counter" (lies dazu mal das Datenblatt Deines Prozessors durch, da gibts mehrere Timer/Counter die verwendbar sind um a) Timer zu spielen - also ne Zeit zu messen oder einen Zeittakt zu bewirken oder b) um Counter zu spielen, d.h. z.B. Encoder-Signal-Flanken zu zählen . . . und da kann man sogar meist zwischen steigender, fallender oder irgendeiner Flanke auswählen.

... Für die Motoransteuerung ... habe ich ... Routinen entwickelt, die ... Korrektur ... bewirken ...

Das know how müsstest Du ja schon hier angewandt haben ! ? ! ?