Rover-4.0.0-rc3 available for beta testing!

Rover-4.0.0-rc3 (the 3rd beta) has been released and is available using the Ground Stations’ (MP, QGC, etc) “beta firmware” link. The changes vs -rc2 are in the ReleaseNotes and also copied below:

  1. IMU heater control parameters (see BRD_IMUHEAT_P/I params)
  2. Bug Fixes:
    a) DO_CHANGE_SPEED fix (was being ignored)
    b) SET_YAW_SPEED in Guided mode made consistent with Auto mission command handling (yaw in degrees, speed in m/s)
    c) BLHeli fix to RPM calcs and telemetry (aka 0x8000 error)
    d) Fence upload is less strict about altitude types (fences don’t have altitudes)
    e) Pre-arm message fix to reports AHRS/EKF issue (was blank)
    f) Sparky2 autopilot firmware available
    g) Startup message “AK09916: Unable to get bus semaphore” removed (was not an error)

This version has been “rebased on master” which means that it is a new snapshot of our latest development firmware and thus includes a few other smaller changes as well.

The major fix is 2a (DO_CHANGE_SPEED fix). Thanks very much to Jimovonz for finding this!

Our hope is that this is the final release candidate before we push Rover-4.0.0 out as the stable version so any last testing people can do in the next week or so is greatly appreciated!


I tried to get SITL simulation of rangefinder to work (to display simulated measured depth). I noticed that there was a fix for a similar problem in Copter aprox 25 days ago. Does the rebase mean that this is also OK for rover (I get no simulated value at all, or 0.0, when testing for rover - perhaps because Mavproxy does not recognize param RNGFND_ but rather RNGFND1_ etc)?

Hi @oaamaas, so you’re trying to use a simulated downward facing depth sensor on a boat? I don’t think we support that in SITL although it would be useful. I think it’s not straightforward to do because we would need a source of depths. It’s probably best to raise an enhancement request in the issue list.

I have a problem with Rover 4.0.0-rc3 with a PixRacer. Rc2 was working fine. After updating to Rc3 the RC inputs no longer work and it gives this odd error as shown below. If I flash back to 3.5.2 it’s back to working.


OK, thanks for this. This is an annoying but mostly innocuous bug. I’ve got a partial fix for it here which we will include in -rc4. I’m afraid that for now you’ll need to set RC6_OPTION to another value because until this fix goes in the auxiliary function options for RTL, SmartRTL and Simple won’t work, sorry!

Thanks very much for finding this!

OK, but there is a bigger problem. With rc3 I lose RC Input. GPS is not recognized either. I flash back to current Stable and everything is working. Not sure where to find Rc2 which also worked. Attached is a disarmed log of Rc3 if it’s any help. Is it related to the RCx option problem?

2 31-Dec-79 07-00-00 PM.bin (28.0 KB)

Edit: This was the problem. These errors were preventing the FC from initializing. When I removed all Rcx options it’s behaving normally. I can’t really drive it this way as I had several options configured but no big deal. The weather is terrible here anyway and it’s what Beta’s are for!

Hi Randy,

I just wanted to report that UAVCAN is working for me now.
I have connected two Emlid Edge GNSS receivers to a pixhawk, did the required setup and they work!
The rover also gets a very stable heading, but there are no external compasses detected. Both GNSS receivers have a full IMU, Baro and compass. I could not find out yet, if any of the additional data gets used by ardurover.
Today I am going to hook up one of my VESCs (the PC software allows CANbus message inspection) to the CANbus, to see which messages are going around. Perhaps the VESC does also work with the Pixhawk UAVCAN now.

1 Like


Thanks for the follow-up. Yes, it seemed the innocuous config issue then triggered a whole bunch of subsystems to be disabled. An over reaction in the code which we’ve got a fix for and this will also be included in -rc4.

@count74, great that UAVCAN is working. We don’t have documentation yet on how to use two GPSs for yaw but I’ve added it to the wiki to-do list.


Re dual-GPS for use in heading, this PR apparently has some instructions but I think this is for the Hemisphere GPS.


Sorry, we still don’t have instructions but hopefully we will before too long

Randy, I am happy to test dual GPS heading, but I was not really trying to achieve that. I was just trying to find out, if ardurover gets data from the built-in magnetometers in the Emlid GNSS modules over CANbus.
Also I could not get the VESCs to work over CANbus/UAVCAN. One Motor starts turning, when I set the UAVCan ESC bitmap, but I can not control it. Going to test some more.
Weather is awful anyways

1 Like

rc3 when switching to dshot esc’s don’t arm on startup
When using normal (pwm) they work.

I don’t want to request a change before it is really needed. So I put this on hold for some weeks. I’ve been progressing nicely with a GCS for boats (originating from Tower and Drone kit). Now some new and very interesting ideas have surfaced. And then the need for simulated input from a range finder surfaces once more. Before I do submit a request I need to do some thinking. Maybe you and others may help…

My ambition is to combine drone position with depth value and:
Step 1: Make a csv as input to Reefmaster (faster than having to retrieve the data from logs)
Step 2: Also create a geojson stream and try to display the polygons on the GCS map “live”.

The second step is ambitious, but seems to me it can be done and thus worth spending time on. But it is going to be really hard without some help from the SITL.
One option is to have the simulator read from a csv. I have these from previous mappings. But I think this is an unneeded complication as I would not drive the same mission during simulation anyway.
So my thinking is that perhaps all I need is to set a lower and higher value for simulated readings (max and min depth), one value per second, and perhaps a maximum change rate between readings? Not sure how the current simulator for altitude works. Maybe a really easy start (just to test) is to allow the existing simulator to provide input to the rangefinder “down”?
Any thoughts?

1 Like

@oaamaas, sounds like a good plan.

For Step2 I think maybe @peterbarker can give some advice. I think it should be possible to fake up some range data using the vehicle’s location but I’m not sure exactly how it should be done.

Easiest way to fake input data would be to have some function on distance-from-origin. Some sort of sinusoid. Rather unlikely to be physically correct for any location, but easy to put together.

We have a simulated BLping sensor; working state unknown as I only wrote it to cross codepaths, not provide brilliant input.

1 Like

I tested this, and I definitivly got a graph. But that does not input a measured distance into the Mission Planner’s “Sonar range” field. For a boat and a simulation of rangefinder, the rangefinder needs to be of NMEA type (17). Found that such an alternative does exist, but not able to get it to work for a rover:
Simulator for the NMEA serial rangefinder
./Tools/autotest/ --gdb --debug -v ArduCopter -A --uartF=sim:nmea --speedup=1
param set SERIAL5_PROTOCOL 9
param set RNGFND1_TYPE 17
I guess any value would do as long as I successfully can retrieve some data …

I guess it didn’t make any difference if the FRAME_CLASS was setup as a boat?

So FRAME_TYPE =2 is the only key to get it working. I’ll try to test this with an arducopter firmware then. Did a quick test before work, no use of graph for this simulator? Does not really matter as long as it provides some value to trigger a RANGEFINDER mavlink message I guess.

@rmackay9: Got a little uncertain here, and I assume you may know the answer: Will the distance measured from a transducer be reported as a mavlink “rangefinder” message, or will it instead be reported as a “distance_sensor” message? Obviously not using an APM board here…