Rover QuikTune simplified -- testers wanted

[rmackay9]

Thanks for all those who tested the initial version of QuikTune. Based on feedback that it was always producing gains that were too high I’ve simplified the script so that it only attempts to calculate the speed and steering (aka turn rate) controllers FeedForward values. The P and I are then set simply based on the FF value.

The new script is here and while I’ve tested it successfully I wonder if others would like to give it a try?

Instructions for running the script are at the top of the script but in short:

1. Ensure your autopilot has an H7 CPU (e.g. CubeOrange, Durandal, Pixhawk6, etc). An F7 will probably also work but an F4 definitely will not.
2. Ensure Rover-4.4 (or higher) installed on the autopilot
3. Set SCR_ENABLE = 1 and reboot the autopilot
4. Download rover-quicktune.lua from here
5. Upload the above script to your autopilot’s SD card’s APM/scripts directory
6. Setup an auxiliary switch to start/stop the tune by setting RCx_OPTIONS = 300 (scripting1) or alternatively you may use MP’s Aux Function tab with one entry set to “scripting1”
7. Arm the vehicle and switch to Circle mode
8. Start the tuen by moving the RC switch to the middle position or on MP’s Aux Function tab push the “mid” button
9. Check the ground station’s “Messages” tab to confirm the tuning is working
10. After the tune completes save the tuned values by moving the RC switch to the high position or on MP’s Aux Function tab push the “high” button
11. Run the vehicle through a square missing in Auto mode and provide feedback here.

By the way, if you ran an earlier version of the QuikTune script you may see some RTUN_xxx parameter value corruption. It is probably best to check the RTUN_ parameters to be sure the current values match the “Defaults” column.

One key thing that I would like to figure out is what RTUN_xx_P/I_RATIO values work best. I think that for most vehicles the ratio of FF to P and I is probably similar. Perhaps larger vehicles will need a lower ratio.

Thanks!

[stephendade (Stephen)]

Great! I’ll run it with my runt rover later in the week. I’ll check the pivot turn changes you recently added too.

[rmackay9]

@stephendade,

Great, thanks very much.

By the way, I think from your last tune with QuikTune it may have set the PSC_VEL_I/D values to be non-zero. I think it is probably best to return those to zero but up to you of course.

BTW, I think I will merge this latest Rover QuikTune to master shortly.

[admired]

good i will test it tomorrow if not rain

[admired]

can you put a file in this topic ? i can not download the file

[rmackay9]

Hi @admired,

Really sorry about that. We just merged it to master so the link above became invalid. I’ve fixed it now so could you try this link again?

[admired]

still thesame, i can not download ,maybe my internet is firewalled.

[dkemxr (Dave)]

Right click the link and Save Link As

[rmackay9]

@admired,

OK, not sure what’s going on but that’s a link to Ardupilot’s master branch so it should be completely open.

[stephendade (Stephen)]

I tested the new autotune and master on my Runt rover.

The tune worked really well. No over-tuning this time … it felt very nice running in ACRO mode.

Only issue I had was getting the cruise speed/throttle correct. The QuikTune requires a min speed of 0.5m/s, and my rover was having a little trouble reaching that, as its usual cruise speed is 0.6m/s. The initial cruise speed and throttle were 0.58m/s and 95% respectively, where it should be closer to 70%. I’m putting it down to my rover’s speed being fairly marginal, rather than the Quiktune though.

Not sure if there should be some upper limit on the cruise throttle estimate, particularly for skid-steer vehicles?

Navigation and pivot turn tuning were fairly straightforward afterwards.

Below is an auto mission with pivot turns (clockwise vehicle movement):

Ardupilot rover performance after auto tune

The pivot turns are really nice now. There’s a little bit over overshoot, likely due to a too high ATC_STR_ANG_P.

For reference, my tuned parameters are:

ATC_STR_ANG_P    4.000000
ATC_STR_RAT_D    0.020282
ATC_STR_RAT_FF   0.660293
ATC_STR_RAT_I    0.330146
ATC_STR_RAT_IMAX 0.400000
ATC_STR_RAT_MAX  90.000000
ATC_STR_RAT_P    0.330146
ATC_STR_RAT_MAX  90.000000
ATC_STR_ACC_MAX  180.000000

ATC_SPEED_D      0.007409
ATC_SPEED_FF     0.000000
ATC_SPEED_I      1.714367
ATC_SPEED_IMAX   0.300000
ATC_SPEED_P      1.714367

CRUISE_SPEED     0.600000
CRUISE_THROTTLE  80

PSC_POS_P        0.200000
PSC_VEL_D        0.050000
PSC_VEL_FF       0.305000
PSC_VEL_FLTD     5.000000
PSC_VEL_FLTE     5.000000
PSC_VEL_I        0.010000
PSC_VEL_IMAX     1.000000
PSC_VEL_P        1.200000

WP_PIVOT_ANGLE   45
WP_PIVOT_DELAY   0.000000
WP_PIVOT_RATE    90

[rmackay9]

@stephendade,

Thanks so much for testing!

The rover’s performance in the video looks very good to me actually.

I think it’s fine for the CRUISE_THROTTLE to be 100% especially if the vehicle will be spending a lot of time at its top speed.

[Lorbass1 (Otto Küng)]

@rmackay9 Will also test it later, actually difficult because of 20 cm Snow.

