Projektvorstellung: autoCut - a robot lawn mower on steroids

[-schumi-]

Wird ja immer besser!
Ganz toll finde ich die Höhenverstellung.
[...]
Weiterhin viel Erfolg beim Bau!

Danke; und auch vielen Dank für den Skull

Du wirst wahrscheinlich auch automatisch die Höhe einstellen.
Mein Ansatz war bei hohem Gras (gleichmässig hohe Mählast) den Mähteller höher zu stellen.
Erst wenn länger wenig Kraft notwendig ist, wieder langsam nach unten gehen.
Damit kann man den Roboter auch z.B. nach längerer Pause in hohes Gras stellen und er kommt trotzdem zurecht.
Bis jetzt konnte ich leider mein Vorhaben nicht umsetzen.

Ja genau, vor allem mit dem Bumper und der Gefahr des Gras-Verhakens sollte das das Mähen deutlich vereinfachen.

Die Gleitflächen werden dir im Echtbetrieb Probleme bereiten, denn die Reibung wird immer größer (Schmutz und aufrauhen durch Sand)
Würde dir empfehlen auf Gummiaufhängungen umzustellen (ähnlich wie bei den Aussengehäuse Aufhängungen).
Im Test mit sauberen Flächen klappt es natürlich sehr gut, aber wenn das alles verklebt ist und die Wirkkraft eventuell auch noch schräg ist (z.B. Ast von oben) wird er nicht mehr richtig auslösen.

Ja, da habe ich auch schon überlegt. Dass der Bumper nach vorne zurückfedert wird vermutlich recht problemlos gehen, aber zu den Seiten hin macht mir die Konstruktion etwas sorgen.. Gummiaufhängungen sind eine sehr sehr gute Idee! Wenn ich nach Bildern für "gummiaufhängung" google, sind deine selbstgebauten Aufhängungen gleich das erste Ergebnis! ( http://www.robi2mow.at/technik/gehae...mmiaufhaengung ). Habe ich davon inspirieren lassen und mal schnell etwas zusammengeschustert:

Vom Gefühl in der Hand her auch nicht schlecht, allerdings lässt das natürlich auch eine Auslenkung längs der Feder zu. Da wäre so ein Gummi wohl doch besser. Hast du da ein passendes Schlagwort für den Kauf?

Noch ein Tipp gegen das Gewicht am Deck:
Würde die Schutz-Schrauben um das Deck durch Kohleröhrchen ersetzen. Die halten genau so viel aus und haben sicher nicht mal 1/10 Gewicht.
An den Ecken würde ich noch kleinere Gleitflächen machen, die etwas tiefer als die restlichen Röhrchen sind.
Dann sollte er nicht so schnell einhacken, falls das Deck durch Kippen oder Hügel zu tief wird.

Das mit den Carbon-Röhrchen und dein seitlichen Gleitflächen ist eine sehr gut Idee! Um bringt mich auf einen weiteren Gedanken: Ich will die Hobbyglasplatte sowieso durch etwas anderes ersetzen, weil die nicht stabil genug ist - und durchsehen kann man nach ein paar mal mähen auch nicht mehr. Aber eine Carbon-Platte 1mm x 200mm x 400mm ist mit 20€ auch noch erschwinglich ( http://www.ebay.de/itm/1mm-CFK-Carbo...item3f2c2e989d ). Kann jemand beurteilen, ob 1mm Dicke ausreichend ist? Habe gelesen, dass es ca. 4x so stabil wie Aluminium ist - also im Prinzip sollte es gehen, oder?

hübsche Lösung. Und schön, dass Du das so "mittendrin" vorstellst.

Danke!

Vermutlich muss man sich da irgendwie durch Github durchhangeln (ohne rechten Wegweiser :-/ ) - mir war das zuuu unübersichtlich.

Hier ist der Code: https://github.com/schuhumi/autocut/...0Module/main.c
Der betreffende Code ist ab Zeile 144 (das Unterprogramm "calculateBackMotors")

Aber ich verstehe sowieso nicht, wieso die Geschwindigkeit der Einzelräder ein Problem sein soll.

Man misst irgendwo im Antriebsstrang die Bewegungen einer Welle als Sektorzeit oder ganze Umdrehung. Sprich: ein Encoder auf der Welle mit mindestens einem schwarzen und einem weißen Sektor (bzw. Loch und Nicht-Loch) löst einen Interrupt am Controller aus. Anm.: zwei versetzt angebrachte Sensoren (oder zwei Spuren am Encoder mit versetzten Sektoren) sind sinnvoll, dann gibts gleich ne Drehrichtungserkennung dazu. Näheres hier.

Ein festen Timer mit ausreichend feiner Zeitauflösung kann dann den Zeitbedarf für eine solchen Sektordurchlauf liefern. Und die Größe Zeit pro (Teil-)Umdrehung ist dann der Kehrwert der Drehgeschwindigkeit.

Nach diesem Schema messe ich seit "Urzeit" die Geschwindigkeit meiner Motoren und Motörchen . . . und die Regelung läuft dadurch mit bester Genauigkeit (z.B. hier). Zwar "nur" mit zwei Rädern plus Gleiter, aber bei mir ist das auch ein Allrad- (weil Einzelrad-) Antrieb.

Also die Geschwindigkeitsregelung der einzelnen Motoren ist nicht das Problem. Ich benutze allerdings keine Encoder, weil die Motor-Getriebe-Einheit nicht geöffnet werden kann und ich desshalb keine Encoder anbauen kann. Dafür wird zum Messen der Geschwindigkeit die Spannung vom Motor weggenommen, 2ms gewartet und dann über den ADC die vom Motor (der jetzt als Generator läuft) erzeugte Spannung gemessen. Das ist zwar nicht ganz so genau, aber es funktioniert doch erstaunlich gut.

Das eigentliche Problem ist das: der Mikrocontroller der für das Fahrwerk zuständig ist bekommt via I²C die Geschwindigkeiten für die beiden Vorderräder vorgeschrieben, um alles andere muss er sich selbst kümmern. Das heist, dass er die Geschwindigkeit mit der sich die Hinterräder drehen müssen selbst errechnet. Und das ist deshalb schwierig, weil weil die Geschwindigkeiten aller Räder ganz unterschiedlich sind, sobald der Roboter nicht einfach nur geradeaus fährt. In die Rechnung müssen also die Geschwindikgeiten der Vorderräder, der Knickwinkel, die Breite der Achsen und der Radstand sowie die Position des Knickgelenks miteinbezogen werden. Im Code spiegelt sich das so wieder, dass ein Modell des Roboters aus lauter Vektoren gebaut wird. Die Geschwindigkeit der Vorderräder wird dann als kleine Verschiebung und Drehung der Vektoren abgebildet. Zum Schluss wird geschaut, wo sich die Hinterräder befinden würden und daraus wieder die Vorgabegeschwindigkeit für die Hinterräder hergeleitet.

Vorteil der ganzen Rechnerei (anstatt die hinteren Räder einfach frei drehen zu lassen) ist, dass der Roboter selbst wenn ein Rad den Grip oder gar Bodenkontakt verliert sich wie vorgegeben weiterbewegen kann.