Yuri's Mower Updates

@GRS26,

In the past I have heard that configuring the GSP to update at faster than 5hz is not helpful because the GPSs themselves cannot actually provide new solutions at this rate.

strange, this is the frequency ardusimple suggests

@GRS26,

I could be wrong about the update rate because I’ve never used ArduSimple and the F9 GPSs they use are higher performance than many older UBlox GPSs. I just think it might be a good test to try reducing the rate from 10hz to 5hz and see if the “Unhealthy GPS” messages go away.

Section 2.3.2 of ZED-F9P (u-blox.com) discusses 8 Hz update, so that must at least be a supported rate.

I figured that with the heading being provided by the GPSes now, we need as fast a rate as we can get. I assume that a compass module using I2C updated much faster than 5 Hz. I would think that heading is needed at a higher rate than position, but I may be very wrong.

As Yuri has mentioned, the unhealthy GPS goes way if GPS_AUTO_CONFIG is disabled. (EDIT: I am stating this BACKWARDS - see the following posts.) I enabled it to get my GPSes set up the first time and then disabled it. The GPS config is stored in flash after just one initialization with GPS_AUTO_CONFIG=1.

I haven’t seen Unhealthy GPS Signal in a while now.

1 Like

Mine is disabled, I thought you needed to enabled it to make it go away

Up to beta4, I found no way to avoid unhealthy GPS messages with GPS_AUTO_CONFIG=0. I have yet to try beta5, but it looks like there are some significant GPS updates that may prove helpful, and Kenny’s post above looks encouraging. I will test when I get a chance.

1 Like

Re the GPS update rate, a fast update rate shouldn’t be required to keep the heading accurate because the EKF will be blending both the GPS heading and the gyro and the gyros are quite stable.

1 Like

HOLD the HORSES! You are right. I have it backwards. It has to be enabled for the message to go away. Sorry! Although, I can’t say that I have tried it on the latest beta.

1 Like

Oh, I see. That makes sense. Good to know.

There is a problem with using the gps_auto_config, I use the piggyback connection with ardusimple boards, the configuration that works in this setup does not match with the one from gps_auto_config

I understand. Am I right that the change you need from the standard autoconfig is to have RTCM3 OUT on UART1 of the daughter board because that is what feeds into the parent board on it’s UART2?

the rover board’s uart2 is connected to moving base board’s uart1 at 460800.
the rover board’s uart1 is connected to my fc.
the fc does not send corrections, it just receive the nav-relposned and nav-pvt message from rover board at 460800.

I would have to add a option to auto_config or change to this.

I may not be looking at it correctly, but the AP_GPS_UBLOX.cpp file at ardupilot/AP_GPS_UBLOX.cpp at master · ArduPilot/ardupilot (github.com) seems to have the uarts set up the way you want (Lines 106-208). I may be missing something and you may have thoroughly looked at it.

RTCM3 OUT is enabled on Moving Base UART1 (line 112 and 116-122) and UART2 (line 135 and 140-146).
RTCM3 IN is enabled on Rover UART1 (line 165) and UART2 (line 189).

I looked that page, but I thought I wasn’t going so simple to just change the attributes and make it work, and I am not confident in my abilities with this programming language, so I am just waiting for a solution for this unhealthy gps problem.

But I think it is already the way you need it. But, I guess the issue is that you do not have the Moving Base connected to the Flight Controller at all, so ArduPilot can’t configure it at all. Bummer.

I flew the drone, and it was magnificent, much better without the compass, the unheatlhy gps is just an annoyance , but it can fly

1 Like

FYI Tridge has created a pull request that improves serial performance on some serial channels by using a FIFO. This should make setting up the GPS-for-yaw a little easier on CubeOrange and other high powered H7 boards when the autopilot is in the middle (e.g. GPSs are not directly attached together).

If anyone is willing to give it a try I’ll create a binary for CubeOrange or whatever board you’re using.

2 Likes

Sent you a message regarding the new build. I will definitely be up for testing next week. I can test both autopilot-in-the-middle (Cube Orange) and direct F9P-F9P communication over uBlox UART2 configurations with minimal effort to switch between the two. The only configurations I can’t test are the piggyback board setup that GRS26 uses and external (non-MAVLink) RTCM3 injection like Kenny does. I’ll let you know when I’m back up and running so we can coordinate the binary download.

1 Like

Looking at implementing the GPS Yaw since my magnetometer isn’t getting good readings on my large rover. Looks like everyone is having great success with it and have extremely accurate headings! Are you just using 2 F9P GPS units onboard the rover? Do you have to send RTCM3 correction data to one of the GPS units or can you just use the two onboard without corrections? I currently have a SparkFun Zed F9P paired with a Mrobotics Rev2 controller running ArduRover 4.0.

Moving baseline (GPS for yaw) does not require RTCM3 injection from an external source. However, your flight controller looks to be based upon a fairly old processor that may not support the feature set.

1 Like