Rover 4.1.0-beta6 has just been released for beta testing and should appear in the ground stations within the next few hours. Changes vs the previous beta are in the release notes and also listed below.
Changes from 4.1.0-beta5
Enhancements
a) GPS-for-yaw enhancements including using position and yaw from different GPSs
b) Long distance travel supported (thousands of km) including double precision EKF and moving origin
Bug Fixes
a) BendyRuler avoidance fixed (was slow and jerky)
b) BLHeli fix that could cause failure to boot
c) CRSF message spamming and firmware string length fixed
d) Display re-enabled on 1MB boards
e) DShot always sends 0 when disarmed (protects against motors spin while disarmed due to misconfiguration)
f) DShot fix that could cause main loop jitter
g) DShot buzzer tone disabled during motor test to remove bad interation
h) Longitude wrap fix (allows autonomous flights as longitude wraps between -180 and 180 deg)
i) Log created on forced arm
j) MatekF405-bdshot NeoPixel LEDs re-enabled on PWM5
k) Serial port performance improvements using FIFO on H7 boards
We hope that the GPS-for-yaw improvements will make the setup and use easier and more reliable.
Can you elaborate a bit on this? Is the AP now averaging position from both GPSs and/or taking into account their frame offsets in a different way? I don’t have a very large sample size yet, but it appears that the mower may be following my saved waypoint files slightly laterally offset (the axis where my antennas are mounted) from the way it did under beta5 and previous.
EDIT: The offset appears more east/west than axis oriented. I’m rebooting everything, including the fixed base and will report back. I’d still like to understand a bit more about the GPS updates, but I don’t want any misperception on my part to cause undue analysis on yours.
The Willys was the first one to test beta6.
It made 200 WP rounds without problems … like the ones you can see in the video
Somehow the precision and reliability seems to be improved. In previous tests it always got stuck in some bush before the end of the 200 laps. Even after a longer park break (1h) he continued the WP round without any problems. In the past, the EKF often got unhealthy after a longer standstill.
Matek H743
2 x GPS (Matek M9N + Matek M9N-CAN)
Pololu G2 motor driver
Neopixel LED with LUA scripting
Ok, I don’t think it’s my imagination - after a complete reboot/restart of all hardware and software, it appears that the mower is tracking the waypoint paths offset in the direction of the GPS1 antenna.
While I don’t always mow the exact same patterns, I have a series of waypoint files that I consider “safe” (though they have some tight margins on the perimeters) and I gravitate toward those when I just want to get some work done vs test a specific idea or change up the pattern to avoid making ruts in the yard. As such, I’m very familiar with the usual behavior of the mower on those waypoint missions. Today, the mower is offsetting left (toward the GPS1 antenna) by an amount at or less than the distance between the antennas. I had to stop it several times and correct its position before it mowed over a bush or hit an obstacle around the first perimeter pass. Fortunately, the OA margins are wide enough that it’s not hitting the geofenced trees.
I don’t think a log file will be useful, since it’s showing that it’s on the path and nailing the (now offset) waypoints with the same precision that I’ve come to expect. I do think that perhaps the new update is causing an offset with respect to expected behavior.
EDIT:
I noticed a slew of new GPS_MB* parameters that I have not used or set. The brief description of GPS_MB*_TYPE doesn’t give enough information to set it correctly (I’m getting GPS yaw with 0 on both). Also, GPS_MB*_OFS* are all still zero as well, so perhaps that has something to do with the offset I’m seeing today. It’s unclear how those relate to the GPS_POS*__* parameters (or if one overrides the other). I’m sure the intent is to ease the moving base setup, but I can’t quite decipher exactly how to use the new parameters.
Thanks for the report. It is probably best if @tridge has a look at this.
The GPS-for-yaw change involved modifying the GPS and EKF library so that the position and velocity could come from one of the GPSs (probably the first one) and the yaw from the 2nd one.
please send the log anyway. We can look at the raw GPS positions to see what is going on.
Also, please describe the physical positions of the GPS antennas on the vehicle, or give a photo.
@tridge, here’s the log. Sorry for the large file size - I get a lot of work done at once! Ignore the weird BendyRuler behavior - I accidentally uploaded the version of that waypoint file that included waypoints inside the geofences, which is obviously a no-no.
Photo as requested. GPS1 is on the left side (negative Y offset).
I’ve had a look and the behaviour does look correct. The way you can tell is we can map the raw GPS positions from each GPS, and the final position, and the waypoints. You see this:
you can see that the raw GPS positions (which don’t have the sensor offsets applied in the logs) do correctly straddle the vehicle position, and they are on either side of the mission track.
I notice that your base GPS has a fix type of 5, which is RTK-Float. A float fix is often not very accurate. Waiting for the base GPS to get a fix of type 6 may solve the issue. That can make quite a lot of difference.
Ok, that makes sense, and I’m glad to know the position used for navigation is indeed derived from the GPS position offsets.
It’s fairly normal for the mower to waver between RTK-float and RTK-fixed in the area where you took the screenshot, perhaps due to some masking by a building. Later in the log, it gets a pretty steady RTK-fixed solution, but I could’ve sworn that I continued to observe a lateral offset. I’ll review a previous log and see if that illuminates anything. Maybe I’m just seeing things.
EDIT: After a rudimentary review using the KML generation feature, it appears that previous behavior was identical. I’ll chalk it up to over-trust of my own mission files rather than a code change. I really appreciate the feedback, as always.
Can you shed some light on the new GPS_MB_* parameters? I have not changed them from the defaults, and GPS-for-yaw seems to be working the same as before.
you don’t need to change those for your type of setup. They are needed for setups with special GPS receivers where you have just one GPS that has two antennas. The ublox F9P doesn’t do that. Currently we only use it for Septentrio GPS modules.
@GRS26, yes, that’s right. It seems that when using GPS-for-yaw, the best result should come from using the 1st GPS for position and velocity and the 2nd GPS for yaw. If GPS-for-yaw isn’t being used though this statement isn’t relevant though.
But does it have to be this way? Until beta5 I was connecting only the rover gps to the fc, the moving base one only connect to the other module. Can I still use like that?
Sorry, I misunderstood your question so I answered incorrectly…
Yes, I think that should be fine… I’ve never actually used GPS-for-yaw myself but I think the data from both GPSs is still reaching the autopilot even if only one is physically connected to the autopilot.
Randy, I certainly could be wrong, also, but I do not think that the position information from both GPSes will come through if only one is connected.
But still, to @GRS26 question, if only one is connected (and if I am right that this one’s position is the only one that it reports) , that would certainly be the one that Ardupilot would use for position since that is the only GPS it would know about. So, @GRS26 should get what he wants, I think.
correct. You only get position data from the GPS modules that are directly connected.
yes, it should work, but only connecting the rover will lead to lower position and velocity accuracy and some nasty failure modes.
The position and velocity on the rover is always worse than the position/velocity on the base because it is equal to the base plus an error that comes from the RTK process.
When the rover has a good fix type 6 RTK lock then the position/velocity on the rover is ok (just a bit lagged from the base, and with only a few cm of additional error).
But when the rover loses its RTK lock on the base (eg. goes to fix type 5) then the position/velocity on the rover can become a lot worse than the position/velocity on the base. I’ve seen errors of several meters at times.
This is why for copter 4.1.0beta6 we’ve changed the setup to use the base GPS as the primary. It gives more reliable position and velocity. The EKF can cruise along without the yaw for quite a long time, but if the GPS gives it rubbish for the position and velocity then things can go badly wrong fast, especially when the GPS claims to have high accuracy (which it usually does when in fix type 5).
Thanks for the clarification. I had seen, in the code (a couple of months ago), comments about switching to the Moving Base for position IF the rover lost type 6 RTK, which made sense for the reasons you cite. I can see where it makes more sense just to use the Moving Base all the time, as you are now doing.