Use Heading from Dual GPS

,

I think you have the moving base configured correctly and simply misstated the fixed base correction comms. If GPS2_RAW.yaw is reporting heading, there’s nothing left to do there.

I tried to tune the navigation parameters and this are the results (better than yesterday):


with these values:
tune params

steer_params

I guess it is not possible to improve further the behavior of the vehicle close to the 90 degrees turns, is it right?

You should be able to do way better than that. WP_RADIUS is probably too small, and your NAVL1_PERIOD is too short. Increase the radius to 0.5 or so and the period to 5-8 seconds.

There is no need for multiple waypoints in a straight line like that. Delete the redundant ones.

1 Like

I was putting all that waypoints on a straight line because I was thinking that would improve the accuracy of the path since the vehicle will have to move in vineyard rows and it will have to move very straight since the rows are narrow (their width is about 1.5 meters while the vehicle has a width of 0.75 m). But if it is not needed than I’ll remove all the redundant points, thank you!

The period was initially set at 8, but the vehicle waved a lot along the waypoints so I increased it and it waved more. I started to decrease it step-be-step to obtain a straight path between the waypoints. If set it back to 5 or 8 seconds, than it will start to wave again, unfortunately! :frowning:
I increased the radius to 0.5 and tomorrow I will do additional tests on the field.

Your steering rate parameters are probably untuned if you need such a short NAVL1 period. Post a .bin log if you want specific help with tuning.

1 Like

Thank you for your help!

Unfortunately, I deleted all the recent logs before to read your answer, but I have this log which is one of the first logs I did today while I was trying to tune the navigation parameters.
https://drive.google.com/file/d/1vAbARwZ1vRU4V1ahABxeIfxaCmIGvK3L/view?usp=sharing

I aborted the mission after a while because I saw that the vehicle was waving a lot.

EDIT: I noticed that when I control the vehicle by the transmitter and I try to turn on the spot, sometimes, it happens that it suddenly change the turning direction. I don’t know if this can help.

Unfortunately I am going to give some conflicting advise here… I always aimed to have the NAV_L1_PERIOD as low as possible. This value determines how far ahead the vehicle is aiming to get back to the line between way points. A large value will cause it to aim for a point on the line connecting way points further ahead of its current position and thus produce a ‘lazy’ attempt to return to the path. Low values cause the vehicle to attempt to stick to the path more aggressively. The limiting factor is the vehicle ability to follow steering commands and if the value is too aggressive, it can cause overshoot and oscillations about the path.
https://ardupilot.org/dev/docs/rover-L1.html
You can see here that the L1 distance is calculated as 0.3 x damping x period x speed
With a WP_RADIUS of 0.1, the vehicle must be almost on top of the way point before attempting to turn to the next one. I am not sure what the steering limitations of your vehicle are, but you must consider this when planning. If you want tighter turns (and you vehicle is capable of them) then you need to make sure your settings allow these tight turns and that the the WP_RADIUS is set so that it doesn’t turn too late. Obviously a pivot turn would allow following the course most precisely.
We had a number of different types of large, purpose built, agricultural vehicles running AP and managed to get our average cross path error < 0.05m on long runs. We also have vehicles that operate in vineyards but have moved towards lidar based SLAM combined with neural network based row following steering control.

1 Like

While I agree that L1 period should be as low as possible, I think something else is amiss with this tune, and that very low L1 period value is an offsetting error. The log will reveal that, I’m sure.

1 Like

@Yuri_Rage Yes this could quite possibly be the case - a NAV_L1_PERIOD of 1.5 does seem low. Our vehicles typically ended up in the 3-4 range but this figure is dependant on the intended speed. We see here that WP_SPEED is set at 0.4 which is quite slow with respect to my experience. We typically targeted ~2-3m/s for our vehicles.

1 Like

Your vehicle does not appear to be pivoting as it’s capable of doing. Try moving your second throttle output to SERVO3, which is the recommended setup for a skid steering vehicle.

In the log you provided, the throttle is saturating at about 0.5m/s, but you have 1 m/s set as WP_SPEED. Set WP_SPEED and CRUISE_SPEED to 0.4 or 0.5 and re-tune the throttle. I doubt you need ATC_SPEED_I to equal ATC_SPEED_P (probably 1/2 or less its present value of 0.2).

Similarly, try zeroing ATC_STR_RAT_P and ATC_STR_RAT_I, then increase ATC_STR_RAT_FF to a starting value of 0.4 and tune from there. Your actual steering rate lags quite a bit behind desired, though it appears capable of achieving the desired rate with a more aggressive FF term.

As you dial in the rate controller settings, you may find that the vehicle tends to wander again with NAVL1_PERIOD at 1.5s. Increase it a bit to dampen that behavior as needed.

Today, I’ve run another test directly in the field.
Unfortunately, I didn’t have much time and the weather was cloudy and it was going to rain, so I couldn’t dial with the settings (I’ll do that during next days). I just moved the throttle to SERVO3 and run the calibration again for the radio transmitter and I set the CRUISE_SPEED to 0.5 m/s while WP_SPEED was already at 0.4 m/s.
During next days, I’ll play with the other suggested parameters.

