How to stop, turn and continue with precision during a mission?

Hello everyone,

Since I started my unmanned ground vehicle project I realized that I needed precision gps and after reading you guys I understood that the Yaw GPS was very important for my purposes.

Therefore I bought simpleRTK2B+heading and configured it following the manufacturer instructions.

I get rtk Fixed in GPS2 and No GPS in GPS1 as indicated in that tutorial.

My vehicle is skid-steering type and I am using ardurover 4.1.0dev.

I now have “relative” accuracy however the trajectory and turns are not right.

You can see in my video what I mean.

My goal is that when I reach a waypoint the vehicle stops, turns to the next waypoint and starts again.

I think this issue has more to do with the navigation configuration and the pivot turn of the vehicle than with the gps + yaw position but I have followed the advice of the official guide and I do not succeed.
Any advice?

Would you be so kind to tell me how to get the vehicle to stop, turn, and then continue on its way when it reaches a gps?

Thanks a lot for your help

From the video, it appears that your vehicle is executing pivot turns, but it is doing so way short of the WP. The first thing I would check is the WP_RADIUS parameter described under the NAVL1 tuning section of the page you referenced. I expect it is larger than it should be.

Once you fix that, I think you should increase the distance between the waypoints for your testing so that you have longer straight paths to see what is happening. That is assuming you have the rover traveling at a typical speed. But first, decrease WP_RADIUS.

If you upload your parameter file, it will help.

What type of rover do you have?

1 Like

Thanks @ktrussell for you reply,

My WP_RADIUS parameter = 0.

I have been decrementing its default value but even with the value 0 I do not get the expected results.

Here is my parameter file.

My rover is skid-steering type and about 20 cm between axles. Isn’t it beautiful? ;-))

Is a prototype (proof of concept) for a larger one dedicated to agriculture.

Param-Ardurover-4-1-0-dev.param (14.6 KB)

A couple of things I see:

WP_RADIUS at 0 is unusual I think. It could even disable something about the navigation, I don’t know. I try it at 0.5.

I would try making ATC_ACCEL_MAX smaller, maybe even 0.5 just to see. That will make you machine accelerate and decelerate (since ATC_DECEL_MAX is 0) slowly. You can later make it higher. I’m just trying to make sure the rover is approaching and leaving the waypoints at a slow rate, right now.

You might try going slower than 2 m/s, even 0.5 m/s just to see what happens (WP_SPEED).

These changes may not help since your rover is turning short of the waypoint, unless WP_RADIUS at 0 does something strange, as I mentioned.

BUT, WAIT! Now that I look at your video again, it looks like the waypoint square you have drawn is 45 degrees off from what ArduRover is navigating to. It’s like what you see on the screen is not where the waypoints are in the controller. I don’t know what would cause that behavior. You might try a few different missions with less and more waypoints, to see if you detect a pattern or something and report back.

I’m afraid I am not being much help. Hopefully others will have a better idea.

1 Like


I will try to follow your advice and report back.

However about the wp_radius parameter …

According to your definition “Defines the maximum distance from a waypoint that when crossed indicates that the waypoint may be complete” .
I put 0 because I noticed that it did not always turn in the same place and I thought that was the reason why it turned before to the next waypoint.

I put 0 because I wanted it to exactly reach the waypoint. Is it not correct?

Regarding the video and the pattern you indicated… other times it makes a very different pattern, look at the photos.

Also, I have been marking on the ground at a waypoint when the vehicle makes the turn and you can see that it is never in the same place.

I do think that you are interpreting WP_RADIUS correctly, and 0 should make it turn exactly at the WP, so that is probably OK. I was just grasping at straws at a possibility that 0 had a special meaning perhaps. Normally, you would need to be at least slightly greater than 0 so that your rover has time to come to a complete stop and not overshoot the waypoint.

Well, if it is not repeating the same thing every time, I would feel that the issue is the underlying tuning of the throttle and turn rate controller. They must be working pretty well before you can tune the outer loop, the NAVL1 controller.

