Arduino Roboter - Servo reagiert nicht korrekt

[i_make_it]

Der Post von I_make_it bezieht sich darauf, dass das Programm umgeschrieben werden müsste, wenn du das System um weitere Sensoren erweiterst wie z.B. Kontaktsensoren oder ähnliches.

Exakt das.
Wenn Der Roboter also für einige Zeit so bleiben soll, kann man das lassen.
Wenn man aber plant noch Bumper (Kollisionserkennung) und ggf. weitere Fernsensoren (US oder IR) oder Odometriesensoren hinzuzufügen, dann sollte man sich frühzeitig überlegen ob es nicht sinnvoll ist die Programmierung zu ändern bevor man irgendwann ein unterirdisches Timingverhalten hat und dann erst mal Wochen oder Monate damit verbringt alles noch mal neu zu machen.

Mein erstes Arduino Programm war eine Fußgängerampel mit Delays. mein zweites Programm zwei hc-sr04 und die drei Reflexlichtschranken fürs Linienfolgen.
Das wurde dann um die beiden gehackten Servos als Antriebe erweitert und um die Bumper.
Dann kam der Wunsch die hc-sr04 jeweils um 180° in 10° schritten zu drehen und so eine 360° Abdeckung zu bekommen.
Schon bei den beiden parallel betriebenen hc-sr04 und den drei Reflexlichtschranken, war mit Delay und Co kein Blumentopf mehr zu gewinnen.
Weil da keiner Linie mehr gefolgt werden konnte oder man dazu so langsam hätte fahren müssen, daß das gar keinen Sinn mehr macht.

Es ist also eine Anregung etwas vorzuplanen und sich Gedanken zu machen, wo man denn hin will.
Klar, erst mal will man überhaupt ein Ergebniss bekommen das irgendwie funktioniert, Aber wenn man es noch besser hinbekommen kann ist ja auch nicht grade schlecht.

Bei mir selbst geht es momentan halt darum wie viel kann man mit einem Nano denn erreichen.
Der nächste Umbau ist Hardware, um alle Eingänge per IRQ überwachen zu können.
Sprich alles mit UND versehen (Eigenlich ja umgekehrt da 2 Eingänge Gesetzt werden müssen ohne das es zu einem Übersprechen auf die Anderen Eingänge über den gemeinsam genutzten IRQ Eingang kommt) so das immer auch der IRQ ausgelöst wird und dann in der ISR den Status der Eingänge auswerten und entsprechende Merker Variablen für den normal Programmablauf Setzen.
Der zweite IRQ Eingang des Nano ist dann Frei für wirklich wichtige Sachen.

[wendtdir]

Danke für die Hilfe an alle.

Natürlich hast du Recht I_make_it, aber einen Schritt nach dem anderen .

Jetzt macht mein Roboter, was er soweit machen soll. Ein bisschen Feintuning fehlt noch. Doch er fährt und ändert die Richtungen.

Hier das Ergebnis:

Jetzt werde ich weiter basteln. Am Ende schwebt mir ein Roboter vor, der eine Kamera auf dem Rücken hat, die über W-Lan verbunden ist. Damit ich von ausserhalb der Wohnung zum Beispiel die Wohnung befahren kann. Eine andere Version soll Sensoren durch die Gegen fahren zum Messen des Luftdrucks, der Luftfeuchtigkeit, des CO2 Gehalts und der Temperatur.

[i_make_it]

Das ist doch schon ein schöner Anfang.
Allerdings sieht man auch bei 0:31 wie nah er war den Karton mit der Linken vorderen Ecke zu erwischen.
Wäre der Winkel noch flacher gewesen wäre er trotz US-Sensor kollidiert.
Deshalb habe ich die Bumper (und wegen Drehungen auch noch zwei Hinten an den Seiten)
Wie man in dem Link unten sieht, sind die recht simpel aufzubauen:
https://www.roboternetz.de/community...l=1#post622164
Etwas einseitig Cu kaschierte Platine, ein Stück Lochraster, zwei Printmontage Taster (aus Mäusen), etwas Schaltdraht und Litze.
Die Taster sind parallel, also verodert, geschaltet. Ist das selbe Prinzip wie bei der SPACE Taste, da sind auch zwei Tasten drunter, damit es egal ist ob man sie Links, rechts oder in der Mitte drückt.
Zwei Posts weiter unten sieht man die Anordnung der vorderen Bumper am Roboter.

PS: Ich Stelle auch fest, ich sollte mal den aktuellen Bauzustand in dem Tread nachpflegen.