At first, I collected a series a GPS waypoints by using the function “save waypoints” while driving the vehicle along a vineyard to create a very simple path:

  1. enter the row
  2. go straight in the vineyard row
  3. go out the row with the turning maneuver
  4. go straight again in the next row till the end
    This is the waypoints file while this is the BIN file related to the waypoints collection:

Then, I started the mission and, WOW, the vehicle was able to perfectly follow the path even during the steering procedure at the end of the first row!
This is the BIN log related to the mission (I repeated the mission again after 30 minutes).

This is a zoom about the steering:

turn

I was really worried about this aspect because the steering is tight, but the vehicle performed great.
Even the straight path looks accurate.

As @Yuri_Rage, @jimovonz and @ktrussell said few posts ago, the path following algorithm on Ardurover works very well.

Even if I haven’t tuned the other parameters, yet, do you guys think that the vehicle is performing fine? Is there still room to improve it? For me, it seems very good, but I’m just a beginner and so I can’t judge it!

Attachments:

  1. waypoints file: https://drive.google.com/file/d/1JQusjGVTFIDP7Q6mpEQtGaw8PRk74jwT/view?usp=sharing
  2. BIN file related to the waypoints collection with the radio transmitter: https://drive.google.com/file/d/1kehKsOJLBjuD3UFWNodhDQAkmcx2iRKd/view?usp=sharing
  3. The BIN file related to mission:
    https://drive.google.com/file/d/19lQmmwWNu7B-4xqo0hkY6HNK0hZO9Lme/view?usp=sharing
1 Like

Excellent progress!

I’ll have a look at the log later today.

Can you also upload the waypoint file that you used? I’d like to show you how I would go about editing it.

1 Like

Thank you!
This is the link for the waypoints file: https://drive.google.com/file/d/1JQusjGVTFIDP7Q6mpEQtGaw8PRk74jwT/view?usp=sharing and I modified my previous post by including it, too, for reference.

1 Like

First, your throttle tuning is too aggressive. The speed average is very close to desired, but the controller is very rapidly cycling the throttle output value, which may wear or burn out components.

You can probably set ATC_SPEED_I=0 without detriment - the I term (in blue) is doing very little to improve performance here. You may find that you need a corresponding minor increase in ATC_SPEED_P as a result. Consider reducing MOT_SLEWRATE to something between 50 and 100 if the spikes in speed are not tamed by PID tuning.


Your steering controller is massively underperforming:

Here, we can see that the maximum turn rate achieved is 42.7°/s.

So, ATC_STR_RAT_MAX should probably be about 45 degrees per second, which may help tame the desired turn rate. Then follow the instructions here to tune the rate controller, starting with ATC_STR_RAT_P, I, and D all equal to zero, and focused solely on modifying ATC_STR_RAT_FF, at least at first.


As for your waypoint file, the long legs are only about 50m, and they are spaced hardly 2m apart, meaning that the difference between each waypoint and the straight lines of the polygon that I drew here is hardly a few centimeters.

I would edit it to use fewer waypoints and a squared off turn at the end like this, such that we can rely on crosstrack control to maintain the path.

Watch carefully if you choose to use this version of the waypoints file, since I do not have any knowledge of the actual obstacles in your field and simply made some assumptions based on the apparent geometry.

waypoints-yuri.waypoints.txt (514 Bytes - rename without the .txt extension)

1 Like

Thank you, @Yuri_Rage! I will follow all your suggestions and I’ll change the configuration before run the next tests. Moreover, I will change my waypoints file to reflect your tips!

I would like to go deeper all the parameters in order to be able, a day in the future, to inspect the values from the log files and adjust them. For example, I wasn’t aware about the PIDA.Tar, PIDA.Act and PIDA.P,I and D.

Is there a full documentation about all these parameters? I already read everything on ardupilot.org, but I would like to find something more detailed (may be with examples or the math behind it).

1 Like

I am by no means an expert in log analysis and have absorbed most of what I know by reading posts by the development team and those more experienced than me. For example, Randy gives an excellent rundown of his log review in this topic.

If you use Mission Planner for log review, you can hover the mouse over most entries and see a brief description of the value in the lower right corner of the window.

Tridge gives an excellent talk in this video, though he focuses on the Plane platform and uses the more command-line intense MAVExplorer tool for analysis.

There’s also an online tool for log analysis that can be helpful in presenting data in an alternate way.

However, I have not found a single source document that will answer all of your questions, unfortunately.

2 Likes

Thank you, again, the links you gave me are a very good starting point!
I’ve spent last days in reading topics and documents on ardupilot and everything looks so interesting!

1 Like

About the burning out, I checked the temperature by looking at the logs and it was about 45°C.
Is that a normal temperature value or it is too much?

If you’re looking at the IMU temperature of a Cube Orange, that is the default target temperature - they are heated to maintain a high degree of accuracy.

You probably should be less concerned about IMU temperature and more concerned about servo, ESC, and motor temperatures, which are not likely reported in the telemetry data or logs.

Hello, did anyone in this topic try a configuration which uses dual gps, but only the rover connecting to flight controller that it works?