Rover-4.1.0-beta4 released for beta testing

In sync with the Copter release, Rover-4.1.0-beta4 has just been released for beta testing.

The changes are listed below and are also in the Release notes.

Changes from 4.1.0-beta3

  1. Rover/Boat specific enhancements and bug fixes
    a) DShot support fixed
    b) Simple Avoidance fix to allow backing away from obstacles
    c) THR onboard log message logs forward-back acceleration
    d) Waypoint delay of -1 does not delay
  2. Minor enhancements (or changes)
    a) CSRF telemetry improvements to power setting and pass param requests more quickly
    b) CUAV X7/Nora supports ICM42688P IMU
    c) Pix32v5 USB product string fixed and IMU heater enabled
    d) RunCam Hybrid supported (see RUNCAM_TYPE parameter)
    e) VisualOdom feature removed from 1MB boards
  3. Bug fixes
    a) BLHeli Auto only affects telemetry passthrough to ease setup
    b) Circular complex fence radius not truncated
    c) CubeOrange serial1/2 DMA fixed
    d) ESC telemetry fixes including motor index on boards with I/O mcu
    e) I/O MCU reset fix if user had disabled safety switch (recovery from reset would leave motors not spinning)
    f) MSP temperature scaling fixed
    g) PreArm check of roll/pitch and yaw angle difference fixed
    h) Serial port info file (@SYS/uarts.txt) easier to understand
    i) Scheduler fix of premature run of tasks every 11min
    j) Visual odometry yaw alignment fixed

We still have a number of issues to resolve before 4.1.0 can become the stable release but we’re making good progress thanks very much to our beta testers!


Great news! I have to get some mowing done this week, so I’ll update to beta4 and see how it goes.

1 Like

Nice timing, I have this pile of bits ready to start testing when I get my base station set up this weekend.

I notice that beta4 still auto sets the GPS UART2 to 460800 and due to recent change UART1 now set to 230400

I have my corrections coming in on the XBee, so I have set that to 460800 and am hoping that this will work, as I guess it is similar to Kenny’s set up.

I have had parts for a long time and have been watching Yuri and Kenny’s progress over the last year keenly, it appears that RTK with GPS Yaw is now almost plug and play, but we shall see this weekend :slight_smile:



Great, hope it works OK. We are slowly getting through some issues raised by Kenny and Yuri but I think there are a few issues left still. I hope/expect we can get them sorted out before the stable release.

BDshot is now working with Matek H743. I get the RPM reading in esc1_rpm.
I had to activate DShot for all outputs (S1+S2) of the timer group, even if only one ESC is connected.

This is cool!
Can “esc1_rpm” somehow be used to improve the speed estimate?



I don’t know much about rover, but I suspect that currently you cannot use the RPM to estimate the speed. Seems like it would be relatively straightforward though if you knew the wheel diameter.


Great that you’ve got it working and thanks for the feedback!

@andyp1per is right that we don’t support using the RPM as a wheel encoder which is what would be required to use it for speed estimation and control. If it was accurate enough that would allow autonomous driving in non-GPS environments and even outside it might improve the estimate which could be good especially for slow moving vehicles.

Our wheel encoder update rate is really fast and accurate though… I wonder if the ESCs RPM reporting is good enough.

Hi Randy,
for me, on omnibus F4 pro, it still doesn’t work. The distance in “sonar range” is correctly shown, but my rover does not stop and hits the obstacle.


You’ve setup the PRX_TYPE = 4? If possible maybe create a new topic and/or provide an onboard log? Sorry if you’ve already done this somewhere and I’ve missed it…

EDIT: ah, it seems there’s already been a discussion here and it looks like the board is a 1MB board so it doesn’t have the Proximity library (e.g. the PRX_TYPE parameter does not exist).

This situation hasn’t changed I’m afraid.

1 Like

BDShot allows very fast update rates (i.e. 0.25x - 1x loop rate) so might be ok

It is an OMNIBUS F4 (1MB Flash) and the parameter PRX_TYPE is not there.

In that thread it was said that the simple stop could also work on 1MB cards. It is not so? With 1MB cards do we need to have rovers without obstacle avoidance? Is it possible to have at least the simple stop by installing the old versions of the FW?

Thank you


I’m afraid that we’ve removed PRX from the 1MB boards in 4.1 so proximity based avoidance won’t work I’m afraid. If the PRX_ parameter is there in 4.0 then it should work but this is probably not the place to discuss it.

I’ll bring up with the other devs the issue of PRX being disabled in 4.1 for rover on 1MB boards. In general we don’t like to remove features as part of a release but we were forced to because Copter wouldn’t fit on 1MB boards but I suspect that Rover would… it just makes the combinations of features, boards and vehicles more complicated…

1 Like

@rmackay9 thanks!

With FC like omnibus F4 pro, cheap esc and cheap tank on aliexpress, you can make smart tank ardurover for less than 70 USD. If they were smart enough to avoid obstacles that would be great!

Even with 4.0 the simple stop does not work. Maybe I need to try something older?