[wendtdir]

Du hast Recht, ich bin da noch am justieren. Gestern habe ich ihn auf meinem Flur fahren lassen, da schlief er auch an der Wand lang und mir fielen deine Worte ein, dass ich da Bumper anbringen sollte. Zumal er nicht 100% gerade fährt (Odometrie zum Angleich der Geschwindigkeit?), müsste ich mit zwei Geschwindigkeiten spielen.

Gerade bin ich am überlegen, wie ich nun das Programm umschreibe, um wie du schon geschrieben hattest, mit Interrupts zu arbeiten und diversen Fallen. Geplant ist unteranderem ein Bluetooth Receiver für die Steuerung über Handy zuzufügen. Also, ich lasse ihn fahren und prüfen, ob ein BT-Signal eingeht, wenn BT-Signal, dann Steuerung über Handy, wenn Signal "off", wieder eigenständiger Betrieb. Das sehe ich als Vorarbeit für die Schnittstelle übers Internet.

Ich muss mal schauen, ob ich nicht sowas wie Bumber daheim habe, um wieder zurück zu deinem Beitrag zu kommen.

[i_make_it]

Odometrie ist der Erste Schritt für einen Gleichlauf der Antriebe.
Bei einseitigen Traktionsproblemen, kan nes aber trotzdem passieren das er Kurven fährt.
Ein Kettenfahrwerk wie das vom RP5 ist da nicht unbedingt von Vorteil, da das Wenden und Enge Kurven eher ein Rutschen ohne definierten Drehpunkt ist.
Aber die Gradeausfahrt verbessert es schon.

Wenn Du in meinem Tread, im ersten Post den letzten Code ansiehst, findest Du die erste Version meines hc-sr04 Codes (noch ohne Fehlerauswertung falls kein Hinderniss innerhalb der Maximalreichweite vorhanden ist).
Da verwende ich aber schon ISRs um im den Echopin zu verarbeiten. Die Hauptschleife kann also derweil andere Aufgaben ausführen. In dem Code halt die drei Eingänge des Linefollow Moduls auswerten.

Beim Umschreiben kannst Du im Code ja erst mal lauter Print() und Println() Befehle einfügen und so Marken und Zeitstempel ausgeben lassen.
Dann siehst Du was wann durchlaufen wird.
Das hilft dann beim Testen ob der Code auch das macht was man sich denkt was er machen soll.


Der nächste schritt wäre dann z.B den Servo ständig die Positionen -30°,0° und +30° anfahren zu lassen und während der Fahrt ohne Anhalten zu messen.
Bei einem Abstand von 20 cm kann dann während der Fahrt der Kurs in etwa 10° Schritten korrigiert werden. bei Erreichen von 10 cm Abstand dann wie bisher anhalten und z.B. in 5, 45° Schritten messen und abhängig vom Abstand ausweichen.

Damit lässt sich dann schon ein flexibleres Verhaltensmuster erzeugen.

Sind z.B. in einer Sackgasse alle 5 Messpositionen Mit Abständen unter 20oder 30cm belegt, kannst Du ihn um ca. 130° drehen lassen und erneut messen lassen. Selbst wenn dann nur eine Ausfahrt vorhanden ist, die knapp 1,5 Roboterbreiten breit ist, sollt er einen Ausgang finden.
Bei 130° würde er mit einer Auflösung von 10° in 12 Umdrehungen die ganze Umgebung mit dem Sensor in Position 0° erfassen.

Eine Andere Strategie ist bei Gradeausfahrt und freiem Weg bei Sensor Position 0° und Hinderniss bei 30° zwar weiterhin in 10° Schritten zu korrigieren, aber wenn Gradeaus ein Hinderniss ist und bei Sensor 45° keins, dann direkt um die 45° zu drehen.

Da fallen Dir aber bestimmt noch andere Strategien ein.

Mein Ziel war es die Bumper nur für dünne Stuhl und Tischbeine sowie zu flache Gegenstände zu benötigen.

[wendtdir]

Ich werde jetzt anfangen mit den Interrupts. Mittlerweile, denke ich, es ist klar, dass meine Programmierfertigkeiten eingeschränkt sind. Daher meine Frage, ich habe bis jetzt ja nur den US-Sensor angebaut. Ich würde also jetzt programmieren, dass mein Roboter im Loop erstmal gerade aus fährt. Eine Unterbrechung findet statt, wenn der US-Sensor etwas "sieht", also AttachInterrupt (Interruptpin 0, Funktion "Ich sehe was, was du nicht siehst", change). In der Funktion "Ich sehe was, was du nicht siehst" müsste dann die Drehung kommen. Demnach müsste der Sensor durchgehend die Entfernung messen im Loop bzw. in einer Extra-Funktion?

