Yuri's Mower Updates

On the topic of GPS_AUTO_CONFIG=0 and ‘Unhealthy GPS Signal’ warnings, I tested this a bit more today with the same results.

I then connected uCenter and downloaded the GNSS configuration files for both GPSs in both scenarios. There were no differences in those files whether GPS_AUTO_CONFIG was enabled or disabled.

Most curiously, I had a full EK3 alignment with good GPS yaw with GPS_AUTO_CONFIG=0 and the usual, persistent ‘Unhealthy GPS Signal’ messages. I set GPS_AUTO_CONFIG=1 without rebooting, and the messages immediately cleared.

I don’t think this is a case of the configuration not saving completely so much as another flag somewhere in the GPS-for-yaw checks that is not passing when GPS_AUTO_CONFIG=0.

I wrote a similar comment and included the uBlox config downloads in the 4.1.0 issues conversation.

I am currently mowing just fine but I have “Unhealthy GPS Signal” constantly. I cannot turn auto config on because it sets the baud rate of UART2 for both GPSes to 460800. Just giving a second data point about the message, although I cannot completely duplicate your experiment.

I suspected that would be the case for you. I was actually hoping you’d avoid it, and then I could pick your brain about parameter settings, but I think your findings confirm this as a valid issue raised with the dev team.

3 Likes

I saw that gpsyaw is now a selection for the quick window/status screen in Mission Planner beta. However, it shows a 0 value regardless of actual GPS yaw status. I wonder if that should actually be gpsyaw2 to pull the value from the rover in a typical setup?

I have been mowing for about 8 hours with GPS Yaw. I see 65535 flash briefly in Mavlink Inspector (probably 1 update at the 2 Hz rate) about every 20 or 30 seconds, but I cannot tell that it is hurting anything. My tuning isn’t very good right now, but I’m trying to finish a field before rain comes tomorrow. (11pm here now). I’m looking forward to trying to get tighter control now that heading is hopefully solid!

1 Like

I bet you’re going to go through the same thrash I did. I fought the magnetometer errors so hard that I had a bunch of tuning parameters at values that masked the magnetometer problem the best I could, but the tuning parameters became a series of offsetting errors. Honestly, it wasn’t hard to get things back to where they should be, and the steering tuning is key. The documentation on that is pretty good, and I feel good about where I am. Although…Randy just replied after reviewing my .bin log, and I think he’s suggesting I can improve!

The real question is…how’d the mowing go? Sounds like you’re getting some good work done, tuning or no.

A lot of it was in the dark, so I’ll know tomorrow! :slight_smile:
It looked good, though, during the day, as far as not missing any spotos. But the mower was very sloppy. I was cutting my usual 30" width with a 60" mower. I tried exactly 1 meter for a short time and I had some skips. I tried some of you parameter suggestions, such as the Decel setting and didn’t get much improvement. Lowering the NAVL1-Period below my current 20, gave bad oscillations. But, I think once I go back to basics and tune steering and throttle as I have in the past, things will be much better. No sense messing with other parameters until I have pretty good control with steering and tuning.

1 Like

I think I’m going to try to find where in the code the baud rate is set for UART2 on the GPSes and change it to 115200 (or maybe 230400 if my Feather can do that speed and I think it can) and then I think I will be plug and play and can try leaving GPS_AUTO_CONFIG at 1 and see if the Unhealthy GPS signal goes away as it does for you. And it would be nice to report back to the developers that they have everything working well for an external setup like mine.

I know how that goes…I think the neighbors truly think I’m a madman…my lawn mowing itself with a flashing warning light and relay controlled headlights at hours that most people wouldn’t attempt yardwork…

I use a 35" lane width with a 48" deck. I bet once you get tuned up, you’ll be able to increase the width to 40" to 50" without issue.

A decreased NAVL1_PERIOD (at least lower than about 15) is probably the last thing to pursue - it will exacerbate all of your other tuning issues otherwise.

2 Likes

