This is a topic for John Easton’s wobbly navigation which was initially raised on facebook.
Both steering and throttle are having real troubles. Below is a graph of the throttle output (channel 3) vs the vehicle’s speed. It shows a very big oscillation in the output speed almost perfectly out of phase with the output to the motor.
reduce ATC_SPEED_FILT to “1” (it’s possible even lower value will be required) This will smooth output the input to the speed controller so that it responds much more slowly. I’ll reduce the defaults in master as well so future users get a better starting point.
reduce ATC_SPEED_P to 0.02
reduce ATC_SPEED_I to 0.02
It’s actually possible that the unstable throttle output is affecting the steering control because (I think) on a boat the turn response is proportional to the motor output so fixing the above may help steering too. Anyway, in the steering control we still see that it’s not able to achieve the desired lateral acceleration.
set TURN_MAX_G to 0.2 (currently it’s an unrealistic 1G). This should stop the controllers from attempting the impossibly high lateral acceleration requests.
set NAVL1_PERIOD to 12. This will slow the aggressiveness to get back on the path
set NAVL1_XTRACK_I to 0. This will stop I term build-up in case the navigation controller’s requests cannot be executed by the lower level turn controller.
reduce ATC_STR_RAT_FILT to 5. this will slow down the steering response.
reduce ATC_STR_RAT_P to 0.2.
By the way, what type of GPS are you using? If it’s a Ublox could you try setting GPS_TYPE to “2”.
As a side note, it would be great if the logs could be made smaller. It looks like the vehicle was powered on for about 2hrs 15min. Shorter tests as we get it tuned will help me by making the logs smaller and speed up the viewing of logs.
Ok so I will be testing tomorrow with the following settings, should I make any further changes?
The turn rate controller hasn’t been tuned so it’s not performing well (sorry, we don’t attempt to automatically update tuning params from 3.1 to 3.2 because they’re too different). I think the ATC_STR_RAT_FF should be increased from 0.2 (the default) to about 0.6. The TURN_MAX_G should probably also be reduced from "1"G to something more reasonable like 0.3G to stop it from attempting the impossible
The throttle/speed controller needs some tuning as well I’m afraid. There’s good advice on the wiki for setting the CRUISE_THROTTLE and CRUISE_SPEED values using the auxiliary switch but to get started, I think CRUISE_THROTTLE should be increased from 10 to about 80. http://ardupilot.org/.../rover-tuning-throttle-and-speed…
Note: in Rover-3.2 the waypoint navigation speed can be set using the WP_SPEED parameter instead of changing CRUISE_SPEED.
set TURN_MAX_G to 0.2 (currently it’s an unrealistic 1G). This should stop the controllers from attempting the impossibly high lateral acceleration requests.
set NAVL1_PERIOD to 12. This will slow the aggressiveness to get back on the path
set NAVL1_XTRACK_I to 0. This will stop I term build-up in case the navigation controller’s requests cannot be executed by the lower level turn controller.
reduce ATC_STR_RAT_FILT to 5. this will slow down the steering response.
reduce ATC_STR_RAT_P to 0.2.
Oh yes, I forgot to add that to my list above but those changes have been made.
I noticed TURN_MAX_G and ATC_STR_RAT_P goes red when I insert these values, any idea why it does that?
I will give some feedback later, heading off to Inanda Dam in the next half hour.
The value going to red must indicate that the ground station (QGC or MP?) thinks they are out of range. If you can update the values then I wouldn’t worry for now. The values are within the acceptable range according to the latest parameter descriptions in ArduPilot so perhaps the ground station is using old parameter descriptions.
I seem to remember in the past that there was a setting to reduce the throttle to 10% when arriving and departing from a waypoint, but cannot find it now.
Nice video and thanks for the logs. Certainly it’s performing better and I think the latest beta will help some more because it fixes a bug that affects the “origin” of a track.
Here are some other things I found in the logs:
increase CRUISE_THROTTLE from “10” to “80”. If CRUISE_THROTTLE is 10% while the CRUISE_SPEED has been left up at 3.5 (m/s), this means that to the throttle controller thinks the vehicle can reach 3.5m/s at only 10% throttle. It’s closer to 100% throttle required to reach 3.5m/s. This leads to the I-term having to do all the work to control the speed and this leads the throttle control to be quite slow I think.
ATC_SPEED_I can probably be safely increased from 0.02 to 0.05.
The result is the throttle is much smoother than before but I think increasing CRUISE_THROTTLE to 80 would be good for the next test.
For the steering control, it’s doing much better than before but this could help:
reduce TURN_MAX_G from “1” to “0.2”. We can see from the Desired lateral acceleration (in red) that the navigation controllers are requesting up to 3.8m/s/s (0.4G) but the vehicle can only do about 1.8m/s/s (0.18G).
increase NAVL1_PERIOD from “12” to “15”. This should help stop the weaving I think.
increase ATC_STR_RAT_FF to 0.8. Reduce ATC_STR_RAT_P to 0.5.
below is a graph Desired Lateral Acceleration (red) vs Actual Lateral Acceleration (green)
No problem. By the way, the parameter to slow the vehicle during turns is SPEED_TURN_GAIN although 3.2 should do a better job than 3.1 did. 3.1 would only slow-down after it reached a waypoint but 3.2 should slow down before reaching the waypoint as well.
Actually the ATC_ACCEL_MAX value should probably be reduced from 5 (m/s) to 1. This is a more realistic value for this frame and should lead to smoother accelerations.
Today I tried the same settings but with a different motor as I thought it might be my hardware in some way.
It turned out to be exactly the same, but the good news is that due to me making so many passes of the same mission, I could see that it was repeating the same error time and time again.
The Error:-
When the craft arrives at a waypoint, it is very accurate (mostly), but as it over runs the waypoint it seems to ‘panic’ and starts taking radical action to try correct this taking 120m before it is back on track.
The tighter the turn to the next waypoint makes this worse.
