Rover-4.3.0-beta1 released!

Rover-4.3.0-beta1 has been released for beta testing and can be installed using MP or QGC’s “beta firmwares” link or it can be directly downloaded from

The changes vs 4.2.3 are in the release-notes and copied below

  1. Rover specific enhancements
    a) Aux switch for SaveWP displays, “Mission Cleared” if vehicle not armed
    b) Dock mode using modified precision landing library
    c) Manual mode steering scaling with speed can be disabled using MANUAL_OPTIONS parameter
    d) S-Curves for Auto, Guided, RTL
  2. Rover specific bug fixes
    a) Wheel encoder timestamp fix (WRC_xx params may need to be changed)
    b) Auto mode stick mixing fixed (see STICK_MIXING parameter)
    c) Arming check removed to support mixed Ackerman and skid-stering vehicles
  3. New autopilot support
    a) AtomRCF405
    b) CubeOrange-SimOnHardWare
    c) DevEBoxH7v2
    d) KakuteH7Mini-Nand
    e) KakuteH7v2
    f) Mamba F405 Mk4
    g) SkystarsH7HD
    h) bi-directional dshot (aka “bdshot”) versions for CubeOrange, CubeYellow, KakuteF7, KakuteH7, MatekF405-Wing, Matek F765, PH4-mini, Pixhawk-1M
  4. EKF enhancements and fixes
    a) EK3_GPS_VACC_MAX threshold to control when GPS altitude is used as alt source
    b) EKF ring buffer fix for very slow sensor updates (those that update once every few seconds)
    c) EKF3 source set change captured in Replay logs
  5. Gimbal enhancements
    a) Angle limit params renamed and scaled to degrees (e.g. MNT1_ROLL_MIN, MNT1_PITCH_MIN, etc)
    b) BrushlessPWM driver (set MNT1_TYPE = 7) is unstabilized Servo driver
    c) Dual mount support (see MNT1_, MNT2 params)
    d) Gremsy driver added (set MNT1_TYPE = 6)
    e) MAVLink gimbalv2 support including sending GIMBAL_DEVICE_STATUS_UPDATE (replaces MOUNT_STATUS message)
    f) “Mount Lock” auxiliary switch supports follow and lock modes in RC targetting (aka earth-frame and body-frame)
    g) RC channels to control gimbal set using RCx_OPTION = 212 (Roll), 213 (Pitch) or 214 (Yaw)
    h) RC targetting rotation rate in deg/sec (see MNT1_RC_RATE which replaces MNT_JSTICK_SPD)
    i) Yaw can be disabled on 3-axis gimbals (set MNTx_YAW_MIN = MNTx_YAW_MAX)
  6. Notch filter enhancements
    a) Attitude and filter logging at main loop rate
    b) Batch sampler logging both pre and post-filter
    c) FFT frame averaging
    d) In-flight throttle notch parameter learning using averaged FFTs
    e) Triple harmonic notch
  7. RemoteId and SecureBoot enhancements
    a) Remote update of secure boot’s public keys (also allows remote unlocking of bootloader)
  8. Safety enhancements
    a) crash_dump.bin file saved to SD Card on startup (includes details re cause of software failures)
    b) Disabling Fence clears any active breaches (e.g. FENCE_TYPE = 0 will clear breaches)
    c) “GPS Glitch” message clarified to “GPS Glitch or Compass error”
    d) Pre-arm check that configured AHRS is being used (e.g. checks AHRS_EKF_TYPE not changed since boot)
    e) Pre-arm check that gimbals are healthy (currently only for Gremsy gimbals, others in future release)
    f) Pre-arm check that scripts are running
    g) Pre-arm messages are correctly prefixed with “PreArm:” (instead of “Arm:”)
    h) RC auxiliary switch option for Arm / Emergency Stop
  9. Scripting enhancements
    a) CAN2 port bindings to allow scripts to communicate on 2nd CAN bus
    b) ESC RPM bindings to allow scripts to report engine RPM
    c) Gimbal bingings to allow scripts to control gimbal
    d) Pre-arm check bindings (allows scripts to check if pre-arm checks have passed)
    e) Semicolon (:slight_smile: and period (.) supported (e.g both Logger:write() and Logger.write will work)
  10. Sensor driver enhancements
    a) Benewake H30 radar support
    b) BMI270 IMU performance improvements
    c) IRC Tramp VTX suppor
    d) Logging pause-able with auxiliary switch. see RCx_OPTION = 165 (Pause Stream Logging)
    e) Proximity sensor support for up to 3 sensors
    f) Precision Landing consumes LANDING_TARGET MAVLink message’s PositionX,Y,Z fields
    g) RichenPower generator maintenance-required messages can be suppressed using GEN_OPTIONS param
    h) TeraRanger Neo rangefinder support
    i) GPS support to provide ellipsoid altitude instead of AMSL (see GPS_DRV_OPTIONS)
    j) W25N01GV 1Gb flash support
  11. Bug fixes
    a) Accel calibration throws away queued commands from GCS (avoids commands being run long after they were sent)
    b) Cygbot proximity sensor fix to support different orientations (see PRXx_ORIENT)
    c) Lutan EFI message flood reduced
    d) Missions download to GCS corruption avoided by checking serial buffer has space
    e) Safety switch disabled if IOMCU is disabled (see BRD_IO_ENABLE=0)
    f) Script restart memory leak fixed
  12. Developer items
    a) Fast loop task list available in real-time using @SYS/tasks.txt
    b) Parameter defaults sent to GCS with param FTP and recorded in onboard logs
    c) ROS+ArduPilot environment installation script
    d) Sim on Hardware allows simulator to run on autopilot (good for exhibitions)
    e) Timer info available in real-time using @SYS/timers.txt

