Aktuelle Version vom 9. August 2020, 12:59 Uhr

Die Dokumentation ist für die Firmware Version 2.x.x.

Die Dokumentation für die Version 1.1.1 ist hier Raindancer Firmware V1.1.1 (Deutsch)

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
7 TUNE UP
8 Perimeter Sender
9 Ladestation
- 9.1 Kopfladestation
- 9.2 Durchgangsladestation
10 Troubleshooting
- 10.1 Mower bleibt stehen
- 10.2 Ich bekomme diese Meldung: Out: READ und In: CMD
11 Understanding the Behaviour Tree

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 beruht auf dem Code des Nucleomowers welche mit dem Entwicklungsboard STM32 Nuleo 411RE im Jahr 2016/2017 realisiert wurde. Die Firmware wurde dann im Jahr 2017/2018 auf das Ardumower PCB 1.3 konvertiert. Sie verfolgt das Ziel, mit möglichst geringem Hardwareaufwand ein stabiles System zu bekommen, welches das ganze Jahr arbeitet und ein gutes Mähergebnis mit dem Chaosprinzip liefert.

Die Firmware hat folgenden Workflow: Der Mower steht in der Ladestation. Der Mower fährt von der Ladestation eine vorgegebene Strecke am Perimeter entlang zu einem Bereich und fängt dann an nach dem Chaosprinzip zu mähen. Die Mähzeit beträgt mit den original Ardumowerkomponenten ca. 130min-150min. 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 erneut mit einem Bereichsbefehl gestartet. (Der Roboter kann auch ohne Ladestation betrieben werden.)

Die Firmware wurde entwickelt für Roboter mit dem Antriebsmotoren hinten, kann aber auch für das original Ardumower Chassis verwendet werden. Wenn der Mower das Perimeterkabel erreicht, fährt der Roboter noch ca. 20cm weiter. Dann fährt er zurück und dreht sich mit einem Zufallswinkel.

Intern in der Firmware werden Strecken nach cm Angaben gefahren. D.h., es werden Encoder benötigt.

Für die Perimetererkennung wird ein 128Bit Signal verwendet. Daher muss die Raindancer Sendersoftware auf den Sender aufgespielt werden. Es werden 2 Perimeterempfänger benötigt. Beim Annähern an das Perimeterkabel wird der Roboter langsamer. 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. Falls das Perimetersignal zu schwach in der Mitte des Rasens ist, kann ein GPS Bereich konfiguriert werden. Wenn sich der Roboter in diesem Bereich befindet, wird angenommen er ist innerhalb der Perimeterschleife.

Die Firmware unterstützt eine Kopfladestation und eine Durchgangsladestation. 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. Für die Beschleunigung und das Abbremsen wird der Simple Trajection Planer vom Linux CNC Projekt verwendet. Dieser ermöglicht ein sehr sanftes Anfahren und Abbremsen.

Falls ein original Bumperduino, Bumper mit Schaltern, Halleffekt Sensoren,... verwendet werden, können diese wie bisher an die Bumper Pins angeschlossen werden.

Optimiert wurde die Firmware für nicht mit dem Perimeterdraht eingezäunten Hindernissen auf dem Rasen. Anstatt mit voller Geschwindigkeit gegen das Hindernis zu fahren, wird ab einem bestimmten Abstand die Geschwindigkeit verringert und seicht gegen das Hindernis gefahren. Voraussetzung sind dafür Sonarsensoren. Diese Funktion ist optional. Dazu unterstützt der Roboter einen selbstgebauten Bumperduino mit zwei MaxSonar Sonarsenoren und einem MPX5010DP FREESCALE Drucksensor für einen Druckwellenschlauch.

https://github.com/Ardumower/Raindancer/tree/master/DipTrace/DistanceBumperSensor/DistanceBumperSensor.pdf

Die Auswertung übernimmt ein Arduino Nano, welcher am 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. Dadurch kann diese einfach auf einer Laborplatine zusammengelötet werden. Die MaxSonar Sensoren können weggelassen werden und es kann eine eigene Lösung an den Nano angeschlossen werden. Der Sensor für den Druckwellenschlauch kann weggelassen werden und nur der Sonarsensor wird verwendet. Eine anderer Möglichkeit für eine Annährungslösung ist, die aktuelle Raindancer Software zu erweitern. Die original Ardumower Ultraschall Sensoren werden aktuell nicht unterstützt.

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). In Arduino Central können Buttons mit Befehlen konfiguriert werden. 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,60,30,30 //drives left wheel 60cm at 30% speed and right 60cm at 30% speed (//drives...   gehört nicht 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/Ardumower/Raindancer/tree/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/Ardumower/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 dann das Perimetersignal, fängt er an zu mähen.

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 Ardumower Mähmotor
Zwei Ardumower Perimeterspulen vorne Links/Rechts. Bei original Ardumower Chassis ggf. montiert: Links/Mitte (kommt darauf an, welchen Linienverfolgungsalgorithmus man verwendet)
BT Modul
Die Brücke für die Encoder auf dem PCB1.3 ist auf den 2er Teiler überbrückt.
24V Spanungsversorgung

Optional kann verwendet werden

RTC mit EEPROM
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.

Auswahl der Chassisform. Es darf nur ein Parameter true gesetzt werden.

#define ARDUMOWER_CHASSIS  true
#define PARANELLO_CHASSIS  false
#define RAINDANCER_CHASSIS false

Danach in config.h die Code-Sektion anpassen, die die Konfiguration für das gewählte Chassis enthält. Die Sektion beginnt folgendermaßen für das Ardumower Chassis:

//======================================================================================================================
// CONFIG FOR ARDUMOWER CHASSIS
//======================================================================================================================

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 pins (PCB1.3) 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_RAIN_SERVICE              true   // Disables rain sensor
#define CONF_DISABLE_DHT_SERVICE               true   // Disables temp sensor
#define CONF_DISABLE_GPS                       true   // Disables GPS 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, damit dei Drehung am Perimeter optimiert wird:

#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.

Falls folgende Warnung beim kompilieren auftreten, können diese ignoriert werden:

pinman.cpp: 18:0: warning: "PWM_FREQUENCY" redefined [enabled by default]
  #define PWM_FREQUENCY 3900
pinman.cpp: 19:0: warning: "TC_FREQUENCY" redefined [enabled by default]
  #define TC_FREQUENCY 3900

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 Konsolenkabel verbunden. Speed: 115200

Errorhandling

Wenn die Firmware einen Fehler feststellt, geht diese in den Errormode. Der Mower bleibt stehen und der Mähmotor wird abgeschaltet. Die Services laufen weiter. Der als erstes aufgetretene Error wird gelatched. Der Error wird dann alle 2 Sekunden an die Konsole bzw. BT ausgegeben. Je nachdem was als letztes aktiv war oder aktiviert wird durch senden eines Zeichens. Wenn man z.B. den Mower über Bluetooth gestartet hat, wird der Fehler auch auf über BT ausgegeben.

Zum deaktivieren des Error müssen folgende Befehle nacheinander eingegeben werden:

reset     //reset error and motor faults
M         //activate manual mode

Mit dem Befehl error kann sich das Errorlog angezeigt werden. Das Errorlog zeigt die History der durchlaufenen Running Nodes des BHT sowie diverse andere Ereignisse. Es ist 5000 Zeichen groß.

error     //show errormessage

Mit dem Befehl show.hist werden die letzten Drehrichtungen und andere Parameter angezeigt.

show.hist   //show history

Die letzten eingetragenen Werte, werden als erstes ausgegeben, so das diese oben stehen!

Nach dem deaktivieren des Error kann der Mower wieder mit

gestartet werden. Dabei müssen sich allerdings beide Spulen im Perimeter befinden.

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.

Sollte diese um mehr als 0.2V abweichen, so kann diese mit den Konstanten

#define BATTERYFACTOR_BS    11.0f   //Entspricht (100+10)/10 Voltagedivider
#define DIODEDROPVOLTAGE_BS  0.4f

justiert werden. Diese Konstanten sind in batterySensor.h definiert.

Berechnet wird die Spannung in batterySensor.h folgendermaßen

sensorValue = aiBATVOLT.getVoltage(); 
float readVolt = sensorValue * BATTERYFACTOR_BS + DIODEDROPVOLTAGE_BS; // The diode sucks 0.4V

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 Vorgabe 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 von 150 angesteuert. 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. Das Rad sollte sich auf jeden Fall noch bei einer PWM von 50 (besser weniger) drehen.

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 3900Hz. Wenn man die Originalwerte verwenden möchte, muss man nachfolgende Zeilen in pinman.cpp abändern.

#define PWM_FREQUENCY 3900
#define TC_FREQUENCY 3900

Achtung: Wenn die PWM zu hoch gesetzt wird, z.B. 18000Hz, dann drehen sich die Räder bei niedriger PWM von z.B. 60 nicht mehr. Es kommt dann ein Fehler, dass bei Vorgegebener PWM von 60 die Geschwindigkeit 0 ist.

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 und damit auch das Geradeausfahren des Roboters. Für jedes Rad gibt es einen Service also insgesamt zwei Services. Der Service berechnet intern 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ätzlich ist die Konstante CONF_RADUMFANG_CM wichtig, damit die Berechnung für das Fahren eines bestimmten Weges in cm stimmt.

Da am Anfang in der config.h die 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 (Achtung, das USB Kabel sollte lang genug sein. Am besten eine Verlängerung verwenden);

Zurücklegen einer bestimmten Streck in cm

pc.cm,60,60,30,30     Fahre 60cm vorwärts mit der Geschwindigkeit von 30%

pc.cm,-60,-60,30,30   Fahre 60cm rückwärts mit der Geschwindigkeit von 30%

Drehen eines bestimmten Winkels. Voraussetzung: CONF_ENCTICKSPERREVOLUTION, CONF_RADUMFANG_CM, und CONF_DISTANCE_BETWEEN_WHEELS_CM sind richtig konfiguriert.

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 falsch 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.

Wenn das PCB1.3 verwendet wird, wird hier der Mähmotorstrom vermutlich falsch angezeigt. Siehe dazu: Mähmotorstrom einstellen in Tune Up Dies kann später durchgeführt werden und ist für den ersten Mähbetrieb nicht so wichtig.

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 wieder empfangen wird. 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_COIL_INVERSE		true
#define CONF_RIGHT_COIL_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_COIL_INVERSE und CONF_RIGHT_COIL_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_COIL_INVERSE/CONF_RIGHT_COIL_INVERSE findet in der Software später statt. Wichtig ist, das CONF_LEFT_COIL_INVERSE und CONF_RIGHT_COIL_INVERSE so konfiguriert werden, dass per.show innerhalb des Perimeters positive Amplituden anzeigt.

Konfiguration Bluetooth

Wurde das Modul bereits mit 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 dieser 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.

Also los: Platine stromlos schalten (auch USB vom DUE abziehen). Knopf auf BT Modul drücken und gedrückt halten. Platine anschalten. Das BT Module sollte nun alle 2Sek blinken.

Knopf loslassen. USB an den DUE wieder anschließen. Das BT Modul sollte immer noch im 2Sek. Takt blinken.

Nun als erste mit bt.show versuchen, ob das BT Modul gefunden wird:

bt.show

Wenn erfolgreich gefunden:

bt.set

eingeben. Das BT Modul wird konfiguriert.

Einstellen Arduino Central

Die Software läuft auf einem Android Mobilephone oder Tablet. Arduino Central kann aus dem Play Store heruntergeladen werden. Eine andere Software die auch funktioniert ist Serial Bluetooth Terminal.

In Arduino 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 Character 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.

Das USB Kabel abziehen und eine Verbindung mit Arduino Central herstellen.

Roboter in die Schleife stellen. Mit per.show nochmal das Perimetersignal überprüfen. Mit h oder show.show Ausgabe deaktivieren.

A für Auto eingeben 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.

TUNE UP

Konfiguration der Bumper an den Bumperanschlüssen

Das original Ardumower Chassis liefert keine standardmäßige Lösung für Bumper mit. Da die meisten Anwender sich hier eigene Lösungen schaffen, bietet die Software entsprechende Optionen an, die Bumper über die vorgesehenen Pins abzufragen.

Zum aktivieren der Bumper muss in der config.h folgende Zeile konfiguriert werden:

#define CONF_DISABLE_BUMPER_SERVICE    false

Zum Testen der Bumper kann man den Befehl bumper.show verwenden. Der Bumper Service gibt dann auf der Konsole oder dem Mobile Phone seine Aktivität aus, je nachdem von wo dieser Befehl gesendet wurde.

bumper.show

Die Bumper Pins sind standardmäßig als Eingänge mit Pullup Widerstand konfiguriert. Das bedeutet, der Eingang ist standardmäßig auf HIGH, wenn der Pin nicht auf GND gezogen wurde.

Der Bumperservice kann mir folgenden Parametern in der config.h konfiguriert werden:

Verwenden des linken oder/und rechten Bumpers

#define CONF_USE_LEFT_BUMPER            true     // left bumper is used
#define CONF_USE_RIGHT_BUMPER           true     // right bumper is used

Festlegen, ob der Bumper aktiv ist, wenn der Pin auf GND gezogen wird:

#define CONF_LEFT_BUMPER_LOW_ACTIVE     true     // left bumper is activated when pin is low
#define CONF_RIGHT_BUMPER_LOW_ACTIVE    true     // right bumper is activated when pin is low

Wenn man eine linken und einen rechten Bumper verwendet, gibt es noch die Möglichkeit zu konfigurieren, dass die Drehrichtung nach zurückfahren vom aktivierten Bumper bestimmt wird. D.h. dass wenn der linke Bumper betätigt wurde, der Roboter sich dann nach dem Zurückfahren rechts dreht.

#define CONF_ESCAPEDIR_DEPENDING_ON_BUMPER false  // if set to true, the robot rotates in the opposite direction of the activated bumper. If false, the escape direction is random.
                                                  // only set to true if you use a bumper for left and a bumper for right.

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.

Möchte man die Pullupwiderstände ausschalten, müssen die Zeilen folgendermaßen geändert werden

DigitalIn diBumperL(pinBumperLeft, false);

DigitalIn diBumperR(pinBumperRight, false);

Charge Service

Der Charge Service stellt dem BHT die Charge Voltage und den Charge Current zur Verfügung. Er enthält Funktionen zum Ein-/Ausschalten des Laderelais.

Anmerkung:
Wenn den Mower ausgeschaltet ist (also Batterie nicht angeklemmt) und dann an P42 Charger eine Ladespannung angeschlossen wird,
wird das Board über D73 direkt mit Spannung versorgt. Das Problem ist, das die Kondensatoren auf dem Board keine Spannung haben und beim Anklemmen einen Kurzschluss liefern. Dann wird eine 1,6A Sicherung in EF1 durchschlagen.
Daher sollte EF1 5A betragen.
Ich habe bei mir die D73 entfernt, da ich diese nur dann für sinnig halte, wenn die Batterie so leer ist, dass das Board und Relay nicht mehr mit der Batterie funktioniert. Falls dies mal wirklich 
passiert, werde ich die Batterie direkt mit dem Ladegerät laden. Sowas sollte nur im Fehlerfall passieren und nicht die Regel sein (Ich möchte aber niemanden überreden dies auch zu tun).
Weiterhin hat die D73 ein anders Potential auf der Hinterseite, als die Dioden die hinter dieser eingelötet sind. Da ist es sinnig, diese mit Heißkleber zu trennen, nicht das diese aneinander geraten.

Im Folgenden wir beschrieben, wie man den Roboter laden kann

Selbstständiges Fahren in die Ladestation

Wenn der Roboter in die Ladestation fährt, ist das Laderelais ausgeschaltet. Zu diesem Zeitpunkt liegt nur die Spannung der Ladestation an den Kontakten. Hat der Roboter dies festgestellt, stoppt er, wartet zwei Sekunden und überprüft die Ladespannung nochmal. Wenn diese OK ist, fährt er 3cm vorwärts, 3cm rückwärts und wieder 2cm vorwärts. Dies dient dazu die Verbindung zu den Ladekontakten zu optimieren (die aktuell als Schleifkontakte ausgeführt sind). Danach wird das Relay eingeschaltet und die Ladespannung erneut geprüft. (Dieses Verhalten kann ohne großen Aufwand im BHT umprogrammiert werden.) Das Relay bleibt solange angezogen und damit die Batterie mit dem Ladegerät verbunden, bis der Roboter den Befehl bekommt zu einem Bereich (area) zu fahren oder der Roboter in den manuellen Mode geschaltet wurde oder in den auto Mode geschaltet wird.

Verwenden ohne Ladestation

Um den Roboter zu laden sollte dieser sich im Manual mode befinden (Befehl M eingeben). Danach kann man mit charge.relay,1 das Relay einschalten und mit charge.relay,0 das Relay ausschalten. Das Relay schaltet automatisch aus, wenn man den Auto Modus aktiviert. Das Relay schaltet nur ein, wenn an den Ladekontakten die Ladespannung anliegt!. Eine andere Möglichkeit ist, die Ladekontakte im ausgeschaltetem Zustand anzuschließen und den Roboter dann einzuschalten. Der Roboter geht dann in den Auto mode uns schaltet das Behaviour Charging Station ein. Damit denkt er nun, er ist in der Ladestation.

Einstellen in die Ladestation

Hier den Roboter im ausgeschalteten Zustand in die Ladestation stellen, so dass die Ladekontakte Kontakt haben. Dann einschalten. Der Roboter geht dann in den Auto mode in das Behaviour Charging Station. Damit denkt er nun, er ist in der Ladestation, schaltet das Relais ein und lädt.

Um den Chargingservice zu aktivieren inder config.h CONF_DISABLE_CHARGE_SERVICE auf false setzen und Software neu aufspielen.

#define CONF_DISABLE_CHARGE_SERVICE	false

Manuelles Testen:

Den Befehl

charge.show

eingeben. Damit werden die Spannungen und Ströme kontinuierlich angezeigt. Aktuell sollte alles mit 0 angezeigt werden.

Ladegerät an P42 oder Ladekontakte anschließen.

Nun sollten die Chargevoltage (CV) angezeigt werden.

Relay einschalten:

charge.relay,1

Damit fließt nun ein Strom vom Ladegerät zur Batterie und ein Charge Current wird angezeigt (CC).