[i_make_it]

Bau das Programm nach dem Prinzip auf was willst du vermeiden.
Also eine Kollision z.B. (deshalb hast Du ja den US-Sensor)

Bei der Initialisierung sollten also der US-Sensor soweit vorbereitet werden (Variablen vorbelegen, etc.)
das er messen kann und seine Ausgabe an die Fahrroutine so als ob bereits ein Hinderniss da ist.
Damit steht der Roboter erst mal und der Sensor geht in die Routine in der sich erst mal einen Überblick verschafft.

Das Einschalten kann nämlich nicht nur eintreten wenn Du den Roboter auf eine garantiert freie Fläche setzt sondern auch nach einem Reset
(z.B. durch Brown out) wenn er grade vor einem Hinderniss war und eigentlich drehen wollte.
Ich habe die Sensoren in der Hauptschleife, und habe nur den Echopin in der ISR.
Wenn also der Echo Pin triggert springt die Verarbeitung in die ISR und setzt den Zeitstempel für das Ende der Messung.

Update:

Wenn dann Bumper dazukommen, kann man die entweder zum Pin Sparen über ein Widerstandsnetzwerk auf einen Analogeingang führen, oder Digital abfragen.
Wenn Das Programm längere Zykluszeiten hat, ist so ein Polling natürlich nichts mehr, spätestens dann müssen Bumper über IRQ laufen.
Man kann aber selbst bei Bumpern mit Widerstandsnetzwerk Interrupteingänge nehmen, wenn man einen Amplituden-Diskriminator aufbaut,
der beim niedrigsten Spannungswert den ein Bumper verursacht bereits auf High geht.
Wenn man zu wenige IRQ-Eingänge hat, kann man z.B. einen 74HC541 (nicht invertierender Leitungstreiber) nehmen um 8 Leitungen auf einen IRQ zusammenzuführen.
Somit wird jeweils der entsprechende Eingang angesprochen plus der IRQ-Eingang.
Die ISR würde dann prüfen welcher der Eingänge betroffen ist und entsprechende Handlungen ausführen.
Z.B. bei US-Sensor Echo die Zeit speichern und bei Bumper sofort Motoren Stop und ggf. welcher Bumper ausgelöst hat.
Momentan hast Du ja erstmal einen US-Sensor und siehst den Bedarf für Bumper.
Wenn es darum geht, das der Roboter mal an einen Treppenabsatz kommt und nicht abstürzen soll, kommen auch noch Sensoren die überwachen ob Boden vorhanden ist oder ein Abgrund.

Parallel zum umschreiben des Codes kannst Du ja bereits darüber nachdenken was Du in den nächsten Erweiterungen dazunehmen willst.
Mir ist es z.B. bisher nicht gelungen mehr wie 4 Bumper in einem Widerstandsnetzwerk zusammenzufassen ohne dabei die Fähigkeit zu verlieren parallele Mehrfachbetätigungen sicher unterscheiden zu können.
Wenn Es laso auf mehr wie 4 Bumper rausläuft, macht es Sinn diese aufzuteilen.
damit entsteht aber ggf. schon der Bedarf IRQ Quellen zusammenzuführen.


Im Hauptprogramm prüft man zuerst ob die Variable für Hinderniss vorraus gesetzt ist wenn ja verzweigt man in den Teil für das Drehen des Servos um sich einen Überblick verschaffen.
Wenn kein Hinderniss vorraus ist, prüft man ob bereits eine Messung läuft (Merkervariable). Wenn nicht startet man eine Messung und setzt den Zeitstempel für den Start der Messung.
Dann setzt man den Zeitstempel für das Erreichen der maximalen Messdauer.
Dann wird geprüft ob die Variable für ein vorhandenes Echo gesetzt ist und wenn ja die Entfernungsberechnung durchgeführt und Variablen zurückgesetzt (Merker ob ein Echo vorhanden ist).
Wenn kein Echo vorhanden ist kommt der Vergleich ob der Zeitstempel für die maximale Messdauer minus dem Zeitstempel für den Start der Messung größer oder gleich 0,2 Sekunden ist.

Jetzt kommt die Fahrroutine. Ist die Variable für kein Hinderniss vorraus gesetzt, wird gradeaus gefahren.
oder halt entsprechend links bzw. rechts gedreht.