Umsetzung mit Raspberry PI

nero76

Moderator
Alexander schrieb:
Hi,

klare Sache - immer wieder. Macht einfach viel mehr Spaß. Ich bin zwar nicht ganz auf der Ardumower Schiene, habe aber doch die eine oder andere Anregung / Komponente übernommen. Software habe ich komplett selbst geschrieben, als Basis ein Arduino für das Low Level Zeug (Motortreiber, Perimiter etc) und die Steuerung selbst in einem Raspberry. Warum - kann ich nicht sagen, hat einfach Spaß gemacht.

Momentan baue ich den Mower neu auf (wurde von der Regierung Forrest getauft - lauf kleiner Forrest ;-)) - primär mechanisch neu - mit der Software war ich soweit ganz zufrieden, hab knapp 1400qm Rasen zu mähen, rund ums Haus verteilt, daher habe ich GPS Regionen implementiert die virtuelle Grenzen darstellen um das Grundstück auch Sektorweise mähen zu können.

Alex

Hi Alexander,

stell doch mal Deine Software hier hinein, damit nicht nur Du von dem Projekt etwas profitiert hast, sondern auch das Projekt von Dir ;-) (wie sooft im Leben: man lernt nur durch Nachmachen). Finde Die Idee mit dem Rasperry interessant und würde mir gerne weitere Details ansehen.

Gruss,
Alexander
 
Zuletzt bearbeitet von einem Moderator:
Alexander schrieb:
Hi,

klare Sache - immer wieder. Macht einfach viel mehr Spaß. Ich bin zwar nicht ganz auf der Ardumower Schiene, habe aber doch die eine oder andere Anregung / Komponente übernommen. Software habe ich komplett selbst geschrieben, als Basis ein Arduino für das Low Level Zeug (Motortreiber, Perimiter etc) und die Steuerung selbst in einem Raspberry. Warum - kann ich nicht sagen, hat einfach Spaß gemacht.

Momentan baue ich den Mower neu auf (wurde von der Regierung Forrest getauft - lauf kleiner Forrest ;-)) - primär mechanisch neu - mit der Software war ich soweit ganz zufrieden, hab knapp 1400qm Rasen zu mähen, rund ums Haus verteilt, daher habe ich GPS Regionen implementiert die virtuelle Grenzen darstellen um das Grundstück auch Sektorweise mähen zu können.

Alex

Hi Alexander,

stell doch mal Deine Software hier hinein, damit nicht nur Du von dem Projekt etwas profitiert hast, sondern auch das Projekt von Dir ;-) (wie sooft im Leben: man lernt nur durch Nachmachen). Finde Die Idee mit dem Rasperry interessant und würde mir gerne weitere Details ansehen.

Gruss,
Alexander
 
Zuletzt bearbeitet von einem Moderator:
Hi Namenskollege,

ich denke, wenn der Neuaufbau durch ist und ich die Software ein bisschen aufgeräumt habe, kann ich es gerne veröffentlichen.

Vorab - prinzipiell läuft die Geschichte folgendermaßen: Der Arduino sendet seriell (über USB) seine Daten an den Raspberry. Gps ebenso, Kompass hängt am I2c. Dann läuft jeweils für jedes dieser Geräte ein einfaches Python Script, dass die Daten in eine Queue (in dem Fall Rabbit MQ) schreibt.

Das Hauptprogramm hab ich in C# geschrieben, läuft mit Mono am Raspberry. Dank der Rabbit MQ kannst das Programm auch am PC laufen lassen (geht natürlich mit jeder anderen Programmiersprache auch) - und über Wlan den Mower steuern. Ist grad beim Entwicklen sehr nett weil man nicht immer erst die Software drauf laden muss. Kannst dich also mit dem Notebook in den Garten setzen (oder in meinem Fall aus der Bürofenster gucken) und Softwareänderungen relativ gut und schnell testen.

Dazu kannst auch ein Monitorprogramm am PC Laufen lassen - da du ja "beliebig" viele Clients auf die Queues hängen kannst.

Gruß

Alexander
 
Das hört sich interessant an - D.h. Du hast Dir beispielsweise auch Kommandos zum Ansteuern der Motoren und für die Konfiguration der Hardware gebaut (s.u.)? Es gibt ja auch zeitkritische/regelungstechnische Dinge ("travel line distance", "rotate angle"), die der Roboter dann aufgrund von Latenzen autark abarbeiten muss.

Ich benutze derzeit Bluetooth für die Messages (GUI läuft mit Processing/Java am PC).

sunray2.png