Relay ausschalten.

charge.relay,0

Testen im ausgeschaltetem Zustand über die Konsole:

Roboter einschalten und USB anschließen. Warten bis Software hochgelaufen ist. Ladekontakte verbinden. Serielle Konsole öffnen. Der DUE startet neu. Das Relay sollte angezogen werden und die Konsolenausgabe beim Booten sollte "Charging station detected" anzeigen. Der Roboter hat nun in das Chargingbehaviour geschaltet.

M eingeben um wieder in manuellen mode zu gelangen und das Relay abzuschalten.

Watchdog

Der Watchdog dient ausschließlich zur Sicherheit. Falls sich die Software aufhängt, soll der Watchdog verhindern, dass der Roboter unkontrolliert weiterläuft. Der Watchdog ist hardwaretechnisch im DUE realsiert. Er wird in der config.h mit

#define CONF_ENABLEWATCHDOG  true

aktiviert.

Jedesmal wenn der Loop durchlaufen wird, wird der Watchdog mit dem Funktionsaufruf watchdogReset(); reseted. Wenn watchdogReset(); innerhalb von 3 Sek. nicht aufgerufen wird (weil die Software irgendwo hängt), wird der DUE neu gestartet, die Motoren gestoppt und die Software geht in den Modus Manual.

Anmerkung: Da die Variablen der Firmware beim Reboot neu initialisiert werden, ist es schwer herauszufinden, was die Ursache des Fehlers ist. Der Mower bleibt einfach stehen, und man wundert sich beim Öffnen der BT Verbindung, das alles in Ordnung ist und kein Fehler ausgegeben wird - außer das die Software im Manual Mode ist.

Unterspannungsabschaltung

Die Unterspannungsabschaltung dient dazu zu verhindern, dass die Batterie unter eine bestimmte Spannung fällt und dann Tiefen entladen wird. Die Umsetzung der Unterspannungsabschaltung ist im Batterie Service implementiert. Voraussetzung ist, das Hardwareseitig der Jumper 8 UV-Abschaltung auf PCB 1.3 auf Auto gestellt ist. Wenn man dann Spannung auf das Board gibt, bekommt dieses erstmal keinen Strom. Daher muss beim Einschalten der Spannung die UV-Abschaltung mit dem P20 Button überbrückt werden. Dann bekommt das PCB1.3 Spannung. Dieser Button sollte so für 4 Sekunden gehalten werden. Dann übernimmt die Software die Steuerung der UV-Abschaltung. Der P20 Button muss danach wieder offen sein, ansonsten kann die Software die Spannung nicht abschalten.

In der config.h ist die Schwelle eingestellt, bei der die Spannung abgeschaltet wird

#define CONF_VOLTAGE_SWITCHOFF_BS  21.7f

Wenn die Batteriespannung für eine Minute unter diese Spannung abfällt, wird die Spannung zum PCB1.3 und den Motoren abgeschaltet. Das gesamte PCB1.3 ist dann dunkel.

Möchte man die Unterspannungsabschaltung überbrücken, kann man Jumper 8 auf Dauer-An stellen oder P20 überbrücken. Ich habe am P20 einen Ein-/Ausschalter angeschlossen, so das ich für Testzwecke diesen überbrücken kann. Der Jumper 8 steht weiterhin auf Auto.

I2C Bus

Der I2C Bus kann mit dem Befehl i2c.scan gescannt werden. Es werden dann alle gefundenen Adressen angezeigt.

i2c.scan

Die Adressen des RTC Moduls und des EEPROM können in der hardware.cpp angepasst werden. Zur Zeit sind die Standardadressen konfiguriert:

byte DS1307_ADDRESS = B1101000;
byte AT24CX_ADDRESS = B1010000;

RTC

Das RTC Modul wird zur Zeit nicht verwendet. Es ist vorgesehen, später dieses für einen zeitlichen Mähstart zu verwenden. Das RTC Modul kann aber bereits programmiert und getestet werden.

Das RTC Modul wird mit folgender Zeile in der config.h aktiviert:

define CONF_DISABLE_EEPROM_SERVICE  false

Es stehen folgende Befehle zur Verfügung:

rtc.show          //show rtc values every rtc read (10sec)
rtc.config        //show rtc service config
rtc.find          //tries to find RTC and show result
rtc.set,8,17,3,25,01,2017 //set rtc time=8:17 dayOfWeek=3 date=25.01.2017

EEPROM

Es wird das EEPROM auf dem RTC verwendet. Zur Zeit wird es verwendet um Statistiken abzuspeichern. Es werden folgende Statistiken abgespeichert: Gesamte Mähzeit, Gesamte gefahrene Strecke, Gesamte Anzahl an Rotationen, Anzahl Ladevorgänge.

Die Verwendung des EEPROM wird mit folgender Zeile in der config.h eingeschaltet:

#define CONF_DISABLE_EEPROM_SERVICE false

Folgende Befehle stehen für das EEPROM zu Verfügung:

eep.config           //show EEPROM service config
eep.u8t,10           //show uint8_t at address 10
eep.s32t,10          //show int32_t at address 10
eep.f,10             //show float at address 10
eep.set.u8t,10,7     //write value uint8_t=7 to address=10 
eep.set.s32t,10,1234 //write value int32_t=1234 to address=10 
eep.set.f,10,7.3     //write value float=7.3 to address=10 
eep.erase            //erase the eeprom

Zum testen des EEPROM z.B. folgenden Befehl eingeben:

eep.set.f,10,7.3

Damit wird der float Wert 7.3 an die Adressen 10,11,12,13 in das EEPROM geschrieben.

Mit dem Befehl

eep.f,10

kann der Wert dann wieder ausgelesen werden.

Der Befehl eep.erase löscht die ersten 3 Pages des EEPROM. Die anderen Pages werden aktuell nicht gelöscht, da diese nicht verwendet werden.

eep.erase

Es ist sinnvoll das EEPROM nach dem enablen zu löschen, damit die Speicherzellen initialisiert werden.

Geschwindigkeit am Perimeter verlangsamen

Der Mower fährt mit einer Geschwindigkeit von 1200m/s. Um das Abbremsen beim Überfahren des Perimeters etwas sanfter durchzuführen, verringert der Roboter kurz vor dem Perimeter (ca. 20cm) die Geschwindigkeit.

Folgende Konstanten in der config.h beeinflussen das Erkennen nahe am Perimeter:

#define CONF_NEAR_PER_UPPER_THRESHOLD   80.0L    // Threshold of one coil where Perimetersignal is detected as near perimeter
#define CONF_NEAR_PER_LOWER_THRESHOLD   70.0L    // Threshold of the other coil where Perimetersignal is detected as near perimeter

Um festzustellen, ob der Roboter nahe am Perimeter ist, wird die Amplitude der linken und rechten Spule ausgewertet. Dazu ermittelt die Firmware die aktuelle maximale Amplitude über die gesamte Fahrzeit des Mower. Wenn nun die linke Spule eine Amplitude von 80% (CONF_NEAR_PER_UPPER_THRESHOLD) oder höher des Maximalwertes erreicht und die rechte Spule über 70% (CONF_NEAR_PER_LOWER_THRESHOLD) oder höher des Maximalwertes erreicht, so wird angenommen, dass der Roboter nahe am Perimeter ist. Das Gleiche gilt, wenn die rechte Spule 80% erreicht und die linke 70%.

Diese Werte sind abhängig von der verwendeten Spule und von der eingestellten Signalstätke des Sender und müssen daher ggf. nachjustiert werden.

Um dies zu justieren, den Befehl per.show eingeben während der Mower fährt.

per.show

Wenn er dann über den Perimeter fährt den gleichen Befehl eingeben oder h drücken. Dann in der Anzeige zurück scrollen und sich die Werte angucken.

Beispiel: !03, ML: 305 MR: 331 magMax:332 magMedL%: 73 magMedR%: 87

Die Werte magMedL%: 73 magMedR%: 87 zeigen hier die gemessene Prozentzahl der Spulen an. Hiernach dann CONF_NEAR_PER_UPPER_THRESHOLD und CONF_NEAR_PER_LOWER_THRESHOLD einstellen. Es sollten mehrere Versuche zur Bestimmung durchgeführt werden. Besser etwas früher langsamer werden, als zu spät. Der Unterschied zwischen High und Low wurde eingeführt, da die Spulen nicht den gleiche Wert haben, z.B. wenn der Mower schräg oder fast parallel zum Perimeter fährt.

Es kann sein, dass magMedL% und magMedR% mehr als 100% anzeigen. Dies beruht auf der Art der magMax Ermittlung und ist OK.

Die Berechnung ist in der Funktion bool TPerimeterThread::isNearPerimeter() in der Datei perimeter.cpp hinterlegt.

Mähmotorstrom einstellen

Es ist zu berücksichtigen, dass die Ausgänge des Mähmotordrivers auf dem PCB1.3 zusammengeschaltet wurden.

Bei mir wird bei einer PWM von 255 am Mähmotor fast kein Strom gemessen. Habe dann mal mit einem Multimeter nachgemessen. Am M2 FB liegen tatsächlich im vollen Leerlauf nur 0.04V an. Richtig wären ca. 0.22V da der Motor hier 0,41A zieht. Am M1 FB1 messe ich eine Spannung von 0.007V. Es scheint so, dass durch das parallel Schalten die Strommessung nicht mehr stimmt. Man könnte meinen diese sollte sich halbieren. Ist aber nicht so.

Eine Zusammenschaltung der beiden MC33926 wird vom Hersteller nicht ausdrücklich empfohlen und liefert scheinbar eine falsche Strommessung.

https://www.nxp.com/docs/en/application-note/AN4833.pdf

Zitat:"If two independent H-bridges are used (separate MC33926 or similar), the load sharing may not be quite as even,

resulting in a reduction in maximum drive capability. This configuration will latch any fault until the EN pin is toggled."

Ich habe dann vom Mowmotortreiber die Pins M1 OUT1 und M1 OUT2 abgeklemmt (gebogen und neben die Buchsenleist geführt, so das diese keinen Kontakt haben). Und siehe da, die Strommessung funktioniert richtig, wobei unter 1A diese nicht wirklich genau ist. Erst ab 1A ist der Wert zuverlässig.

Forumseintrag: https://www.ardumower.de/index.php/de/forum/ardumower-1-3-mainboard/1461-pcb1-3-motorstrom-wird-vermutlich-falsch-gemessen#13904

Wenn M1 OUT1 und M1 OUT2 nicht abgeklemmt werden wird der Strom zu gering angezeigt. Daher muss der scale Wert für die richtige Strommessung in der setup Funktion der Klasse TMowMotorSensor in der Datei mowmotorSensor.h angepasst werden. Der scale factor sollte bei Strömen um die 1A oder mehr eingestellt werden. D.h. die Mähscheibe muss belastet werden, wenn man mit dem Multimeter den Strom misst.

Wenn M1 OUT1 und M1 OUT2 abgeklemmt werden ist der Faktor den ich durch Messen eingestellt habe vermutlich einigermaßen richtig. Dies kann aber nur durch Nachmessen von Stromstärken ab 1A überprüft werden.

Der gemessene Strom und die Wattzahl wird mit dem Befehl

mot.curm

angezeigt.

Langsamer fahren, wenn Mähmotor belastet

Wenn der Mähmotor belastet ist, wird der Mower langsamer.

Ab welcher Wattzahl des Mähmotors langsamer gefahren wird, wird in der config.h mit dem Parameter

#define CONF_MOW_MOT_UNDER_LOAD 30.0f

eingestellt. Wenn der Mähmotor über 30W benötigt, wird die Geschwindigkeit verlangsamt.

Die aktuelle Watt Zahl beim Mähen kann mit dem Befehl

mot.curm

angezeigt werden. Danach kann der Wert nach eigenem Ermessen eingestellt werden.

Achtung, die Motordriver liefern eine genaue Strommessung erst ab 1A (lt. Datenblatt 0.5A). D.h. Werte wo der Strom unter 1A angezeigt wird sind ungenau und sollten nicht verwendet werden. Die Genauigkeit beträgt lt. Datenblatt bei einem Strom von über 0.5A +-20%.

Der Code für die Geschwindigkeitseinstellung befindet sich in der Klasse class TCruisePerimeterNear : public Node in der Datei bCruise.h.

Weiterhin ist zu berücksichtigen, dass die Ausgänge des Mähmotordrivers zusammengeschaltet wurden. Dies wird vom Hersteller nicht empfohlen und liefert eine falsche Strommessung.

Perimeter Tracking

Hier wird der Perimetertrackingalgorithmus erklärt, mit dem Ziel genügend Informationen zu liefern, dass dieser durch den Anwender auf sein Chassis optimiert werden kann. Es fiel die Wahl auf diesen Algorithmus, da dieser unabhängig von der Perimeteramplitude ist. Weiterhin ist der Algorithmus extrem stabil und nicht von seinem Vorhaben abzubringen dem Perimeter zu folgen. Video Beispiel

Als Perimetertrackingalgorithmus wird ein one bounce Algorithmus verwendet. Der Algorithmus fährt counter clockwise den Perimeter ab. Dabei bounced die rechte äußere Spule immer gegen den Perimeter von außen. Wenn diese gegen den Perimeter stößt, wird die Spule erstmal vom Perimeter abgestoßen. Danach bewegt sich die Spule in einem Bogen zum Perimeter hin. Video Beispiel

Der Algorithmus ist in der Datei: bGotoAreaX.h Klasse: TlineFollow implementiert. Die folgende Darstellung zeigt die if Abfragen in einer anderen chronologischen Reihenfolge zur besseren Erklärung, als diese tatsächlich im Programmcode stehen. Daher nicht verwirren lassen, wenn man den Programmcode ansieht.

Ablauf: Die rechte Spule befindet sich immer außerhalb des Perimeter. Wenn diese den Perimeter nach innen überschreitet, wird als erstes eine aggressive Drehung clockwise ausgeführt mit:

bb.motor.L->setSpeed((bb.cruiseSpeed + 5));
bb.motor.R->setSpeed((bb.cruiseSpeed - 20));

Sollte die Spule dann nach 1 Sekunde nicht außerhalb sein, wird die Drehung aggressiver:

if ((millis() - lastTransitionTime) > 1000) { // If more than 1sec inside rotate aggressive
  bb.motor.L->setSpeed((bb.cruiseSpeed + 10)); 
  bb.motor.R->setSpeed(-25); 
}

Sollte die Spule dann nach 1,5sek Sekunde nicht außerhalb sein, wird gedreht

if ((millis() - lastTransitionTime) > 1800) {
  bb.cruiseSpeed = 25;
  bb.driveDirection = DD_ROTATECW;
  bb.motor.L->setSpeed(25);
  bb.motor.R->setSpeed(-25);

}

Wenn die Spule nun nach außen gedreht wurde, fährt der Roboter eine seichte Kurve counter clockwise, bis er den Perimeter erreicht. Für die Berechnung der Kurve, wird ein Integral verwendet, das mit dem Faktor Ki gesteuert werden kann. (Anmerkung: Das Integral wird auf 0 gesetzt, sobald die Spule den Perimeter überschreitet.)

integral = integral + (Ki*error); // der Wert error ist eine Konstante und hat den Wert -1 wenn die Spule außerhalb des Perimeters ist.
double Output = integral;

Das Fahren der Kurver erfolg dann folgendermaßen: Dadurch, dass das Integral größer wird, wird die Kurve mit zunehmender Integralgröße kleiner.

bb.motor.L->setSpeed((bb.cruiseSpeed + Output));  // beachte: Output ist negative
bb.motor.R->setSpeed((bb.cruiseSpeed));

Wenn nach 1 Sekunde der Perimeter nicht überschritten wurde, wird aggressiver die Kurve gefahren;

if ((millis() - lastTransitionTime) > 1000) { // If more than 2sec Outside rotate aggressive
  bb.motor.L->setSpeed((bb.cruiseSpeed + Output));
  bb.motor.R->setSpeed((bb.cruiseSpeed +5));
}

Wenn nach 1.5 Sekunde der Perimeter nicht überschritten wurde, wird noch aggressiver die Kurve gefahren:

if ((millis() - lastTransitionTime) > 1500) { // If more than 2.8sec Outside rotate more aggressive
  bb.motor.L->setSpeed((bb.cruiseSpeed + Output));
  bb.motor.R->setSpeed((bb.cruiseSpeed +10));
}

Wenn nach 2 Sekunde der Perimeter nicht überschritten wurde, wird gedreht:

if ((millis() - lastTransitionTime) > 1500) { // If more than 2.8sec Outside rotate more aggressive
  bb.motor.L->setSpeed((bb.cruiseSpeed + Output));
  bb.motor.R->setSpeed((bb.cruiseSpeed +10));
}
if ((millis() - lastTransitionTime) > 2000) { // If more than 3.5sec Outside rotate full
  bb.cruiseSpeed = 25;
  bb.driveDirection = DD_ROTATECC;
  bb.motor.L->setSpeed(-25);
  bb.motor.R->setSpeed(25);
}

Sollte die linke Spule außerhalb des Perimeters sein, wird sofort counter clockwise gedreht:

if (bb.perimeterSensoren.isLeftOutside() == true) {
  bb.cruiseSpeed = 25;
  bb.driveDirection = DD_ROTATECC;
  bb.motor.L->setSpeed(-25);
  bb.motor.R->setSpeed(25);
  waitForRightInside = true;
}

Zum Einstellen des Algorithmus sollte als erstes versucht werden eine gerade Strecke zu fahren. Dabei ist das erste Rausdrehen zu konfigurieren und Ki für den Bogen zum reinfahren.

Testen des Algorithmus: Den Roboter auf den Perimeter stellen, so das die rechte Spule außen ist und die linke Spule innen. Mit dem Befehl

tpt     //test perimeter tracking to dock. Mower stands on perimeter

das Perimetertracking starten. Der Befehl

stoppt den Test.

Mit dem Befehl

set.lfki,1.1

kann der Ki Wert während des Testen eingestellt werden. Der Wert muss wenn zufriedenstellend ermittelt, in der Klasse TlineFollow im Konstructor zugewiesen werden.

