Rover-4.4.0-beta11 available for beta testing -- perhaps the last beta before a stable release

Rover-4.4.0-beta11 has been released for beta testing and should be available for install using MP or QGC’s “beta firmwares” links within a few hours. Alternatively it can be manually downloaded from (once the build completes in a few hours).

Changes vs -beta10 are in the release-notes and copied below:

  1. Autopilot related enhancement and fixes
    • CubeOrange Sim-on-hardware compilation fix
    • RADIX2HD supports external I2C compasses
    • SpeedyBeeF405v4 support
  2. Bug fixes
    • DroneCAN battery monitor with cell monitor SoC reporting fix
    • NTF_LED_TYPES parameter description fixed (was missing IS31FL3195)
    • ProfiLED output fixed in both Notify and Scripting
    • Scripting bug that could cause crash if parameters were added in flight
    • STAT_BOOTCNT param fix (was not updating in some cases)
    • don’t query hobbywing DroneCAN ESC IDs while armed
  3. Rover specific changes
    • Auto mode keeps navigating while paused at waypoints (reduces overshoot)
    • QuikTune script simplification (only tunes rate and speed controllers)
    • Torqeedo battery nearly empty reporting fix

As you can see the last few changes are specific to Rover and I hope that the auto mode change plus the quiktune will allow us to release this version as Rover-4.4.0 stable within a couple of weeks. So now more than ever, any testing feedback is really appreciated!


Charging the transmitter for testing later today. My plan is to revert PSC values to default, accomplish QuikTune, and then test navigation. Please let me know if there are other specific testing needs, and I will try and make it happen.

1 Like

Hi @Yuri_Rage,

Sounds great, thanks for the help in testing.

EDIT: Beta11 is now available on the firmware server. Will try and test tomorrow!


Tested today. Comments in the QuikTune topic:

Rover QuikTune simplified – testers wanted - ArduRover / Rover 4.4 - ArduPilot Discourse

To briefly summarize: I think it’s worth exploring steering rate I-term buildup before a stable release, but otherwise, pretty impressive improvements over previous!!!

1 Like

Rover, Boat, Omni3… CubeOrange+ Herelink , with v4.4.0 beta 11
I have stripped down the assembly and re written the firmware with the v4.4.0 beta 11.
I cannot get the transmitter stick signals to appear in the servo output page, or to move the output signals, to channels 1-4.
I do get some sort of partial responses from the individual motor test screen. If I change eg #2 channel in the Servo Output page, from Motor1 to RC1 passthru, then the channels does output as expected. So it seems that the issue is within Ardurover, and not necessarily with the Herelink?
See the screen shots and parameter list.
orange14122023.param (15.9 KB)

Can you advise where I have erred?

Hi @Colechr,

It’s difficult to know what’s going on with only the parameter file. Any chance you could provide an onboard log?

The only thing that I see that looks suspicious is the SERVO4_FUNCTION is set to Motor2 (34) but it’s an Omni3 so it shouldn’t matter.

I guess you’ve tried the motor test?

I have not got as far as installing in a vehicle yet, still carrying out a bench test. So no actual movements.
I have found a tlog, attached, but I guess this is not quite what you are after? I will try to get a log from the Orange sd card.
I did try the motor tests, and all that I could get to work was setting a value of about 50%, then clicking each motor test individually, and that would send the 50% to that servo output. A test of each motor in turn, would just move the 1st, but no other, and stopping motors did nothing. Changing the value to say-80% and then doing individual tests would then send the right output to each servo channel.

2023-12-14 10-04-57.tlog (190.7 KB)

regards CC

I extracted some of what looks to be repeated and so the extract is shorter.
extract2023-12-14 09-58-41.log (66.8 KB)

This is the bin file from the 14th, when the system was stable, but had the issue that there was no servo output response to stick actions, even when the system was armed, and in manual.

Since then as further checks to eliminate sources of the problem:-
I did replace the Herelink TX/RX, with a TX16S/X8R, which was working with a PIX32 v6c. There was no improvement on the servo output problem. The same issue.

I went back to the Herelink, and then backdated the firmware to the Rover V4.2.3 and by toggling the safety, and forcing the arming, immediately on going to the servo output page in Mission Planner, I could drive the Servo output changes, in response to the stick movements, in manual. A good result. But I would like to go back to trying the V4.4.0.

The reason for having ch4 as motor2, is that the boat will have a bow thrust and rudders, and as rudder is not available, and selecting ground steering cause the Pre-Arm error “Check steering and throttle config.” So the suggestion was that selecting motor2 for the rudder, would be workable. (It should be noted that a rudder doesn’t work at low speeds, but is very effective as speeds rise, while a bow thruster, is the opposite, as it works well at low speeds, but not as water speeds increase, as the water rushes past the inlet nozzles. I guess that as one fades, the other will take over for yaw control, but not work for sideways motion.)

Might consider moving this basic configuration discussion to its own topic. Doesn’t seem relevant or specific to a firmware release.

Hi Yuri
I apologise for my error in wrongly posting. I am happy for the posts to be moved/removed. As V4.4.0 is now official, there may not be any need for testers.
That said I have loaded V4.4.0 Rover official cubeOrange+ to my system. The problem of not getting any output on the servo settings page in Mission Planner remain.
Interestingly backdating the same system to V4.2.3 (Rover) did work. Same configuration steps for both. Either I have missed a specific setup step for V4.4.0 or the earlier beta 10 & 11, or Boat, Omni3 is no longer supported in Versions after V4.2.3? There have been no advises, to what I haven’t done, or done wrong, but surely there is a user who has successfully setup cubeOrange+ for rover/boat with omni3? Would the parameter file be available?
Best regards CC


Hi @Colechr,

The Omni3 frame is still supported so it should work. I’ve added this to the 4.4 issues list so it won’t be forgotten.

No apology necessary, just seems like this deserves its own title and heading.

Anyway, I haven’t yet taken time to review the logs, but I’m wondering if there’s just some fundamental error at play? Like misconfiguring the safety switch or not arming prior to motion control attempts?

There was a change to the safety switch parameter between 4.2 and 4.4.

The Omni frame types don’t seem to be particularly popular, so I’m not terribly surprised at a lack of response from others. But I’m also unaware of any breaking changes in the frame options.

After a brief log review, unless I’m missing something, I see no attempt at arming, so it seems logical that there would be no motor output.

Many thanks.
If there is more information I can supply, I will have a go. I may not have tried the arming in the bin file sent, as I could see that there was no display of servo output, even at or below 1000micro seconds. As its a boat with reverse thrust would the at rest value not be 1500? Or is the output completely blocked till armed? CC

I attach the latest bin and parameters.
I have done a recalibration of the accelerometers, but get EKF variance/AHRS unhealthy. I think I have disabled the Fail-safes, “do nothing.”

orange2312023.param (15.9 KB)

Motor output is disabled until armed. This isn’t a new feature.

Mission Planner’s motor test ought to be your first step, as Randy mentioned before.

Yes, motor tests have been carried out, as detailed above, and repeated when firmware updated to v4.4.0 official.

Is the boat in the water at power-up? It appears to be pitching and rolling as if it’s in the water.

While I’m not thoroughly versed in the boat frame options, I think there is still an expectation of being motionless at boot-up. If you can’t boot on dry land, maybe setting INS_GYR_CAL=0 could avoid those AHRS alignment issues.