* robot messages
* 101 : sensor data
* 103 : map bitmap data
* 105 : perimeter outline data
* 111 : tracking forever
* 112 : start mapping
* 113 : mowing lanes
* 114 : mowing random
* 115 : particles data
* 116 : distribute particles on perimeter
* 117 : robot motion data (distance, orientation)
* 170 : configure bluetooth
* 175 : erase microcontroller flash memory
* 176 : eeprom data

* perimeter messages
* 284 : perimeter settings

* motor messages
* 300 : stop immediately
* 302 : set motor pwm (left, right)
* 306 : travel line distance (speed, distance, orientation)
* 307 : travel line time (speed, time, orientation)
* 308 : rotate angle (speed)
* 309 : rotate time (speed)
* 374 : set mow motor pwm
* 383 : motor settings

* ADC messages
* 471 : calibrate ADC

* IMU messages
* 504 : IMU data (verbose)
* 510 : calibrate gyro
* 572 : calibrate compass
* 573 : toggle verbose
* 578 : compass calibration data (centre X,Y,Z,radii X,Y,Z)
* 579 : IMU self test
* 580 : start compass calibration
* 581 : stop compass calibration
* 582 : IMU settings

* ranging messages
* 677 : ranging data (time, address, distance, power)
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/sunray2.png/
 
Zuletzt bearbeitet von einem Moderator:
Wollte auch grad schreiben, der Topic entgleitet hier gerade ;-)

Was die Hardware betrifft - das ist alles selbst zusammengeschustert - genauso die Firmware im Arduino (sogar die Motortreiber sind diskrete H-Brücken - waren noch von einem alten Modellbauprojekt über).

In der Firmware habe ich dann konkrete Befehle implementiert - und mache Dinge eben dorthin ausgelagert - so gebe ich z.B. einen Fahrbefehl (wahlweise auch mit Distanzangabe - die drehzahlsensoren der Motoren überwacht der Arduino) und sollten Hindernisse getroffen werden schaltet der Arduino die Motoren aus - gibt gleichzeitig Rückmeldung an die Queue - da hat man dann wieder genügend Zeit zu reagieren.
Ein Problem bei der aktuellen Implementierung ist z.B. nach Kompass zu fahren. Dass liegt aber mehr an der etwas "schrägen" Implementierung der Steuerkommandos an den Arduino. Das werde ich in V2 nochmal deutlich überarbeiten. Was die zeitkritischen Dinge betrifft - da bin ich doch der Meinung dass es eigentlich gar nicht so zeitkritisch ist - so schnell fahren die Dinger ja dann auch nicht. Wenn ich jetzt mich jetzt nicht ganz falsch erinnere hab ich 50-100 Messages die ich pro Sekunde und Sensor verarbeite - in meinen Augen mehr als ausreichend für so gut wie alle Prozesse. Und was damit nicht zu schaffen ist, kann man immer noch in den Arduino auslagern.

Was ich momentan überlege - ob ich das Original Ardumower Board als neue Basis nehme und dann "nur" die Firmware etwas anpasse. Dann wärs für das "Ardumower" Projekt etwas brauchbarer.
 
Hallo Ihr "Zwei" :)

ich hatte auch schon überlegung das ganze mit dem Raspi zu machen (schnellere Prozessoren und deutlich mehr RAM).
Den Einsatz beides zu verbinden finde ich genial!

Wenn du das ganze wirklich auf dem Original Ardumower Board aufbaust,
dann wird es denke ich aufgeräumter und einfacher werden das nachzubauen und auszubauen und mit deutlich mehr Ideen zum Leben zu bringen da die Gemeinschaft auch nicht zu verachten ist :) .

Gruß Nick B)
 
Wenn Echtzeit-Regelungen wie "Fahre Bahn nach Kompass/Gyro" autark ablaufen, kann man die Latenz-Zeiten, also Verzögerungen (beim Entwickeln aus der Ferne) durch WLAN etc. natürlich vernachlässigen.

Ich habe dieses Kommando übrings für die zukünftige Ardumower Sunray Firmware so umgesetzt - allerdings ist es richtig tricky einen Kompass auf ca. 2 Grad relative Genauigkeit zu bekommen (die braucht man wenn er seine Bahnen versetzt und parallel mähen soll). Dazu habe ich eine Kompass-Kalibriersoftware (Elliposid-Fitting) entwickelt (ebenfalls Java mit Processing) und werde das alles noch genauer beschreiben. Eingesetzt wird derzeit ein GY-88 Modul (MPU6050 und HMC5883L).

Desweiteren regelt das Kommando aber auch selbständig die Bahn ein (über Odometrie) - sollte der Roboter die Bahn also einmal geringfügig verlassen haben (z.B. durch Überschwingen der Regelung), fährt er wieder näher zur Bahn und dann wieder nach Kompass/Gyro weiter.

Bin schon gespannt auf Deine Veröffentlichung.
 
Oben