Wenn die Antriebsräder hinten sind, ist der Abstand zu den Spulen größer und die Spulen können außerhalb der Mitte angeordnet werden. Bei dem original Ardumower Chassis sind die Antriebsräder vorne. Hier muss die rechte Spule nah der Mitte angeordnet werden, ansonsten ist die Drehung zu asymmetrisch. Aufgrund der kurzen Distanz ist vermutlich auch das Bounce-Intervall von 1 Sek. zu verkürzen, so dass auf gerader Strecke vermutlich alle 0.3Sek gebounced werden muss.(aktuell nicht getestet)

Schnelle Rückkehr

Auf dem Rückweg zu Ladestation kann es sein, dass der Mower an einer Stelle auf das Perimeter fährt, so dass er den gesamten Perimeterdraht bis zur Ladestation abfahren muss. Um diesen Weg zu verkürzen, gibt es die schnelle Rückkehr. Der Anwender muss dazu das Perimeterkabel so verlegen, dass es ein Viereck ergibt. Diese Viereck wird dann vom Roboter beim Perimetertracking erkannt. Wenn er das Viereck erkannt hat, dreht er sich um 90 Grad vom Perimeter weg in den Innenbereich, und fährt auf die andere Seite des Rasens. Wenn er dort das Perimeterkabel entdeckt, nimmt er von dieser Stelle das Perimetertracking wieder auf.

Um die schnelle Rückkehr zu aktivieren muss folgende Option in config.h gesetzt werden.

#define CONF_DISABLE_FAST_RETURN   false

Für das Viereck hat sich folgende Abmessung als günstig herausgestellt. Es kommt allerdings auch auf die Abmessungen des Mowers an. Der Mower sollte bei dem Tracking in den Drehmodus kommen. Drehen bei der ersten Linkskurve. Dann drehen bei der nächsten Rechtskurve. Dann Linkskurve fahren. [Video:https://youtu.be/ipdVJzQn5Tc]

Das Viereck kann auf zwei Arten verlegt werden. Einmal mit Ecken und einmal mit abgeflachten Ecken. Die Abgeflachten Ecken sind dazu da, dass der Mower an der Ecke besser erkennt, in welche Richtung er sich vom Perimeter wegdrehen soll, wenn er fast parallel zum Perimeter fährt. Dadurch ist die Perimeternahe Spule als erstes draußen und er dreht vom Perimeter weg anstatt zum Perimeter hin. Das ist notwendig, falls hinter dem Perimeter ein Beet kommt in das sich der Mower reindrehen könnte.

Beispiel, wie ich meine Vierecke angebracht habe

Die Erkennung ist abhängig von der Position der Spulen und vom Abstand der Spulen zum Antriebsrad.

Die Implemetierung steht in der Datei: bPerimeterTracking.h Klasse: class TfindTriangle : public Node

Die Erkennung erfolgt anhand des jeweils gedrehten Winkels. Sie wurde mit einer Statemachine umgesetzt.

Den Ablauf der Statmachine und die berechneten Winkel kann man sich mit dem Befehl bht.tri anzeigen lassen.

bht.tri

Die entsprechenden Winkel und maximal Distanzen muss man dann im Code in der Klasse: class TfindTriangle anpassen. Im Folgenden die leicht ausgedünnte Klasse um einen besseren Überblick zu bekommen. Die Zeilen errorHandler.setInfoNoLog(..) sind die Ausgabe, wenn der Befehl bht.tri aktiviert wurde. Diese wurden hier mit aufgeführt um die Ausgabe besser interpretieren zu können.

 virtual NodeStatus onUpdate(Blackboard& bb) {
   ...

Der gefahrene Winkel wird vor dem Case Statement alle 500ms ermittelt.

   //============================================
   // Calculate driven angle every 500ms.
   //============================================
   if (millis() - lastRunAngleCalculation >= 500) {
     lastRunAngleCalculation = millis();
     ... 
     angle = (cmL - cmR)  * 57.2957795f / CONF_DISTANCE_BETWEEN_WHEELS_CM;
     if (flagShowFindTriangleStates) {
       errorHandler.setInfoNoLog(F("Winkel: %f cmL %f cmR %f\r\n"), angle, cmL, cmR);
     }
   }

Abfrage der States

   // Check for left curve / right curve / second left curve
   switch (state)
   {

Im case 0 wird nach eine Linkskurve gesucht. Ein negativer Winkel bedeutet eine Linkskurve/-drehung. Wenn der Winkel z.B. <-25 Grad ist, wurde diese gefunden und es wird in den case 1 geschaltet.

   case 0:  // search for left curve
     if (angle < -25) { 
       if (flagShowFindTriangleStates) {
         errorHandler.setInfo(F("!03,s0 set state = 1 Left turn found angle: %f ms: %lu\r\n"), angle, millis());
       }
       bb.motor.startDistanceMeasurementTriangle();
               ...
       state = 1; // Activate triangle searching
     }
     break;

In case 1 wird ständig überprüft, ob eine bestimmte Strecke nach der Linkskurve überschritten wurde. Im Beispiel 55cm. Wenn ja, ist das zu weit und es wird wieder zurück in den case 0 gesprungen, da es nicht sein kann, das die erste Strecke so lang ist. Wenn innerhalb der Strecke von 55cm dann ein Winkel > 50 gefunden wurde, wird in den case 2 gesprungen. Ein positiver Winkel bedeutet eine Rechtskurve/-drehung.

   case 1: // search for right turn
     distance = bb.motor.getDistanceInCMForTriangle();
     if (distance > 55) {
       state = 0;
       if (flagShowFindTriangleStates) {
         errorHandler.setInfo(F("!03,s1 set state = 0 distance %f > 55 ms: %lu\r\n"), distance, millis());
       }
     }
     else if (angle > 50) { 
       if (flagShowFindTriangleStates) {
         errorHandler.setInfo(F("!03,s1 set state = 2 angle %f distance %f < 50\r\n"), angle, distance);
       }
       bb.motor.startDistanceMeasurementTriangle();
       ...
       state = 2;
     }
     break;

In case 2 wird als erstes wieder die gefahrene Distanz nach dem Rechtswinkel überprüft. Solange die Distanz von 50 cm nicht überschritten wurde, wird auf eine Linkskurve geprüft. Wenn der Winkel <-25 Grad ist, wurde diese erkannt und es wird in den State 3 gesprungen.

   case 2:  // search for second left curve
     distance = bb.motor.getDistanceInCMForTriangle();
     if (distance > 50) {
       state = 0;
       if (flagShowFindTriangleStates) {
         errorHandler.setInfo(F("!03,s2 set state = 0 distance %f > 50 ms: %lu\r\n"), distance, millis());
       }
     }
     else if (angle < -25) {
       if (flagShowFindTriangleStates) {
         errorHandler.setInfo(F("!03,s2 set state = 3 angle %f distance %f < -25\r\n"), angle, distance);
       }
       bb.motor.startDistanceMeasurementTriangle();
        ...
       state = 3;
     }
     break;

Case 3 gibt BH_SUCCESS an den BHT zurück und es wird auf die andere Seite des Rasens gefahren.

   case 3:
     if (flagShowFindTriangleStates) {
       errorHandler.setInfo(F("!03,s3 set state=0  Cross Lawn Activated\r\n"));
     }
     state = 0;
     return BH_SUCCESS;
     break;

      ...
   }
   return BH_RUNNING;
 }

Testen des Algorithmus: Den Roboter auf den Perimeter stellen, so das die linke Spule außen ist und die rechte Spule innen. Mit dem Befehl

tpt     //test perimeter tracking to dock. Mower stands on perimeter

das Perimetertracking starten.

Mit dem Befehl

bht.tri

die Ausgabe der Viereckserkennung starten. (tri steht für triangle, da vorher wurde ein Dreieck zur Erkennung verwendet wurde)

Mähzonen zwischen aneinander liegenden Flächen

Mähzonen können eingerichtet werden zwischen aneinander liegenden Flächen die eine direkte Verbindung haben. Dazu wird das Perimeterkabel zwischen den Flächen in einem Abstand von ca. 13cm verlegt. Es wird eine Lücke von ca. 30cm zu dem gegenüberliegenden Perimeterkabel gelassen. Dadurch ist die Wahrscheinlichkeit geringer, dass der Roboter auf die andere Fläche fährt.

Siehe Bild:

Beispiel, Mähzonenabgrenzung
Abmessungen

(Im obigen Bild ist es normal nicht notwendig Mähzonen einzurichten, da der Roboter durch den Algorithmus relative gut alle Bereiche des Rasens abdeckt.)

Der Abstand des Bereichsabgrenzungskabels zum gegenüberliegenden Perimeterkabel (hier 30cm Abstand) kann durch Tests optimiert werden. Der Abstand hängt von der Funktionalität des Perimetertracking ab. Zum einen von der Position der linken Spule beim Tracken des gebenüberliegenden Kabels, sowie das Tracking des Bereichsabgrenzungskabels selber.

Da der Roboter voreingestellt mit den Spulen ca. 20cm über das Kabel fährt, kann es sein, dass er mit den Spulen dann innerhalb des nächsten Bereichs stehen bleibt.

Das Anfahren eines Bereiches aus der Ladestation heraus erfolgt mit dem Befehl:

area,x     //wobei x der zurückzulegende Weg in m ist.

Wurde die angegebene Strecke x am Perimeter zurückgelegt, fängt der Mower an zu mähen.

Die gefahrene Distanz auf dem Perimeter kann mit dem Befehl

show.distance

angezeigt bzw. gemessen werden.

Achtung: Man sollte sich genau merken, wo die Kabel für die Mähzonenabgrenzung liegen für den Fall, dass der Rasen vertikutiert wird.

Verlegung des Perimeterkabels an Ecken

Der Mower bestimmt in welcher Richtung er sich am Perimter dreht anhand der zuerst rausgefahrenen Spule. Daher ist es wichtig die Ecken nicht im 90 Grad Winkel zu verlegen. Wenn der Mower z.B, mit der rechte Spule nahe am Perimeter langfährt und dann an der Ecke rausfährt, sollte auch die rechte Spule als erstes aus dem Perimeter fahren.

In den folgenden Bildern sind drei Beispiele zu sehen, wie Ecken verlegt werden sollten.

Außenecke
Außenecke
Innenecke

Temperatur Sensor

Es werden die Temperatursensoren DHT11/DHT21/DHT22/AM2301 unterstützt. Aktuell wurde aber nur mit dem Sensor DHT22 getestet. Der Temperatursensor wird mit dem dafür vorgesehenen Port des PCB1.3 verbunden.

In config.h wird der verwendete Temperatursensor konfiguriert:

#define DHTTYPE DHT22

Zum enablen des Services muss folgende Zeile konfiguriert werden:

#define CONF_DISABLE_DHT_SERVICE   false   // Disables temp sensor

Mit folgendem Befehl wird der Sensor ausgelesen:

temp.show

Im manuellen Mode wird der Sensor direkt ausgelesen. Es werden Temperatur, Luftfeuchtigkeit und die letzte gespeicherte Temperatur im Service angezeigt. Im auto mode wird nur die Temperatur die im Service gespeichert wurde angezeigt. Die Temperatur wird aktualisiert wenn der Mower über den Perimeter fährt und zum stehen kommt und mindestens 20 Sek. seit der letzten Messung vergangen sind.

Der DHT Service schaltet den Strom des PCB1.3 ab, wenn eine Temperatur von 50 Grad zwei mal gemessen wurde:

#define CONF_OVERHEATING_TEMP  50.0f   // if this temperature is measured, robot shuts down the complete power for security

Regen Sensor

Wenn der Roboter im AUTO Modus mäht und es anfängt zu regnen, fährt der Roboter in die Ladestation zurück. Der Regensensor wird mit dem dafür vorgesehenen Port des PCB1.3 verbunden. Die Empfindlichkeit des Regensensors, wird am Regensensor mit dem Poti eingestellt.

Zum enablen des Services muss folgende Zeile konfiguriert werden:

#define CONF_DISABLE_RAIN_SERVICE false   // Disables rain sensor

Der Regensensor wird ca. alle 1.7 Sekunden ausgelesen.

Das ausgelesene Ergebnis kann mit

rain.show

angezeigt werden.

Shutdown Service

Wenn der shutdown service aktiviert wird, schaltet dieser den Strom über die Undervoltageprotection ab. Wenn ein Raspberry PI an den USB Port angeschlossen ist kann

CONF_WAIT_FOR_PI_SHUTDOWN  = true

gesetzt werden. Dann wartet die Software 50 Sekunden bis zur Abschaltung. Es wird jede Sekunde $PwrOff und ein Countdown zu dem PI geschickt, so dass dieser herunterfahren kann.

Mit dem Befehl:

poweroff

kann der shutdown über die Benutzerschnittstelle oder vom PI aus aktiviert werden.

Der shutdown service wir auch von dem Batterie Service und dem Temperatur Service zum herunterfahren verwendet. Somit wird der PI informiert, dass er herunterfahren soll, wenn die Batteriespannung zu gering oder die Temperatur zu hoch ist.

GPS Service

Der GPS Service empfängt die Daten von dem GPS Modul.

Es gibt zwei Möglichkeiten diese Daten zu verarbeiten. Beide Möglichkeiten können parallel genutzt werden.

a) Die Empfangenen GPS Daten werden an das Raindancer Controlcenter weitergeleitet.
b) Die Empfangenen GPS Daten werden in der Raindancer Firmware ausgewertet. Man kann dann einen Bereich auf der Rasenfläche definieren. 
   Befindet sich der Mower in diesem Bereich wird angenommen, dass der Mower sich innerhalb der Perimeterschleife befindet. So besteht die Möglichkeit ein schwaches Perimetersignal auf größeren Flächen zu überbrücken.

Das GPS Modul wird an den dafür vorgesehenen Anschluss an das PCB1.3 angschlossen. Das GPS Modul sendet periodisch Daten an das PCB1.3. Falls keine Daten empfangen werden, bitte folgenden Artikel lesen. Es kann sein, dass RX3 und TX3 auf dem PCB1.3 falsch verdrahtet wurden. https://www.ardumower.de/index.php/de/forum/navigation-gps-odmetrie/1737-wait-for-gps-position-data

Senden an das Raindancer Controlcenter

Zum aktivieren des GPS Services muss folgendes konfiguriert werden:

#define CONF_DISABLE_GPS false

Für die erste Inbetriebnahme kann man folgende Parameter setzen:

#define CONF_GPS_PASS_THROUGH true
#define CONF_DEACTIVATE_GPS_CALCULATION true

Der Parameter #define CONF_GPS_PASS_THROUGH sagt der Firmware, dass alle empfangenen GPS Daten zum Controlcenter geschickt werden sollen.

Damit man diese Daten auf der Console angezeigt bekommt, muss folgender Befehl ausgeführt werden:

set.cco,1

Nun sieht man alle Daten die an das Controlcenter geschickt werden. Darunter auch die GPS Datensätze.

Mit folgendem Befehl stoppt man die Ausgabe:

set.cco,0

Standardmäßig schickt das GPS Modul mehrere Datensätze in einem 1 Sekunden Intervall. Diese Datensätze werden nicht alle benötigt und erzeugen einen Overhead. Es wird nur der Datensatz: $GPRMC bei NEO-6M und $GNRMC bei NEO-M8N benötigt. Daher gibt es die Möglichkeit, das Modul bei dem Starten der Raindancer Firmware so einzustellen, das es nur den benötigten Datensatz schickt und dies auch nur in einem 3 Sekunden Takt. Dazu wird folgender Parameter eingestellt:

#define CONF_INIT_GPS_WITH_UBLOX  true

Damit wird beim Hochfahren das Array const char UBLOX_INIT[] (steht in config.h) an das GPS Modul geschickt. Zum aktivieren bzw. deaktivieren muss man dann einzelne Zeilen ein- bzw. auskommentieren.

Aktivieren der internen Berechnung

Auch hier sollte #define CONF_INIT_GPS_WITH_UBLOX true verwendet werden. Zum aktivieren der internen Berechnung muss

#define CONF_DEACTIVATE_GPS_CALCULATION false

gesetzt werden. Bei dem NEO-6M Modul wird der Datensatz: $GPRMC verwendet. Bei dem NEO-M8N wird der Datensatz $GNRMC verwendet. Daher müssen je nach verwendetem Modul folgende Zeilen ein bzw. auskommentiert werden:

#define CONF_N_GPRMC_STR            "$GPRMC"    // GPS messagetype begin for $GPRMC for NEO-6M
//#define CONF_N_GPRMC_STR          "$GNRMC"    // GPS messagetype begin for $GPRMC for NEO-M8N

Mit

gps.show

kann man sich die berechneten Werte anzeigen lassen.

Falls man in UBLOX_INIT[] den Datensatz "GxGGA on" mit eingebunden hat, werden zusätzlich noch Quality, Satellites und Altitude angezeig. Diese werden aber nicht weiter verwendet.

Es besteht die Möglichkeit einen GPS Bereich zu Konfigurieren, in dem der Mower annimmt er ist im Perimeter falls hier das Perimetersignal für die Erkennung zu schwach ist.

Der Bereich wird als Polygon angegeben.

const float CONF_LAT_POLYGON_Y[] = { 54.083245f, 54.084068f,  54.084679f,  54.085623f,  54.084018f }; // Latitude polygon points
const float CONF_LON_POLYGON_X[] = { 10.447986f, 10.447055f,  10.446015f,  10.447120f,  10.44930f }; // Longitudinal polygon points
const int   CONF_NUMBER_OF_POLYGON_POINTS = 5;  // The number of the ploygon points

Jede Spalte gehört zu einem Polygonpunkt. Man kann in https://www.google.de/maps z.B. einen Punkt in die Suche eingeben: 54.08728,10.448400. Dann sieht man wo diese Koordinate ist. So kann man dann punkt für punkt sehen, wie das Polygon aufgebaut ist. Wichtig ist, dass mit CONF_NUMBER_OF_POLYGON_POINTS die Anzahl der Spalten richtig definiert ist. Es können 3 bis N Koordinatenpunkte eingegeben werden. Allerdings schlage ich vor nicht mehr als 8 Punkte zu verwenden, um die Berechnungszeit so gering wie möglich zu machen.

Um die Punkte zu ermitteln, kann man den Roboter an den entsprechenden Punkt stellen und gps.show eingeben. Dann wird z.B. folgendes angezeigt:

