Steering PID tuning - achieved PID tracks desired PID but frequently deviates into opposite direction of travel

Hi there,

I’ve been having some issues whilst trying to tune the steering PID for the AgileX Scout Mini rover, where the achieved PID deviates so far from the desired PID at times that it changes the direction of travel, whilst also nominally tracking the desired PID…

I have been following the steering tuning document by I believe @rmackay9. I have had to perform the tuning in ‘auto’ mode, however, due to the desired PID never being shown when tuning, only the achieved PID is shown. As such, I’ve been having the rover attempt to reach 4 waypoints in a small-ish box pattern.

My PID tunings haven’t really gotten past the FF as a result, apart from one attempt with P and I of 0.01 (just to see if anything changed).


I’ve tried to search for similar issues, but none of those I saw had this sporadic behaviour. Would anyone have an idea about why this would be occurring when tuning in auto mode?

Thanks for any help/advise you guys can offer!

1 Like

I’m having the same issue.
Is it just me or what happen to all the rover people

I know at work we’re moving a lot of our developments over to ROS 2.0, as it’s becoming more mature, so maybe that’s where they’ve gone?

1 Like

This looks like a mechanical or fundamental setup problem.

Can you drive normally in MANUAL? How about in ACRO?

Is it possible that you’re attempting to output left/right throttle to a motor controller that expects throttle/steering? A brief read through the user manual for the Scout Mini shows that the intended primary mechanism for autopilot control should be via CAN. You could write a CAN driver in Lua and have ArduPilot interface with the vehicle that way.

Initial tuning should be done in ACRO. The Mission Planner live tuning screen will display the same as in AUTO mode.

1 Like

Awesome as I think ROS2 is the next level
Will now study more about these advantages

Hi Yuri,

Sorry about the delay, I’ve finally had time to take the robot out today to do some testing.

I can report that the servo left/right is correct. Unfortunately I’m using the AgileX joystick, which is setup to talk directly to the rover, and not the flight controller, so manual and acro mode aren’t useable for me. I’ve found reducing the FF, and keep P and I low, effect of the sudden counter turns are minimized, and while it isn’t pretty, it can manage a trip around the waypoints in auto mode.

I have a python script already in place that takes the mavlink messages and converts them for sending to the rover. I’ve used it before with some success, though I did take another look at it to see if the error is coming from here, and it doesn’t seem to be.

I tried it on someone elses robot today, not a scout but a bunker, same manufacturer and with the same control schema for throttle/steering.

Unfortunately this was even worse than on the scout. It’s been so bad that I questioned whether it truly was throttle/steering on those servo channels, and played around with reversing the values, swapping them around and even trying left-throttle/right-throttle.

Honestly, the behaviour looked about the same, with random turns and reversing direction. Not so much that it ‘rocks’ back and forth, as when I tried swapping throttle and groundsteering, but more like it was sketching out a giant toddlers doodle on the ground…

Looking at the desired/achieved PID for tuning, the achieved was still trying to match the desired, but seemed to have far more divergence from the desired track, so much that I’m not sure exactly what is going on nor how to try and fix it. I feel if I had taken the time to configure a joystick to use via ardupilot instead of relying on the provided AgileX setup this would be easier to debug.

I managed to get a working configuration file from another bunker user and spliced together my existing scout mini parameter file with his, only keeping the ATC_* params from his. Armed with the splice, and with just enough time before nightfall, it worked as a well as the scouts did, so I guess it was that my pid tuning was completely wrong when used with the bunker.
In case the parameters for the scout mini and bunker are of use to anyone as a starting point, I’ll attach them here.
It would be interesting if anyone more knowledgeable than could take a gander at them, in case there’s something glaring that could cause the random divergence from the desired pid.
bunker2_working.param (18.1 KB)
slambox2_working_partially_tuned.param (18.2 KB)