Fortbewegungsstrategie gesucht

[Moppi]

Es geht um die Fortbewegung, wie es im Titel steht. Nicht die Zielsuche. Das ist ein anderes Thema. Und auch die Wegplanung betrachte ich noch nicht. Jetzt gerade habe ich das Chassis pausenlos im Kreis fahren lassen - "hakelig". Da ist jetzt eine recht große Pause zwischen zwei Bewegungsabschnitten. Muss mal schauen, wie ich den Programmablauf gestalte. Jetzt (ujm überhaupt irgendwo anzufangen) warte ich, bis eine Bewegung beendet ist, dann kommen paar Programmteile dazwischen (Pause) und dann fährt es weiter im Kreis. Ich muss jetzt anfangen so zu denken, dass ich die Dinge parallel ausführe (der ESP-12E hat hier zurzeit noch nichts zu tun, außer dass der Programmpakete in seine Umwelt verteilt). Jetzt ist das alles noch etwas unbeholfen, weil es noch ganz am Anfang steht. Da sind noch nicht mal US-Wandler dran oder Bumper ... nichts. Ich muss sehen, wie ich mit den Ausführungszeiten zurechtkomme. Muss immer eins nach dem andern.

MfG

[muell-er]

Es geht um die Fortbewegung, wie es im Titel steht. Nicht die Zielsuche. Das ist ein anderes Thema. Und auch die Wegplanung betrachte ich noch nicht ..

Der Titel ist allgemein gehalten. Aber dir es geht um nur deine Strategie. Es gibt viel andere Strategie und nicht jede ist immer richtig. Und ich versuch meist möglichst das ganze Umfeld zu betrachten - sonst klappts eben nicht.

[Moppi]

Wie und wann der Roboter was tun soll, ist (noch) nicht festgelegt, selbst, wenn ich Vorstellungen habe, wie es in etwa funktionieren könnte. Das sollte aus meinem ersten Beitrag hervorgegangen sein.

Und da es viele Möglichkeiten gibt, wollte ich gerne einen Einblick haben, was sich bei den Usern so etabliert hat, die sich hier damit auch beschäftigen.

Wenn ich denke, dass ich aus den Beiträgen für mich was ableiten kann (und ich lese die sehr sorgfältig, jeden Einzelnen) oder wenn mir bei Lesen weitere Sachen einfallen oder ich dann sogar erst einmal eine Lösung zu haben meine, die auf mein Projekt passt (weil die technisch umsetzbar ist), dann schreibe ich diese meine Vorstellung hier mit hin. Ja, das ist dann "meine Strategie".

Ob meine Strategie richtiger als eine andere ist, kann und soll gerne weiter diskutiert werden, genau so, wie jeder andere Beitrag dazu.

Gruß
Moppi

[Holomino]

Wenn ich DC-Motoren ansteuere, muss ich Werte in die PWM-Register schreiben. Das erzeugt in der Regel keinen Overhead. Das zyklische Regeln, also die Generierung der PWM-Werte sollte sicherlich zeitlich nicht den gesamten Zyklus beanspruchen. Wenn Du also alle 20ms einmal die PWM-Werte neu berechnest, dauert das in der Regel keine Millisekunde.

Wenn Du noch andere zeitkritische Operationen hast (der Interrupt eines US-Sensors riecht danach, aber auch die Bytes an der RxD-Leitung wollen bei 115kBaud alle 100µs abgeholt werden), würde ich Dir einen Controller mit mehreren Interruptprioritäten nahelegen. Das vereinfacht Vieles.

Letztlich nur eine Frage des Werkzeuges, was man parallel ohne Pausen in der Abarbeitung hinbekommt.

[Gerdchen]

Wenn ich DC-Motoren ansteuere, muss ich Werte in die PWM-Register schreiben. Das erzeugt in der Regel keinen Overhead. Das zyklische Regeln, also die Generierung der PWM-Werte sollte sicherlich zeitlich nicht den gesamten Zyklus beanspruchen. Wenn Du also alle 20ms einmal die PWM-Werte neu berechnest, dauert das in der Regel keine Millisekunde.

Bei den AVR-Controllern z.B. läuft eine PWM ja einmal angestoßen hardwaremäßig im Hintergrund, ohne das Hauptprogramm zu belasten. Neue PWM-Registerwerte brauche ich eigentlich nur bei Drehzahländerung.

[Holomino]

Ja, also laufend, weil die Drehzahlregelung ist ja eine Regelung. Sie regelt den Ist- zum Sollwert aus.

[Gerdchen]

Ja, also laufend, weil die Drehzahlregelung ist ja eine Regelung. Sie regelt den Ist- zum Sollwert aus.

Stimmt natürlich. Eventuell wäre eine Auslagerung dieser Regelung in einen separaten "Antriebscontroller" sinnvoll. Der kümmert sich dann nur um die Belange des Fahrwerks.