Yuri's Mower Updates

ArduRover Rover 4.4
82

To be slightly flippant…I would kill for enough free time to be able to give you a full breakdown and schematic. Unfortunately (and as you can see by my snails pace of video uploads), free time is at a bit of a premium here.

I’ll try and answer as many questions as I can, though, and I really hope to carve out some time this summer for some more detailed videos.

Speed is the answer to your question. Linear actuators (at least affordable ones) tend to be slow. Kenny and I almost independently arrived at identical conclusions there. We both bought the same linear actuators at first (unbeknownst to one another at the time). I knew immediately I’d likely be unhappy with them and went looking for alternatives. It’s actually how I found this site and Kenny’s videos. He released his servo update video that week, and I immediately bought the same ones. They’ve been working great for both of us.

2 Likes
83

Enjoyed your latest video what to learn more about the python scripting looking forward to your next video
Regards
Darren

1 Like
84

Hello,
I am trying to see what sets off the Unhealthy GPS Signal, to try and discover what is happening, so far I found in this link


This line of code:
else if (!sensors_health.gps && sensors_enabled.gps && sensors_present.gps)
{
messageHigh = Strings.BadGPSHealth;

85

@GRS26,

This mission planner code is likely making use of the mavlink SYS_STATUS message which is sent from the vehicle using AP’s GCS_MAVLink library which is using the AP_GPS library’s is_healthy() method.

My guess is that the cause of the problem is the 2nd GPS isn’t updating at 4hz which can be verified by checking the onboard log GPS message but you might need to filter the messages by the “I” field (“I” is for instance) so that the times from each GPS can be checked separately.

86

in my case, that I am using the piggyback setup, what should I change to stop the unhealthy gps?

87

through ucenter it seems it is updating higher than 4hz, i set it up for 10 hz

88

@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.

89

strange, this is the frequency ardusimple suggests

90

@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.

91

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
92

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

93

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
94

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
95

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
96

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

97

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

98

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?

99

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.

100

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).

101

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.