Another Idea:
Using a Lidar for a “simple” Obstacle avoidance it stopps at the defined distance, default 2m.
May be its enoughe smart for slow vehicles. My Rover is a Absima Yucatan with a top speed of 20 km/h.
Already with 10 km/h it reaches the obstacle just without crash. So I would need to set AVOID_MARGIN much higher.
But then it would be difficult to maneuver in narrow regions and need to switch to Manual.
Could the braking distance be calculated relativ to the speed?
E.g. by defining an AVOID_MARGIN_MAX and an AVOID_MARGIN_MIN.
It starts braking according to the speed. Finally it stopps at _MIN. Similar to the Mode Steering for turnrate.
Just as it is used by humans.
Whats your opinion?

[rmackay9]

Hi @Lorbass1,

Nice pic! That’s a lot of snow.

Re stopping, Rover should already be using the vehicle’s current speed and maximum acceleration when calculating how soon it needs to start braking so that it doesn’t hit something. I think you should be able to see the effect of this by changing ATC_ACCEL_MAX or just ATC_DECEL_MAX and then approach an obstacle at different speeds. At higher speed it should start slowing sooner.

If this isn’t how the vehicle’s behaving then I suspect the issue may be in the speed controller tuning.

[Lorbass1 (Otto Küng)]

@rmackay9
Thanks for your reply.
Yes, 4 times more Snow than usual in Europe.
I made some tests before my post and thats why I came to my proposition.
Instead of 2m it stopped at 0.45m.
Log: Test 13.bin - Google Drive

But I will make more test to see your advice with better GPS connection.
And use a lightweight obstacle in case of… because I would like to reduce the target distance.

[Fossil (Martin Rye)]

I managed at last to run the Quick Tune today.
Could not have got here without everyone’s help…thank you.

It went very well. I found the instructions easy to follow and very informative. Never run a lua script on ardurover until today.

Acro mode after the Quick Tune worked well.

Tried some simple missions after tuning and found that it kept stopping at some of the
way points. I changed Waypoint Pivot Angle to 0 and bingo. It was doing very nice 2m radius turns effortlessly with maybe a slight acceleration in the turn after that.

More to do but very happy.

Thank you all again.

[rmackay9]

Hi @Fossil,

Thanks very much for the feedback. Yes, the vehicle will stop at waypoints if the angle of the corner is greater than the WP_PIVOT_ANGLE parameter or if the waypoint command’s delay field has been set to 1 or higher (seconds).

By the way, when it was stopping at the corners did it pivot OK towards the next waypoint? … and how was it holding the line after the pivot?

There is actually one more potential improvement we could make to the pivot turns which is to remove the turn controller’s “I-term build-up” after it completes the turn. There can be a lot more friction when pivoting which means that the turn controller needs to work really hard to spin the vehicle around. When it does that the “I-term” builds up and it takes some time for it to reduce and that can lead to a wobble after the turn.

[Yuri_Rage]

@rmackay9, this is exactly what I will be watching for when I do my own testing. Went down another project’s rabbit hole this week and so still need to get beta11 on my machine. Will make an effort to get that done this weekend!

[Fossil (Martin Rye)]

@rmackay9

Thanks very much for the feedback. Yes, the vehicle will stop at waypoints if the angle of the corner is greater than the WP_PIVOT_ANGLE parameter or if the waypoint command’s delay field has been set to 1 or higher (seconds).

Thanks for your feedback @rmackay9. That would explain it. My WP angle was approximately 90 degrees and WP_PIVOT_ANGLE was set to 60 degrees.
The Rover did the turn well but just sat there pointing to the next waypoint. If I stopped the mission and then restarted it, it would carry on to the next point and do the same again.
I will experiment with pivot turns but at the moment I am looking for nice smooth turns with a large radius for mowing.

[Yuri_Rage]

Initial results very promising!

I reset PSC params to defaults prior to this session.

That first half circle had some big bumps, so I offset a little before initiating QuikTune. It completed quickly and with little issue, though I think my circle radius might have been on the ragged edge of too large (a couple of warnings to “increase steering”).

First auto mission looked pretty solid. Brief log review shows that STER.DesTurnRate may be overshooting a little, but the data is noisy (likely a combination of rough terrain and machine vibration).

I’ll run a longer mission as soon as I finish typing here and report any further findings and/or manual refinements of the tuning.

Log file (anon) linked here. Can provide .bin privately upon request.

(and yes, I still have arming checks disabled…I really ought to employ a solution to that…)

---

UPDATE (while the longer mission runs):
Based on my log review and observation during the mission, I made some very small tweaks to the autotuned values (mostly just rounding them slightly up or down from the long decimal values) and may have gotten slightly better results. I’m not sure anything I did there was meaningful enough to warrant changing the QuikTune script. Noticed I had some lingering D-term values as well, so zeroed those, since it appears QuikTune doesn’t touch them anymore (comment at the top of the script probably needs an update).

Also reset TURN_MAX_G and WP_RADIUS to defaults, which smoothed S-Curves from a more aggressive setting I had tried previously.

I’ve noticed that both the L1 controller and PSC controller seem to misbehave just a little bit after a scripted speed change. The vehicle always wanders a little before correcting back to track after a speed change (particularly when slowing). That behavior is much improved in beta11, but I wonder if that might be a similar term buildup that @rmackay9 mentions regarding post-pivot oscillation?

On the topic of pivots, I didn’t notice much oscillation after turns, but I did see that x-track error was worst at the beginning of any given segment, so there may be merit to zeroing or damping the I-term as suggested.