So, in Acro, does your rover drive well. You probably followed the instructions at Tuning Process Instructions — Rover documentation (, being sure to click on the links “Tuning Speed and Throttle” and “Tuning Steering Rate” and following them. I can’t stress how important it is to get the throttle, and especially the turning rate controller working well.

Be sure you set the CRUISE_SPEED and CRUISE_THROTTLE according to the instructions.

Maybe others will jump in with other suggestions. Don’t lose heart, tuning IS tough, but if you methodically follow the instructions, you will get there.

At some point, posting a .bin log may be helpful for someone to evaluate. I personally am not an expert at that but others here are. But, first, I would be sure I felt good about the Speed and Turn Rate tuning.

1 Like

I agree with Kenny’s advice that the lower controllers should be tuned first and this is likely the problem with the inaccurate and inconsistent path.

Setting the WP_RADIUS to 0 is generally not a good idea because it means that the vehicle will be struggling to get to the waypoint right up until the last moment where it crosses over the “finish line” (the line that intersects the waypoint but is tangential to the line between the start and end of this waypoint segment).

Thanks for the help and encouragement.
I think the best thing to do will be to start again from scratch.

If it helps you feel better, I have been using ArduRover for 2 years. I have started over several times with tuning. Every time I do, I learn a lot that I never noticed before. The documentation now seems very good to me, but I have to read it carefully every time not to miss some detail.


Much better!
I have followed your advice and I have started from the default configuration and I have followed the instructions of the wiki in order.

1.- Tune the Speed and Throttle Controller
2.- Tune the Turn Rate Controller
3.- Configure Pivot Turns (Skid Steering vehicles only)

However, before configuring anything in the third step I proceeded to load the old square mission and before configuring anything I set it to perform the mission.

My big surprise has been that now it has ALWAYS turned in the same point and the track as you can see is a beautiful square.

Now the next question is. Why the square is not like the square that delimits the waypoints?

Thank you very much for your support!

How strange!

Now I have only modified the wp_radius parameter.

Video with wp_radius = 0.1

Video with wp_radius = 0.5

Video with wp_radius = 1

Why does the direction between waypoints vary so much?

I must say that in the first video the wp_radius parameter was set to 2 by default.

With wp_radius = 0.1 I set the ATC_STR_ANG_P parameter between 1 and 5 (2.5 is default) and found no improvement.

The reason that the WP_RADIUS parameter is so critical is because Rover doesn’t plan the corners well. What I mean by this is that the navigation controllers only know about the waypoint they are currently going towards. They don’t consider the next waypoint after the current waypoint.

The sequence of events is, once the vehicle enters the WP_RADIUS, the navigation controllers are stopped and the vehicle straightens the steering and slows to a stop, it then turns towards the next waypoint and then finally re-starts the navigation controller to move towards the next waypoint.

If the WP_RADIUS and ATC_ACCEL (or ATC_DECEL) are perfectly matched then the vehicle will stop very close to the line between this waypoint and the next one but if they’re not then the vehicle will either stop too early or drive too far past the line. This leads to a lateral position error that the navigation will try to get rid of by turning towards the line.

In some of the pictures shown above we can see the WP_RADIUS is too small (compared to the ATC_ACCEL/DECEL) so the vehicle overshoots the line and then turns back.

When set perfectly the vehicle comes to a stop close to the line and the result is a decent square.

This issue is why we want to introduce SCurves to Rover.

1 Like

Thanks Randy for helping with that good explanation, which helped me also.

@comodin, you might try decreasing the deceleration (either with ATC_DECEL or with ATC_ACCEL - see Tuning Speed and Throttle — Rover documentation ( to a very low rate (just for testing right now) and set WP_RADIUS very small and see if you achieve a very close approach to your WP, to build confidence that you can hit the WP on the nose. Then you can increase the ATC_DECEL to an acceptable rate for your purposes and adjust WP_RADIUS up some to compensate for the higher speed at which the vehicle will approach the WP. Eventually, you will get the deceleration and the WP radius matched.

1 Like

A final note from me re WP_RADIUS, the vehicle doesn’t give up on the current waypoint until it enters the WP_RADIUS or crosses the “finish line” so if WP_RADIUS is set too small the vehicle will try to turn towards the waypoint right up until it is very close to it which leads to overly aggressive turns right at the end of each segment… and those turns are pretty random because they depend upon which side of the green line the vehicle is on and how much lateral position error there is.

1 Like

Good point. I probably should have quantified my “very small”. @comodin, with the deceleration turned down so the rover slows way down as it approaches a waypoint, perhaps set WP_RADIUS to 0.5 and see what happens. If it stops short, change it to 0.4, etc. (And Randy, please override anything I say that you feel is not right for 2 reasons (1) you have way more experience than I, and (2) on top of that, this is a small rover, unlike anything I have ever had. :slight_smile: )

1 Like

Hi ,
I was configuring the ATC_ACCEL (or ATC_DECEL) parameters and found no improvement so I was searching deeply in this forum looking for an answer and I found in this topic how @rmackay9 was analyzing certain graphs.

I must say that I am a novice in this type of analysis but it caught my attention that my graph on speed and steering were so different from what @rmackay9 pointed out.

SPEED with wp_radius = 0.1


So I started all the tuning from scratch again.

I think I have improved the SPEED theme quite a bit and it is now more coherent.

And as @ktrussell rightly says, every time you read the wiki you find something new.
In this case I’m talking about ACRO_TURN_RATE
Following the instructions I find the following graph (it was always turning to one side and to the other, but as it is a skid vehicle it was always turning on its own axis)

And as the wiki states
“Note the value shown may be in centi-degrees/sec so its value should be divided by 100 to match the parameter’s deg/sec”

If the maximum values were -2000 and 2000 I divided them by 100 and therefore 20 so I set it a little lower, i.e. to 18. I probably misunderstood?

As a result, the ACRO_TURN_RATE parameter is changed from 180 to 18 =180 to ACRO_TURN_RATE =18.

I then continued with the PID of the steering rate and went from these initial parameters
pid inciales
to these final
pid finales

Before continuing with the wiki I tested the mission again with WP_RADIUS = 0.1 and I found an improvement. Now the track between waypoints was more correct.
However I analyzed the steering graph and it seems a bit strange, doesn’t it?

As I indicated at the beginning this prototype is only the proof of concept for a bigger one that will be dedicated to agriculture where the “streets” between crops will be 80cm so the turns must be exact, that’s why my insistence on WP_RADIUS = 0.1.
For example I put a “similar” mission and the results of new ones were very diverse and some very frustrating.