I think the issue is that bendy ruler has been enabled and the next waypoint is loaded it takes about 1 second for bendy ruler to determine if there is a safe path to this next destination. I think if you turn off bendy ruler the delay will go away.
By the way, I think that it would be good to set ATC_ACCEL_MAX to perhaps 1.5. It is currently 0 meaning that the forward-back acceleration limits have been turned off but if we look at the desired vs actual speed (in the post above) we can see that the actual speed (in green) follows far behind the desired speed (in red).
It might also be good to slightly reduce ATC_STR_RAT_FF because there’s consistent overshoot in the turn rate controller’s desired vs actual. Maybe reduce it from 1.4 to perhaps 0.8 or 0.9.
Thankyou @rmackay9 for your quick reply.
ok! didn’t thought about that. I have bendy ruler enabled because I am trying to make obstacle avoidance to work. So far, no good, so instead of the more advanced options, I went back to the basic bendy ruler to do more testing.
Regarding ATC_ACCEL_MAX, I set it to zero on purpose because I was seeing too much slew rate in the PID.desired speed, I will go back to tune it more properly. FF=1.4 value was suggested by you in
this post and seemed to work well, buy I have made so many changes after that …
This reminds me about the MOT_SPD_SCA_BASE parameter. All my troubles tunning steering were due to the default value of 1 m/s, above this speed (just 2 … 3 m/s) the rovers went almost straight with a very very weak turn, even for a full-to-the-left or full-to-the-right intent. I have no doubt that steering should be reduced at increasing speeds, as explained here, but in my case, it was very difficult for me to relate the behaviour to this parameter, which does not have a friendly name either, and it is not mentioned in the tuning pages in the wiki. I don’t know if I can make a “pull request” to modify documentation, but I would suggest to add a paragraph in the tuning turn rate page just mentioning this parameter and what it does. I had this problem with two rc cars (1/16 and 1/5 scale) wich are not-so-rare vehicles and, as I said, at a mere 2…3 m/s (7 … 10Kmph) , steering was like disabled in acro mode.
Thankyou again for your helpful advice,
Just adding that the same is noticeable on ArduCopter.
Can also confirm that the stop/delay goes away if you turn off OA.
Likewise here. In the original discussion on SCurve testing for Rover, Randy and I arrived at the same conclusion, which is indeed independent of the nav controller and solely based on OA processing time.
I would like to add on that the aircraft also stops at the intermittent “waypoint” that it calculates when avoiding a fence obstacle. This is with OA_AVOID set to 3.