!03,$GPRMC,104503.00,A,5123.24690,N,00812.92063,E,0.094,,290718,,,A*72
!03,$GPRMC speed: 0.094000 course:0.000000
!03,$GPRMC lat: 54.08744800,N lon: 10.44867700,E
!03,$GPRMC date: 29.7.18 time: 11:45:3

Der Punkt kann dann aus der Zeile !03,$GPRMC lat: 54.08744800,N lon: 10.44867700,E entnommen werden. Hier für Latitude = 54.087448 und Longitude=10.448677.

Die Bereichserkennung wird mit

#define CONF_USE_GPS_POLYGON   true

eingeschaltet.

Es ist zu beachten, dass das GPS Signal eine toleranz von +-10m hat. D.h. man sollte weit genug vom Perimeter weg bleiben. Da das manchmal nicht geht, wurde noch der Parameter

#define CONF_PER_THRESHOLD_IGNORE_GPS   300

eingeführt. Dieser besagt, dass wenn die Amplitude vom Perimeter diesen Wert überschreitet, wird auf jeden Fall das Perimetersignal verwendet und nicht mehr durch das GPS Signal überschrieben, auch wenn der Mower im GPS Bereich ist. Der Wert 300 muss entsprechend den eigenen Anforderungen eingestellt werden.

Sicherheitshinweis: Falls das Perimetersignal ausfällt und der GPS Bereich den Perimeter überschreitet, wird der Mower den Perimeterbereich verlassen

Perimeter Sender

Es wird die original Ardumower Sender Hardware verwendet. Die Software wurde etwas abgeändert. Es wird ein 128 Bit Signal gesendet.

Folgendes Perimetersignal wird gesendet:

1, 1, -1, -1, -1, 1, -1, -1, 1, -1, 1, -1, -1, 1, 1, -1, 1, 1, -1, -1, 1, 1, -1, 1, 1, -1, 1, -1, 1, -1, -1, 1, -1, -1, 1, -1, 1, 1, -1, 1, -1, 1, -1, 1, -1, 1, 1, -1, -1, 1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, -1, -1, 1, -1,
-1, 1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, -1, 1, 1, -1, 1, -1, -1, 1, -1, -1, 1, 1, -1, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, -1, -1, 1, -1, -1, 1, 1, -1, 1, 1, -1, -1, 1

Die LEDs haben folgende Funktion (von links nach rechts):

1. 12V vorhanden
2. 5V vorhanden
3. Grün wenn der Interrupt läuft, der das Signal sendet ( rote LED nicht verfügbar). Aus wenn geladen wird.
4. Grün wenn ein Strom durch den Perimeter fließt, rot wenn keine Strom fließt (Perimeter unterbrochen) oder sehr wenig Strom. Aus wenn geladen wird.
5. Gelb der Roboter wird geladen. Perimetersignal ist ausgeschaltet.

Achtung: die LEDs 3 und 4 sind Duo LEDs. D.h. diese haben zwei Farben. Bei LED 3. ist die rote LED nicht ansprechbar, da auf dem Nano der falsche Pin hardwaretechnisch connected wurde. Desweiteren, können die LEDs falsch herum eingelötet worden sein. Dann wundert man sich z.B., dass LED 4. rot ist obwohl alles in Ordnug ist und ein Strom fließt. Oder eben LED 3. rot anzeigt, obwohl ich hier grün geschrieben habe.

Wenn der Sender an ist und der Roboter kehrt nach zwölf Stunden nicht in die Ladestation, schaltet der Sender das Signal ab. Dann entweder den Sender neu starten, oder den Roboter in der Ladestation laden.

Ladestation

Die Ladestationen werden gegen den Uhrzeigersinn angefahren.

Wird keine Ladestation verwendet, sollte

CONF_DISABLE_CHARGINGSTATION = true

eingestellt werden. Dann fährt der Mower bei geringer Batteriespannung zum Perimeter und bleibt stehen.

Kopfladestation

Wird eine Kopfladestation verwendet ist darauf zu achten , dass die Kontakte mindestens 3 cm nachgeben können wenn der Mower dagegen fährt. Besser wären 4 cm. Weiterhin ist zu beachten, dass der Anpressdruck der Kontaket ausreichend ist. Ich schlage daher die Verwendung von schleifenden Kontakten vor.

Um eine Kopfladestation zu verwenden muss in config.h folgendes konfiguriert werden:

#define CONF_DISABLE_CHARGINGSTATION       false
#define CONF_PASS_THROUGH_CHARGING_STATION false //the mower can go through the station
#define CONF_HEAD_CHARGING_STATION         true  //the mower can't go through the station

Mit dem Befehl

gohome

wird der Mower beim Mähen angewiesen den Perimeterdrath zu suchen und in die Ladestation zu fahren.

Zum Testen kann der Mower 2m vor der Ladestation auf den Perimeterdraht plaziert werden. Dann

tpt

eingeben. Der Mower fährt dann zu Ladestation.

Zum verlassen der Ladestation

area,0

eingeben. Der Mower fährt dann 1m rückwärts, dreht um 90 Grad und fährt 50cm vorwärst. Dreht dann nochmal einen Zufallswinkel und fängt an zu mähen. Dieser Prozess läuft ohne Bumperschutz ab. Daher ist darauf zu achten, dass dieser Bereich frei von Hindernissen ist.

Mit folgenden Parametern können die Fahrtstrecken konfiguriert werden:

#define CONF_HEAD_CHARGING_DRIVE_BACK_CM   100   //when the mower leaving the head charging station, how far it should drive back
#define CONF_HEAD_CHARGING_DRIVE_FORW_CM    50   //when the mower drove back and then rotates 90 degree, how far it should run forward that both coils securely inside

Wenn der Mower die Ladekontakte erkannt hat, fährt er 3cm zurück und 3 cm vor. Dann wird das Laderelay eingeschaltet. Nach 10 Sekunden wird überprüft, ob ein Ladestrom fließt. Falls nicht, wird das Andocken ein zweites mal versucht. Wenn dies nicht funktioniert, wird ein Fehler ausgegeben.

Durchgangsladestation

Wird eine Durchgangsladestation verwendet ist darauf zu achten , dass die Kontakte mindestens 10cm schleifen können. Weiterhin ist zu beachten, dass der Anpressdruck der Kontaket ausreichend ist.

Um eine Durchgangsladestation zu verwenden muss in config.h folgendes konfiguriert werden:

#define CONF_DISABLE_CHARGINGSTATION       false
#define CONF_PASS_THROUGH_CHARGING_STATION true   //the mower can go through the station
#define CONF_HEAD_CHARGING_STATION         false  //the mower can't go through the station

Mit dem Befehl

gohome

wird der Mower beim Mähen angewiesen den Perimeterdrath zu suchen und in die Ladestation zu fahren.

Zum Testen kann der Mower 2m vor der Ladestation auf den Perimeterdraht plaziert werden. Dann

tpt

eingeben. Der Mower fährt dann zu Ladestation.

Zum verlassen der Ladestation

area,10

eingeben. Der Mower fährt dann 10m am Perimeter draht entlang und fängt dann an zu mähen. 10m kann gegen eine beliebige Entfernung ausgetauscht werden.

Wenn der Mower die Ladekontakte erkannt hat, fährt er 4cm vorwärts, 3cm zurück und 3 cm vor. Dies dient dazu die Kontakte leicht zu schleifen für einen besseren Kontakt. Dann wird das Laderelay eingeschaltet. Nach 10 Sekunden wird überprüft, ob ein Ladestrom fließt. Falls nicht, wird das Andocken ein zweites mal versucht. Wenn dies nicht funktioniert, wird ein Fehler ausgegeben.

Troubleshooting

Mower bleibt stehen

Problem: Mower blieb stehen, Ursache war wohl der Sender. Da leuchteten nur noch die beiden linken LEDs. Sender ausgeschaltet und wieder eingeschaltet, 4 LEDs wieder auf grün und dann ging es wieder.

Lösungsvorschlag: Die dritte grüne Leuchte von links zeigt an, ob der Sender Interrupt im Nano läuft.

Möglichkeit a) Der Sender ist länger als 12h an, ohne das der Roboter wieder in die Station zurückgekehrt ist. Dann schaltet der Sender das Perimetersignal ab.

Möglichkeit b) Da diese nicht an war scheint sich der Nano aufgehängt zu haben. Falls das noch mal passiert, würde ich den China Nano gegen einen original Arduino Nano austauschen. Da die Software bei mir seit einem Jahr läuft, gehe ich nicht davon aus, das diese die Ursache ist. Ich hatte vorher billige Nanos verwendet. Die waren bei mir nicht wirklich Frequenzstabil, was für den Sender aber notwendig ist. Nun habe ich einen Originalen drin.

Ich bekomme diese Meldung: Out: READ und In: CMD

Problem: In Arduino Central wird folgendes angezeigt:

Out: READ
In: CMD: Command not recognized.
Out: READ
In: CMD: Command not recognized.
Out: READ
In: CMD: Command not recognized.
Out: READ

Lösungsvorschlag: In den Arduino Central Settings ist "Read Command -> Enable Read Command" eingeschaltet

Understanding the Behaviour Tree

Die Beschreibung steht ausschließlich in Englisch zur Verfügung.

REDIRECT Understanding the Behaviour Tree

@@ Zeile 1: / Zeile 1: @@
-Achtung! Die Software ist noch im Wandel und kann jederzeit geändert/erweitert werden.
+'''Die Dokumentation ist für die Firmware Version 2.x.x.'''
+'''Die Dokumentation für die Version 1.1.1 ist hier [[Raindancer Firmware V1.1.1 (Deutsch)]] '''
 =Download=
