Tuning big rover

After a topic about GPS YAW, we succeed to get to the next step: Tuning of steering
(I now the throttle can be improved too, but we have an extra controller that makes a differential drive for both rear wheel motors, I have some extra functions in this code. For example drive slower when steering more, this will screw up the throttle tuning).

The mechanical steering of this rover takes like for ever, I have changed the setup of the actuator, but still slower than standard rovers.
Currently it steers nice and stable, but in my opinion I can see two parts of the steering tuning that can make it drive much better, but I can use some help with this:

  1. but after a turn it just takes too long for it to get back to the yellow line. I think the rover doesn’t steer enough at that moment. (PID: I?)
  2. after the rover has reached the yellow line again, we do have a litte overshoot causes it to drive on the other side of the yellow line for a short time. (PID: P?)

2022-03-01_steering_tuning.param (15.3 KB)

Log-file of the video is coming…


Something to try: On our rover, using the same steering parameters as you are, we dropped the “Lat Acc Ctrl Period” to a very low number (1) out of desperation and everything started working splendidly. We are mowing with a 4” overlap using a 60” deck without striping. You have a much different rover and our answer may not be the best solution, but it’s working. Good luck!

Consider using a large servo motor instead of that linear actuator. There are plenty of high torque motors that can operate in closed loop mode and provide better response.

1 Like

Thank you @Swebre, I have lowered the Lat Accn Ctrl Period, and it completely changed the behavior of the rover. For us, if I’m getting lower than 18, it gets very nervous, even when I try to match the P, I, FF settings.

Today I have found our best setup so far. But I would like to ask if you know how I can make the rover overshoot less? I think I can get the tuning for long straights right, but I’m not happy with turns like 90 degrees or more. The start of steering is good, ofcourse there is a overshoot, but this is okay. Because of this, it has to steer more than 90 degrees to get back to the yellow line as soon as possible. At this point I have two questions:

  1. Can you help me with getting back on the next yellow line while turning earlier? Maybe my driving velocity is too high (steering with linear actuator is very slow) at this moment?
  2. After is reaches the yellow line again, the heading of the rover is having a big deviation related to the next waypoint, so it will get another overshoot, and after steering back, it will again have a (smaller) overshoot. so in my opinion, it should steer back earlier (way before the position of the rover reaches the yellow line). I have tried a lot to achieve this, but unfortunately witouth luck so far…

— How can I upload a logfile to share this with you?
— If you have another idea of a possible improvement of a parameter, please also let me know :slight_smile:
20-04-2022_2027uur.param (15.3 KB)

Hi @Koenstruction,

We have instructions here for downloading logs files from the autopilot.

My guess is the turn rate controller tune needs improving but a log will show for sure.

Yes I have the file already, but how can I upload it in this forum?

If I’m looking to STER.DesTurnRate and STER.TurnRate, I can see the rover expects (red) to steer faster than it does (green). What parameter could this be? My steering isn’t linear because it is done with ackerman linear actuator. Can we help the expected PID accelerate steering less with a parameter?

Hi @Koenstruction,

Txs for the logs. Tuning large slow vehicles with lag in the response is quite difficult… they’re probably the most difficult vehicles to tune actually.

A few things I notice:

  • I guess the vehicle is actually a skid-steering vehicle but there is another controller in the middle which makes it appear to be an ackermann steering vehicle? This may be causing a few problems:

    • The vehicle won’t be able to do pivot turns
    • AP won’t be able to handle wheel output saturation. For example when one wheel is spinning at its maximum rate either turn rate or the speed (or both) must be sacrificed. If AP knows it is controlling a skid-steering vehicle it will tend to prioritise turn rate over speed meaning the vehicle will tend to stay on the path better (the MOT_STR_THR_MIX parameter controls the prioritisation)
    • Turn rate controller accuracy could be worse at higher speeds because Ackermann steering vehicle turn rate response changes with speed (and AP has compensation for this) while skid-steering vehicle response does not. My guess is that the vehicle is slow enough though that this doesn’t matter (the vehicle is always below 1m/s which is the MOT_SPD_SCA_BASE param value)
  • TURN_RADIUS is quite large at 10m. It might help to reduce this

  • WP_OVERSHOOT = 0. This means the vehicle will constantly be reducing its speed trying to stay exactly on the line. This probably isn’t helpful and it would be better to restore this to 2m.

  • the ATC_SPEED_FF is set to 0.1. This should probably be set back to “0” because CRUISE_SPEED and CRUISE_THROTTLE are essentially used as a feedforward so having both set is just a bit confusing.

  • NAVL1_PERIOD is very high (27). If set lower the vehicle will try to get back on the path more quickly

  • The speeed and turn rate controller tunes are pretty OK it’s just that the vehicle’s response is really slow.

  • ARMING_CHECK = 0. This is normally not a good idea because the arming checks will alert you to various setting that are incorrect. If possible it is better to resolve the errors or just disable one or two of the arming checks instead of all of them

  • ATC_STOP_SPEED = 0. This will mean the vehicle never stops trying to control the forward-back speed of the vehicel.

  • The RC failsafe has been disabled (FS_THR_ENABLE). I suspect you know what you’re doing but this can be a bit dangerous if the vehicle really is being controlled by RC (I suspect you have a ground station as well though)

Sorry I don’t have a silver bullet response to fix the issue. I suspect the biggest issue is the controller in the middle though.

I also wonder if it might be worth trying Rover-4.3.0-DEV (aka “latest”) which has SCurve navigation which may work better although it is a bit bleeding edge and hasn’t gone through beta testing yet.

Thank you, I will do some tests with your recommended numbers and come back to this topic!

I have the following:
From AP comes just a channel for throttle (PWM) and a channel for steering (PWM).
This goes into my arduino, this calculates differential for rear wheels (left and right) based on the steering. After this, the rear wheels are told to drive with 2 analog outputs of the arduino (0-5V) and the motorcontroller for our linear actuator (for steering) gets an analog output 0-5v too.
I couldn’t find a differential drive and a forced steering option in AP, so I made it myself (with some help of others ofcourse). It should not get in the way of the AP calculations, for AP it is just a normal rover with RC channel for throttle and for steering


Skid steering is here on the rover wiki and although it is not the default it is one of the most common setups.

I’m afraid it does make a difference in the controls for the reasons mentioned above. I can’t say for sure that switching to skid-steering will improve things enough to resolve all problems but I think it would be an improvement…