Improving the tracking precision of the mowing lines (by moving the GPS antenna)

AlexanderG

Lawn robot freak and project co-founder
Teammitglied
Hello,

You may have noticed that your Alfred robot mower sometimes does not follow the path precisely (depending on slope, ground disturbance, etc. it is 10cm apart the planned mowing line). The reason for this might be the position of the GPS antenna. This is how to improve this.

In an ideal world, the GPS antenna is located directly at the center point between the wheels axle (aka 'steering point' of the robot, point Q in the image below).
1722450250984.png
Unfortunately, this is not the case with Alfred robot mower (actually, it's located a few cm's behind the correct position). Now we have to two choices to improve this:

1. Transform the physical GPS position (not exactly between the wheels) to a virtual position (exactly between the wheels) like it is done here ( https://forum.ardumower.de/threads/sunray-ce-a-simple-collection-of-fw-mods.25444/ ). This also requires that we have a precise orientation of the robot (yaw, pitch ,roll), so we know the exact orientation of the robot coordinate frame in the GPS world frame. This can be done, and I will try this out too later (however, because we have slope here, I doubt the IMU will be sufficient precise for such a transformation...).

2. We can move the GPS antenna to the correct position. I have done this today. The position estimation is improved and due to this, one can set the line tracking controller more 'aggressive' (you could try this without a changed GPS antenna, however then the robot will start to oscillate on the mowing line).

As you can see the GPS antenna position is now directly between the wheels axle (and not few cm's behind them):
alfred_rtk_antenna.jpeg alred_rtk_antenna4.jpegalfred_rtk_antenna3.jpegalfred_rtk_antenna2.jpeg

The Stanley parameters I used for more 'aggressive' mowing line tracking (the sliders will appear if you toggle on the DEBUG button):
alfred_stanley.jpeg

These parameters can be changed permanently in your config.h ( you can find out more about how to custom compile your firmware here: https://github.com/Ardumower/Sunray?tab=readme-ov-file#sunray_alfred ) :
Code:
// stanley control for path tracking - determines gain how fast to correct for lateral path errors
#define STANLEY_CONTROL_P_NORMAL  2.0   // 3.0 for path tracking control (angular gain) when mowing
#define STANLEY_CONTROL_K_NORMAL  0.5   // 1.0 for path tracking control (lateral gain) when mowing

And because the robot position estimation is more precise now, we can reduce the target threshold (in config.h) that informs the robot if it has reached a target position:
Code:
// below this robot-to-target distance (m) a target is considered as reached
#define TARGET_REACHED_TOLERANCE 0.05    // 5 cm tolerance

With these changes (GPS antenna position, Stanley parameters, target threshold) the mowing line tracking precision has improved here greatly.

Cheers,
Alexander
 
Zuletzt bearbeitet:
@AlexanderG
passt vielleicht nicht 100% hier her, aber führt doch auch zu Problemen wenn nicht genug Platz zu Mauern etc. eingehalten wird bzw. die Position mal nicht 100%ig stimmt beim Anfahren.
Hast Du eventuell schon einen Plan für die Umsetzung von dem offenen Issue Zwecks Offset bzw. Abstand zum Perimeter? Mir persönlich würde schon vielleicht ein einstellbarer Abstand zum Perimeter oder Exclusion reichen.
 
Die Frage, die sich eher stellt, ist "Warum werden erst neue Funktionen wie Lidar und TTS entwickelt, anstatt die aktuellen Problemen beim bisherigen Funktionsumfang durch Hilfe der bereits vorhandenen Lösungen aus z. B. "Sunray CE" und " SunrayModdingSpielwiese" zu lösen?"
 
As I wrote above I doubt that the virtual antenna GPS solution will work robustly (we may try it) under all conditions (high slope or quickly changing ground surfaces as with in a hilly garden). What we need are solutions that work robustly and under all conditions. LiDAR is a good candidate and it can replace RTK one day as a more robust solution. In the meantime we will try to find solutions to make RTK more robust.
 
@AlexanderG
Maybe it doesn't fit 100% here, but it does lead to problems if there isn't enough space between it and walls etc. or if the position isn't 100% correct when starting off.
Do you perhaps already have a plan for implementing the open issue regarding offset or distance to the perimeter? Personally, an adjustable distance to the perimeter or exclusion would perhaps be sufficient for me.

If Im understanding correctly, this is quite simple to do:
 
Oben