Raindancer Firmware (Deutsch)
Achtung! Die Software ist noch im Wandel und kann jederzeit geändert/erweitert werden.
Inhaltsverzeichnis
- 1 Download
- 2 Überblick
- 3 Für eine minimale Inbetriebnahme sollten folgende Voraussetzungen erfüllt sein
- 4 Optional kann verwendet werden
- 5 config.h
- 6 QUICK START TO MOW
- 6.1 Zum warm werden: Konfiguration des Batterie Service
- 6.2 Inbetriebnahme der Motoren
- 6.3 Inbetriebnahme der Encoder
- 6.4 Check des closed loop control services
- 6.5 Check des position control services
- 6.6 Mähmotor Inbetriebnahme
- 6.7 Perimeter Inbetriebnahme
- 6.8 Charge service (kann auch später erfolgen)
- 6.9 Konfiguration Bluetooth
- 6.10 Einstellen Arduino Central
- 6.11 Erste Testfahrt
- 6.12 Konfiguration der Bumper an den Bumperanschlüssen
Download
(Auf Github mit dem grünen Button das Zip-File herunterladen)
Die Raindancer Firmware befindet sich im Verzeichnis code\Raindancer Die Sender Firmware befindet sich im Verzeichnis code\sender
Überblick
Die Raindancer Firmware mäht nach dem Chaos Prinzip. Der Roboter fährt von der Ladestation eine angegebenen Strecke am Perimeter lang und fängt dann an zu mähen. Die Mähzeit beträgt mit den original Ardumowerkomponenten bei dem Raindancer Chassis ca. 130min. Nachdem die Batteriespannung auf 23,7V heruntergegangen ist, sucht der Roboter das Perimeterkabel und fährt dieses bis zur Ladestation entlang. In der Ladestation angekommen, wird die Batterie geladen. Der nächste Mähvorgang wird über das Mobile Phone gestartet.
Die Firmware wurde entwickelt für Roboter mit dem Antriebsmotoren hinten, kann aber auch für das original Ardumower Chassis verwendet werden. Optimierungen für das original Chassis erfolgen zu einem späteren Zeitpunkt. Der Mower dreht sich auf dem Perimeter. Wenn eine Spule über das Perimeterkabel gefahren ist, fährt der Roboter noch ca. 20cm weiter. Dann werden beide Spulen, in die Schleife gedreht und ab da an wird dann mit einem Zufallswinkel weitergedreht. Da das original Chassis einen kurzen Abstand zwischen Spulen und Rädern hat, gibt es hier folgenden Workaround: In der config.h kann eingestellt werden, dass der Mower weiter zurückfährt, dann einen festen Winkel dreht (Drehung auf dem Perimeter simuliert) und nach dem Drehen des festen Winkels wird der Zufallswinkel gedreht.
Für die Perimetererkennung wird ein 128Bit Signal verwendet. Daher muss die Raindancer Sendersoftware auf den Sender aufgespielt werden. Beim annähren an das Perimeterkabel wird der Roboter langsamer. Die Bedingungen dafür müssen ggf. im Code angepasst werden. Erkennt der Roboter das Signal für 2 Sekunden nicht, bleibt er stehen und schaltet die Motoren aus. Erkennt er es wieder, fährt er weiter.
Die Firmware unterstützt in der aktuellen Version eine durchfahrende Ladestation (unterstützen einer einseitig befahrbaren Ladestation folgt zu einem späteren Zeitpunkt). Das Anfahren der Ladestation kann in der Software ausgeschaltet werden. Dann bleibt der Roboter am Perimeter stehen, wenn die Batteriespannung unter 23,7V fällt. Zum Laden kann der Roboter dann ausgeschaltet werden, an das Ladekabel angeschlossen werden und wieder eingeschaltet werden. Der Roboter geht dann in den Lademodus. Fällt die Spannung unter 21,7V löst die Unterspannungsabschaltung aus falls diese nicht überbrückt wird.
Mit den original Motoren und Rädern fährt der Roboter mit einer Geschwindigkeit von ca. 1200m/h. Um ein vernünftiges Schnittbild zu erlangen, muss der Roboter bei einer 1000m² Fläche ca. 6-9h pro Tag mähen (meine Erfahrung). Hängt natürlich auch von der Art und Verwinkelung der Fläche ab.
Der Roboter unterstützt zusätzlich einen selbstgebauten Bumperduino mit zwei MaxSonar Sonarsenoren und einem MPX5010DP FREESCALE Drucksensor für einen Druckwellenschlauch.
https://github.com/kwrtz/Raindancer/blob/master/DipTrace/DistanceBumperSensor/DistanceBumperSensor.pdf
Die Auswertung übernimmt ein Arduino Nano, welcher an PinUserSwitch2/3 des PCB1.3 angeschlossen ist. Bei Erkennen eines Hindernisses mit den Sonarsenoren, wird der Roboter langsamer und bumped seicht gegen das Hindernis wo dann der Bumper oder Bumperduino auslöst. Die Platine ist relative einfach aufgebaut. Die MaxSonar Sensoren können weggelassen werden und es kann eine eigene Lösung an den Nano angeschlossen werden, oder die aktuelle Raindancer Software kann erweitert werden. Die original Ardumower Ultraschall Sensoren werden aktuell nicht unterstützt.
Falls ein original Bumperduino verwendet wird oder eigene Bumper, können diese wie bisher an die Bumper Pins angeschlossen werden.
Für die Bedienung wird das Serielle Interface verwendet. Auf dem Mobile Phone eignet sich die Software Arduino Central (kostenlos mit Werbung oder ohne Werbung für wenige Euros). Die Bedienung erfolgt über Kommandozeilenbefehle. Die gesendete Zeile muss mit CR abgeschlossen werden. Die Ausgabe erfolgt automatisch auf der Console oder auf dem Mobile Phone, je nachdem von wo gerade der Befehl eingegeben wurde. Die meisten Befehle sind nach Services Gruppiert. Die Gruppe entspricht den angesprochenen Services in der Software. Der auf den Service folgende Befehl ist dann durch einen Punkt getrennt. Leerzeichen werden übersprungen und haben keine Bedeutung. Dies ist gerade bei Verwendung des Mobile Phones nützlich, wo ein Leerzeichen nach einem Punkt eingefügt wird.
Beipiel: clc.enc
Der Service clc enthält den Befehl enc. Damit wird der closes loop control service angesprochen und ihm mittgeteilt, dass er die Encoderdaten anzeigen soll.
Parameter werden mit einem Komma getrennt.
Beispiel: pc.cm,60,30 //drives 60 cm with speed 30 (//drives... gehört nich zum Befehl)
Damit wird der Positioncontrol Service angesprochen. Fahre 60cm mit der Geschwindigkeit von 30%
Der Befehl H zeigt die Hilfe an.
Viele Befehle geben Ausgaben auf der Konsole aus. Um diese Ausgabe zu deaktivieren, kann man h eingeben oder den gleichen Befehl wieder (der die Ausgabe angestoßen hat). Falls ein Error oder Motorstall ausgegeben wird, kann dieser mit dem Befehl reset zurückgesetzt werden.
Die Software ist Modular aufgebaut. Die einzelnen Module beeinflussen sich fast gar nicht. Damit ist es relative einfach etwas Abzuändern oder zu Erweitern.
https://github.com/kwrtz/Raindancer/blob/master/Documentation/SoftwareStructure.pdf
Zur Dartsellung und Bearbeitung der Software Structure wurde die Software UMLET verwendet.
Es gibt einen Hardware Abstraction Layer. Die gesamte Kommunikation mit der Hardware erfolgt über Objekte in hardware.h. Die meisten Objekte in hardware.h sind in InOutInterface.h definiert. In hardware.cpp findet die Initialisierung und Pinzuordnung der Hardware statt. Services sammeln Daten oder steuern die Motoren und stellen ihren Service der Steuerung zur Verfügung. Als Steuerung wird ein Behaviourtree verwendet. Der Behaviourtree greift auf die Services über das Blackboard zu. Nodes des Behaviourtree tauschen informationen über das Blackboard aus.
Für die grafische Erstellung des BHT wurde SPLAN verwednet.
https://www.electronic-software-shop.com/elektronik-software/splan-70.html?language=de
Um die Dateien des BHT zu betrachten kann folgende kostenlose Software verwendet werden:
https://www.electronic-software-shop.com/support/kostenlose-datei-viewer/?xoid=oep38ca4ehqn37a7dn3rnrpie6
Die Dateien des BHT befinden sich hier
https://github.com/kwrtz/Raindancer/tree/master/Documentation
Der Roboter kennt zwei Modi: Manual und Auto. Im manuellen Mode laufen alle Services, aber der Behaviourtree (BHT) ist ausgeschaltet. Im Auto mode wird der BHT aktiviert.
Welcher Modi wird wann gestartet:
MANUAL Roboter wird eingeschaltet und ist nicht in der Ladestation AUTO Der Roboter wird in der Ladestation eingeschaltet und erkennt eine Spannung an den Ladekontakten. Das Behaviour Charging wird aktiviert. Der Roboter wird geladen.
Ist der Roboter im MANUAL Mode, kann er mit dem Befehl A in den Automode geschaltet werden. Erkennt der Roboter das Perimetersignal, fängt er an zu mähen.
Offene Punkte
- Stabilität der Software langfristig Prüfen. Stand 28.04.2018 Aktuell hat die aktuelle Softwareversion 63h gemäht, hat dabei 59km zurückgelegt und hat 8426 mal rotiert.
- Der Linienverfolgungsalgorithmus wurde aktuell für das Chassis mit Antriebsrädern hinten optimiert. Aufgrund des kurzen Abstandes von Spule zu den Rädern des original Chassis kann es notwendig sein einen anderen Algorithmus zu programmieren.
- Optimierung für das Original Chassis (Das mähen funktioniert mit dem Workaround schon sehr gut. Ggf. mit den Parametern CONF_PER_CORRECTION_ANGLE und CONF_PERIMETER_DRIVE_BACK_CM etwas spielen)
- Ausweichen von Objekten, die nahe am Perimeter stehen optimieren (SecondReverse2 im BHT)
- Einseitig befahrbare Ladestation umsetzen
- RTC verwenden um Zeitgesteuert zu mähen
Weitere Wünsche
- Regensensor einbinden
- Die Ladestation wird aktuell nur counter clockwise angefahren.
- Verstärken des Signals der Ladestation auf +-20V Spannung Hub
- SRF08 einbinden
- I2C Temperatursensoren einbinden
- Anfahren der Ladestation mit GPS. 15m vor der Ladestation auf den Perimeter fahren und dann in die Ladestation einfahren.
- GPS Karte - es kann sein, dass der Mower das Signal in der Mitte des Rasens nicht erkennt, da das Signal zu schwach ist. Man kann dann mit GPS dann sehen, ob man auf der Fläche ist. Wenn man nun sagt, dass das Signal mindesten in 15m Abstand vom Perimeter erkannt werden muss, kann man es innerhalb der Fläche vernachlässigen wenn das GPS Signal anzeigt, das man auf der Fläche ist.
- GPS Karte - Vermerken wo der Robbi schon gemäht hat. Dann ggf. in weniger gemähten Bereichen mähen.
Die GPS Karte wird vermutlich auf einen externen Prozessor ausgelagert weden müssen.
Für eine minimale Inbetriebnahme sollten folgende Voraussetzungen erfüllt sein
Sicherheitshinweis: Aus Sicherheitsgründen sind die Mähmesser bei den ersten Tests nicht zu montieren!
Wichtig: Für die ersten Getriebemotortests sollte der Roboter hochgebockt werden so dass die Räder keinen Kontakt zum Boden haben!
- PCB1.3 mit Arduino DUE
- Original Ardumower Antriebsmotoren mit Encoder
- Original Mähmotor
- Zwei Ardumower Perimeterspulen vorne Links/Rechts. Bei original Chassis ggf. montiert: Links/Mitte (kommt darauf an, welchen Linienverfolgungsalgorithmus man verwendet)
- BT Modul
- RTC mit EEPROM
- Die Brücke für die Encoder auf dem PCB1.3 ist auf den 2er Teiler überbrückt.
- 24V Spanungsversorgung
Optional kann verwendet werden
- Ardumower Bumper Pins mit Schaltern, Hall Effekt Sensoren, original Bumper Duino, ...
- Durchfahrende Ladestation
- Selbst gebauter Bumperduino mit 2MaxSonar Sensoren an PinUserSwitch2/3
config.h
Die Datei config.h enthält die Grundkonfiguration der Firmware.
Vor der ersten Inbetriebnahme müssen die Parameter angepasst werden.
Konsolenspeed:
#define CONF_PC_SERIAL_SPEED 115200 // Speed serial consol
Sollte das Bluetooh Modul bereits mir der Azurit Firmware konfiguriert worden sein, ist die Zeile
#define CONF_BT_SERIAL_SPEED 115200
auf
#define CONF_BT_SERIAL_SPEED 19200
abzuändern.
Einstellen des Radumfangs und Radabstandes. Das original Ardumower Rad hat einen Umfang von 78.54f cm
#define CONF_RADUMFANG_CM 80.738f // Wheel circumfence in cm original ardumower: 78.54f #define CONF_DISTANCE_BETWEEN_WHEELS_CM 36.0f // Distance where the wheels hits the ground do not measure on top of the wheels!!!
Für die erste Inbetriebnahme sollten die meisten Services deaktiviert werden um Fehlermeldungen zu Verhindern:
#define CONF_ENABLEWATCHDOG false // Set to false to disable Watchdog. true to enable. #define CONF_DISABLE_RANGE_SERVICE true // Disables my own range sensor running on bumper duino on pinUserSwitch3 => diNearObsacleSensor #define CONF_DISABLE_BUMPER_SERVICE true // Disables original bumper sensor on pinBumperLeft => diBumperL and pinBumperRight => diBumperR #define CONF_DISABLE_BUMPERDUINO_SERVICE true // Disables my own bumper duino sensor on pinUserSwitch2 => diBumperSensor
#define CONF_DISABLE_PERIMETER_SERVICE false // Disables perimeter sensor #define CONF_DISABLE_RTC_SERVICE true // Disables rtc sensor #define CONF_DISABLE_EEPROM_SERVICE true // Disables EEPROM requests #define CONF_DISABLE_BATTERY_SERVICE true // Disables battery sensor #define CONF_DISABLE_CHARGE_SERVICE true // Disables charge system service
#define CONF_DISABLE_MOTOR_STALL_CHECK true // Disables the motor stall/encoder check in closed loop control #define CONF_DISABLE_MOW_MOTOR false // Disables the mow motor
#define CONF_DISABLE_CHARGINGSTATION true
NUR FÜR DAS original Ardumower Chassis Design sollten noch folgende Konstanten eingestellt werden:
#define CONF_PER_CORRECTION_ANGLE 30 #define CONF_PERIMETER_DRIVE_BACK_CM 40.0f
Da nun häufiger kompiliert wird, ist es sinvoll den Roboter aufzubocken, so dass die Antriebsräder und der Mähmotor frei drehen können.
Nach dem ersten kompilieren und aufspielen sollte als letzte Zeile folgendes angezeigt werden:
Press H for help.
Hier H eingeben. Danach werden alle verfügbaten Befehle angezeigt. Diese am besten kopieren und abspeichern, so dass man diese einsehen kann.
QUICK START TO MOW
Ziel dieses Kapitels ist, mit der Bedienung etwas vertrauter zu werden, und den Roboter soweit zu konfigurieren, dass die Perimeter Sensoren funktionieren und man innerhalb des Perimeters mähen kann.
Der Roboter ist über das Konsolen-kabel verbunden. Speed: 115200
Zum warm werden: Konfiguration des Batterie Service
Der Batterie Service ermittelt die Spannung der Batterie und stellt diese dem BHT zur Verfügung.
In config.h den Batterieservice aktivieren und danach die Software neu aufspielen.
#define CONF_DISABLE_BATTERY_SERVICE false
Den Befehl
bat.show
eingeben. Es sollte die richtige Batteriespannung angezeigt werden.
Inbetriebnahme der Motoren
Als erstes wird geprüft ob die Motoren sich drehen und ob diese auch in die richtige Richtung drehen. Dazu werden die Motoren direkt mit einer PWM Wert angesteuert. D.h es erfolgt keine Regelung der Geschwindigkeit anhand der Encoder. Die Regelschleife für die Geschwindigkeit ist offen (open loop);
Der Befehl clc.mt,1,150 veranlasst den clc Service die eingegebene PWM von 150 direkt an den Motor zu schicken. Maximum für die PWM ist 255. Die 1 steuert den linken Motor an, die 2 den rechten.
Den Befehl
clc.mt,1,150
eingeben.
Damit wird der Motor (1) links direkt mit einer PWM con 150 angesteuert. Bei Werten unter 100 kann es sein, dass sich der Motor nicht dreht. Gestoppt wird das Rad dann mit
clc.mt,0,0
Das Rad links sollte sich vorwärts drehen. Falls es sich rückwärts dreht muss das Kabel am Stecker umgepolt werden. Sollten sich das Rad nicht drehen, kann man es noch mit einer höheren PWM von z.B. 200 versuchen. Bei einer PWM kleiner 80 dreht sich der Motor vermutlich nicht.
Das gleiche für das rechte Rad (2):
clc.mt,2,150
Gestoppt wird das Rad dann mit
clc.mt,0,0
Anmerkung:
Die PWM für die Motoren läuft mit 20000Hz. Original Adrumower PWM ist 3900Hz.
Wenn man die Originalwerte verwenden möchte, muss man nachfolgende Zeilen in pinman.cpp auf 3900 abändern.
#define PWM_FREQUENCY 20000 #define TC_FREQUENCY 20000
Sollten sich die Räder bei einer PWM von 150 nicht drehen, dann bitte die PWM auf 3900Hz stellen und erneut versuchen.
Inbetriebnahme der Encoder
Es wird geprüft, ob die Encoder funktionieren und ob diese auch in die richtige Richtung zählen.
Die Encoderroutine hat pro Rad zwei Zähler. Einmal einen Absolutzähler (absEnc), der zählt immer positive egal wie rum sich das Rad dreht. Und einmal einen positiv/negative Zähler (enc), der bei Vorwärtsfahren hochzählt und bei Rückwärtsfahren runterzählt.
Den Befehl
clc.mt,1,150
eingeben, damit sich das linke Rad dreht.
Dann
clc.enc
eingeben. Damit werden die Encoderwerte vom linken und rechten Rad angezeigt.
Die Ausgabe wird mit dem Befehl: h beendet.
Beide angezeigten Zähler des linken Rades (1) müssen nun hochzählen.
Beispiel:
motor 1 = links -sollte nicht zählen, wenn nur der rechte Motor läuft. motor 2 = rechts -sollte nicht zählen, wenn nur der linke Motor läuft. !03,motor 1 enc: 972 absEnc: 972 rpm: 2.596326 m/h: 125.773315 deltaTicks: 2 deltaTime: 32986us !03,motor 2 enc: 974 absEnc: 974 rpm: 3.325853 m/h: 161.113647 deltaTicks: 2 deltaTime: 33445us !03,motor 1 enc: 974 absEnc: 974 rpm: 2.923552 m/h: 141.625061 deltaTicks: 2 deltaTime: 33156us !03,motor 2 enc: 975 absEnc: 975 rpm: 2.678638 m/h: 129.760696 deltaTicks: 1 deltaTime: 33144us !03,motor 1 enc: 976 absEnc: 976 rpm: 3.132316 m/h: 151.738159 deltaTicks: 2 deltaTime: 32857us !03,motor 2 enc: 976 absEnc: 976 rpm: 2.296233 m/h: 111.235962 deltaTicks: 1 deltaTime: 32859us !03,motor 1 enc: 978 absEnc: 978 rpm: 3.251686 m/h: 157.520752 deltaTicks: 2 deltaTime: 32998us
Das Beispiel Zeigt, dass die Encoder hoch zählen. Beispiel motor 1: enc:972 dann enc:974, dann enc:976 ... Beispiel motor 2: enc:972 dann enc:975, dann enc:976 ...
Falls der enc Wert negative beim Vorwärtsfahren zählt kann man das in der config.h konfigurieren:
#define CONF_LEFT_ENCODER_INVERSE false #define CONF_RIGHT_ENCODER_INVERSE false
Dazu CONF_LEFT_ENCODER_INVERSE für das linke Rad auf true setzen. Für das rechte Rad CONF_RIGHT_ENCODER_INVERSE auf true setzen.
Das gleiche für das rechte Rad durchführen:
clc.mt,2,150
Befehl wird mit clc.mt,0,0 gestoppt.
Nachdem die Zeilen in der config.h richtig eingestellt wurden, neu kompilieren, aufspielen und neu testen!
Check des closed loop control services
Der closed loop control (clc) service regelt die Geschwindigkeit eines Rades. Für jedes Rad gibt es einen Service also insgesamt zwei Services. Der Service berechnet intern die die Geschwindigkeit des Rades mit Hilfe der Encoderwerte und stellt dann die notwendige PWM ein um die vorgegebene Geschwindigkeit zu erreichen (closed loop). Die Geschwindigkeit wird in % angegeben. Dabei beziehen sich 100% auf die Konstante CONF_MAX_WHEEL_RPM in der config.h.
Mit dem Befehl clc.v,30 wird beiden Services gesagt, drehe das Rad mit einer Geschwindigkeit(v) von 30%. Somit sollten sich beide Räder vorwärts drehen.
Eingeben:
clc.v,30 Fährt vorwärts mit Geschwindigkeit 30%
dann
clc.v,s Motor stoppen
dann
clc.v,-30 Fährt Rückwärts mit Geschwindigkeit 30%
Hat alles funktioniert, dann weiter. Ansonsten nochmal die Encoder und Drehrichtung überpürfen.
mot.cur Zeigt den Motorstrom an.
Check des position control services
Der Position Control Service (pc) dient dazu, das Rad einen bestimmten Weg zu fahren oder das Rad einen bestimmten Winkel zu drehen. Pro Rad gibt es einen Service. Mit dem Befehl pc.a,360,80 werden beide Räder angesprochen. Drehe die Räder einen Winkel von 360 Grad mit einer Geschwindigkeit von maximal 80%.
An einem Rad eine Markierung anbringen, damit man sieht, wie weit es sich dreht
pc.a,360,80 Rotiert beide Räder vorwärts um 360 Grad mit 80% Speed wenn alles richtig konfiguriert ist. pc.a,-360,80 Rotiert beide Räder rückwärts um 360 Grad mit 80% Speed wenn alles richtig konfiguriert ist.
Die Position Control kann mit dem Befehl
pc.s
gestoppt werden.
Sollte sich das Rad nicht um 360 Grad gedreht haben, scheint der Wert CONF_ENCTICKSPERREVOLUTION in config.h falsch zu sein. Für die original Motoren aus dem Ardumower Shop ist der Wert von 1060 vorgegeben.
Zusätlich ist die Konstante CONF_RADUMFANG_CM wichtig, damit die Berechnung für das Fahren eines bestimmten Weges in cm stimmt.
Da an Anfang in der config.h der Motorüberwachung ausgeschaltet wurde, wird diese nun wieder eingeschaltet. Die Motorüberwachung prüft, ob die Encoder bei Drehung der Motoren Werte liefern, ob in die richtige Richtung gedreht wird oder ob der Motor überhaupt dreht wenn eine PWM anliegt.
Zum Einschalten der Morotüberwachung in der config.h den Wert CONF_DISABLE_MOTOR_STALL_CHECK auf false setzen.
#define CONF_DISABLE_MOTOR_STALL_CHECK false
Neu kompilieren und aufspielen. Dann nochmal probieren. Es dürfen keine Fehler angezeigt werden.
Wenn alles funktioniert hat, kann der Roboter auf die Räder gestellt werden.
Weiter Tests können noch durchgeführt werde:
Zurücklegen einer bestimmten Streck in cm
pc.cm,60,30 Fahre 60cm vorwärts mit der Geschwindigkeit von 30%
pc.cm,-60,30 Fahre 60cm rückwärts mit der Geschwindigkeit von 30%
Drehen eines bestimmten Winkels
turnto,360,30 Drehe den Roboter um 360 Grad CW (clockwise)
turnto,-360,30 Drehe den Roboter um 360 Grad CC (counter clockwise)
Sollte der Roboter nicht 360 Grad drehen, so ist vermutlich die Konstante CONF_DISTANCE_BETWEEN_WHEELS_CM in config.h falsche eingestellt.
Mähmotor Inbetriebnahme
Der Mähmotor verwendet keinen Encoder. Er wird mit einer PWM von 255 betrieben. Die PWM von 255 wird nicht sofort auf den Motor gegeben. Es wird über eine Rampe die PWM von 0 auf 255 erhöht. Das gleiche gilt für das Abbremsen des Motors. Es kann vorkommen, das bei dem Abbremsen des Motors ein Motorfault angezeigt wird. Dies liegt daran, dass die Motorscheibe durch die Trägheit versucht den Motor weiter zu drehen und dieser somit einen Storm in den Motortreiber rückwirkend einspeist, welcher die Limits überschreitet so dass die Tri State Ausgänge des des Treibers in den hochohmige Zustand gehen. Sollte das passieren kann der Fehler mit dem Befehl reset zurückgesetzt werden.
Befehl eingeben:
z //mow motor start
danach
t //mow motor stop
Es kann sein, dass beim stoppen ein motorfault kommt. Diesen mit reset zurücksetzen.
mot.curm //zeigt den Mähmotorstrom an.
Perimeter Inbetriebnahme
Die Raindancer Firmware arbeitet mit zwei Spulen. Damit wird festgestellt, in welchem Winkel der Roboter auf den Perimeter triff. Dementsprechend wird entschieden, ob CC oder CW gedreht wird. Das Perimetersignal muss die ganze Zeit während des Mähens empfangen werden. Wird für 2 Sekunden das Signal nicht empfangen, stoppt der Roboter und fährt weiter, sobald das Signal empfangen wurde. Die Zeit die ein nicht Empfang toleriert wird, wird mit dem Parameter CONF_PER_SIGNAL_LOST_TIME in der config.h festgelegt. So kann mann ggf. "Empfangslöcher" in der Mitte des Rasen überbrücken. Nachteil ist, falls der Sender genau dann ausfällt wenn sich der Roboter am Perimeter befindet, kann es sein, dass der Roboter diese eingestellte Zeit außerhalb der Perimeterschleife fährt.
Voraussetzung zur Inbetriebnahme: Die Spulen des Roboters müssen für die Inbetreibnahme innerhalb der Perimeterschleife sein. Die Raindancer Sender Firmware muss auf dem Sender installiert sein.
Als erstes wird geprüft, ob das Signal erkannt wird.
Man kann sich die berechneten Wert der einzelnen Spulen folgendermaßen anzeigen lassen: per.resultl für linke Spule und per.resultr für rechte Spule. Am Beispiel unten kann man am BAD erkennen, dass kein gültiges Signal empfangen wurde. Wichtig ist hier, dass kein BAD angezeigt wird. Die empfangene Amplitude steht hinter mag:. Die Signalqualität kann man an der Peak Signal Noise Ratio psnr sehen.
Beispiel per.resultl mag: 453 peak @ 432 : 453 peak2 @ 328 : 142 MSE: 1704.569 psnr: 120.388 psnr2: 11.829 ratio: 10.177 mag: 431 peak @ 279 : 431 peak2 @ 145 : -125 MSE: 1638.841 psnr: 113.349 psnr2: 9.534 ratio: 11.889 mag: 372 peak @ 128 : 372 peak2 @ 12 : 119 MSE: 1521.076 psnr: 90.978 psnr2: 9.310 ratio: 9.772 mag: 458 peak @ 486 : 458 peak2 @ 352 : -195 MSE: 1922.495 psnr: 109.110 psnr2: 19.779 ratio: 5.516 mag: 428 peak @ 335 : 428 peak2 @ 233 : 118 MSE: 1818.376 psnr: 100.740 psnr2: 7.657 ratio: 13.156
Beispiel per.resultr
mag: 6 peak @ 144 : 6 peak2 @ 24 : -5 MSE: 3.161 psnr: 11.388 psnr2: 7.908 ratio: 1.440 BAD mag: -5 peak @ 161 : -5 peak2 @ 46 : 4 MSE: 2.380 psnr: 10.504 psnr2: 6.723 ratio: 1.562 BAD mag: -5 peak @ 60 : -5 peak2 @ 179 : 5 MSE: 3.556 psnr: 7.030 psnr2: 7.030 ratio: 1.000 BAD mag: 5 peak @ 159 : 5 peak2 @ 3 : 4 MSE: 2.949 psnr: 8.477 psnr2: 5.425 ratio: 1.563 BAD mag: 5 peak @ 11 : 5 peak2 @ 153 : 5 MSE: 3.286 psnr: 7.607 psnr2: 7.607 ratio: 1.000 BAD
Mit h Ausgabe beenden.
Beide Spulen sollten das Signal erkennen, also kein BAD anzeigen. Auch nicht sporadisch!
Als nächstes muss die Polarität des Signals konfiguriert werden.
per.show eingeben. (mit h Ausgabe ausschalten)
Wenn die Spule innerhalb des Perimetes ist, muss die Amplitude der Spule positive sein.
Es werden nun die erkannten Perimeteramplituden ausgegeben. ML zeigt die Amplitude der linken Spule an, MR die Amplitude der rechten Spule.
!03, ML: -305 MR: 331 magMax:332 magMedL%: 0 magMedR%: 102 !03, ML: -330 MR: 338 magMax:332 magMedL%: 0 magMedR%: 102 !03, ML: -327 MR: 330 magMax:332 magMedL%: 0 magMedR%: 102 !03, ML: -336 MR: 332 magMax:332 magMedL%: 0 magMedR%: 102 !03, ML: -304 MR: 328 magMax:332 magMedL%: 0 magMedR%: 102 !03, ML: -326 MR: 324 magMax:332 magMedL%: 0 magMedR%: 102
Allerdings sieht man hier, dass die Magnetude links negative ist. In der Perimeterschleife muss diese positive sein.
Dies kann in der config.h eingestellt werden:
#define CONF_LEFT_ENCODER_INVERSE true #define CONF_RIGHT_ENCODER_INVERSE false
Nach neuem aufspielen, sollten die Werte positive sein.
Achtung, bei per.resultl und per.resultr wird das Vorzeichen der Amplitude wie tatsächlich empfangen angezeigt unabhängig von den Einstellungen in CONF_LEFT_ENCODER_INVERSE und CONF_RIGHT_ENCODER_INVERSE.
Es kann sein, dass per.resultl eine positive Amplitude liefert und per.resultr eine negative. Das ist OK, da es von dem Anschluss der Spulen abhängt. Die Umrechnung mit CONF_LEFT_ENCODER_INVERSE/CONF_RIGHT_ENCODER_INVERSE findet in der Software später statt.
Wichtig ist, das CONF_LEFT_ENCODER_INVERSE und CONF_RIGHT_ENCODER_INVERSE so konfiguriert werden, dass per.show innerhalb der Spule positive Amplituden anzeigt.
Charge service (kann auch später erfolgen)
In config.h folgendes setzen und Software neu aufspielen.
#define CONF_DISABLE_CHARGE_SERVICE false
charge.show eingeben. Nun werden die Spannungen und Ströme angezeigt. Aktuell alles 0.
Ladegerät an P42 oder Ladekontakte anschließen.
Nun sollten die Chargevoltage gemessen werden.
Relay einschalten:
charge.relay,1
Nun müsste das Relay angehen und alle Werte müsseten was anzeigen.
Relay ausschalten.
charge.relay,0
Roboter ausschalten und USB abziehen. Ladekontakte sind noch verbunden. Roboter einschalten, USB anschließen und serielle Konsole aufrufen. Der DUE startet neu. Das Relay sollte angezogen werden und die Konsolenausgabe sollte in Charging Station anzeigen. Der Roboter hat nun in das Chargingbehavioour geschaltet.
M eingeben um wieder in manuellen mode zu gelangen.
Konfiguration Bluetooth
Wurde das Modul bereits mir der original Arduower Software konfiguriert, kann
#define CONF_BT_SERIAL_SPEED 19200
eingestellt werden. (Die Perimeterausgaben sind extrem umfangreich. Es kann sein, das die Software bei dieser Übertragungsrate ins Stocken gerät, wenn man sich Perimeterdaten über BT bei diesr Baudrate anzeigen läßt.) Damit wäre dann die Konfiguration fertig.
Da es häufiger Probleme mit der Konfiguration von BT Modulen gibt, schlage ich vor ein funktionierendes BT Modul nur dann umzuprogrammieren, wenn man noch ein anderes funktionierendes BT Modul als Reserve hat.
Für die Konfiguration des BT wird die original Ardumower Routine verwendte. Allerdings wird die Baudrate auf 115200 gesetzt. Daher kann man die zur Fehlersuche verwendeten Tips im Forum verwenden.
Alos los: Platine stromlos schalten. Knopf auf BT Modul drücken und gedrückt halten. Platine anschalten. Das BT Module sollte nun alle 2Sek blinken.
Knopf loslassen.
bt.show eingeben. Versucht das BT modul zu finden.
Wenn erfolgreich gefunden:
bt.set eingeben. Das BT Modul wird konfiguriert.
Einstellen Arduino Central
In Adrduino Central kann oben rechts das Menü (drei Punkte) aufgemacht werden. Dort settings aufrufen.
Dann Button layout Configuratin öffnen. Hier wird eingestellt, welche Buttons angezeigt werden. Nur folgendes soll angewählt sein:
Show Control Button Show Standard Button set 1 Show Standard Button set 2 Show Standard Button set 3
Zurückgehen und Serial Terminal Settings öffnen Terminal View Characcter Limit auf 10000 setzen
Zurückgehen und Line Ending for Commands auswählen
Hier CR auswählen
Zurückgehen und Line Ending for Incomming Data auswählen
Hier NL auswählen.
Dann erstmal ganz aus dem Menü rausgehen.
Als erstes muss nun das BT Modul mit dem Handy gekoppelt werden. Das heißt am Handy BT Aktivieren. Dann in das BT Menue am Handy gehen und nach neuen Geräten suchen. Dort sollte dann eine neues Gerät auftauchen. Dieses Geräte auswählen und paaren bzw koppeln. Es kommt zu einer Passwortabfrage die 1234 ist oder auch 0000 Danach wird das Modul in der Gerätelist aufgenommen.
Jetzt in Arduino Cnetral im Menü auf connect to Device gehen und das BT des robbis klicken. Wenn alles erfolgreich war, sollte oben rechts BT connect angezeigt werden.
In der Befehlszeile dann H eingeben und Senden. Es sollte dann die Hilfe angezeigt werden.
In Arduino Central können unter dem Menüpunkt Standard Button Setup Befehle hinterlegt werden. Aktuell habe ich bei mir folgende Befehle hinterlegt:
Button 1 Text: Manual Command: M Button 2 Text: Auto Command: A Button 3 Text: Hide Command: h Button 4 Text: area,19 Command: area,19 Button 5 Text: gohome Command: gohome Button 6 Text: per Command: per.show Button 7 Text: mowense Command: mot.curm Button 8 Text: bat Command: bat,show Button 9 Text: charge Command: charge.show
Diese Befehle können je nach Bedarf angepasst werden.
Erste Testfahrt
Dazu zur Sicherheit für den ersten Test den Mähmotor in config.h ausschalten.
#define CONF_DISABLE_MOW_MOTOR true
Danach neu kompilieren und Software aufspielen.
Achtung, es sind noch keine Bumper aktiv! D.h. die Fläche innerhalb des Perimeters muss frei sein.
Roboter in die Schleife stellen. Mit show.per nochmal das Perimetersignal überprüfen. Mit h oder show.per Ausgabe deaktivieren.
A für Auto eingegen um das mähen zu starten.
Es kann nun 5 Sek. dauern bis sich etwas tut. Der Roboter fährt erst den Mähmotor hoch. Da dieser abgeschaltet ist, kann es so aussehen, als ob nicht passiert.
M eingeben für manuellen mode, um den Roboter zu stoppen.
Konfiguration der Bumper an den Bumperanschlüssen
Die Bumper Pins sind standardmäßig als Eingänge mit Pullup Widerstand konfiguriert in hardware.cpp:
DigitalIn diBumperL(pinBumperLeft, true);
DigitalIn diBumperR(pinBumperRight, true);
Das bedeutet, der Eingang ist standardmäßig auf HIGH, wenn der Pin nicht auf GND gezogen wurde.
Zum aktivieren der Bumper muss in der config.h fogende Zeile eingestellt werden:
#define CONF_DISABLE_BUMPER_SERVICE false
Da je nach Anwendung beide Bumper oder nur einer benutzt wird, muss man den Bumperservice ggf. noch umprogrammieren auf die eigenen Anforderungen.
Der Bumperserviceist in bumperSensor.cpp programmiert.
Dabei sind folgende Zeilen zu berücksichtigen.
// Orignal Ardumower Bumper #if CONF_DISABLE_BUMPER_SERVICE == false if (( /*diBumperL == LOW &&*/ diBumperR == LOW) && _bumperActivated) { if (flagShowBumper) { errorHandler.setInfo("!03,Bumper deactivated\r\n"); } _bumperActivated = false; //motor.hardStop(); } if ((/*diBumperL == HIGH ||*/ diBumperR == HIGH) && !_bumperActivated) { if (flagShowBumper) { errorHandler.setInfo("!03,Bumper activated\r\n"); } _bumperActivated = true; //motor.hardStop(); } #endif
Die obigen Zeilen aktivieren den Bumper wenn der Bumperport auf HIGH geht und deaktivieren ihn wieder wenn er auf LOW geht. Dies ist die Konfiguration für einen Hall Sensor. Wenn der Magnet über dem Hallsensor ist, schaltet dieser den Open Collector Ausgang durch in der aktuellen Konfiguratin bedeutet das, der Bumper ist nicht betätigt.
Weiterhin wird nur der Rechte Bumperanschluss verwendet. Möchte man den linken Anschluss auch verwenden, so muss man "diBumperL == LOW &&" sowie "diBumperL == LOW ||" einkommentieren.
Möchte man einen Schalter am rechten Bumperanschluss anschließen, der bei ausgelöstem Bumper schließt (also zu bedeutet Bumper aktiv), muss man folgenden Code verwenden (aktuell nicht getestet)
// Orignal Ardumower Bumper #if CONF_DISABLE_BUMPER_SERVICE == false if (( /*diBumperL == HIGH &&*/ diBumperR == HIGH) && _bumperActivated) { if (flagShowBumper) { errorHandler.setInfo("!03,Bumper deactivated\r\n"); } _bumperActivated = false; //motor.hardStop(); } if ((/*diBumperL == LOW ||*/ diBumperR == LOW && !_bumperActivated) { if (flagShowBumper) { errorHandler.setInfo("!03,Bumper activated\r\n"); } _bumperActivated = true; //motor.hardStop(); } #endif
Bei zwei Schaltern:
#if CONF_DISABLE_BUMPER_SERVICE == false if (( diBumperL == HIGH && diBumperR == HIGH) && _bumperActivated) { if (flagShowBumper) { errorHandler.setInfo("!03,Bumper deactivated\r\n"); } _bumperActivated = false; //motor.hardStop(); } if ((diBumperL == LOW || diBumperR == LOW && !_bumperActivated) { if (flagShowBumper) { errorHandler.setInfo("!03,Bumper activated\r\n"); } _bumperActivated = true; //motor.hardStop(); } #endif
Die Zeile //motor.hardStop(); wird aktuell nicht mehr verwendet. Kann aber eingefügt werden wenn der Bumper ausgelöst wirs, falls die Räder beim Anstoßen durchdrehen. (aktuell nicht getestet)