-[https://github.com/kwrtz/Raindancer Github Download]
+[https://github.com/Ardumower/Raindancer 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. 2.3h.
+Die Raindancer Firmware beruht auf dem Code des Nucleomowers welche mit dem Entwicklungsboard STM32 Nuleo 411RE im Jahr 2016/2017 realisiert wurde. Die Firmware wurde dann im Jahr 2017/2018 auf das Ardumower PCB 1.3 konvertiert. Sie verfolgt das Ziel, mit möglichst geringem Hardwareaufwand ein stabiles System zu bekommen, welches das ganze Jahr arbeitet und ein gutes Mähergebnis mit dem Chaosprinzip liefert.
-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 aktuell über das Mobile Phone gestartet.
-Die Firmware wurde entwickelt für Roboter mit dem '''Antriebsmotoren''' hinten, kann aber auch für das original Chassis verwendet werden. Optimierungen für das original Chassis erfolgen zu einem späteren Zeitpunkt.
+Die Firmware hat folgenden '''Workflow''':
-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.
+Der Mower steht in der Ladestation. Der Mower fährt von der Ladestation eine vorgegebene Strecke am Perimeter entlang zu einem Bereich und fängt dann an nach dem Chaosprinzip zu mähen. Die Mähzeit beträgt mit den original Ardumowerkomponenten ca. 130min-150min. 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 erneut mit einem Bereichsbefehl gestartet. (Der Roboter kann auch ohne Ladestation betrieben werden.)
-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.
+Die Firmware wurde entwickelt für Roboter mit dem Antriebsmotoren hinten, kann aber auch für das original Ardumower Chassis verwendet werden.
-Erkennt der Roboter das Signal für 2Sekunden nicht, bleibt er stehen und schaltet die Mootoren aus. Erkennt er es wieder, fährt er weiter.
+Wenn der Mower das Perimeterkabel erreicht, fährt der Roboter noch ca. 20cm weiter. Dann fährt er zurück und dreht sich mit einem Zufallswinkel.
-Die Firmware unterstützt in der aktuellen Version eine durchfahrende Ladestation (einfügen 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.
+Intern in der Firmware werden Strecken nach cm Angaben gefahren. D.h., es werden Encoder benötigt.
-Mit dem original Motoren und Rädern fährt der Roboter mit einer Geschwindigkeit von ca. 1200m/h.
+Für die '''Perimetererkennung''' wird ein 128Bit Signal verwendet. Daher muss die Raindancer Sendersoftware auf den Sender aufgespielt werden. Es werden 2 Perimeterempfänger benötigt. Beim Annähern an das Perimeterkabel wird der Roboter langsamer.
+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. Falls das Perimetersignal zu schwach in der Mitte des Rasens ist, kann ein GPS Bereich konfiguriert werden. Wenn sich der Roboter in diesem Bereich befindet, wird angenommen er ist innerhalb der Perimeterschleife.
+Die Firmware unterstützt eine Kopfladestation und eine Durchgangsladestation. 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.
+Für die Beschleunigung und das Abbremsen wird der Simple Trajection Planer vom Linux CNC Projekt verwendet. Dieser ermöglicht ein sehr sanftes Anfahren und Abbremsen.
+Falls ein original Bumperduino, Bumper mit Schaltern, Halleffekt Sensoren,... verwendet werden, können diese wie bisher an die Bumper Pins angeschlossen werden.
-Der Roboter unterstützt zusätzlich einen selbstgebauten Bumperduino mit zwei MaxSonar Sonarsenoren und einem MPX5010DP FREESCALE Drucksensor für einen Druckwellenschlauch.
+Optimiert wurde die Firmware für '''nicht mit dem Perimeterdraht eingezäunten Hindernissen''' auf dem Rasen. Anstatt mit voller Geschwindigkeit gegen das Hindernis zu fahren, wird ab einem bestimmten Abstand die Geschwindigkeit verringert und seicht gegen das Hindernis gefahren. Voraussetzung sind dafür Sonarsensoren. Diese Funktion ist optional.
-  https://github.com/kwrtz/Raindancer/blob/master/DipTrace/DistanceBumperSensor/DistanceBumperSensor.pdf
+Dazu unterstützt der Roboter einen selbstgebauten Bumperduino mit zwei MaxSonar Sonarsenoren und einem MPX5010DP FREESCALE Drucksensor für einen Druckwellenschlauch.
-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.
+  https://github.com/Ardumower/Raindancer/tree/master/DipTrace/DistanceBumperSensor/DistanceBumperSensor.pdf
-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 Auswertung übernimmt ein Arduino Nano, welcher am 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. Dadurch kann diese einfach auf einer Laborplatine zusammengelötet werden. Die MaxSonar Sensoren können weggelassen werden und es kann eine eigene Lösung an den Nano angeschlossen werden. Der Sensor für den Druckwellenschlauch kann weggelassen werden und nur der Sonarsensor wird verwendet. Eine anderer Möglichkeit für eine Annährungslösung ist, die aktuelle Raindancer Software zu erweitern.
 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). In Arduino Central können Buttons mit Befehlen konfiguriert werden. 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.
-Für die Bedienung wird das Serielle Interface verwendet. Auf dem '''Handy''' 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.
@@ Zeile 37: / Zeile 52: @@
 Parameter werden mit einem Komma getrennt.
-  Beispiel: pc.cm,60,30       //drives 60 cm with speed 30 (//drives...   gehört nich zum Befehl)
+  Beispiel: pc.cm,60,60,30,30 //drives left wheel 60cm at 30% speed and right 60cm at 30% speed (//drives...   gehört nicht zum Befehl)
 Damit wird der Positioncontrol Service angesprochen. Fahre 60cm mit der Geschwindigkeit von 30%
@@ Zeile 46: / Zeile 61: @@
 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
+  https://github.com/Ardumower/Raindancer/tree/master/Documentation/SoftwareStructure.pdf
-Zur Dartsellung wurde die Software UMLET verwendet.
+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.
@@ Zeile 55: / Zeile 70: @@
 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 betrachten kann folgende kostenlose Software verwendet werden:
+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
+  https://github.com/Ardumower/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.
-Der Roboter kennt zwei Modi: Manuel und Auto. Im manuellen laufen alle Services, aber der Behaviourtree ist ausgeschaltet. Im Auto mode wird der BHT aktiviert.
 Welcher Modi wird wann gestartet:
@@ Zeile 66: / Zeile 80: @@
   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.
+Ist der Roboter im MANUAL Mode, kann er mit dem Befehl A in den Automode geschaltet werden. Erkennt der Roboter dann das Perimetersignal, fängt er an zu mähen.
-==Offene Punkte==
+=Für eine minimale Inbetriebnahme sollten folgende Voraussetzungen erfüllt sein=
-* 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.
+[[File:warning.png]]Sicherheitshinweis: Aus Sicherheitsgründen sind die Mähmesser bei den ersten Tests [[nicht]] zu montieren!
-* 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)
+[[File:warning.png]]Wichtig: Für die ersten Getriebemotortests sollte der Roboter hochgebockt werden so dass die Räder keinen Kontakt zum Boden haben!
-* Einseitig befahrbare Ladestation umsetzen
-==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=
 *PCB1.3 mit Arduino DUE
 *Original Ardumower Antriebsmotoren mit Encoder
-*Original Mähmotor
+*Original Ardumower Mähmotor
-*Zwei Ardumower Perimeterspulen vorne Links/Rechts. Bei original Chassis ggf. montiert: Links/Mitte (kommt darauf an, welchen Linienverfolgungsalgorithmus man verwendet)
+*Zwei Ardumower Perimeterspulen vorne Links/Rechts. Bei original Ardumower 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.
-*Die erste Brücke für die Encoder ist auf de PCB1.3 überbrückt.
 *24V Spanungsversorgung
 =Optional kann verwendet werden=
-*Ardumower Bumper Pins
+*RTC mit EEPROM
+*Ardumower Bumper Pins mit Schaltern, Hall Effekt Sensoren, original Bumper Duino, ...
 *Durchfahrende Ladestation
 *Selbst gebauter Bumperduino mit 2MaxSonar Sensoren an PinUserSwitch2/3
@@ Zeile 103: / Zeile 105: @@
 =config.h=
 Die Datei config.h enthält die Grundkonfiguration der Firmware.
+'''Vor der ersten Inbetriebnahme müssen die Parameter angepasst werden.'''
+Auswahl der Chassisform. Es darf nur ein Parameter true gesetzt werden.
+ #define ARDUMOWER_CHASSIS  true
+ #define PARANELLO_CHASSIS  false
+ #define RAINDANCER_CHASSIS false
+Danach in config.h die Code-Sektion anpassen, die die Konfiguration für das gewählte Chassis enthält.
+Die Sektion beginnt folgendermaßen für das Ardumower Chassis:
+ //======================================================================================================================
+ // CONFIG FOR ARDUMOWER CHASSIS
+ //======================================================================================================================
 Konsolenspeed:
   #define CONF_PC_SERIAL_SPEED			115200 // Speed serial consol
-Solle das bluetooh Modul bereits mir der original Ardumower Software konfigurert worden sein, ist die Zeile
+Sollte das Bluetooh Modul bereits mir der Azurit Firmware konfiguriert worden sein, ist die Zeile
   #define CONF_BT_SERIAL_SPEED			115200
-mit
+auf
   #define CONF_BT_SERIAL_SPEED			19200
- zu ersetzen.
+abzuändern.
-Einstellen des Radumfangs und Radabstandes:
+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!!!
@@ Zeile 122: / Zeile 138: @@
   #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_BUMPER_SERVICE		true   // Disables original bumper sensor pins (PCB1.3) on pinBumperLeft => diBumperL and  pinBumperRight => diBumperR
   #define CONF_DISABLE_BUMPERDUINO_SERVICE	true   // Disables my own bumper duino sensor on pinUserSwitch2 => diBumperSensor
@@ Zeile 130: / Zeile 146: @@
   #define CONF_DISABLE_BATTERY_SERVICE	        true   // Disables battery sensor
   #define CONF_DISABLE_CHARGE_SERVICE		true   // Disables charge system service
+ #define CONF_DISABLE_RAIN_SERVICE              true   // Disables rain sensor
+ #define CONF_DISABLE_DHT_SERVICE               true   // Disables temp sensor
+ #define CONF_DISABLE_GPS                       true   // Disables GPS 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_MOW_MOTOR          	false  // Disables the mow motor
   #define CONF_DISABLE_CHARGINGSTATION    	true
-NUR FÜR DAS original Ardumower Chassis sollten noch folgende Konstanten abeänder abgeändert werden:
+'''NUR FÜR DAS original Ardumower Chassis Design''' sollten noch folgende Konstanten eingestellt werden, damit dei Drehung am Perimeter optimiert wird:
   #define CONF_PER_CORRECTION_ANGLE       30
   #define CONF_PERIMETER_DRIVE_BACK_CM    40.0f
@@ Zeile 151: / Zeile 170: @@
 Hier H eingeben. Danach werden alle verfügbaten Befehle angezeigt. Diese am besten kopieren und abspeichern, so dass man diese einsehen kann.
-= QUICKSTART TO MOW =
-Der roboter ist über das Konsolenkabel verbunden. Speed: 115200
-==Zum warm werden: Konfiguration des Batterie service==
+Falls folgende Warnung beim kompilieren auftreten, können diese ignoriert werden:
-In config.h folgendes setzen und Software neu aufspielen.
+ pinman.cpp: 18:0: warning: "PWM_FREQUENCY" redefined [enabled by default]
+   #define PWM_FREQUENCY 3900
+ pinman.cpp: 19:0: warning: "TC_FREQUENCY" redefined [enabled by default]
+   #define TC_FREQUENCY 3900
+= 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 Konsolenkabel verbunden. Speed: 115200
+==Errorhandling==
+Wenn die Firmware einen Fehler feststellt, geht diese in den Errormode. Der Mower bleibt stehen und der Mähmotor wird abgeschaltet. Die Services laufen weiter. Der als erstes aufgetretene Error wird gelatched.
+Der Error wird dann alle 2 Sekunden an die Konsole bzw. BT ausgegeben. Je nachdem was als letztes aktiv war oder aktiviert wird durch senden eines Zeichens. Wenn man z.B. den Mower über Bluetooth gestartet hat, wird der Fehler auch auf über BT ausgegeben.
+Zum deaktivieren des Error müssen folgende Befehle nacheinander eingegeben werden:
+ reset     //reset error and motor faults
+ M         //activate manual mode
+Mit dem Befehl error kann sich das Errorlog angezeigt werden. Das Errorlog zeigt die History der durchlaufenen Running Nodes des BHT sowie diverse andere Ereignisse. Es ist 5000 Zeichen groß.
+ error     //show errormessage
+Mit dem Befehl show.hist werden die letzten Drehrichtungen und andere Parameter angezeigt.
+ show.hist   //show history
+Die letzten eingetragenen Werte, werden als erstes ausgegeben, so das diese oben stehen!
+Nach dem deaktivieren des Error kann der Mower wieder mit
+ A
+gestartet werden. Dabei müssen sich allerdings beide Spulen im Perimeter befinden.
+==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
-bat.show eingeben. Es sollte die richtige Batterispannung angezeigt werden.
+Den Befehl
+ bat.show
+eingeben. Es sollte die richtige Batteriespannung angezeigt werden.
+Sollte diese um mehr als 0.2V abweichen, so kann diese mit den Konstanten
+ #define BATTERYFACTOR_BS    11.0f   //Entspricht (100+10)/10 Voltagedivider
+ #define DIODEDROPVOLTAGE_BS  0.4f
+justiert werden.
+Diese Konstanten sind in batterySensor.h definiert.
+Berechnet wird die Spannung in batterySensor.h folgendermaßen
+ sensorValue = aiBATVOLT.getVoltage();
+ float readVolt = sensorValue * BATTERYFACTOR_BS + DIODEDROPVOLTAGE_BS; // The diode sucks 0.4V
 ==Inbetriebnahme der Motoren==
-Den Befehl clc.mt,1,150 eingeben.
+Als erstes wird geprüft ob die Motoren sich drehen und ob diese auch in die richtige Richtung drehen.
-Damit wird der Motor links direkt mit einer PWM con 150 angesteuert.
+Dazu werden die Motoren direkt mit einer PWM Vorgabe angesteuert. D.h es erfolgt keine Regelung der Geschwindigkeit anhand der Encoder. Die Regelschleife für die Geschwindigkeit ist offen (open loop);
-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 linke sollte sich vorwärts drehen. Falls nicht muss es umgepolt werden.
+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.
-Das gleiche für das rechte Rad:
+Den Befehl
+ clc.mt,1,150
+eingeben.
+Damit wird der Motor (1) links direkt mit einer PWM von 150 angesteuert.
+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.
+Das Rad sollte sich auf jeden Fall noch bei einer PWM von 50 (besser weniger) drehen.
+Das gleiche für das rechte Rad (2):
   clc.mt,2,150
-Sollten sich die Räder nicht drehen, kann man es noch mit einer höheren PWM versuchen.
+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.
+Anmerkung:
-Wenn man die Originalwerte verwenden möchte, muss man nachfolgende Zeilen in pinman.cpp auf 3900 abändern.
+Die PWM für die Motoren läuft mit 3900Hz.
-  #define PWM_FREQUENCY 20000
+Wenn man die Originalwerte verwenden möchte, muss man nachfolgende Zeilen in pinman.cpp abändern.
-  #define TC_FREQUENCY 20000
+  #define PWM_FREQUENCY 3900
+  #define TC_FREQUENCY 3900
+Achtung: Wenn die PWM zu hoch gesetzt wird, z.B. 18000Hz, dann drehen sich die Räder bei niedriger PWM von z.B. 60 nicht mehr. Es kommt dann ein Fehler, dass bei Vorgegebener PWM von 60 die Geschwindigkeit 0 ist.
 ==Inbetriebnahme der Encoder==
-Den Befehl clc.mt,1,150 eingeben, damit sich das linke Rad dreht.
+Es wird geprüft, ob die Encoder funktionieren und ob diese auch in die richtige Richtung zählen.
-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.
+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 Encoder, der bei Vorwärtfahrt hochzählt und bei Rückwärtsfahrt zurückzählt.
+Und einmal einen positiv/negative Zähler (enc), der bei Vorwärtsfahren hochzählt und bei Rückwärtsfahren runterzählt.
-Beide angezeigten Zähler des linken Rades  müssen nun hochzählen.
+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.
- Beispiel:
+Beide angezeigten Zähler des linken Rades (1) müssen nun hochzählen.
-  motor 1 = Links
-  motor 2 = rechts -sollte nicht zählen, wenn der linke Motor läuft.
+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
@@ Zeile 199: / Zeile 286: @@
   !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 negative beim Vorwärtsfahren zählt kann man das in der config.h konfigurieren:
+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:
+Das gleiche für das rechte Rad durchführen:
-  clc.mt,1,150
+  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.
+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 und damit auch das Geradeausfahren des Roboters. Für jedes Rad gibt es einen Service also insgesamt zwei Services. Der Service berechnet intern 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%
@@ Zeile 223: / Zeile 315: @@
   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 ein Rad eine Markierung anbringen, damit man sieht, wie weit es sich dreht
+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
+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ätzlich ist die Konstante CONF_RADUMFANG_CM wichtig, damit die Berechnung für das Fahren eines bestimmten Weges in cm stimmt.
+Da am Anfang in der config.h die 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
-setzen, neu kompilieren und aufspielen. Dann nochmal probieren.
+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 (Achtung, das USB Kabel sollte lang genug sein. Am besten eine Verlängerung verwenden);
+Zurücklegen einer bestimmten Streck in cm
+ pc.cm,60,60,30,30     Fahre 60cm vorwärts mit der Geschwindigkeit von 30%
+ pc.cm,-60,-60,30,30   Fahre 60cm rückwärts mit der Geschwindigkeit von 30%
+Drehen eines bestimmten Winkels. Voraussetzung: CONF_ENCTICKSPERREVOLUTION, CONF_RADUMFANG_CM, und CONF_DISTANCE_BETWEEN_WHEELS_CM sind richtig konfiguriert.
+ 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 falsch 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
-mot.curm   //zeigt den Mähmotorstrom an.
 danach
@@ Zeile 253: / Zeile 376: @@
 Es kann sein, dass beim stoppen ein  motorfault kommt. Diesen mit reset zurücksetzen.
+ mot.curm   //zeigt den Mähmotorstrom an.
+Wenn das PCB1.3 verwendet wird, wird hier der Mähmotorstrom vermutlich falsch angezeigt. Siehe dazu: Mähmotorstrom einstellen in Tune Up
+Dies kann später durchgeführt werden und ist für den ersten Mähbetrieb nicht so wichtig.
 ==Perimeter Inbetriebnahme==
-Die Spulen des Roboters sollten innerhalb der Schleife sein.
+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 wieder empfangen wird. 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.
-Die Raindancer Sendersoftware muss auf dem Sender installiert sein.
+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.
@@ Zeile 263: / Zeile 394: @@
 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 empfangen wurde. Die Signalqualität kann man an der Peak Signal Noise Ration psnr sehen.
+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
@@ Zeile 281: / Zeile 412: @@
 Mit h Ausgabe beenden.
-Beide Spulen sollten das Signal erkennen.
+Beide Spulen sollten das Signal erkennen, also kein BAD anzeigen. Auch nicht sporadisch!
-Als nächstes muss die Ploarität des Signals konfiguriert werden.
+Als nächstes muss die Polarität des Signals konfiguriert werden.
   per.show eingeben. (mit h Ausgabe ausschalten)
@@ Zeile 291: / Zeile 422: @@
 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
@@ Zeile 303: / Zeile 435: @@
 Dies kann in der config.h eingestellt werden:
-  #define CONF_LEFT_ENCODER_INVERSE		true
+  #define CONF_LEFT_COIL_INVERSE		true
-  #define CONF_RIGHT_ENCODER_INVERSE		false
+  #define CONF_RIGHT_COIL_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 .
+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_COIL_INVERSE und CONF_RIGHT_COIL_INVERSE.
-Es kann sein, dass  per.resultl eine positive Amplitude liefert undper.resultr eine negative. Das ist OK. Die Umrechnung  mit CONF_LEFT_ENCODER_INVERSE/CONF_RIGHT_ENCODER_INVERSE  findet später statt.
+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_COIL_INVERSE/CONF_RIGHT_COIL_INVERSE  findet in der Software 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.
+Wichtig ist, das CONF_LEFT_COIL_INVERSE und CONF_RIGHT_COIL_INVERSE so konfiguriert werden, dass per.show innerhalb des Perimeters 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
+Wurde das Modul bereits mit 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.)
+(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 dieser 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:
+Also los:
-Platine stromlos schalten. Knopf auf BT Modul drücken und gedrückt halten. Platine anschalten.
+Platine stromlos schalten (auch USB vom DUE abziehen). Knopf auf BT Modul drücken und gedrückt halten. Platine anschalten.
 Das BT Module sollte nun alle 2Sek blinken.
-Knopf loslassen.
+Knopf loslassen. USB an den DUE wieder anschließen. Das BT Modul sollte immer noch im 2Sek. Takt blinken.
- bt.show eingeben. Versucht das BT modul zu finden.
+Nun als erste mit bt.show versuchen, ob das BT Modul gefunden wird:
+ bt.show
 Wenn erfolgreich gefunden:
-  bt.set eingeben. Das BT Modul wird konfiguriert.
+  bt.set
+eingeben. Das BT Modul wird konfiguriert.
 ==Einstellen Arduino Central==
+Die Software läuft auf einem Android Mobilephone oder Tablet.
+Arduino Central kann aus dem Play Store heruntergeladen werden. Eine andere Software die auch funktioniert ist Serial Bluetooth Terminal.
-In Adrduino Central kann oben rechts das Menü (drei Punkte) aufgemacht werden. Dort settings aufrufen.
+In Arduino 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.
@@ Zeile 380: / Zeile 488: @@
 Zurückgehen und Serial Terminal Settings öffnen
-Terminal View Characcter Limit auf 10000 setzen
+Terminal View Character Limit auf 10000 setzen
 Zurückgehen und Line Ending for Commands auswählen
@@ Zeile 397: / Zeile 505: @@
 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.
+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.
@@ Zeile 410: / Zeile 518: @@
   Button 5 Text: gohome 	Command: gohome
   Button 6 Text: per 	Command: per.show
- Button 7 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 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.
+Dazu zur Sicherheit für den ersten Test den Mähmotor in config.h ausschalten.
-Achtung, es sind noch keine Bumper aktiv.
   #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.
+Das USB Kabel abziehen und eine Verbindung mit Arduino Central herstellen.
 Roboter in die Schleife stellen.
-Mit show.per nochmal das Perimetersignal überprüfen. Mit h oder show.per Ausgabe deaktivieren.
+Mit per.show nochmal das Perimetersignal überprüfen. Mit h oder show.show Ausgabe deaktivieren.
-  A für Auto eingegen um das mähen zu starten.
+  A für Auto eingeben 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.
@@ Zeile 437: / Zeile 544: @@
   M eingeben für manuellen mode, um den Roboter zu stoppen.
+=TUNE UP =
-==Konfiguration Original Bumper==
+==Konfiguration der Bumper an den Bumperanschlüssen==
-Die Bumper Pins sind standardmäßig als Eingänge mit Pullup widerstand konfiguriert in hardware.cpp:
+Das original Ardumower Chassis liefert keine standardmäßige Lösung für Bumper mit. Da die meisten Anwender sich hier eigene Lösungen schaffen, bietet die Software entsprechende Optionen an, die Bumper über die vorgesehenen Pins abzufragen.
+Zum aktivieren der Bumper muss in der config.h folgende Zeile konfiguriert werden:
+ #define CONF_DISABLE_BUMPER_SERVICE    false
+Zum Testen der Bumper kann man den Befehl bumper.show verwenden. Der Bumper Service gibt dann auf der Konsole oder dem Mobile Phone seine Aktivität aus, je nachdem von wo dieser Befehl gesendet wurde.
+ bumper.show
+Die Bumper Pins sind standardmäßig als Eingänge mit Pullup Widerstand konfiguriert. Das bedeutet, der Eingang ist standardmäßig auf HIGH, wenn der Pin nicht auf GND gezogen wurde.
+Der Bumperservice kann mir folgenden Parametern in der config.h konfiguriert werden:
+Verwenden des linken oder/und rechten Bumpers
+ #define CONF_USE_LEFT_BUMPER            true     // left bumper is used
+ #define CONF_USE_RIGHT_BUMPER           true     // right bumper is used
+Festlegen, ob der Bumper aktiv ist, wenn der Pin auf GND gezogen wird:
+ #define CONF_LEFT_BUMPER_LOW_ACTIVE     true     // left bumper is activated when pin is low
+ #define CONF_RIGHT_BUMPER_LOW_ACTIVE    true     // right bumper is activated when pin is low
+Wenn man eine linken und einen rechten Bumper verwendet, gibt es noch die Möglichkeit zu konfigurieren, dass die Drehrichtung nach zurückfahren vom aktivierten Bumper bestimmt wird. D.h. dass wenn der linke Bumper betätigt wurde, der Roboter sich dann nach dem Zurückfahren rechts dreht.
+ #define CONF_ESCAPEDIR_DEPENDING_ON_BUMPER false  // if set to true, the robot rotates in the opposite direction of the activated bumper. If false, the escape direction is random.
+                                                   // only set to true if you use a bumper for left and a bumper for right.
+Die Bumper Pins sind standardmäßig als Eingänge mit Pullup Widerstand konfiguriert in hardware.cpp:
   DigitalIn diBumperL(pinBumperLeft, true);
@@ Zeile 445: / Zeile 587: @@
   DigitalIn diBumperR(pinBumperRight, true);
-Das bedeutet, der Eingang ist standardmäßig auf HIGH.
+Das bedeutet, der Eingang ist standardmäßig auf HIGH, wenn der Pin nicht auf GND gezogen wurde.
+''Möchte man die Pullupwiderstände ausschalten, müssen die Zeilen folgendermaßen geändert werden''
+ ''DigitalIn diBumperL(pinBumperLeft, false);''
+ ''DigitalIn diBumperR(pinBumperRight, false);''
+==Charge Service==
+Der Charge Service stellt dem BHT die Charge Voltage und den Charge Current zur Verfügung. Er enthält Funktionen zum Ein-/Ausschalten des Laderelais.
+ Anmerkung:
+ Wenn den Mower ausgeschaltet ist (also Batterie nicht angeklemmt) und dann an P42 Charger eine Ladespannung angeschlossen wird,
+ wird das Board über D73 direkt mit Spannung versorgt. Das Problem ist, das die Kondensatoren auf dem Board keine Spannung haben und beim Anklemmen einen Kurzschluss liefern. Dann wird eine 1,6A Sicherung in EF1 durchschlagen.
+ Daher sollte EF1 5A betragen.
+ Ich habe bei mir die D73 entfernt, da ich diese nur dann für sinnig halte, wenn die Batterie so leer ist, dass das Board und Relay nicht mehr mit der Batterie funktioniert. Falls dies mal wirklich
+ passiert, werde ich die Batterie direkt mit dem Ladegerät laden. Sowas sollte nur im Fehlerfall passieren und nicht die Regel sein (Ich möchte aber niemanden überreden dies auch zu tun).
+ Weiterhin hat die D73 ein anders Potential auf der Hinterseite, als die Dioden die hinter dieser eingelötet sind. Da ist es sinnig, diese mit Heißkleber zu trennen, nicht das diese aneinander geraten.
+[[Im Folgenden wir beschrieben, wie man den Roboter laden kann]]
+'''Selbstständiges Fahren in die Ladestation'''
+Wenn der Roboter in die Ladestation fährt, ist das Laderelais ausgeschaltet. Zu diesem Zeitpunkt liegt nur die Spannung der Ladestation an den Kontakten.
+Hat der Roboter dies festgestellt, stoppt er, wartet zwei Sekunden und überprüft die Ladespannung nochmal. Wenn diese OK ist, fährt er 3cm vorwärts, 3cm rückwärts und wieder 2cm vorwärts.
+Dies dient dazu die Verbindung zu den Ladekontakten zu optimieren (die aktuell als Schleifkontakte ausgeführt sind). Danach wird das Relay eingeschaltet und die Ladespannung erneut geprüft.
+(Dieses Verhalten kann ohne großen Aufwand im BHT umprogrammiert werden.) Das Relay bleibt solange angezogen und damit die Batterie mit dem Ladegerät verbunden, bis der Roboter den Befehl bekommt zu einem Bereich (area) zu fahren oder der Roboter in den manuellen Mode geschaltet wurde oder in den auto Mode geschaltet wird.
+'''Verwenden ohne Ladestation'''
+Um den Roboter zu laden  sollte dieser sich im Manual mode befinden (Befehl M eingeben). Danach kann man mit charge.relay,1 das Relay einschalten und mit charge.relay,0 das Relay ausschalten. Das Relay schaltet automatisch aus, wenn man den Auto Modus aktiviert. '''Das Relay schaltet nur ein, wenn an den Ladekontakten die Ladespannung anliegt!'''.
+Eine andere Möglichkeit ist, die Ladekontakte im ausgeschaltetem Zustand anzuschließen und den Roboter dann einzuschalten. Der Roboter geht dann in den Auto mode uns schaltet das Behaviour Charging Station ein. Damit denkt er nun, er ist in der Ladestation.
+'''Einstellen in die Ladestation'''
+Hier den Roboter im ausgeschalteten Zustand in die Ladestation stellen, so dass die Ladekontakte Kontakt haben. Dann einschalten. Der Roboter geht dann in den Auto mode in das Behaviour Charging Station. Damit denkt er nun, er ist in der Ladestation, schaltet das Relais ein und lädt.
+Um den Chargingservice zu aktivieren inder config.h CONF_DISABLE_CHARGE_SERVICE	auf false setzen und Software neu aufspielen.
+ #define CONF_DISABLE_CHARGE_SERVICE	false
+[[Manuelles Testen:]]
+Den Befehl
+ charge.show
+eingeben. Damit werden die Spannungen und Ströme kontinuierlich angezeigt. Aktuell sollte alles mit  0 angezeigt werden.
+Ladegerät an P42 oder Ladekontakte anschließen.
+Nun sollten die Chargevoltage (CV) angezeigt werden.
+Relay einschalten:
+ charge.relay,1
+Damit fließt nun ein Strom vom Ladegerät zur Batterie und ein Charge Current wird angezeigt (CC).
+Relay ausschalten.
+ charge.relay,0
+[[Testen im ausgeschaltetem Zustand über die Konsole:]]
+Roboter einschalten und USB anschließen. Warten bis Software hochgelaufen ist.
+Ladekontakte verbinden.
+Serielle Konsole öffnen. Der DUE startet neu. Das Relay sollte angezogen werden und die Konsolenausgabe beim Booten sollte "Charging station detected" anzeigen.
+Der Roboter hat nun in das Chargingbehaviour geschaltet.
+ M eingeben um wieder in manuellen mode zu gelangen und das Relay abzuschalten.
+==Watchdog==
+Der Watchdog dient ausschließlich zur Sicherheit.
+Falls sich die Software aufhängt, soll der Watchdog verhindern, dass der Roboter unkontrolliert weiterläuft.
+Der Watchdog ist hardwaretechnisch im DUE realsiert. Er wird in der config.h mit
+ #define CONF_ENABLEWATCHDOG  true
+aktiviert.
+Jedesmal wenn der Loop durchlaufen wird, wird der Watchdog mit dem Funktionsaufruf watchdogReset(); reseted.
+Wenn watchdogReset(); innerhalb von 3 Sek. nicht aufgerufen wird (weil die Software irgendwo hängt), wird der DUE neu gestartet, die Motoren gestoppt und die Software geht in den Modus Manual.
+Anmerkung:
+Da die Variablen der Firmware beim Reboot neu initialisiert werden, ist es schwer herauszufinden, was die Ursache des Fehlers ist.
+Der Mower bleibt einfach stehen, und man wundert sich beim Öffnen der BT Verbindung, das alles in Ordnung ist und kein Fehler ausgegeben wird - außer das die Software im Manual Mode ist.
+== Unterspannungsabschaltung ==
+Die Unterspannungsabschaltung dient dazu zu verhindern, dass die Batterie unter eine bestimmte Spannung fällt und dann Tiefen entladen wird. Die Umsetzung der Unterspannungsabschaltung ist im Batterie Service implementiert.
+Voraussetzung ist, das Hardwareseitig der Jumper 8 UV-Abschaltung auf PCB 1.3 auf Auto gestellt ist. Wenn man dann Spannung auf das Board gibt, bekommt dieses erstmal keinen Strom. Daher muss beim Einschalten der Spannung die UV-Abschaltung mit dem P20 Button überbrückt werden. Dann bekommt das PCB1.3 Spannung. Dieser Button sollte so für 4 Sekunden gehalten werden. Dann übernimmt die Software die Steuerung der UV-Abschaltung. Der P20 Button muss danach wieder offen sein, ansonsten kann die Software die Spannung nicht abschalten.
+In der config.h ist die Schwelle eingestellt, bei der die Spannung abgeschaltet wird
+ #define CONF_VOLTAGE_SWITCHOFF_BS  21.7f
+Wenn die Batteriespannung für eine Minute unter diese Spannung abfällt, wird die Spannung zum PCB1.3 und den Motoren abgeschaltet.
+Das gesamte PCB1.3 ist dann dunkel.
+Möchte man die Unterspannungsabschaltung überbrücken, kann man Jumper 8 auf Dauer-An stellen oder P20 überbrücken. Ich habe am P20 einen Ein-/Ausschalter angeschlossen, so das ich für Testzwecke diesen überbrücken kann. Der Jumper 8 steht weiterhin auf Auto.
+==I2C Bus==
+Der I2C Bus kann mit dem Befehl i2c.scan gescannt werden. Es werden dann alle gefundenen Adressen angezeigt.
+ i2c.scan
+Die Adressen des RTC Moduls und des EEPROM können in der hardware.cpp angepasst werden. Zur Zeit sind die Standardadressen konfiguriert:
+ byte DS1307_ADDRESS = B1101000;
+ byte AT24CX_ADDRESS = B1010000;
+==RTC==
+Das RTC Modul wird zur Zeit nicht verwendet. Es ist vorgesehen, später dieses für einen zeitlichen Mähstart zu verwenden.
+Das RTC Modul kann aber bereits programmiert und getestet werden.
+Das RTC Modul wird mit folgender Zeile in der config.h aktiviert:
+ define CONF_DISABLE_EEPROM_SERVICE  false
+Es stehen folgende Befehle zur Verfügung:
+ rtc.show          //show rtc values every rtc read (10sec)
+ rtc.config        //show rtc service config
+ rtc.find          //tries to find RTC and show result
+ rtc.set,8,17,3,25,01,2017 //set rtc time=8:17 dayOfWeek=3 date=25.01.2017
+==EEPROM==
+Es wird das EEPROM auf dem RTC verwendet. Zur Zeit wird es verwendet um Statistiken abzuspeichern. Es werden folgende Statistiken abgespeichert: Gesamte Mähzeit, Gesamte gefahrene Strecke, Gesamte Anzahl an Rotationen, Anzahl Ladevorgänge.
+Die Verwendung des EEPROM wird mit folgender Zeile in der config.h eingeschaltet:
+ #define CONF_DISABLE_EEPROM_SERVICE false
+Folgende Befehle stehen für das EEPROM zu Verfügung:
+ eep.config           //show EEPROM service config
+ eep.u8t,10           //show uint8_t at address 10
+ eep.s32t,10          //show int32_t at address 10
+ eep.f,10             //show float at address 10
+ eep.set.u8t,10,7     //write value uint8_t=7 to address=10
+ eep.set.s32t,10,1234 //write value int32_t=1234 to address=10
+ eep.set.f,10,7.3     //write value float=7.3 to address=10
+ eep.erase            //erase the eeprom
+Zum testen des EEPROM z.B. folgenden Befehl eingeben:
+ eep.set.f,10,7.3
+Damit wird der float Wert 7.3 an die Adressen 10,11,12,13 in das EEPROM geschrieben.
+Mit dem Befehl
+ eep.f,10
+kann der Wert dann wieder ausgelesen werden.
+Der Befehl eep.erase löscht die ersten 3 Pages des EEPROM. Die anderen Pages werden aktuell nicht gelöscht, da diese nicht verwendet werden.
+ eep.erase
+Es ist sinnvoll das EEPROM nach dem enablen zu löschen, damit die Speicherzellen initialisiert werden.
+==Geschwindigkeit am Perimeter verlangsamen==
+Der Mower fährt mit einer Geschwindigkeit von 1200m/s. Um das Abbremsen beim Überfahren des Perimeters etwas sanfter durchzuführen, verringert der Roboter kurz vor dem Perimeter (ca. 20cm) die Geschwindigkeit.
+Folgende Konstanten in der config.h beeinflussen das Erkennen nahe am Perimeter:
+ #define CONF_NEAR_PER_UPPER_THRESHOLD   80.0L    // Threshold of one coil where Perimetersignal is detected as near perimeter
+ #define CONF_NEAR_PER_LOWER_THRESHOLD   70.0L    // Threshold of the other coil where Perimetersignal is detected as near perimeter
+Um festzustellen, ob der Roboter nahe am Perimeter ist, wird die Amplitude der linken und rechten Spule ausgewertet. Dazu ermittelt die Firmware die aktuelle maximale Amplitude über die gesamte Fahrzeit des Mower. Wenn nun die linke Spule eine Amplitude von 80% (CONF_NEAR_PER_UPPER_THRESHOLD) oder höher des Maximalwertes erreicht und die rechte Spule über 70% (CONF_NEAR_PER_LOWER_THRESHOLD) oder höher  des Maximalwertes erreicht, so wird angenommen, dass der Roboter nahe am Perimeter ist. Das Gleiche gilt, wenn die rechte Spule 80% erreicht und die linke 70%.
+Diese Werte sind abhängig von der verwendeten Spule und von der eingestellten Signalstätke des Sender und müssen daher ggf. nachjustiert werden.
+Um dies zu justieren, den Befehl per.show eingeben während der Mower fährt.
+ per.show
+Wenn er dann über den Perimeter fährt den gleichen Befehl eingeben oder h drücken. Dann in der Anzeige zurück scrollen und sich die Werte angucken.
+Beispiel:
+!03, ML: 305  MR: 331 magMax:332 magMedL%: 73 magMedR%: 87
+Die Werte  magMedL%: 73 magMedR%: 87 zeigen hier die gemessene Prozentzahl der Spulen an. Hiernach dann CONF_NEAR_PER_UPPER_THRESHOLD und CONF_NEAR_PER_LOWER_THRESHOLD  einstellen. Es sollten mehrere Versuche zur Bestimmung durchgeführt werden. Besser etwas früher langsamer werden, als zu spät. Der Unterschied zwischen High und Low wurde eingeführt, da die Spulen nicht den gleiche Wert haben, z.B. wenn der Mower schräg oder fast parallel zum Perimeter fährt.
+Es kann sein, dass magMedL% und magMedR% mehr als 100% anzeigen. Dies beruht auf der Art der magMax Ermittlung und ist OK.
+Die Berechnung ist in der Funktion '''bool TPerimeterThread::isNearPerimeter()''' in der Datei perimeter.cpp hinterlegt.
+==Mähmotorstrom einstellen==
+Es ist zu berücksichtigen, dass die Ausgänge des Mähmotordrivers auf dem PCB1.3 zusammengeschaltet wurden.
+Bei mir wird bei einer PWM von 255 am Mähmotor fast kein Strom gemessen. Habe dann mal mit einem Multimeter nachgemessen. Am M2 FB liegen tatsächlich im vollen Leerlauf nur 0.04V an. Richtig wären ca. 0.22V da der Motor hier 0,41A zieht. Am M1 FB1 messe ich eine Spannung von 0.007V. Es scheint so, dass durch das parallel Schalten die Strommessung nicht mehr stimmt. Man könnte meinen diese sollte sich halbieren. Ist aber nicht so.
+Eine Zusammenschaltung der beiden MC33926 wird vom Hersteller nicht ausdrücklich empfohlen und liefert scheinbar eine falsche Strommessung.
+https://www.nxp.com/docs/en/application-note/AN4833.pdf
+Zitat:"If two independent H-bridges are used (separate MC33926 or similar), the load sharing may not be quite as even,
+resulting in a reduction in maximum drive capability. This configuration will latch any fault until the EN pin is toggled."
+Ich habe dann vom Mowmotortreiber die Pins M1 OUT1 und M1 OUT2 abgeklemmt (gebogen und neben die Buchsenleist geführt, so das diese keinen Kontakt haben). Und siehe da, die Strommessung funktioniert richtig, wobei unter 1A diese nicht wirklich genau ist. Erst ab 1A ist der Wert zuverlässig.
+Forumseintrag:
+https://www.ardumower.de/index.php/de/forum/ardumower-1-3-mainboard/1461-pcb1-3-motorstrom-wird-vermutlich-falsch-gemessen#13904
+Wenn M1 OUT1 und M1 OUT2 nicht abgeklemmt werden wird der Strom zu gering angezeigt.
+Daher muss der scale Wert für die richtige Strommessung in der setup Funktion der Klasse TMowMotorSensor in der Datei mowmotorSensor.h angepasst werden.
+Der scale factor sollte bei Strömen um die 1A oder mehr eingestellt werden. D.h. die Mähscheibe muss belastet werden, wenn man mit dem Multimeter den Strom misst.
+Wenn M1 OUT1 und M1 OUT2 abgeklemmt werden ist der Faktor den ich durch Messen eingestellt habe vermutlich einigermaßen richtig. Dies kann aber nur durch Nachmessen von Stromstärken ab 1A überprüft werden.
+Der gemessene Strom und die Wattzahl wird mit dem Befehl
+ mot.curm
+angezeigt.
+==Langsamer fahren, wenn Mähmotor belastet==
+Wenn der Mähmotor belastet ist, wird der Mower langsamer.
+Ab welcher Wattzahl des Mähmotors langsamer gefahren wird, wird in der config.h mit dem Parameter
+ #define CONF_MOW_MOT_UNDER_LOAD 30.0f
+eingestellt. Wenn der Mähmotor über 30W benötigt, wird die Geschwindigkeit verlangsamt.
+Die aktuelle Watt Zahl beim Mähen kann mit dem Befehl
+ mot.curm
+angezeigt werden. Danach kann der Wert nach eigenem Ermessen eingestellt werden.
+Achtung, die Motordriver liefern eine genaue Strommessung erst ab 1A (lt. Datenblatt 0.5A).
+D.h. Werte wo der Strom unter 1A angezeigt wird sind ungenau und sollten nicht verwendet werden.
+Die Genauigkeit beträgt lt. Datenblatt bei einem Strom von über 0.5A +-20%.
+Der Code für die Geschwindigkeitseinstellung befindet sich in der Klasse class TCruisePerimeterNear : public Node in der Datei bCruise.h.
+Weiterhin ist zu berücksichtigen, dass die Ausgänge des Mähmotordrivers zusammengeschaltet wurden. Dies wird vom Hersteller nicht empfohlen und liefert eine falsche Strommessung.
+==Perimeter Tracking==
+Hier wird der Perimetertrackingalgorithmus erklärt, mit dem Ziel genügend Informationen zu liefern, dass dieser durch den Anwender auf sein Chassis optimiert werden kann. Es fiel die Wahl auf diesen Algorithmus, da dieser unabhängig von der Perimeteramplitude ist. Weiterhin ist der Algorithmus extrem stabil und nicht von seinem Vorhaben abzubringen dem Perimeter zu folgen. [https://www.youtube.com/watch?v=RdufyzkYSPU '''Video Beispiel''']
+Als Perimetertrackingalgorithmus wird ein one bounce Algorithmus verwendet. Der Algorithmus fährt counter clockwise den Perimeter ab. Dabei bounced die rechte äußere Spule immer gegen den Perimeter von außen. Wenn diese gegen den Perimeter stößt, wird die Spule erstmal vom Perimeter abgestoßen. Danach bewegt sich die Spule in einem Bogen zum Perimeter hin. [https://www.youtube.com/watch?v=Y3wxURV0qtw '''Video Beispiel''']
+[[Datei:OneBounce.png]]
+Der Algorithmus ist in der Datei: bGotoAreaX.h Klasse: TlineFollow implementiert.
+Die folgende Darstellung zeigt die if Abfragen in einer anderen chronologischen Reihenfolge zur besseren Erklärung, als diese tatsächlich im Programmcode stehen. Daher nicht verwirren lassen, wenn man den Programmcode ansieht.
+Ablauf:
+Die rechte Spule befindet sich immer außerhalb des Perimeter.
+Wenn diese den Perimeter nach innen überschreitet, wird als erstes eine aggressive Drehung clockwise ausgeführt mit:
+ bb.motor.L->setSpeed((bb.cruiseSpeed + 5));
+ bb.motor.R->setSpeed((bb.cruiseSpeed - 20));
+Sollte die Spule dann nach 1 Sekunde nicht außerhalb sein, wird die Drehung aggressiver:
+ if ((millis() - lastTransitionTime) > 1000) { // If more than 1sec inside rotate aggressive
+   bb.motor.L->setSpeed((bb.cruiseSpeed + 10));
+   bb.motor.R->setSpeed(-25);
+ }
+Sollte die Spule dann nach 1,5sek Sekunde nicht außerhalb sein, wird gedreht
+ if ((millis() - lastTransitionTime) > 1800) {
+   bb.cruiseSpeed = 25;
+   bb.driveDirection = DD_ROTATECW;
+   bb.motor.L->setSpeed(25);
+   bb.motor.R->setSpeed(-25);
+}
+Wenn die Spule nun nach außen gedreht wurde, fährt der Roboter eine seichte Kurve counter clockwise, bis er den Perimeter erreicht.
+Für die Berechnung der Kurve, wird ein Integral verwendet, das mit dem Faktor Ki gesteuert werden kann.
+(Anmerkung: Das Integral wird auf 0 gesetzt, sobald die Spule den Perimeter überschreitet.)
+ integral = integral + (Ki*error); // der Wert error ist eine Konstante und hat den Wert -1 wenn die Spule außerhalb des Perimeters ist.
+ double Output = integral;
+Das Fahren der Kurver erfolg dann folgendermaßen: Dadurch, dass das Integral größer wird, wird die Kurve mit zunehmender Integralgröße kleiner.
+ bb.motor.L->setSpeed((bb.cruiseSpeed + Output));  // beachte: Output ist negative
+ bb.motor.R->setSpeed((bb.cruiseSpeed));
+Wenn nach 1 Sekunde der Perimeter nicht überschritten wurde, wird aggressiver die Kurve gefahren;
+ if ((millis() - lastTransitionTime) > 1000) { // If more than 2sec Outside rotate aggressive
+   bb.motor.L->setSpeed((bb.cruiseSpeed + Output));
+   bb.motor.R->setSpeed((bb.cruiseSpeed +5));
+ }
+Wenn nach 1.5 Sekunde der Perimeter nicht überschritten wurde, wird noch aggressiver die Kurve gefahren:
+ if ((millis() - lastTransitionTime) > 1500) { // If more than 2.8sec Outside rotate more aggressive
+   bb.motor.L->setSpeed((bb.cruiseSpeed + Output));
+   bb.motor.R->setSpeed((bb.cruiseSpeed +10));
+ }
+Wenn nach 2 Sekunde der Perimeter nicht überschritten wurde, wird gedreht:
+ if ((millis() - lastTransitionTime) > 1500) { // If more than 2.8sec Outside rotate more aggressive
+   bb.motor.L->setSpeed((bb.cruiseSpeed + Output));
+   bb.motor.R->setSpeed((bb.cruiseSpeed +10));
+ }
+ if ((millis() - lastTransitionTime) > 2000) { // If more than 3.5sec Outside rotate full
+   bb.cruiseSpeed = 25;
+   bb.driveDirection = DD_ROTATECC;
+   bb.motor.L->setSpeed(-25);
+   bb.motor.R->setSpeed(25);
+ }
+Sollte die linke Spule außerhalb des Perimeters sein, wird sofort counter clockwise gedreht:
+ if (bb.perimeterSensoren.isLeftOutside() == true) {
+   bb.cruiseSpeed = 25;
+   bb.driveDirection = DD_ROTATECC;
+   bb.motor.L->setSpeed(-25);
+   bb.motor.R->setSpeed(25);
+   waitForRightInside = true;
+ }
+Zum Einstellen des Algorithmus sollte als erstes versucht werden eine gerade Strecke zu fahren. Dabei ist das erste Rausdrehen zu konfigurieren und Ki für den Bogen zum reinfahren.
+Testen des Algorithmus:
+Den Roboter auf den Perimeter stellen, so das die rechte Spule außen ist und die linke Spule innen. Mit dem Befehl
+ tpt     //test perimeter tracking to dock. Mower stands on perimeter
+das Perimetertracking starten.
+Der Befehl
+ M
+stoppt den Test.
+Mit dem Befehl
+ set.lfki,1.1
+kann der Ki Wert während des Testen eingestellt werden. Der Wert muss wenn zufriedenstellend ermittelt, in der Klasse TlineFollow im Konstructor zugewiesen werden.
+Wenn die Antriebsräder hinten sind, ist der Abstand zu den Spulen größer und die Spulen können außerhalb der Mitte angeordnet werden. Bei dem original Ardumower Chassis sind die Antriebsräder vorne. Hier muss die rechte Spule nah der Mitte angeordnet werden, ansonsten ist die Drehung zu asymmetrisch. Aufgrund der kurzen Distanz ist vermutlich auch das Bounce-Intervall von 1 Sek. zu verkürzen, so dass auf gerader Strecke vermutlich alle 0.3Sek gebounced werden muss.(aktuell nicht getestet)
+==Schnelle Rückkehr==
+Auf dem Rückweg zu Ladestation kann es sein, dass der Mower an einer Stelle auf das Perimeter fährt, so dass er den gesamten Perimeterdraht bis zur Ladestation abfahren muss. Um diesen Weg zu verkürzen, gibt es die schnelle Rückkehr.
+Der Anwender muss dazu das Perimeterkabel so verlegen, dass es ein Viereck ergibt. Diese Viereck wird dann vom Roboter beim Perimetertracking erkannt. Wenn er das Viereck erkannt hat, dreht er sich um 90 Grad vom Perimeter weg in den Innenbereich, und fährt auf die andere Seite des Rasens. Wenn er dort das Perimeterkabel entdeckt, nimmt er von dieser Stelle das Perimetertracking wieder auf.
+Um die schnelle Rückkehr zu aktivieren muss folgende Option in config.h gesetzt werden.
+ #define CONF_DISABLE_FAST_RETURN   false
+Für das Viereck hat sich folgende Abmessung als günstig herausgestellt. Es kommt allerdings auch auf die Abmessungen des Mowers an. Der Mower sollte bei dem Tracking in den Drehmodus kommen. Drehen bei der ersten Linkskurve. Dann drehen bei der nächsten Rechtskurve. Dann Linkskurve fahren. [Video:https://youtu.be/ipdVJzQn5Tc]
+Das Viereck kann auf zwei Arten verlegt werden. Einmal mit Ecken und einmal mit abgeflachten Ecken. Die Abgeflachten Ecken sind dazu da, dass der Mower an der Ecke besser erkennt, in welche Richtung er sich vom Perimeter wegdrehen soll, wenn er fast parallel zum Perimeter fährt. Dadurch ist die Perimeternahe Spule als erstes draußen und er dreht vom Perimeter weg anstatt zum Perimeter hin. Das ist notwendig, falls hinter dem Perimeter ein Beet kommt in das sich der Mower reindrehen könnte.
+[[Datei:ViereckSchnelleRückkehr.JPG]]
+[[Datei:ViereckSchnelleRückkehr2.JPG]]
+<gallery>
+  File:Raindancer FastReturn.png |  Beispiel, wie ich meine Vierecke angebracht habe
+</gallery>
+Die Erkennung ist abhängig von der Position der Spulen und vom Abstand der Spulen zum Antriebsrad.
+Die Implemetierung steht in der Datei: bPerimeterTracking.h Klasse: class TfindTriangle : public Node
+Die Erkennung erfolgt anhand des jeweils gedrehten Winkels.  Sie wurde mit einer Statemachine umgesetzt.
+Den Ablauf der Statmachine und die berechneten Winkel kann man sich mit dem Befehl bht.tri  anzeigen lassen.
+ bht.tri
+Die entsprechenden Winkel und maximal Distanzen muss man dann im Code in der Klasse: class TfindTriangle  anpassen.
+Im Folgenden die leicht ausgedünnte Klasse um einen besseren Überblick zu bekommen. Die Zeilen errorHandler.setInfoNoLog(..) sind die Ausgabe, wenn der Befehl bht.tri aktiviert wurde. Diese wurden hier mit aufgeführt um die Ausgabe besser interpretieren zu können.
+  virtual NodeStatus onUpdate(Blackboard& bb) {
+    ...
+Der gefahrene Winkel wird vor dem Case Statement alle 500ms ermittelt.
+    //============================================
+    // Calculate driven angle every 500ms.
+    //============================================
+    if (millis() - lastRunAngleCalculation >= 500) {
+      lastRunAngleCalculation = millis();
+      ...
+      angle = (cmL - cmR)  * 57.2957795f / CONF_DISTANCE_BETWEEN_WHEELS_CM;
+      if (flagShowFindTriangleStates) {
+        errorHandler.setInfoNoLog(F("Winkel: %f cmL %f cmR %f\r\n"), angle, cmL, cmR);
+      }
+    }
+Abfrage der States
+    // Check for left curve / right curve / second left curve
+    switch (state)
+    {
+Im case 0 wird nach eine Linkskurve gesucht. Ein negativer Winkel bedeutet eine Linkskurve/-drehung. Wenn der Winkel z.B. <-25 Grad ist, wurde diese gefunden und es wird in den case 1 geschaltet.
+    case 0:  // search for left curve
+      if (angle < -25) {
+        if (flagShowFindTriangleStates) {
+          errorHandler.setInfo(F("!03,s0 set state = 1 Left turn found angle: %f ms: %lu\r\n"), angle, millis());
+        }
+        bb.motor.startDistanceMeasurementTriangle();
+                ...
+        state = 1; // Activate triangle searching
+      }
+      break;
+In case 1 wird ständig überprüft, ob eine bestimmte Strecke nach der Linkskurve überschritten wurde. Im Beispiel 55cm. Wenn ja, ist das zu weit und es wird wieder zurück in den case 0 gesprungen, da es nicht sein kann, das die erste Strecke so lang ist. Wenn innerhalb der Strecke von 55cm dann ein  Winkel > 50 gefunden wurde, wird in den case 2 gesprungen.  Ein positiver Winkel bedeutet eine Rechtskurve/-drehung.
+    case 1: // search for right turn
+      distance = bb.motor.getDistanceInCMForTriangle();
+      if (distance > 55) {
+        state = 0;
+        if (flagShowFindTriangleStates) {
+          errorHandler.setInfo(F("!03,s1 set state = 0 distance %f > 55 ms: %lu\r\n"), distance, millis());
+        }
+      }
+      else if (angle > 50) {
+        if (flagShowFindTriangleStates) {
+          errorHandler.setInfo(F("!03,s1 set state = 2 angle %f distance %f < 50\r\n"), angle, distance);
+        }
+        bb.motor.startDistanceMeasurementTriangle();
+        ...
+        state = 2;
+      }
+      break;
+In case 2 wird als erstes wieder die gefahrene Distanz nach dem Rechtswinkel überprüft. Solange die Distanz von 50 cm nicht überschritten wurde, wird auf eine Linkskurve geprüft. Wenn der Winkel <-25 Grad ist, wurde diese erkannt und es wird in den State 3 gesprungen.
+    case 2:  // search for second left curve
+      distance = bb.motor.getDistanceInCMForTriangle();
+      if (distance > 50) {
+        state = 0;
+        if (flagShowFindTriangleStates) {
+          errorHandler.setInfo(F("!03,s2 set state = 0 distance %f > 50 ms: %lu\r\n"), distance, millis());
+        }
+      }
+      else if (angle < -25) {
+        if (flagShowFindTriangleStates) {
+          errorHandler.setInfo(F("!03,s2 set state = 3 angle %f distance %f < -25\r\n"), angle, distance);
+        }
+        bb.motor.startDistanceMeasurementTriangle();
+         ...
+        state = 3;
+      }
+      break;
+Case 3 gibt BH_SUCCESS an den BHT zurück und es wird auf die andere Seite des Rasens gefahren.
+    case 3:
+      if (flagShowFindTriangleStates) {
+        errorHandler.setInfo(F("!03,s3 set state=0  Cross Lawn Activated\r\n"));
+      }
+      state = 0;
+      return BH_SUCCESS;
+      break;
+       ...
+    }
+    return BH_RUNNING;
+  }
+Testen des Algorithmus: Den Roboter auf den Perimeter stellen, so das die linke Spule außen ist und die rechte Spule innen. Mit dem Befehl
+ tpt     //test perimeter tracking to dock. Mower stands on perimeter
+das Perimetertracking starten.
+Mit dem Befehl
+ bht.tri
+die Ausgabe der Viereckserkennung starten. (tri steht für triangle, da vorher wurde ein Dreieck zur Erkennung verwendet wurde)
+==Mähzonen zwischen aneinander liegenden Flächen==
+Mähzonen können eingerichtet werden zwischen aneinander liegenden Flächen die eine direkte Verbindung haben. Dazu wird das Perimeterkabel zwischen den Flächen in einem Abstand von ca. 13cm verlegt. Es wird eine Lücke von ca. 30cm zu dem gegenüberliegenden Perimeterkabel gelassen. Dadurch ist die Wahrscheinlichkeit geringer, dass der Roboter auf die andere Fläche fährt.
+Siehe Bild:
+<gallery>
+  File:RaindancerGroundAreas.png |  Beispiel, Mähzonenabgrenzung
+  File:RaindancerZoneKabelverlegung.png |  Abmessungen
+</gallery>
+''(Im obigen Bild ist es normal nicht notwendig Mähzonen einzurichten, da der Roboter durch den Algorithmus relative gut alle Bereiche des Rasens abdeckt.)''
+Der Abstand des Bereichsabgrenzungskabels zum gegenüberliegenden Perimeterkabel (hier 30cm Abstand) kann durch Tests optimiert werden. Der Abstand hängt von der Funktionalität des Perimetertracking ab. Zum einen von der Position der linken Spule beim Tracken des gebenüberliegenden Kabels, sowie das Tracking des Bereichsabgrenzungskabels selber.
+Da der Roboter voreingestellt mit den Spulen ca. 20cm über das Kabel fährt, kann es sein, dass er mit den Spulen dann innerhalb des nächsten Bereichs stehen bleibt.
+Das Anfahren eines Bereiches aus der Ladestation heraus erfolgt mit dem Befehl:
+ area,x     //wobei x der zurückzulegende Weg in m ist.
+Wurde die angegebene Strecke x am Perimeter zurückgelegt, fängt der Mower an zu mähen.
+Die gefahrene Distanz auf dem Perimeter kann mit dem Befehl
+ show.distance
+angezeigt bzw. gemessen werden.
+Achtung: Man sollte sich genau merken, wo die Kabel für die Mähzonenabgrenzung liegen für den Fall, dass der Rasen vertikutiert wird.
+==Verlegung des Perimeterkabels an Ecken==
+Der Mower bestimmt in welcher Richtung er sich am Perimter dreht anhand der zuerst rausgefahrenen Spule. Daher ist es wichtig die Ecken nicht im 90 Grad Winkel zu verlegen.
+Wenn der Mower z.B, mit der rechte Spule nahe am Perimeter langfährt und dann an der Ecke rausfährt, sollte auch die rechte Spule als erstes aus dem Perimeter fahren.
+In den folgenden Bildern sind drei Beispiele zu sehen, wie Ecken verlegt werden sollten.
+<gallery>
+  File:RaindancerCorner1.png |  Außenecke
+  File:RaindancerCorner2.png |  Außenecke
+  File:RaindancerCorner3.png |  Innenecke
+</gallery>
+==Temperatur Sensor==
+Es werden die Temperatursensoren DHT11/DHT21/DHT22/AM2301 unterstützt. Aktuell wurde aber nur mit dem Sensor DHT22 getestet.
+Der Temperatursensor wird mit dem dafür vorgesehenen Port des PCB1.3 verbunden.
+In config.h wird der verwendete Temperatursensor konfiguriert:
+ #define DHTTYPE DHT22
+Zum enablen des Services muss folgende Zeile konfiguriert werden:
+ #define CONF_DISABLE_DHT_SERVICE   false   // Disables temp sensor
+Mit folgendem Befehl wird der Sensor ausgelesen:
+ temp.show
+Im manuellen Mode wird der Sensor direkt ausgelesen. Es werden Temperatur, Luftfeuchtigkeit und die letzte gespeicherte Temperatur im Service angezeigt.
+Im auto mode wird nur die Temperatur die im Service gespeichert wurde angezeigt. Die Temperatur wird aktualisiert wenn der Mower über den Perimeter fährt und zum stehen kommt und mindestens 20 Sek. seit der letzten Messung vergangen sind.
+Der DHT Service schaltet den Strom des PCB1.3 ab, wenn eine Temperatur von 50 Grad zwei mal gemessen wurde:
+ #define CONF_OVERHEATING_TEMP  50.0f   // if this temperature is measured, robot shuts down the complete power for security
+==Regen Sensor==
+Wenn der Roboter im AUTO Modus mäht und es anfängt zu regnen, fährt der Roboter in die Ladestation zurück.
+Der Regensensor wird mit dem dafür vorgesehenen Port des PCB1.3 verbunden.
+Die Empfindlichkeit des Regensensors, wird am Regensensor mit dem Poti eingestellt.
+Zum enablen des Services muss folgende Zeile konfiguriert werden:
+ #define CONF_DISABLE_RAIN_SERVICE false   // Disables rain sensor
+Der Regensensor wird ca. alle 1.7 Sekunden ausgelesen.
+Das ausgelesene Ergebnis kann mit
+ rain.show
+angezeigt werden.
+==Shutdown Service==
+Wenn der shutdown service aktiviert wird, schaltet dieser den Strom über die Undervoltageprotection ab.
+Wenn ein Raspberry PI an den USB Port angeschlossen ist kann
+ CONF_WAIT_FOR_PI_SHUTDOWN  = true
+gesetzt werden.
+Dann wartet die Software 50 Sekunden bis zur Abschaltung.
+Es wird jede Sekunde $PwrOff und ein Countdown zu dem PI geschickt, so dass dieser herunterfahren kann.
+Mit dem Befehl:
+ poweroff
+kann der shutdown über die Benutzerschnittstelle oder vom PI aus aktiviert werden.
+Der shutdown service wir auch von dem Batterie Service und dem Temperatur Service zum herunterfahren verwendet.
+Somit wird der PI informiert, dass er herunterfahren soll, wenn die Batteriespannung zu gering oder die Temperatur zu hoch ist.
+==GPS Service==
+Der GPS Service empfängt die Daten von dem GPS Modul.
+Es gibt zwei Möglichkeiten diese Daten zu verarbeiten. Beide Möglichkeiten können parallel genutzt werden.
+ a) Die Empfangenen GPS Daten werden an das Raindancer Controlcenter weitergeleitet.
+ b) Die Empfangenen GPS Daten werden in der Raindancer Firmware ausgewertet. Man kann dann einen Bereich auf der Rasenfläche definieren.
+    Befindet sich der Mower in diesem Bereich wird angenommen, dass der Mower sich innerhalb der Perimeterschleife befindet. So besteht die Möglichkeit ein schwaches Perimetersignal auf größeren Flächen zu überbrücken.
+Das GPS Modul wird an den dafür vorgesehenen Anschluss an das PCB1.3 angschlossen. Das GPS Modul sendet periodisch Daten an das PCB1.3.
+Falls keine Daten empfangen werden, bitte folgenden Artikel lesen. Es kann sein, dass RX3 und TX3 auf dem PCB1.3 falsch verdrahtet wurden.
+https://www.ardumower.de/index.php/de/forum/navigation-gps-odmetrie/1737-wait-for-gps-position-data
+===Senden an das Raindancer Controlcenter===
+Zum aktivieren des GPS Services muss folgendes konfiguriert werden:
+ #define CONF_DISABLE_GPS false
+Für die erste Inbetriebnahme kann man folgende Parameter setzen:
+ #define CONF_GPS_PASS_THROUGH true
+ #define CONF_DEACTIVATE_GPS_CALCULATION true
+Der Parameter #define CONF_GPS_PASS_THROUGH sagt der Firmware, dass alle empfangenen GPS Daten zum Controlcenter geschickt werden sollen.
+Damit man diese Daten auf der Console angezeigt bekommt, muss folgender Befehl ausgeführt werden:
+ set.cco,1
+Nun sieht man alle Daten die an das Controlcenter geschickt werden. Darunter auch die GPS Datensätze.
+Mit folgendem Befehl stoppt man die Ausgabe:
+ set.cco,0
+Standardmäßig schickt das GPS Modul mehrere Datensätze in einem 1 Sekunden Intervall. Diese Datensätze werden nicht alle benötigt und erzeugen einen Overhead.
+Es wird nur der Datensatz: $GPRMC bei NEO-6M und $GNRMC bei NEO-M8N benötigt.
+Daher gibt es die Möglichkeit, das Modul bei dem Starten der Raindancer Firmware so einzustellen, das es nur den benötigten Datensatz schickt und dies auch nur in einem 3 Sekunden Takt.
+Dazu wird folgender Parameter eingestellt:
+ #define CONF_INIT_GPS_WITH_UBLOX  true
+Damit wird beim Hochfahren das Array const char UBLOX_INIT[] (steht in config.h) an das GPS Modul geschickt. Zum aktivieren bzw. deaktivieren muss man dann einzelne Zeilen ein- bzw. auskommentieren.
+===Aktivieren der internen Berechnung===
+Auch hier sollte #define CONF_INIT_GPS_WITH_UBLOX  true verwendet werden.
+Zum aktivieren der internen Berechnung muss
+ #define CONF_DEACTIVATE_GPS_CALCULATION false
+gesetzt werden.
+Bei dem NEO-6M Modul wird  der Datensatz: $GPRMC verwendet. Bei dem NEO-M8N wird der Datensatz $GNRMC verwendet.
+Daher müssen je nach verwendetem Modul folgende Zeilen ein bzw. auskommentiert werden:
+ #define CONF_N_GPRMC_STR            "$GPRMC"    // GPS messagetype begin for $GPRMC for NEO-6M
+ //#define CONF_N_GPRMC_STR          "$GNRMC"    // GPS messagetype begin for $GPRMC for NEO-M8N
+Mit
+ gps.show
+kann man sich die berechneten Werte anzeigen lassen.
+Falls man in UBLOX_INIT[] den Datensatz "GxGGA on" mit eingebunden hat, werden zusätzlich noch Quality, Satellites und Altitude angezeig. Diese werden aber nicht weiter verwendet.
+Es besteht die Möglichkeit einen GPS Bereich zu Konfigurieren, in dem der Mower annimmt er ist im Perimeter falls hier das Perimetersignal für die Erkennung zu schwach ist.
+Der Bereich wird als Polygon angegeben.
+ const float CONF_LAT_POLYGON_Y[] = { 54.083245f, 54.084068f,  54.084679f,  54.085623f,  54.084018f }; // Latitude polygon points
+ const float CONF_LON_POLYGON_X[] = { 10.447986f, 10.447055f,  10.446015f,  10.447120f,  10.44930f }; // Longitudinal polygon points
+ const int   CONF_NUMBER_OF_POLYGON_POINTS = 5;  // The number of the ploygon points
+Jede Spalte gehört zu einem Polygonpunkt. Man kann in https://www.google.de/maps z.B. einen Punkt in die Suche eingeben: 54.08728,10.448400. Dann sieht man wo diese Koordinate ist. So kann man dann punkt für punkt sehen, wie das Polygon aufgebaut ist.
+Wichtig ist, dass mit CONF_NUMBER_OF_POLYGON_POINTS die Anzahl der Spalten richtig definiert ist. Es können 3 bis N Koordinatenpunkte eingegeben werden. Allerdings schlage ich vor nicht mehr als 8 Punkte zu verwenden, um die Berechnungszeit so gering wie möglich zu machen.
+Um die Punkte zu ermitteln, kann man den Roboter an den entsprechenden Punkt stellen und gps.show eingeben. Dann wird z.B. folgendes angezeigt:
+ !03,$GPRMC,104503.00,A,5123.24690,N,00812.92063,E,0.094,,290718,,,A*72
+ !03,$GPRMC speed: 0.094000 course:0.000000
+ !03,$GPRMC lat: 54.08744800,N lon: 10.44867700,E
+ !03,$GPRMC date: 29.7.18 time: 11:45:3
+Der Punkt kann dann aus der Zeile !03,$GPRMC lat: 54.08744800,N lon: 10.44867700,E entnommen werden. Hier für Latitude = 54.087448 und Longitude=10.448677.
+Die Bereichserkennung wird mit
+ #define CONF_USE_GPS_POLYGON   true
+eingeschaltet.
+Es ist zu beachten, dass das GPS Signal eine toleranz von +-10m hat. D.h. man sollte weit genug vom Perimeter weg bleiben. Da das manchmal nicht geht, wurde noch der Parameter
+ #define CONF_PER_THRESHOLD_IGNORE_GPS   300
+eingeführt. Dieser besagt, dass wenn die Amplitude vom Perimeter diesen Wert überschreitet, wird auf jeden Fall das Perimetersignal verwendet und nicht mehr durch das GPS Signal überschrieben, auch wenn der Mower im GPS Bereich ist.
+Der Wert 300 muss entsprechend den eigenen Anforderungen eingestellt werden.
+[[File:warning.png]]'''Sicherheitshinweis: Falls das Perimetersignal ausfällt und der GPS Bereich den Perimeter überschreitet, wird der Mower den Perimeterbereich verlassen'''
+=Perimeter Sender=
+Es wird die original Ardumower Sender Hardware verwendet. Die Software wurde etwas abgeändert. Es wird ein 128 Bit Signal gesendet.
+Folgendes Perimetersignal wird gesendet:
+, 1, -1, -1, -1, 1, -1, -1, 1, -1, 1, -1, -1, 1, 1, -1, 1, 1, -1, -1, 1, 1, -1, 1, 1, -1, 1, -1, 1, -1, -1, 1, -1, -1, 1, -1, 1, 1, -1, 1, -1, 1, -1, 1, -1, 1, 1, -1, -1, 1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, -1, -1, 1, -1,
+ -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, -1, 1, 1, -1, 1, -1, -1, 1, -1, -1, 1, 1, -1, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, -1, -1, 1, -1, -1, 1, 1, -1, 1, 1, -1, -1, 1
+Die LEDs haben folgende Funktion (von links nach rechts):
+*1. 12V vorhanden
+*2.  5V vorhanden
+*3. Grün wenn der Interrupt läuft, der das Signal sendet ( rote LED nicht verfügbar). Aus wenn geladen wird.
+*4. Grün wenn ein Strom durch den Perimeter fließt, rot wenn keine Strom fließt (Perimeter unterbrochen) oder sehr wenig Strom. Aus wenn geladen wird.
+*5. Gelb der Roboter wird geladen. Perimetersignal ist ausgeschaltet.
+Achtung: die LEDs 3 und 4 sind Duo LEDs. D.h. diese haben zwei Farben. Bei LED 3. ist die rote LED nicht ansprechbar, da auf dem Nano der falsche Pin hardwaretechnisch connected wurde. Desweiteren, können die LEDs falsch herum eingelötet worden sein. Dann wundert man sich z.B., dass LED 4. rot ist obwohl alles in Ordnug ist und ein Strom fließt. Oder eben LED 3. rot anzeigt, obwohl ich hier grün geschrieben habe.
+'''Wenn der Sender an ist und der Roboter kehrt nach zwölf Stunden nicht in die Ladestation, schaltet der Sender das Signal ab.''' Dann entweder den Sender neu starten, oder den Roboter in der Ladestation laden.
+=Ladestation=
+Die Ladestationen werden gegen den Uhrzeigersinn angefahren.
+Wird keine Ladestation verwendet, sollte
+ CONF_DISABLE_CHARGINGSTATION = true
+eingestellt werden. Dann fährt der Mower bei geringer Batteriespannung zum Perimeter und bleibt stehen.
+==Kopfladestation==
+Wird eine Kopfladestation verwendet ist darauf zu achten , dass die Kontakte mindestens 3 cm nachgeben können wenn der Mower dagegen fährt. Besser wären 4 cm. Weiterhin ist zu beachten, dass der Anpressdruck der Kontaket ausreichend ist. Ich schlage daher die Verwendung von schleifenden Kontakten vor.
+Um eine Kopfladestation zu verwenden muss in config.h folgendes konfiguriert werden:
+ #define CONF_DISABLE_CHARGINGSTATION       false
+ #define CONF_PASS_THROUGH_CHARGING_STATION false //the mower can go through the station
+ #define CONF_HEAD_CHARGING_STATION         true  //the mower can't go through the station
+Mit dem Befehl
+ gohome
+wird der Mower beim Mähen angewiesen den Perimeterdrath zu suchen und in die Ladestation zu fahren.
+Zum Testen kann der Mower 2m vor der Ladestation auf den Perimeterdraht plaziert werden. Dann
+ tpt
+eingeben. Der Mower fährt dann zu Ladestation.
+Zum verlassen der Ladestation
+ area,0
+eingeben. Der Mower fährt dann 1m rückwärts, dreht um 90 Grad und fährt  50cm vorwärst. Dreht dann nochmal einen Zufallswinkel und fängt an zu mähen. Dieser Prozess läuft ohne Bumperschutz ab. Daher ist darauf zu achten, dass dieser Bereich frei von Hindernissen ist.
+Mit folgenden Parametern können die Fahrtstrecken konfiguriert werden:
+ #define CONF_HEAD_CHARGING_DRIVE_BACK_CM   100   //when the mower leaving the head charging station, how far it should drive back
+ #define CONF_HEAD_CHARGING_DRIVE_FORW_CM    50   //when the mower drove back and then rotates 90 degree, how far it should run forward that both coils securely inside
+Wenn der Mower die Ladekontakte erkannt hat, fährt er 3cm zurück und 3 cm vor.
+Dann wird das Laderelay eingeschaltet. Nach 10 Sekunden wird überprüft, ob ein Ladestrom fließt. Falls nicht, wird das Andocken ein zweites mal versucht. Wenn dies nicht funktioniert, wird ein Fehler ausgegeben.
+==Durchgangsladestation==
+Wird eine Durchgangsladestation verwendet ist darauf zu achten , dass die Kontakte mindestens 10cm schleifen können. Weiterhin ist zu beachten, dass der Anpressdruck der Kontaket ausreichend ist.
+Um eine Durchgangsladestation zu verwenden muss in config.h folgendes konfiguriert werden:
+ #define CONF_DISABLE_CHARGINGSTATION       false
+ #define CONF_PASS_THROUGH_CHARGING_STATION true   //the mower can go through the station
+ #define CONF_HEAD_CHARGING_STATION         false  //the mower can't go through the station
+Mit dem Befehl
+ gohome
+wird der Mower beim Mähen angewiesen den Perimeterdrath zu suchen und in die Ladestation zu fahren.
-Zum aktivieren der Bumper muss in der config.h fogende Zeile eingestellt werden:
+Zum Testen kann der Mower 2m vor der Ladestation auf den Perimeterdraht plaziert werden. Dann
-  #define CONF_DISABLE_BUMPER_SERVICE		true
+  tpt
+eingeben. Der Mower fährt dann zu Ladestation.
+Zum verlassen der Ladestation
+ area,10
+eingeben. Der Mower fährt dann 10m am Perimeter draht entlang und fängt dann an zu mähen. 10m kann gegen eine beliebige Entfernung ausgetauscht werden.
-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.
+Wenn der Mower die Ladekontakte erkannt hat, fährt er 4cm vorwärts, 3cm zurück und 3 cm vor. Dies dient dazu die Kontakte leicht zu schleifen für einen besseren Kontakt.
+Dann wird das Laderelay eingeschaltet. Nach 10 Sekunden wird überprüft, ob ein Ladestrom fließt. Falls nicht, wird das Andocken ein zweites mal versucht. Wenn dies nicht funktioniert, wird ein Fehler ausgegeben.
- // Orignal Ardumower Bumper
+=Troubleshooting=
- #if CONF_DISABLE_BUMPER_SERVICE == false
+==Mower bleibt stehen==
-   if (( /*diBumperL == LOW &&*/ diBumperR == LOW) && _bumperActivated) {
+[[Problem:]]
-     if (flagShowBumper) {
+Mower blieb stehen, Ursache war wohl der Sender. Da leuchteten nur
-       errorHandler.setInfo("!03,Bumper deactivated\r\n");
+noch die beiden linken LEDs. Sender ausgeschaltet und wieder
-     }
+eingeschaltet, 4 LEDs wieder auf grün und dann ging es wieder.
-     _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.
+[[Lösungsvorschlag:]]
-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.
+Die dritte grüne Leuchte von links zeigt an, ob der Sender Interrupt im Nano läuft.
-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öglichkeit a)
+Der Sender ist länger als 12h an, ohne das der Roboter wieder in die Station zurückgekehrt ist. Dann schaltet der Sender das Perimetersignal ab.
-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)
+Möglichkeit b)
+Da diese nicht an war scheint sich der Nano aufgehängt zu haben. Falls das noch mal passiert, würde ich den China Nano gegen einen original Arduino Nano austauschen. Da die Software bei mir seit einem Jahr läuft, gehe ich '''nicht''' davon aus, das diese die Ursache ist. Ich hatte vorher billige Nanos verwendet. Die waren bei mir nicht wirklich Frequenzstabil, was für den Sender aber notwendig ist. Nun habe ich einen Originalen drin.
- // Orignal Ardumower Bumper
+==Ich bekomme diese Meldung: Out: READ und In: CMD==
- #if CONF_DISABLE_BUMPER_SERVICE == false
+[[Problem:]] In Arduino Central wird folgendes angezeigt:
-   if (( /*diBumperL == HIGH &&*/ diBumperR == HIGH) && _bumperActivated) {
+ Out: READ
-     if (flagShowBumper) {
+ In: CMD: Command not recognized.
-       errorHandler.setInfo("!03,Bumper deactivated\r\n");
+ Out: READ
-     }
+ In: CMD: Command not recognized.
-     _bumperActivated = false;
+ Out: READ
-     //motor.hardStop();
+ In: CMD: Command not recognized.
-   }
+ Out: READ
-   if ((/*diBumperL == LOW ||*/ diBumperR == LOW && !_bumperActivated) {
+[[Lösungsvorschlag:]]
-     if (flagShowBumper) {
+In den Arduino Central Settings ist "Read Command -> Enable Read Command" eingeschaltet
-       errorHandler.setInfo("!03,Bumper activated\r\n");
-     }
-     _bumperActivated = true;
-     //motor.hardStop();
-   }
- #endif
-Bei zwei Schaltern:
+=Understanding the Behaviour Tree=
- #if CONF_DISABLE_BUMPER_SERVICE == false
+Die Beschreibung steht ausschließlich in Englisch zur Verfügung.
-     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)
+#REDIRECT [[Understanding the Behaviour Tree]]

