Fortbewegungsstrategie gesucht

[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.

[Moppi]

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

[muell-er]

.. Ich habe drei Ebenen .. AVRs .. Echtzeitsteuerung .. AVR .. Berechnungen .. AVR .. nur .. Schnittstellenhandling dient. Der stellt vor allem Digital- und Analog-Pins zur Verfügung .. oberste Ebene ist ein ESP-12E .. verteilt vor allem Programmcode an die darunter liegende Ebene ..

Drei "Ebenen" AVRs. Versteh ich.

Der AVR für Schnittstellenhandling stellt Digital- und Analog-Pins zur Verfügung? Wieso dann Schnittstellen? Das verstehe ich nicht, kann mir nicht vorstellen. wie gehts?

Und ESP verteilt Programmcode? An die AVRs? Wie geht das? Programmiert der at runtime die Controller neu?

[Moppi]

Hallo muell-er!

Ja, wieso Schnittstellen?

Schnittstellen gibt es überall, in Software, Hardware und auch in Hardware selbst.
Bei mir gibt es nur einen AVR, wo man praktisch noch was anschließen kann. Alles andere ist intern auf der Platine verdrahtet und (fast) nichts mehr nach außen geführt. Da sind theoretisch noch eine USART, serielle Schnittstelle und I2C, die I2C-Schnittstelle nutzt er selbst. Aber auch durch Software auf einem AVR lassen sich zusätzlich Schnittstellen installieren, die man so gängig als das sehen würde, wie SoftwareSerial (wo die ganz normalen I/O-Ports genutzt werden). Oder man nutzt die Pins anderweitig, direkt selbst als Schnittstelle und zusammen mit anderen Pins, womöglich einen ganzen Port, als weitere Schnittstelle. Da aber noch nichts festgelegt ist: Schnittstellenhandling, als allgemeinen Begriff, für Schnittstellen zu externen Geräten.

Programmiert der at runtime die Controller neu?

Der Programmcode ist festgelegt und gespeichert auf SD-Karte. Aber es ist durchaus denkbar, dass die Software auf dem ESP in der Lage ist, diesen Programmcode auch zu ändern. Die AVRs haben ihre Firmware drauf, die die Funktionen beinhaltet, die ein AVR ausführen soll. Also Funktionsumfang ist damit festgelegt. Damit tut der AVR aber jetzt nichts. Einzige Ausnahme hier vielleicht die IR-Diode, die ich fest in der Firmware drin habe, die aber auch nicht ausgewertet wird, solange dieses Feature nicht aktiviert ist. Damit die AVRs was tun, brauchen die Code für den Programmablauf. Den fordern sie beim ESP an. Der ESP ist auch in der Lage, selbst mitzuteilen, wer was tun soll. Er kann direkt dem AVR mitteilen, dass dieser jetzt als nächstes Programmcode Nr. 14365 ausführen soll. Darauf hin wird der AVR schauen, ob er den schon gespeichert hat, wenn nicht, muss er ihn anfordern und der ESP schickt ihm den (per I2C oder USART). Zu diesem Zweck habe ich einen Bytecode-Interpreter eingebaut. Und um der nächsten Frage zuvor zu kommen: auf dem ESP ist ein Webserver installiert, worüber man diese Codeblöcke erstellen und verwalten kann.

MfG

[Moppi]

Ich bin etwas weiter. Nachdem ich ein paar Korrekturen im Code vorgenommen habe, fährt das Chassis nun endlich zufriedenstellend per IR-Fernsteuerung. So konnte ich das jetzt mal ausprobieren, was ich benötigen würde, um in der Wohnung zumindest herum zu fahren und Hindernisse zu umfahren. Zurzeit habe ich 45°-Abschnitte zum Drehen. Das ist etwas zu wenig. Praktisch ist die Hälfte davon besser. Also 22.5°. Zum Fahren sind 30cm am Stück schon ganz gut. Aber auch hier manchmal etwas viel. Deswegen denke ich, 10cm-Abschnitte wären gut, vielleicht auch 15cm. Feinsteuerung ergäbe sich später per Abstandsmessung, auch genaueres Fahren, um z.B. eine Ladestation anzufahren.

MfG