Rover-4.0.0 released!

Hi. I am years light from understanding the implications of this for Rover code. Surprisingly, in Rover release notes appears:
Rover 4.0.0-rc3 08-Nov-2019
Changes from 4.0.0-rc2

2) Bug Fixes:

c) BLHeli fix to RPM calcs and telemetry (aka 0x8000 error)

I experimented on the balanced bot with two pixhawks at the time (one over the other), one with v4.0.0 (moving motors) and the other with v3.5.2 (with same parameters (mostly)), with the encoder outputs connected to both with Y’s, armed it, and leaned it forward and back several times, resulting this

(v4.0.0 not showing WENC RPM0 RPM1)

(v3.5.2 showing WENC RPM0 RPM1)

Also RPM’s can be seen playing the v3.5.2 tlog file.

I regret the loss of this feature.

I would try add a pullup resistor between the 5V and signal line. I do not have a rover with encoders right now, but I remember having a problem with encoders between versions. I simply pushed the resistor legs in the servo connector from the rear to test it out. I used a 4.7kOhm resistor.

No need for that at all. Previous log captures were done with the balance bot motor encoders outputs simultaneously connected to two pixhawk’s one over the other with (mostly) same parameters using servo Y’s on AUX3 to 6 (as inputs), one with rover v4.0.0 (moving the motors, logging) and the other with v3.5.2 (just logging), on two instances of MP using two telemetries (arm both, lean balance bot forward and backward (pitch -90º to +90º), disarm both). Note RPM0/1 are opposite, since really motors move in opposite directions.

v4.0.0 dataflash log image shows pitch (aditionally, inserted WENC portion capture (missing RPM0/1)), and v3.5.2 shows RPM0 and RPM1 (additionally other WENC possible signals same as for v4.0.0).

Conclusion: RPM0/1 have disappeared in rover v4.0.0, both in telemetry logs (.tlog) and dataflash logs (.bin, .log); why?

Note that TradHeli maintains it for governors.

This is a first test (extracted from a twitch transmission; driver Barbie Harley Davidson) with this parameters:Barbie_20200103_v400test1.param (16.3 KB).

This is how encoder signals look like:

Ok, in earlier versions the rpm library was called at 10Hz in Copter and it was for logging only. When I designed the helicopter governor, I could not get enough samples thru the 5 element mode filter at 10Hz to get the governor to work. So I changed the update rate in Copter to 40Hz.

This should not affect Rover at all, the rpm library is the same as it always was. There was no mods to it. So I’m fairly sure I didn’t break it for Rover.

From the params you posted, it doesn’t look like the RPM settings are configured for Barbie? It looks like the pin and type is set to -1 and 0 for both RPM/RPM2, which is disabled.


Thanks for your attention to this problem.

Recall that I maintain two pixhawks on the Barbie, one with v4.0.0 moving the motors, and the other with v3.5.2 (just logging), with the encoder outputs connected to both with servo Y’s. There are two telemetries and I run two MP instances, or one instance with a connection list.

v3.5.2 configuration has no RPM_xx parameters, and RPM0/1 works. For clarity here are last versions:
Barbie352.param (13.2 KB)
Barbie400.param (16.3 KB)

Trying to configure v4.0.0, I found confusing give values to RPM_xx parameters; after all AUX3 to 6 (encoder inputs) are defined with BRD_PWM_COUNT, RELAYxx (3 to 6) and WENCxx on both versions, which are the same on files above.

So v3.5.2 gets data for RPM0/1 from WENCxx parameters, and it works.

@Webillo, @Matt_C, @ChrisOlson,

So as mentioned by @Matt_C, in Rover-4.0 we are no longer reporting the wheel encoder data using the mavlink RPM message, instead we use the WHEEL_DISTANCE message.

We could add the rpm calculations back but that would only be for the convenience of the users. The RPM is not needed for anything internally.

By the way, we should not mixup the setup for wheel encoders (which is on the wiki here) with the setup method for the RPM sensor because they are separate features. It’s a bit odd that we even have the RPM sensor feature in Rover because we don’t use the output of these sensors at all at the moment. I probably won’t remove the RPM feature because it’s in all vehicle (including submarines even!) but it’s not actually useful at the moment.

