Mower correts path too agressively at low speeds.

[ShadedSelf]

Since the steering restrictions were removed I noticed that the mower turns quite aggressively at low speeds.
This is noticeable right after turning after reaching a waypoint and when the gps is on float, Ive seen the mower do a 180 in a fraction of a second.
This happens because the stanley correction is inversely proportional to speed.

Possible solution:
Make the stanley softening variable user adjustable, having a larger softening variable means that the heading correction is less correlated with speed, this should also remove the need to have two different sets of stanley values for normal and low speeds.

[disaster123]

@greymfm i saw this as well - but didn't noticed that this is related to the stanley stuff.

[greymfm]

Thanks. Well, I think I have a better solution: we all like fast control corrections (and for a GPS FIX they are here quite good now). However if the "GPS jumps behind or beside the robot" (e.g. due to FLOAT) while driving, fast control corrections are not what we want :) Actually, we don't want any corrections at all if something like that happens. So, my suggestion is that the robot stops driving and turns in place if the angle error to the target is more than e.g. 90 degree...

[ShadedSelf]

Oh yeah, we need something different for float, as it is right now I would rather have the mower stop when the gps flaots.
I see there is a issue opened about using just the imu and heading when floating, that would probably be better yeah, or at least not use gps for heading estimation/fusion while floating.

Right now while going in and out of waypoints sunray doesnt seem to use the slow stanley values, so we get crazy heading corrections even with fixed gps, this could be fixed using the slow stanley variables for waypoints, in my opinion a larger stanley softening value is more elegant though 😊.

Ill try those changes and see how it feels.

[greymfm]

I modified it (b92b11f) and now I'm testing this modification...

[ShadedSelf]

So, if the heading varies by more than 45 degress, rotate intead of stanley tracking?
That helps with gps jumps.

Ive tried adding a larger softening value, the mower runs smoothly at low speeds now.

Previous settings:

1. Max speed: 0.4 m/s
2. Stanley P (heading error gain): 2.5
3. Stanley K (cross track error gain): 1
4. Stanley Ksoft: 0.001 m/s

Current settings:

1. Max speed: 0.4 m/s
2. Stanley P (heading error gain): 2
3. Stanley K (cross track error gain): 2
4. Stanley Ksoft: 0.4 m/s

In literature Ksoft is set to 1m/s apparently.
Also Stanley is made for actual cars, since this is a differential drive robot I feel like we dont want to be dividing by the speed at all.

[greymfm]

Changing the Stanley controller will require to do all tests again (low speed and high speed) with a specific robot as this controller is very robot dependent (mass, motors etc.). Are you testing with Alfred, Ardumower stock motors or something else? :-)
Note, that the 0.001 is only to avoid dividing by zero, the actual value is between 0.1 (docking) and 0.4 (high-speed mowing) - I typically use 0.2 for mowing speed...

[ShadedSelf]

Im using standard ardumower from this year.

Seems like its not only to avoid dividing by zero:
Here

4.3 Lateral Control
Another difference with respect to equation (1.22) is the presence of a softening constant
ksof t. This constant can be tuned according to the vehicles’ longitudinal speed, which
in standard conditions will be kept under 2m/s.

After a few attempts at a speed of 1m/s and with Stanley gain k = 2, the steering action appeared too sharp. For this reason, it was decided to add a softening constant ksof t = 3
to the control law, which is suitable in low- speed cases like this.

Maybe I notice it more because I need a bigger K to stay on track at 0.4 m/s, so at low speeds it becomes more unstable.
Next time Ill test without dividing by the robot speed.

[ShadedSelf]

Ok, feels pretty good without the speed factor, with a P of 2 and a K of arund 3-4 works well fo both low and high speeds.

The code then becomes:
angular = p * trackerDiffDelta + atan(k * lateralError);

[disaster123]

I still saw situations where the mower takes far too long to correct the path especially for a mow point 10m away - i would expect that the mower tries to get to the mowline in 1-2m of driving

[ShadedSelf]

With the above code?
What speed, P and K?
K needs to be a lot larger since we are not dividing by speed anymore.

[disaster123]

No with original Code and for Alfred those values are very low (see: https://github.com/Ardumower/Sunray/blob/master/alfred/config.h#L381) because otherwise it starts to swing left to right.

[SirVival71]

Is there an additional planned change?

I've still the problem that the mower sometimes turns very fast at a waypoint. Mostly it turns smooth and then it speeds up. After that it often has a deviation to the target direction and has to correct it within the path tracking.

At waypoints with only a small needed angle correction, the mower does not slow down any more. Here the new path direction is often not exact enough and it has to correct it while path tracking.

I have this new behavior since I changed from Sunray v.1.0.306 to v.1.0.314 (commit b44caf) and I believe it is a result of the removal of steering restrictions, too.
Perhaps, it depends on gps float. I've recognized the behavior only in two edges where float could happen and only at the beginning of the mowing process (first part of driving the perimeter) where jumps could happen as correction to learning better position.

This happens with standard ArduMower + standard brushless drives and mowing speed =0.4m/s.
But it seem not to be a special problem with ArduMower. Some Alfred user seem to have the same behavior.

I think, not to speed up the turning speed in these situations and slow down at all waypoints as it was before would be preferable behavior.

[ShadedSelf]

You can try the suggested code replacing this line linetrackere.cpp

@greymfm are you interested in merging this?