Fortbewegungsstrategie gesucht

[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

[Moppi]

Hallo!

Ich habe mehrere Themen zu dem, was ich noch hinzufügen möchte. Aber ich tu das jetzt mal alles hier drunter schreiben, weil es mit der Fortbewegung zu tun hat. Vielleicht interessiert es den ein oder anderen.

Aus gegebenem Anlass habe ich mir einen Saugroboter zugelegt. Extra mit Fernbedienung. Daraus konnte ich jetzt auch erkennen, wie dort die Fortbewegung stattfindet. Da mein Projekt mit der IR-Bedienung auch schon funktioniert, habe ich jetzt mit gekauften Roboter keine Probleme, den in Betrieb zu nehmen. Man kann den ebenfalls mit IR-Bedienung "herumschubsen".

1. Mir ist aufgefallen, dass die Radien, in denen er sich per Fernbedienung drehen lässt, für meine oder unsere Ansprüche hier im Forum, bei weitem nicht so genau zu sein scheinen. Entweder ist der Drehradius so gewählt, dass sich damit keine ganze Umdrehung ausführen lässt, so dass man ihn in die Ausgangsstellung bekommt. Oder Die Drehungen sind schlicht einfach zu ungenau.

2. Ein zweiter Punkt ist, trotz breiterer Räder, dass der auf meinem 1.5cm hohen Teppich (anderer Thread) ebenfalls nicht geradeaus fährt. Der Roboter zeigt hier ein vergleichbares Fahrverhalten. Den Teppich überfährt er regelmäßig nicht gerade, mal schlingert er (das sieht man dann an der Fahrspur, die er auf dem Teppich hinterlässt) oder er fährt eine Kurve, mal weniger, mal stärker ausgeprägt.

3. Die Bewegung per IR-Bedienung erfolgt so, wie ich es bei meinem Projekt auch schon gemacht habe: in jede Richtung in Schritten. Vorwärts fährt er etwa 20cm, dann hält er an. Die Teildrehungen fallen sehr grob aus, da hätte die Hälfte auch gut getan, um ihn besser manövrieren zu können.

4. Sensoren, auch Bumper, sind nur in Fahrtrichtung. Nach hinten scheint er blind zu sein und fährt dann einfach auf Verdacht, wobei er zur Not auch Stühle verschiebt oder andere Gegenstände. Kein Ultraschall, habe keinen gesehen. Das Gehäuse ist geschlossen, da gibt es offenbar nur IR-Sensoren seitlich und vorne. Und die sind auch nicht besonders ausgefeilt, mindestens 50% der Kollisionen werden mechanisch erkannt. Fährt er an einer Kante lang, geht das nur so.

5. Die Strategie, um außen an der Fußleiste eines Raumes entlang zu fahren, besteht darin, immer im Kreisbogen nach außen zu fahren, bis es zur Kollision kommt. Danach dreht das Gerät etwas nach außen (in den Raum hinein), um im Kreisbogen wieder auf die Wand zu zu fahren. So geht das in kurzen Abständen immer und immer wieder.

6. Meistens fährt er, nachdem er angestoßen ist, rechts herum. Dreht vom Hindernis etwas weg, und fährt dann eine Kurve, wobei der Drehpunkt das rechte Rad ist.

7. Beide Räder sind gefedert, der Antrieb mittels Zahnradgetriebe. Es gibt keine stufenlose Geschwindigkeitsregelung. Es werden 3 oder 4 Geschwindigkeiten genutzt, bei Beschleunigungen kann man das deutlich erkennen und hören.

8. Die Ladestation findet er nur, wenn er schon davor steht. Die wird mit zwei Kontakten realisiert, die Gegenkontakte zum Laden sind unter dem Roboter angebracht und liegen frei. Das Laden erfolgt per Netzteil über zwei Drähte. Um in die Ladestation einzufahren muss er irgendein Signal erkennen. Er dreht dann sehr langsam und fährt schräg zur Ladestation bis zu einem bestimmten Punkt, dreht dann bei und fährt gerade auf die Station zu, in der Hoffnung, sie zu treffen. Manchmal klappt das auch nicht so gut.

So weit soll das hierzu erst mal genügen.

MfG

[inka]

hallo Moppi,
um die erfahrungen mit meinem Saugroboter vergleichen zu können, könntest Du bitte einen link spendieren? Einiges, wie das auffinden der ladestation ist z.b. völlig problemlos?

[Moppi]

Das Auffinden der Ladestation macht der, indem er immer außen am Raum lang fährt. Sind die Türen offen, kommt er irgendwann in den Raum, wo die Ladestation an der Wand steht. Ca. 1m davor erkennt er sie irgendwie. Da ist eine Helle, weiße LED oben dran verbaut, vielleicht da drüber. Dazu steht natürlich nichts in der Gebrauchsanweisung. Wenn er in einem weit entfernten Raum steht, hangelt er sich so mühsam über die Außenwände zur Ladestation. Das kann schon dauern.

Ich kann Dir einen Link zum Produkt geben.

Saugen tut er einwandfrei, gibt es nichts dran auszusetzen.

MfG