For other reading this, the wheel encoders are good for two things in Rover:

  • Non-GPS navigation (wheel encoder data is integrated by EKF3 to calculate position and velocity)
  • Improving balance on a balance bot but only if the wheel rate controllers are enabled (see WRC_ parameters). I don’t think we have anything on the wiki explaining this part of the setup sadly.

I think it’s this last point that we are focusing on to improve @Webillo’s balance bot performance.

Ah, I see. It’s (was) an internal calculation, not an actual external sensor input like heli. That explains my confusion.

1 Like


Everything is clear now.

What happened historically is that I was assembling the vehicle, and not seeing rpm values (and no smoke) I thought I had something wrong, till trying v3.5.2 on a spare pixhawk: rpm’s appeared. A lot of wasted time.

Later, with motor data, I could not find logic values for motors CPR, measuring rpm with tachometer. I adjusted CPR empirically (v3.5.2 rpm’s displayed = tachometer rpm’s). From what is said here, I doubt if this is correct, so I’ll check with real distance later in the track. Anyhow, for different motor setups adjustments (such as using gimbal brushless motors) there is this spare pixhawk and servo Y’s method.

So now, if rpm’s calculation were internal, I have the doubt if having real rpm’s displayed is not correct (the CPR’s I use are not logical).

I suppose that there is used a servo for steering. I could not find documentation about motor controller DIR1/2, although being there two pixhawk free outputs these should be used (needing RELAY_PIN=50

There appears:
Another way to check operation on Rover 4.0 and later versions is to monitor the Wheel_Distance MAVLink messages as shown below.
My natural language is not english, and this seems to imply that for v4.0 on the old method is still valid (Another…).

Other observation is disregard the limits for PID parameters and MP warnings.

Your work is extraordinary; thanks a lot.

1 Like

@Matt_C, @Webillo, yes indeed, the wording was unclear so I’ve clarified it a bit more to make it clear that rpm1/rpm2 is visible with 3.5 (or earlier) and WHEEL_DISTANCE should be used for 4.0 (and higher).

One slightly difficulty is that because an individual message is sent for each wheel the user can’t easily see both wheel’s distances at the same time…


EKF3 Compass problems. See this.

From this and this (600 rpm at tachometer) it seems that the CPR’s should be around 100. So I left them at 105.6, as calculated from motor data. But then rpm’s with v5.2 appear four times greater (415->105.6).

It works, including a first auto mode test with RTK GPS.

1 Like

Two more 4K videos with Barbie GPS RTK missions:

Satellites positioning was bad; that prevented completing a lap on the small circuit (second video).


In regards to the motor support for the Sailboat improvements, is there a way to control stepper motors using the Pixhawk?

My senior design project is to make an autonomous large scale sailboat (14 feet long). I have succeeded with making a small scale sailboat using a pixhawk and servo motors, though for the large scale design I would have to scale up to stepper motors.

Could this update enable a motor driver to be connected with the pixhawk to control stepper motors, or would I have to interface the pixhawk with an arduino in order to use a motor driver and stepper motor? If the latter is the case, how would I go about doing this?

Any information is much appreciated!


We have an item on the to-do list to add support for stepper motors but I’m afraid it hasn’t been completed yet.

My only suggestion is perhaps there are motor controllers out there that can drive stepper motors but can also accept a PWM input.

Dear Randy,

I am currently using Rover 3.5 firmware and everything is running perfectly… Once I upgrade to Rover 4.0 when switched into Auto Mode the rover does not follow mission waypoints and instead just turns on the spot acting confused with which direction it should turn.

Is there something that needs to be changed in parameters in rover 4.0 to fix this?

Thank you

Got the same issue. In the past this had been a rangefinder issue so I tried to disable it. All RNGFNDx_TYPE is set to 0 but still showing Bad Lidar Health and doing cycles.

1 Like


The only possible thing I can think of is the change to how CRUISE_SPEED and WP_SPEED are handled. In 3.5 CRUISE_SPEED was used as the default speed for missions if WP_SPEED was left at zero. In Rover-4.0 WP_SPEED is the main parameter to set to control the speed during missions. If this isn’t it then probably best to provide a log file (ideally a .bin file).

1 Like

@rmackay9 I don’t seem to be able to disable Rangefinders anymore. Any ideas?


We’ve removed the older “dodge” style of object avoidance and replaced it with BendyRuler which is still not perfect but is much better at least.

Individual rangefinders can be disabled by setting the RNGFNDx_TYPE param to zero.