Raindancer Firmware (Deutsch): Unterschied zwischen den Versionen

Aktuelle Version vom 9. August 2020, 12:59 Uhr

Inhaltsverzeichnis

Download

Überblick

Für eine minimale Inbetriebnahme sollten folgende Voraussetzungen erfüllt sein

Optional kann verwendet werden

config.h

QUICK START TO MOW

Errorhandling

Zum warm werden: Konfiguration des Batterie Service

Inbetriebnahme der Motoren

Inbetriebnahme der Encoder

Check des closed loop control services

Check des position control services

Mähmotor Inbetriebnahme

Perimeter Inbetriebnahme

Konfiguration Bluetooth

Einstellen Arduino Central

Erste Testfahrt

TUNE UP

Konfiguration der Bumper an den Bumperanschlüssen

Charge Service

Watchdog

Unterspannungsabschaltung

I2C Bus

RTC

EEPROM

Geschwindigkeit am Perimeter verlangsamen

Mähmotorstrom einstellen

Langsamer fahren, wenn Mähmotor belastet

Perimeter Tracking

Schnelle Rückkehr

Mähzonen zwischen aneinander liegenden Flächen

Verlegung des Perimeterkabels an Ecken

Temperatur Sensor

Regen Sensor

Shutdown Service

GPS Service

Senden an das Raindancer Controlcenter

Aktivieren der internen Berechnung

Perimeter Sender

Ladestation

Kopfladestation

Durchgangsladestation

Troubleshooting

Mower bleibt stehen

Ich bekomme diese Meldung: Out: READ und In: CMD

Understanding the Behaviour Tree

Navigationsmenü

Suche