Hi all, what you have created and tested is absolutely amazing! I have hit full covid/boredom/new hobby mode. As I am getting into tinkering/robotics(my background is light business automation with python, so in the ballpark but hanging out in right field, lol), I thought this would be the place to start and I apologize if this is not the correct forum, but I have been watching Yuri’s videos on youtube and my jaw is on the floor! With the research I have done so far, does anyone have a recommendation on where to start with regard to GPS GNSS systems? I realize I have a lot to build, but curious if the group has pro’s/con’s with experience with pixhawk/cube vs emlid navio2/M reach M+/Reach RS, etc? Or something entirely different. My hope would be to eventually create a lawn bot as well. Any recommendations or help/guidance you can provide would be awesome! Thanks and again, the work yall have done is amazing! John

While I can’t compare and contrast too many flight controllers, I used a PX4 FMUv5 controller when I first got started. It was adequate, and I don’t think a GPS-for-yaw mower needs much more. However, I upgraded to a Cube Orange and have been very pleased. I make significant use of onboard Lua scripting, and I can’t help but think the faster processor helps with GPS-for-yaw as well. @ktrussell used a Kakute controller up until recently, and he has likewise found that the Cube Orange is a good upgrade.

I used a Holybro plug-and-play GPS module for proof of concept. It was non-RTK capable, and as such, nearly useless for mowing applications. It did, however, prove that I was on the right track.

I then upgraded to a single Here2 M8P based module with an M8P base station. No matter how I configured things, I could never maintain an RTK Fixed solution (almost always RTK Float). Also, several combinations of magnetometers proved equally disadvantaged on a large steel rover with a combustion engine and spinning blades. I did some decent mowing with that setup, but it never achieved the kind of accuracy I really wanted.

The next step was a pair of simpleRTK2B Zed-F9P boards and a foray into GPS-for-yaw. I was on the bleeding edge when it came to practical use of GPS-for-yaw, which induced a lot of frustration, but I was able to finally reduce the magnetometer errors (and eventually completely eliminate them as the firmware matured). I REALLY like those boards and continue to use them today.

After I upgraded to F9Ps on the mower, I was still using an M8P base station, and RTK Float was still my usual mode of operation. As soon as I upgraded the base station to yet another simpleRTK2B board, everything really started to click, and the mower maintained RTK Fixed almost continuously.

For the price and the ease of integration into the ArduPilot ecosystem, I highly recommend the Cube Orange with Zed-F9P-based boards for all GPS needs in a mowing application. At a minimum, it’s a proven combination, and there’s a lot to be said for not reinventing the wheel (as tempting as it is sometimes!).


Thank you so much @Yuri!!

1 Like

I will basically second Yuri’s advice. Be sure the controller you get has 2MB of flash (or more). I was happy with the performance of the Kakute F7, but it only had 1 MB of flash which meant it could not run “off-the-shelf” Ardurover that includes the GPS for Yaw feature. If you do not plan to use GPS for Yaw, then 1 MB is fine. The difference in price from something like the Kakute F7 to a Pixhawk Cube Orange is significant.

I was able to get the GPS for Yaw to work on an old Pixhawk 1 (2.4.8) (which has 2 MB of flash). (Demo here: I did not put it into operation in the field, but it probably would work OK. I do like the Cube Orange, though. With it, you know you’ve got the horsepower for things to come. The Holybro Durandal controller is pretty popular and I believe has the same processor as the Cube Orange. I probably would have gone with it instead of the Cube Orange but stock was not available in the US.

Ublox sells a C099-F9P evaluation board. I have 4 of them (used them for a work project and for my mower). I also have several Ardusimple RTK2B boards (for same project). The Ardusimple boards are easier to connect. The C099-F9P boards have a built-in wifi chip that can be used between the boards for the RTK corrections from base to rover, but the range is so short that they really are not useful and the extra complexity is of no use. The Ardusimple boards have a connector ready to go to connect to the flight controller.

Good luck!

1 Like

Good luck with your build! One word to the wise: Be careful with your GPS_POS… parameters. It is very important for the X, Y and Z relationships between your Moving Base and your Rover GPSes specified by those 6 parameters to be pretty close. I have helped another person recently and that was the problem. It gave me a little trouble also a couple of weeks ago when I was getting mine going.

1 Like

Initial thoughts on beta4:

The firmware updated without issue as always, however, Mission Planner immediately crashed when I tried to connect MAVLink telemetry via TCP. I updated Mission Planner to the newest beta, and that did not solve the problem. I was able to connect via USB, and once the parameters were downloaded, I was able to successfully connect via TCP.

Also, many of my tuning/calibration parameters were lost (making my initial auto mission behave EXTREMELY poorly, especially with that aggressive NAVL1_PERIOD of 2s!). Thankfully I routinely back those settings up, so I reloaded them from a recent file, and all seems well now.

1 Like

Also, something has gone very wonky WRT fence avoidance. With the same BendyRuler settings as I mentioned in this thread, the mower did not perform well, as you can see in the screenshot. I’m not blaming beta4 just yet, though, because I failed to move two waypoints out of the fence confines like I usually do, but I think it’s worth noting this oddity.

Unforunately, my time to explore this fully is quite limited until later in July (I’m doing some last minute mowing before some other commitments will take me away from this project for a couple of weeks).