Hallo,
hier diskutieren wir einen Umbau eines Husqvarna-Chassis auf Ardumower-Komponenten. Der Roboter wurde mir zusammengebaut zum Testen und zur Fehlersuche übergeben. Hier beschreibe ich nun was mir alles aufgefallen ist.
Zunächst ein paar Bilder vom Zusammenbau (wie mir der Roboter zum Testen/zur Fehlersuche übergeben wurde):
1. Button-Kabel:
Das Kabel zum Button (PCB-Button) hat sich immer wieder gelöst und so lies sich der Roboter oft nicht einschalten. Das Kabel sollte man ggf. verlängern. Desweiteren löst der Button scheinbar sporadisch selber aus und dadurch hört der Roboter im Mähbetrieb unerwartet auf zu arbeiten. Manchmal piept der Roboter direkt beim Einschalten oder später im Betrieb unendlich vor sich in ... das ist dann der (halb-)defekte gelbe Taster
(hier sollte ein Taster mit höherer Qualität eingesetzt werden).
2. Chassis Dimension, Rad-Grösse, Fahrrichtung:
Da die freien Rollen vorne sitzen (und die Antriebsmotoren hinten) habe ich die config.h entsprechend angepasst:
#define FREEWHEEL_IS_AT_BACKSIDE false // default Ardumower: true (change to false, if your freewheel is at frontside) - this is used for obstacle avoidance
#define WHEEL_BASE_CM 46 // wheel-to-wheel distance (cm)
#define WHEEL_DIAMETER 250 // wheel diameter (mm)
#define MOWER_SIZE 60 // mower / chassis size / length in cm
2. IMU:
Da hier eine MPU6050 zum Einsatz kommt habe ich entsprechend die config.h angepasst:
#define MPU6050
3. Da Bumper etc. nicht nicht angeschlossen sind habe ich diese zunächst alle deaktiviert:
#define BUMPER_ENABLE false
#define TOF_ENABLE false
#define RAIN_ENABLE false
#define SONAR_ENABLE false
// #define ENABLE_LIFT_DETECTION 1
4. Für SD-Karte wird nur das Fortsetzen-Feature aktiviert:
#define ENABLE_SD 1 // enable SD card services (resuming, logging)? (uncomment to activate)
// #define ENABLE_SD_LOG 1 // enable SD card logging? uncomment to activate (not recommended - WARNING: may slow down system!)
#define ENABLE_SD_RESUME 1 // enable SD card map load/resume on reset? (uncomment to activate)
5. Motor-Treiber:
Da hier ACT-Motortreiber zum Einsatz kommen wurde die config.h entsprechend angepasst:
#define MOTOR_DRIVER_BRUSHLESS 1 // uncomment this for new brushless motor drivers
#define MOTOR_DRIVER_BRUSHLESS_MOW_BLDC8015A 1 // uncomment for brushless BLDC8015A driver and mowing motor
#define MOTOR_DRIVER_BRUSHLESS_GEARS_BLDC8015A 1 // uncomment for brushless BLDC8015A driver and gear/traction motors
6. Motor-Odometrie:
Die Steuerung der Motoren über Sunray-App (Bluetooth) war nicht wirklich in Echtzeit (starker Nachlauf der Motoren etc.). Dies deutet darauf hin dass die Odometrie-Konfiguration (Ticks und/oder PID-Regler) nicht optimal eingestellt ist. Zum Überprüfen (steht auch im Sunray-Wiki): man bockt den Roboter auf (so dass die Räder in der Luft drehen) und geht dann in die Arduino Serial Console und sendet den Befehle "AT+E" (+ENTER) um den Odometrie-Test durchzuführen. Die Räder sollten dann genau 10 Umdrehungen machen. In diesem Fall haben sie mehr als 30 Umdrehungen gemacht und so habe ich den Wert durch probieren angepasst:
#define TICKS_PER_REVOLUTION 300 / 2
#define ENABLE_ODOMETRY_ERROR_DETECTION false
7. Motor-Drehrichtung:
Damit sich die Motoren in die richtige Richtung drehen habe ich diese noch angepasst:
#define MOTOR_LEFT_SWAP_DIRECTION 1 // uncomment to swap left motor direction
#define MOTOR_RIGHT_SWAP_DIRECTION 1 // uncomment to swap right motor direction
8. Motor-PID-Regelung:
Da die Mortoren jetzt zwar schnell über Joystick (Bluetooth) reagieren aber zwischendurch gestockt haben war klar, dass die Motor-PID-Regelung nicht optimal eingestellt ist. Diese wurde vom Alfred übernommen (scheinen ganz gut für dieses Gesamtsystem zu sein):
#define MOTOR_PID_KP 0.5
#define MOTOR_PID_KI 0.01
#define MOTOR_PID_KD 0.01
Damit lief die Geschwindigkeitsregelung für die Motoren weich und das Stocken war weg.
9. Da ich das eingesetzte XBee-NTRIP-Modul nicht einsetzen wollte habe ich kurzerhand mein XBee-866 Mhz Modul eingesetzt. Damit konnte ich das RTK ans Laufen bekommen.
10. Nun wurde ein Perimeter-Rechteck festgelegt, dies auf den Roboter hochgeladen und getestet:
Video:
drive.google.com
Der Erste Test sah schon ganz gut aus und mir sind weitere Dinge aufgefallen:
11. Stanley-Regler:
Der Roboter fuhr die Mähbahnen nicht gerade ab (pendelete stark). Die GPS-Antenne ist nicht exakt mittig zwischen den Rädern angebracht worden (dies sollte man ggf. korrigieren). Desweiteren sollte die Stanley-Regelung zum Abfahren einer Linie optimal eingestellt werden:
Wenn man den DEBUG-Mode (Button) in der App aktiviert erscheinen ganz unten neue Regler zum Testen des Stanley-Reglers. Die so gefundenen Werte sind nicht permament und müssen abschliessend in der config.h eingetragen werden:
Video:
drive.google.com
Folgende Einstellungen scheinen ganz gut für dieses Gesamtsystem zu sein:
// stanley control for path tracking - determines gain how fast to correct for lateral path errors
#define STANLEY_CONTROL_P_NORMAL 2.6 // 3.0 for path tracking control (angular gain) when mowing
#define STANLEY_CONTROL_K_NORMAL 0.1 // 1.0 for path tracking control (lateral gain) when mowing
12. IMU-Aussetzer:
Hin- und wieder bricht die Kommunikation zur IMU zusammen (und kann dann aufgrund der schlecht implementierten I2C-Library vom Arduino-Framework nicht von dieser recovered werden). Sunray führt zwar ein IMU-Recovery durch (man hört Buzzer-Töne) aber das kostet Zeit. Hier könnte man die I2C-Kabel weiter verkürzern (am Besten das Modul direkt über die Buchsenleiste am PCB platzieren, siehe Sunray-Wiki), ggf. zum darunter liegenden Motor abschirmen etc.
13. Test-WLAN (Hotspot):
Damit das WLAN schneller getestet werden kann habe ich in der "esp32_ble/config.h die Verbindungsparameter für einen Handy-Hotspot eingetragen:
#define WIFI_STA_SSID "hero_hotspot" // WiFi SSID
#define WIFI_STA_PSK "xxxxxxxxxxxxxx" // WiFi password ( siehe Zettel vorne im Roboter )
Am Handy aktiviert man nun einen Hotspot (mit oben genannten Zugangsdaten) und der Roboter kann sich dann über das Handy mit dem Handy-WLAN verbinden (ohne dass ein WLAN-Router zum Einsatz kommt welcher in der Regel zu bemerkbaren Latenzen bei der Kommunikation führt):
Im Anhang meine "config.h"
hier diskutieren wir einen Umbau eines Husqvarna-Chassis auf Ardumower-Komponenten. Der Roboter wurde mir zusammengebaut zum Testen und zur Fehlersuche übergeben. Hier beschreibe ich nun was mir alles aufgefallen ist.
Zunächst ein paar Bilder vom Zusammenbau (wie mir der Roboter zum Testen/zur Fehlersuche übergeben wurde):
1. Button-Kabel:
Das Kabel zum Button (PCB-Button) hat sich immer wieder gelöst und so lies sich der Roboter oft nicht einschalten. Das Kabel sollte man ggf. verlängern. Desweiteren löst der Button scheinbar sporadisch selber aus und dadurch hört der Roboter im Mähbetrieb unerwartet auf zu arbeiten. Manchmal piept der Roboter direkt beim Einschalten oder später im Betrieb unendlich vor sich in ... das ist dann der (halb-)defekte gelbe Taster
(hier sollte ein Taster mit höherer Qualität eingesetzt werden).2. Chassis Dimension, Rad-Grösse, Fahrrichtung:
Da die freien Rollen vorne sitzen (und die Antriebsmotoren hinten) habe ich die config.h entsprechend angepasst:
#define FREEWHEEL_IS_AT_BACKSIDE false // default Ardumower: true (change to false, if your freewheel is at frontside) - this is used for obstacle avoidance
#define WHEEL_BASE_CM 46 // wheel-to-wheel distance (cm)
#define WHEEL_DIAMETER 250 // wheel diameter (mm)
#define MOWER_SIZE 60 // mower / chassis size / length in cm
2. IMU:
Da hier eine MPU6050 zum Einsatz kommt habe ich entsprechend die config.h angepasst:
#define MPU6050
3. Da Bumper etc. nicht nicht angeschlossen sind habe ich diese zunächst alle deaktiviert:
#define BUMPER_ENABLE false
#define TOF_ENABLE false
#define RAIN_ENABLE false
#define SONAR_ENABLE false
// #define ENABLE_LIFT_DETECTION 1
4. Für SD-Karte wird nur das Fortsetzen-Feature aktiviert:
#define ENABLE_SD 1 // enable SD card services (resuming, logging)? (uncomment to activate)
// #define ENABLE_SD_LOG 1 // enable SD card logging? uncomment to activate (not recommended - WARNING: may slow down system!)
#define ENABLE_SD_RESUME 1 // enable SD card map load/resume on reset? (uncomment to activate)
5. Motor-Treiber:
Da hier ACT-Motortreiber zum Einsatz kommen wurde die config.h entsprechend angepasst:
#define MOTOR_DRIVER_BRUSHLESS 1 // uncomment this for new brushless motor drivers
#define MOTOR_DRIVER_BRUSHLESS_MOW_BLDC8015A 1 // uncomment for brushless BLDC8015A driver and mowing motor
#define MOTOR_DRIVER_BRUSHLESS_GEARS_BLDC8015A 1 // uncomment for brushless BLDC8015A driver and gear/traction motors
6. Motor-Odometrie:
Die Steuerung der Motoren über Sunray-App (Bluetooth) war nicht wirklich in Echtzeit (starker Nachlauf der Motoren etc.). Dies deutet darauf hin dass die Odometrie-Konfiguration (Ticks und/oder PID-Regler) nicht optimal eingestellt ist. Zum Überprüfen (steht auch im Sunray-Wiki): man bockt den Roboter auf (so dass die Räder in der Luft drehen) und geht dann in die Arduino Serial Console und sendet den Befehle "AT+E" (+ENTER) um den Odometrie-Test durchzuführen. Die Räder sollten dann genau 10 Umdrehungen machen. In diesem Fall haben sie mehr als 30 Umdrehungen gemacht und so habe ich den Wert durch probieren angepasst:
#define TICKS_PER_REVOLUTION 300 / 2
#define ENABLE_ODOMETRY_ERROR_DETECTION false
7. Motor-Drehrichtung:
Damit sich die Motoren in die richtige Richtung drehen habe ich diese noch angepasst:
#define MOTOR_LEFT_SWAP_DIRECTION 1 // uncomment to swap left motor direction
#define MOTOR_RIGHT_SWAP_DIRECTION 1 // uncomment to swap right motor direction
8. Motor-PID-Regelung:
Da die Mortoren jetzt zwar schnell über Joystick (Bluetooth) reagieren aber zwischendurch gestockt haben war klar, dass die Motor-PID-Regelung nicht optimal eingestellt ist. Diese wurde vom Alfred übernommen (scheinen ganz gut für dieses Gesamtsystem zu sein):
#define MOTOR_PID_KP 0.5
#define MOTOR_PID_KI 0.01
#define MOTOR_PID_KD 0.01
Damit lief die Geschwindigkeitsregelung für die Motoren weich und das Stocken war weg.
9. Da ich das eingesetzte XBee-NTRIP-Modul nicht einsetzen wollte habe ich kurzerhand mein XBee-866 Mhz Modul eingesetzt. Damit konnte ich das RTK ans Laufen bekommen.
10. Nun wurde ein Perimeter-Rechteck festgelegt, dies auf den Roboter hochgeladen und getestet:
Video:
ardumower_husqvarna.mp4
drive.google.com
Der Erste Test sah schon ganz gut aus und mir sind weitere Dinge aufgefallen:
11. Stanley-Regler:
Der Roboter fuhr die Mähbahnen nicht gerade ab (pendelete stark). Die GPS-Antenne ist nicht exakt mittig zwischen den Rädern angebracht worden (dies sollte man ggf. korrigieren). Desweiteren sollte die Stanley-Regelung zum Abfahren einer Linie optimal eingestellt werden:
Wenn man den DEBUG-Mode (Button) in der App aktiviert erscheinen ganz unten neue Regler zum Testen des Stanley-Reglers. Die so gefundenen Werte sind nicht permament und müssen abschliessend in der config.h eingetragen werden:
Video:
sunray_tune_stanley_controller.mp4
drive.google.com
Folgende Einstellungen scheinen ganz gut für dieses Gesamtsystem zu sein:
// stanley control for path tracking - determines gain how fast to correct for lateral path errors
#define STANLEY_CONTROL_P_NORMAL 2.6 // 3.0 for path tracking control (angular gain) when mowing
#define STANLEY_CONTROL_K_NORMAL 0.1 // 1.0 for path tracking control (lateral gain) when mowing
12. IMU-Aussetzer:
Hin- und wieder bricht die Kommunikation zur IMU zusammen (und kann dann aufgrund der schlecht implementierten I2C-Library vom Arduino-Framework nicht von dieser recovered werden). Sunray führt zwar ein IMU-Recovery durch (man hört Buzzer-Töne) aber das kostet Zeit. Hier könnte man die I2C-Kabel weiter verkürzern (am Besten das Modul direkt über die Buchsenleiste am PCB platzieren, siehe Sunray-Wiki), ggf. zum darunter liegenden Motor abschirmen etc.
13. Test-WLAN (Hotspot):
Damit das WLAN schneller getestet werden kann habe ich in der "esp32_ble/config.h die Verbindungsparameter für einen Handy-Hotspot eingetragen:
#define WIFI_STA_SSID "hero_hotspot" // WiFi SSID
#define WIFI_STA_PSK "xxxxxxxxxxxxxx" // WiFi password ( siehe Zettel vorne im Roboter )
Am Handy aktiviert man nun einen Hotspot (mit oben genannten Zugangsdaten) und der Roboter kann sich dann über das Handy mit dem Handy-WLAN verbinden (ohne dass ein WLAN-Router zum Einsatz kommt welcher in der Regel zu bemerkbaren Latenzen bei der Kommunikation führt):
Im Anhang meine "config.h"
Zuletzt bearbeitet: