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.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 ..
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
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.
Geändert von Holomino (12.12.2020 um 14:09 Uhr)
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.Zitat von Holomino
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.
Die Interruptgeschichte, was Holomino meint, spielt sich bei mir, wenn, dann (für das Fahrwerk) auf unterster Ebene ab. Ich habe drei Ebenen. Die AVRs für die Echtzeitsteuerung der Räder (Encoder auslesen, Motor steuern, auf Ereignisse mit Stillstand reagieren). Die zweite Ebende ist auch ein AVR, der soll Berechnungen anstellen, wie die einzelnen Räder zu steuern sind (also welche Daten die untergeordnete Ebene bekommt) und kann auch auf Ereignisse von außen reagieren; aber vor allem auf Ereignisse der Ebene drunter (also direkt von den Antriebseinheiten). Es gibt auf Ebene 2 noch einen AVR, der eigentlich nur dem Schnittstellenhandling dient. Der stellt vor allem Digital- und Analog-Pins zur Verfügung. Irgendwie muss ich ja noch was messen können. Da kommt es dann drauf an, was angeschlossen wird, danach richten sich dann die Funktionen in der Firmware und da kann ich z.B. auch noch Interrupts einbauen. Die oberste Ebene ist ein ESP-12E, als schnellste Recheneinheit. Der verteilt vor allem Programmcode an die darunter liegende Ebene und ist sonst noch nicht ausgelastet. Ich fürchte, dass ich vermutlich Funktionen der zweiten Ebene aus dem AVR am besten raus nehme und die auf den ESP-12E verlagere (zum Beispiel langwierigere Berechnungen); das muss ich dann mal sehen, wie das mit den Zeitfenstern überall so passt. Eigentlich soll die mittlere Ebene die Oberste entlasten. Der ESP muss vor allem Daten zusammensuchen, vielleicht Wege berechnen usw. Also so weit habe ich das durchdacht. Zurzeit übe ich noch mit der Fortbewegung, ich probiere noch aus, was auf Ebene 2 wie schnell geht und wie dort die Vorgänge optimal gestalten kann (also den Programmablauf zur Fortbewegung). Deshalb dieses Thema hier "Fortbewegungsstrategie gesucht".
MfG
Berechtigungen
Zitieren
Lesezeichen