AP_GPS_UBLOX.cpp, lines 132 and 185 :smiley:

After all that code research yesterday, that was an easy one.

2 Likes

so ap_gps_ublox.cpp is the file with the auto configuration Mission Planner uploads to the receivers when gps_auto_config is 1?

if you guys don’t mind me asking, what are the messages you have enabled on uart1/2 of moving base and moving rover?

I know on moving base you should send rtcm3 to rover and relposned, and nav-pvt to flight controller so you can see the fix type on mission planner, and on rover you enable relponed and nav-pvt, but are other messages also necessary?

I will be glad to look up those messages for you, but with beta3, if you simply enable GPS_AUTO_CONFIG for a few seconds, it will configure everything correctly. In fact, if you are using MAVlink injection for your RTCM3 from the fixed base, you should be able to leave it enabled. (That is the way Yuri is operating).

In my case, after a few seconds, I turn off GPS_AUTO_CONFIG and go into Ucenter and change the baud rate on UART2 for both GPSes to 115200 (and commit to RAM and FLASH) so that my uplink of RTCM3 from the fixed base can get into GPS1 (moving base).

You, then leave the GPS_AUTO_CONFIG off. The GPSes have committed the settings to flash, so it comes back up perfectly from then on.

Hope that helps, but here are the messages set up by Ardurover in my configuration.

From Moving Base to Rover (on UART2):
RTCM3_3X_TYPE4072_0
RTCM3_3X_TYPE4072_1 1
RTCM3_3X_TYPE1077 1
RTCM3_3X_TYPE1087 1
RTCM3_3X_TYPE1097 1
RTCM3_3X_TYPE1127 1
RTCM3_3X_TYPE1230 1

From Moving Base to Flight Controller (on UART 1):
UBX_MON_HW2 5
UBX_MON_HW 5
UBX_NAV_DOP 1
UBX_NAV_PVT 1
UBX_NAV_TIMEGPS 5

From Rover to Flight Controller (on UART1):
UBX_MON_HW2 5
UBX_MON_HW 5
UBX_NAV_DOP 1
UBX_NAV_PVT 1
UBX_NAV_RELPOSNED 1
UBX_NAV_TIMEGPS 5

2 Likes

@rmackay9 Happy Camper Here! I changed the UART2 baud rate to 115200 in AP_GPS_UBLOX.cpp, lines 132 and 185, and am happy to report that ArduRover configures my GPSes perfectly now for my configuration. I think if that baud rate was configurable via a parameter, we would be golden.

This is my exact configuration using Ublox C099-F9P evaluation boards:

It is also equivalent to this configuration with Ardusimple SimpleRTK2B boards:

1 Like

I wanted to use the beta version, but when I connect both of the gps to my cube, the mission planner crashes, also with the dev version, only the stable one this does not happen.

Also I using the piggyback connection with the smaller board, so it wouldnt work the auto config because the it has to be the uart 1 from the small one connected to the big one, and the autoconfig uses the uart2 from both of them

If you update to the latest beta of mission planner (on the help screen), the crashing should stop. I had the same trouble you are having until I did that.

If you have room on your rover to mount the piggyback board beside the other gps board, you can probably wire them the way you want. The piggyback feature is nice, though.

@jolivart from ArduSimple posted a good tutorial on using the piggyback boards. I think he reverses the moving base and rover as GPS2 and GPS1, respectively. I’ll try and find the link later when I’m not tied to my phone.

1 Like

I think this is the link you are talking about: Rover 4.0 + Ardusimple = GPS Yaw debugging

But I believe there may have been another thread about it as well.

That’s the one! He also mentioned this link. However, you’ll need to use EK3_SRC1_YAW= 2 instead of EK3_MAG_CAL=5 with the newer 4.1-series firmware updates.

Hi @GRS26,

There are some mixed reports about whether the latest MP resolves the “evaporation” problem or not. For me (using the version printed below) it seems fine but there is at least one user who says that it is still happening.
image