Rover-4.1.0-beta1 released!

After over a year of development we have just released Rover 4.1.0-beta1 for beta testing and it can be installed using the ground station’s beta firmwares link. If using MP, click “beta firmwares” on the bottom right of the Firmware Install screen, confirm the label changes to “Rover 4.1.0 BETA” and then push the Rover icon.

This is the first release of 4.1 so there are undoubtedly issues but it has been alpha tested by a few developers so we think it is generally safe and would greatly appreciate testing and feedback.

If you find issues, please create a new “topic” in this Rover 4.1 category and include an onboard log if possible. The dev team will be actively investigating and tracking reports.

Changes from 4.0.0

  1. EKF changes:
    a) EKF3 is default estimator (EKF2 is available as an option)
    b) External AHRS/IMU support (e.g. VectorNav)
    c) Gaussian Sum Filter (GSF) allows emergency yaw correction using GPS
    d) GPS-for-yaw (dual F9 UBlox GPS can provide yaw)
    e) Lane switching logic improvements
    f) Sensor affinity (improves sensor failure redundancy)
    g) Source switching for GPS/Non-GPS transitions (see EK3_SRCx_ parameters)
    h) Yaw estimation and reliability improvements
  2. Control improvements:
    a) Vectored thrust improvements (see MOT_VEC_ANGLEMAX parameter)
    b) Skid-steering supports prioritising steering vs throttle (see MOT_STR_THR_MIX parameter)
  3. Walking robot support (basic)
  4. Object avoidance:
    a) BendyRuler hesitancy improvements
    b) Intel Realsense 435/455 camera support (companion copmuter required)
    c) Return to original path after clearing obstacle (see OA_OPTIONS parameter)
    d) Simple avoidance backs away from obstacles (see AVOID_BACKUP_SPD parameter)
    e) Simple avoidance accel limited (see AVOID_ACCEL_MAX parameter)
    f) Simultaneous Dijkstra and BendyRuler path planning
    g) Obstacle database now 3D
    h) Obstacle filtering improvements
  5. Compass enhancements
    a) In-flight learning improvements (see COMPASS_LEARN = 3)
    b) Large vehicle calibration support (e.g. point vehicle north and push button in MP)
    c) Prioritisation (see MP’s compass prioritisation table)
    d) Custom orientations
  6. Intel RealSense T265 support (see VISO_TYPE = 2, companion computer required)
    a) Position and velocity from external sources accepted at up to 50hz
    b) Resets from external sources accepted
  7. New autopilot boards
    a) CUAV-Nora, CUAV-X7
    b) FlywooF745
    c) Holybro Pix32v5
    d) iFlight BeastF7 and BeastH7
    e) MatekH743
    f) mRo ControlZero, Nexus, PixracerPro
    g) R9Pilot
    h) SuccexF4
    i) QioTekZealotF427
  8. IMU improvements:
    a) temperature calibration
    b) faster gyro sampling on high performance autopilots (F7 and faster, see INS_GYRO_RATE)
  9. New drivers
    a) AllyStar NMEA GPS
    b) BMM150 as external compass
    c) CRSF and SRXL2 RC protocols
    d) Dshot (bi-directional) for RPM telemetry
    e) GY-US32-v2 lidar
    f) HC-SR04 lidar
    g) Intelligent Energy hydrogen fuel cell
    h) Lightware SF45b lidar
    i) MSP protocol support (and DJI DPV systems)
    j) RichenPower generator
    k) Rotoye smart battery
    l) RunCam Split 4 and RunCam hybrid support
    m) Smart Audio
    n) SMBus batteries up to 12 cells
    o) USD1 CAN radar
  10. Scripting enhancements:
    a) Button, Proximity, RangeFinder and RPM sensor support
    b) DO_ mission commands can be triggered from scripts
    c) I2C sensor driver support (i.e. allows writing sensor drivers in Lua)
    d) Logging (i.e. allows Lua scripts to write to onboard logs)
    e) Mission item read support
    f) Motor drivers support (used for walking robots)
    g) Position, velocity and direct steering & throttle control while in Guided mode
    h) Pre-arm checks (i.e. allows writing custom pre-arm checks in Lua)
    i) RCx_OPTIONs can be triggered from scripts
    j) ROMFS support (allows writing scripts to ROMFS instead of SD Card)
    k) Serial port support (allows reading/writing to serial port from Lua)
    l) ToshibaCAN ESC usage time read support
  11. Other enhancements:
    a) Baro parameters start with BARO_ (was GND_)
    b) Barometers get device id for easier identification
    c) ChibiOS upgrade to 20.3
    d) CRSF passthrough for Yaapu widget
    e) DShot rates increased (see SERVO_DSHOT_RATE)
    f) Filesystem/MAVFTP expansion including @SYS for performance monitoring
    g) MAV_CMD_DO_REPOSITIOaN support
    h) MAVFTP performance improvements
    i) Parameter reset workaround by backing-up and restoring old params after eeprom corruption
    j) Sailboats get arming check for windvane health
    k) Simple mode supports two paddle input
    l) Speed nudging in Auto made more consistent with Acro (i.e. same stick position results in same speed)
    m) Spektrum VTX control
    n) Switch to Manual mode after mission completes (see MIS_DONE_BEHAVIOR parameter)
  12. Bug fixes:
    a) Arming rejected in RTL, SmartRTL and Initising modes
    b) CAN GPS ordering fix (previously order could switch meaning GPS_POS_ params were used on the wrong GPS)
    c) Logging reliability improvements
    d) RM3100 compass scaling fixed
    e) Speed control jumps avoided by resetting I-term when stopped
    f) Throttle slew rate fix (MOT_SLEWRATE param)
    g) Two paddle steering deadzone fix
    h) Wheel encoder fix (data could be skipped)

