Raindancer Firmware (Deutsch)

Aus www.wiki.ardumower.de
Version vom 30. April 2018, 08:58 Uhr von Roland (Diskussion | Beiträge) (Inbetriebnahme der Motoren)

Wechseln zu: Navigation, Suche

Achtung! Die Software ist noch im Wandel und kann jederzeit geändert/erweitert werden.

Download

Github 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

Warning.pngSicherheitshinweis: Aus Sicherheitsgründen sind die Mähmesser bei den ersten Tests nicht zu montieren!

Warning.pngWichtig: 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 abgeändert 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, un 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 einem PWM Wert angesteuert.0 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

Den Befehl

clc.mt,1,150 

eingeben, damit sich das linke Rad dreht. Dann

clc.enc 

eingeben, um die Encoderwerte anzuzeigen. Die Encoder haben zwei Zähler. Einmal einen Absolutencoder, der zählt immer positive egal wie rum sich das Rad dreht. Und einmal einen Encoder, der bei Vorwärtfahrt hochzählt und bei Rückwärtsfahrt zurückzählt. Beide angezeigten Zähler des linken Rades müssen nun hochzählen.

Die Ausgabe wird mit dem Befehl: h beendet.

Beispiel:

motor 1 = Links
motor 2 = rechts -sollte nicht zählen, wenn 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
!

Falls der enc 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

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 und aufspielen.

Check des closed loop control services

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

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.

Nun in config.h

#define CONF_DISABLE_MOTOR_STALL_CHECK  false

setzen, neu kompilieren und aufspielen. Dann nochmal probieren. Es dürfen keine Fehler angezeigt werden.

Mähmotor Inbetriebnahme

Befehl eingeben:

z          //mow motor start

mot.curm //zeigt den Mähmotorstrom an.

danach

t          //mow motor stop

Es kann sein, dass beim stoppen ein motorfault kommt. Diesen mit reset zurücksetzen.


Perimeter Inbetriebnahme

Die Spulen des Roboters sollten innerhalb der Schleife sein. Die Raindancer Sendersoftware 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 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.


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.

!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. Die Umrechnung mit CONF_LEFT_ENCODER_INVERSE/CONF_RIGHT_ENCODER_INVERSE findet später statt. Wichtig ist, das CONF_LEFT_ENCODER_INVERSE und CONF_RIGHT_ENCODER_INVERSE so configuriert 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 als erstes den Mähmotor ausschalten, falls innen getestet wird. Achtung, es sind noch keine Bumper aktiv.

#define CONF_DISABLE_MOW_MOTOR          	true

Danach neu kompilieren und Software aufspielen.

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 Original Bumper

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.

Zum aktivieren der Bumper muss in der config.h fogende Zeile eingestellt werden:

#define CONF_DISABLE_BUMPER_SERVICE		true


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)