While we think this beta is safe, this is the first beta release of 4.3.0 so it includes a lot of changes and certainly the chance of issues is much higher than with other beta releases so please be careful and be ready to re-take control in Manual or Hold.

We are very much looking forward to any and all feedback on this new major release and we will be answering and investigating all reports.

Thanks to all the developers who contributed to this release!


Great amount of work! Thanks a lot to all developers.

I flashed this version on a Balance Bot, maintaining parameters from v4.2.3. As had happened with other 4.3dev previous version, initially it started oscillating heavily back and forth, even disarming by itself (CRASH_ANGLE=45). So I changed ATC_BAL_D 0.1->0.5, and oscillations stopped; it kept vibrating back and forth a bit, and was manageable but noisy exactly as in here.

I started the same indoor mission (no GPS, with wheel encoders) I had installed on it (back and forth on a straight line), and the straight line was followed much better:

I observe that the irq handler for encoder signals includes the division µs->ms:
irq_state.last_reading_ms = timestamp * 1e-3f;
so this seems to me executed at both edges for both signals edges for both encoders. Reading in µs and moving the conversion to the backend would save divisions, with a faster irq handler.

In adition in that irq handle the call to AP_WheelEncoder_Quadrature::pin_ab_to_phase() can be supressed with:
phase_after = (pin_a?(pin_b?2:3):(pin_b?1:0));
saving one call/return, with more clear coding. Better make the irq handler monolithic (no call/returns at all).

I have been using WRC_ENABLE=0. If changing that can stop vibrations, please illuminate me.

1 Like

Big thanks to the workers for the update to fix these features!
I downloaded the 4.3 beta firmware and found some issues.

  1. In the Basic Tuning interface, there are several parameters that cannot be modified directly, but can only be modified in all parameter tables, which makes the test inconvenient and it is uncertain whether the parameters are written to the controller.
  2. In the flight data interface, the mode in the mode selection is not the car mode, but the drone mode, which greatly affects the mode control of the ground station.
  3. In this update I didn’t find any instructions for turning on the panning function and the device pivoting when turning or turning in place.

1 Like


Thanks very much for the report. I’ve added the WheelEncoder noise to the 4.3 issues list and I plan to look for a fix in the coming week or two.


Thanks for the report. These are really both ground station issues but in any case, yes we need to update Mission Planner’s Basic Tuning screen to match the new S-Curve navigation parameters. I’ve added this to our 4.3 issues list.

By the way, those parameters do not exist any more and instead we have different parameters for tuning the position controller. I plan to update the wiki to provide advice on this.

Re the flight mode display, I tried to reproduce this but on my Mission Planner it seems to be working OK. I wonder if you could try again and make sure that you’ve got an internet connection. I suspect the problem is temporary but if it keeps happening we can raise an issue with Mission Planner developers.

1 Like

First of all thanks for your reply.
I have switched computers and tested many times, and this problem has always existed. Hopefully it will be resolved by updating the ground station. Please let us know the wiki link for the S-curve and other parameter descriptions for subsequent updates.
thank you very much!

1 Like

Thanks for the update, you listed support for the Mamba F405 Mk4 does that include the mini 20x20 version?

1 Like


I’m not sure but maybe @andyp1per knows because it appears he added support for this board.

EDIT: ah, looks like you’ve already discussed with AndyP over on the Copter release discussion.

Yes he responded there, thanks. Still not sure whats the difference between version A & B he speaks of tho.

Here are two mission tests, indoors, without GPS, using Pixhawk1’s compass, with two balance bots:

and three balance bots:

all with ArduRover v4.3beta 20220913.

Tuning parameters was essentially:

  • Starting with v4.2.3 parameters, all balance bots start oscillating heavily back and forth, even disarming by itself (CRASH_ANGLE=45). These oscillations are stopped increasing ATC_BAL_D to around 0.5, but this causes a lot of vibrations and noise (motor gearing teeth are heard knocking exactly as in here (ArduRover v4.3dev firmware dated june 16)).
  • Teeth knocking can be greatly reduced increasing ATC_BAL_P and ATC_BAL_I and reducing ATC_BAL_D, and enabling WRC_ENABLE with a slow rate PID for both wheels, such as:
    with a lot of “Parameter outside range” messages.

Is there an easier way?

In adition, at times there are communication failures such as this:
at t=305 on the second video (three balance bots), which has happened always (they last a few seconds) and I wonder if it has to do with the wheel encoders code, so I think that optimising the duration of its irq handler as described above can be tried.

1 Like