Rover-4.3.0-beta9 available for beta testing

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

Changes vs -beta8 are in the release-notes and copied below.

  1. AutoPilot specific enhancements
    a) CubeOrangePlusBG support
    b) Foxeer ReaperF745 supports external compass
    c) MambaH743v4 supports VTX power
  2. Bug fixes
    a) Arming check fix if BARO_FIELD_ELEV set
    b) Compass calibration diagonals set to 1,1,1 if incorrectly set to 0,0,0
    c) Gimbal’s yaw feed-forward set to zero when landed (affects Gremsy gimbals)
    d) IOMCU double reset and safety disable fix
    e) Logging fix for duplicate format messages
    f) OpenDroneId sets emergency status on crash or chute deploy
    g) Peripheral firmware updates using MAVCAN fixed
    h) RC protocol cannot be changed once detected on boards with IOMCU

This release is really mostly to keep it in line with the equivalent Plane and Copter releases.

Any feedback is greatly appreciated!

P.S. I haven’t forgotten about the Rover position control tuning issues… it’s just the work on cameras and gimbals is taking some time.


While Rover last betas have been coming, I have assembled a balance bot on a hoverboard with a Pixhawk1 with a 48cm doll as driver. This is a first field test in Acro (see also a rotation):

(No GPS on both: position from wheel encoders and Pixhawk1 internal compass)
Those videos were with previous betas; next problems should be common in last betas, although tested most recently with beta8 (beta9 shortly). On that video BAL_PITCH_MAX=22, but can be higher (wheels are 6.5", but 10" is the way to go):
Most of the time it is leaning forward at -22º:

Pitch all/none in Acro.
In Acro, pitch control was all|none and steering was controllable. In Manual, pitch was controllable but steering was fast. Above videos:

  • Circuit: on Acro.
  • Rotation: on Manual.

For tuning on Acro new explanations on Tuning Pitch Control have helped; I made ATC_BAL_FLTT=0.6 as workaround for Acro.
Related to this are parameters WENC_POS_Z/WENC2_POS_Z, documented as:
Z position of the center of the wheel in body frame. Positive Z is down from the origin.
I suppose that body frame refers to the moving part (excluding the wheels but including the battery), so this parameter should be the position of its COG with respect to the center of the wheels. Left alone the doll falls slowly, so it needs balancing. WENC_POS_Z/WENC2_POS_Z could be measured with some weightings (each wheel 2.5Kp (6")) and calculations, but I assign them as -0.03 (the COG of the moving part excluding wheels and including battery is 3cm above wheels axle (negative: left alone the doll falls)).

  • if the COG of the moving part is above wheels axle (negative) but low the doll will be balanced with an small effort (wheels don’t matter);
  • if the COG of the moving part is above wheels axle (negative) but high the effort to balance the doll will be high (wheels don’t matter).

However, I have never seen the influence of these parameters. Are above supositions correct?

Timeout after arming.
This is a mistery: after arming there is a timeout of a few seconds in which if not moving sticks switching to motors stops (switching sound on motors stops being heard) but does not disarm, so disarm+arm is needed. Moving continuously the balance bot after arming to recover, such as in circles, prevents this.
This log shows it.

  • t=1:17.5 armed from transmitter, but not moved.
  • t=1:27.5 RCOU.C1 and RCOU.C2 stop (ESC’s on Pixhawk1 MAIN1/MAIN2). Switching sound stops being heard, but it continues armed.
  • t=1:39 disarmed manually from MP button (it falls). MP asks if really wanting to disarm

What can be the reason for this timeout?

Arm with switch.
I normally use car 3ch radios for balance bots (steering/throttle/mode), but I recently tried a 4ch one (steering/throttle/mode/arm+disarm), with RC4_OPTION=153 and ch4 on a two positions switch. With 3ch radios I was using RCMAP_YAW=4 (default) which refers to a dummy nonexistent chanel which is now used for arming/disarming, so I had to change to that RCMAP_YAW=6, also a nonexistent channel. Needing to have a parameter related to a dummy nonexisting chanel is confusing.


Here are other videos with more racing setups (beta8):

1 Like