Navigation: Richtung ändern

[Rabenauge]

Du brauchst auch drehen um X Grad nicht.
Das heisst: dein Roboter braucht das nicht.
Meter, Millimeter, Winkelgrade-das sind alles nur Erfindungen, die uns das Denken vereinfachen.
Ein Roboter braucht das nicht.

Stell dir einfach vor, du hast irgendwo in Sichtweite des Roboters eine Bake stehen, die er anfahren soll.
Dann kann er sich einfach so weit drehen, bis er Fahrtrichtung Bake hat...wieviel das in Grad ausgedrückt wäre, ist völlig unwichtig.
Du kannst eine Menge Rechenarbeit sparen, wenn du das mal beherzt umsetzt.
Zumal du das im Fall dieses Beispiels gleich zweimal unnötigerweise machen müsstest: zuerst den Winkel des Roboters zur Bake ermitteln, und dann auch noch um diesen Winkel drehen...wenn du mal gründlich drüber nachdenkst, wird dir auffallen, wie umständlich das eigentlich ist.

[Moppi]

Du brauchst auch drehen um X Grad nicht.

Ich stehe auf Deiner Seite!

Normal hätte ich auch nichts weiter eingebaut, außer das Drehen auf der Stelle und Geradeausfahrt. Das war erst so. Das habe ich rel. flott zusammen bekommen.

Gruß
Moppi

----------------------------------

Ergänzung zum weiteren Vorgehen in meinem Konzept:

Zum normalen Auto, dass einfach irgendwie durch die Gegend kurvt - vielleicht noch die Richtungswechsel etwas geglättet und die Abstände zur Linken und Rechten einhalten, habe ich einen eigenen AVR, der sich um so etwas kümmert. Um etwas unmissverständlich zu sein: wenn ich eine Grafikkarte in meinen Computer einbaue, ist fraglich, ob ich alle Funktionen dieser Karte nutzen werde. So denke ich hier jetzt auch. Ich habe die Funktionen ja nun schon eingebaut, weil ich dachte, sie könnten irgendwann mal nützlich sein. Für den Fall, dass sie gebraucht werden, sind sie in der Firmware jetzt drin. Sie belegen ein paar Byte Speicher, verbrauchen aber erst einmal keine Rechenzeit (wobei ich die bereits auf einfache Rechenoperationen optimiert habe, dass ich ohne MATH-Lib auskomme).