Thanks in advance for your help with beta testing and we hope you enjoy the new features!


@rmackay9 I’m currently in the middle of some modifications to Rover for internal use. I’ve been working in a fork of Rover-4.0 so far.

Will this branch - - continue to be updated through the beta testing and become the final 4.1 release?

i.e. should I fork from Rover-4.1, keep it updated with any updates you make, and plan to merge my changes into this branch?

1 Like


Yes, the Rover-4.1 branch will be updated and eventually the final official release will come from this branch. We suspect we will rebase on master at least once during the beta period because we expect that there are a lot of issue we will need to resolve. Most of these will fall out of the Copter testing but in any case, we think this Rover-4.1 branch (and master) will be quite active over the coming month or two before the stable release goes out.

If you intend to try and get your changes into the official release then it’s best to submit PRs against master rather than the release branch. If you’re going to hold the changes just for yourself (and there are of course lots of good reasons to do this as well) then rebasing occasionally on this Rover-4.1 branch makes sense.

Thanks. It’s unfortunate timing - we wont have time to test any of the code changes in the real world before you’re likely to be releasing, so I don’t think I can submit them as PRs yet.

Main changes I’m working on are:

  • Implementing ICEngine for Rover (and fixing what I see as a couple of problems in that code)
  • “Fixing” Hold so that it actually uses the speed controller to bring the vehicle to a stop (rather than just trimming throttle), and runs the lateral acceleration controller to hold zero lateral acceleration until it stops.
  • Modifying the speed controller in AR_AttitudeController so you can use a negative desired speed to influence how aggressively it applies the brakes.
1 Like

@mroberts, ok great, those changes all sound useful!

I installed beta1 on my MatekH743 based rover.
Here is what I noticed:

  1. “Install Firmware” with latest MP-beta 1.3.7772.5701 failed, but works fine with “Install Firmware Legacy”.

  2. ESP8266 Telemetry behaves strange.
    I use ESP8266 as an AcessPoint in the rover. After some minutes the UDP WIFI connection terminates on the PC. It looks like the ESP8266 reboots somehow. I can re-connect after the AP is shown again on the PC.
    It seems to work stable, after I reduced SERIAL1_BAUD from 921k to 230k. 460k and 500k also did not work reliable in my setup. 921k is the default for ESP8266. So I think it is designed to work with such high baudrate.

WiFi communication is OK on my Rover with a Pixracer.

1 Like

Hi Peter ,
I’m, testing the functionality of ap_button , i activate it and limited the BRD_COUNT_PWM to 4 but when i try don’t see the action on mode change … i set change from manual to acro and vice versa on 4 different pin .
The firmware that i uploaded is 4.01 beta the version that automatically is possible to download to mission planner . I’m testing the Pixhawk 4
Thanks for support.


OK, so this is working as expected in master.

I created this autotest to demonstrate the behaviour:

What you need on the pin is a toggle switch, not a momentary button.

What happens is that when the channel goes high, we change to that mode - when it goes low we re-poll the mode switch (there’s some funky interactions if you assert multiple of these aux-function-change-mode channels at the same time, but let’s ignore those). This is entirely analogous to what happens when you use the functions via RC remote control - would you expect to be able to put “auto” mode on a momentary (e.g. trainer) switch on your RC unit, and when you release it it stays in auto (hint: it won’t :slight_smile: )

One thing we could do is add a bit to the “button options” parameter we now have for each configured button, making it a “toggle switch”. So pressing it once activates the function, pressing it a second time deactivates the function. Entirely doable AFAICS, just nobody’s asked for it :slight_smile:

1 Like

@peterbarker, thanks very much for this analysis. Another option would be that the AP_Button only executes the high option when pressed. I think for many of our auxiliary switch options it’s the high option that is the important one so it might be best to simply not to implement them.

1 Like

I intend to use it as a bumper safety button (with some backing up and than resuming), so i guess i dont need a toggle but just a trigger - high.