Rover-3.5.0 released!

After months of beta testing Rover-3.5.0 has been released as the official/stable version and will be available for download through ground stations including the Mission Planner and QGC within the next few hours.

The changes are listed in the ReleaseNotes and also copied below.

Changes from 3.4.2

  1. ChibiOS provides improved performance and support for many new boards including:
    a) F4BY
    b) TauLabs Sparky2
    c) Furious FPV F-35 lightening and Wing FC-10
    d) Holybro KakuteF4
    e) Mateksys F405-Wing
    f) Omnibus F4 Pro, NanoV6 and F7
    g) SpeedyBee F4
  2. BalanceBot support
  3. Sailboat support
  4. OmniPlus, OmniX frame support (vehicles can move laterally using 4 thrusters or wheels)
  5. Mode changes:
    a) Follow mode (allows following another vehicle if connected via telemetry)
    b) Simple mode (pilot controls direction regardless of vehicle’s heading)
    c) Loiter can be configured to always drive towards target (i.e. does not reverse) (see LOIT_TYPE parameter)
    d) Guided, RTL, SmartRTL will reverse towards target if DO_SET_REVERSE command received (via telemetry or as mission command)
    e) Boats hold position after reaching target in Auto and Guided (also see MIS_DONE_BEHAVE)
    f) SmartRTL default num points increased to 300
  6. Auxiliary Switches expanded to many channels (see RCx_OPTION parameters)
  7. External position estimates accepted from ROS and Vicon systems
  8. MAVLink message interval support (allows precise control of mavlink message update rates)
  9. Safety Features:
    a) RC and GCS failsafe timeout shortened
    b) EKF failsafe added and checked before entering autonomous modes
    c) Object avoidance enabled in autonomous modes (Auto, Guided, RTL)
    d) Safety switch ability to arm/disarm vehicle now configurable (see BRD_SAFETYOPTION parameter)
  10. Bug fixes and small enhancements:
    a) Object avoidance fix to include all sectors from proximity sensor (aka 360 lidar)
    b) Onboard OSD support (for ChibiOS-only boards)
    c) Gripper support
    d) Sprayer support
    e) Wheel encoder offset fix
    f) Avoid potential divide-by-zero when waypoints are almost in a straight line
    g) Cruise speed/throttle learning always runs for 2 seconds (saves user from having to lower switch)

There is still at least one known issue (DShot support) that we will resolve in a follow up “point” release. Some wiki updates are also required which we should get to in the coming weeks.

If you have any issues with this release please post below or create a new topic in this Rover-3.5 category

Thanks to those in this forum that helped out with beta testing, it was very much appreciated!


By the way, if anyone has a video of their rover or boat I’m looking for a better video to put at the top of the announcement blog post. No pressure of course!

I will give it a test Randy, thank you.

Do you think this will resolve my boat wobble problem?

I might have one for you in 12 hours or so.

I did not get anything worth editing worthy of this community. Sorry.


This release doesn’t include any changes that will help with the wobbles I’m afraid. That will come with Rover-3.6. Until then though i have an idea which I’ll post in the other topic.

So should I do the update or stick to the old version?

Hi John and Randy

Would a mode or feature like Boat mode for Copter be relevant for Rover? Maybe helping with problems of powering and arming boats on water. I get gyro warnings a bit when arming on water. I like doing it as it sets home in a good spot for retrieval.


The parameter for setting up boat mode. Shows up on rovers full parameter list in docs. You could try setting it. Se if it works.

Hi @John_Easton,

it’s up to you whether to upgrade or not. i think it will do no harm and should be an easy upgrade (please tell me if it’s not).


Copter’s “boat mode” is available in Rover as well. It’s not really a “mode” (like Loiter or Acro), it’s more about how to ensure the gyro calibration completes. Maybe we need to do more to make it work reliably? It’s a good point and you’re the first person to bring it up I think.

1 Like

Randy and hdtechk

I will give “boat mode” a try on the weekend, I wasn’t aware of it in rover. The thought came to me after reading some of John’s thread with his trimaran.


More important though is home is set when you arm unless you set up always armed


I think I’ve found a BUG in Omni3.

Moving lateral has a wrong motor mix.

Motors one and three can not be in the same direction moving lateral or while rotating.
motor one and three can only move the same direction while moving forward or backward..

Right now they move the same way while commanding “roll” witch assume is lateral movement…
And if i where to reverse one then commanding forward would result in a turn, so revers is not an solution i thin. I think the motor mix is wrong.

Hi @Nando,

Txs for the report. It’s certainly possible - it’s a new-ish frame type and I haven’t personally tested it.

There are a few common ways that users hit problems though that are not caused by the motor mixing so I wonder if you can test a few things:

  • could you run the motors test and make sure each motor is spinning so that it provides thrust so the vehicle would move in the direction of the green arrows?
  • on the RC calibration page, can you make sure the green bars (assuming you’re using the mission planner) move in the same direction as the physical sticks with the exception of the Pitch (for pitch the green bar moves in the opposite direction to the physical sticks).

@Ammarf, maybe you could comment on the motor mix?

EDIT: the code for setting up the omni3 motor mix is here. It looks to me like the lateral factor for the front-right motor (motor 1) is -1 while for the front-left motor (motor 3) is +1.0.


lateral is actually assigned to the yaw channel, since the steering is already assigned to the roll channel in Ardurover.

Motors 1 and 3 has to move in the same direction to facilitate moving forward/backward, motor 2 doesn’t do anything when you apply throttle.
When you apply steering, all the motors will move in the same direction (rotate CW or CCW).
Moving laterally will requires 1 and 2 to move in the same direction if you’re applying positive lateral input, and 2 and 3 to move in the same (other) direction when negative lateral input is applied. This seems to be already the case in the current motor mix, unless I misunderstood your point?

1 Like

I’m shure the rc-mapping is correct.
And if it’s not this problem would still be there, both in lateral and in turning M1 and M3 have to be opposite, now they are the same in one of the two. The wrong channel would only make it wrong for the ‘other’ one.
The same goes for the spinning motors, I think i was wrong in saying lateral movemewnt is incorrect, apparently it’s yaw.

Thank you for clearing that up, I wasn’t sure, I have set up many multirotors so i expected that to be the same. No problem here tho.

(green arrow = normal positive output, blue is the disired output.

That’s exactly where it goes wrong, they should not be the same direction for turning (nor for lateral movement).

Current situation:

    _motors_num = 3;
    add_omni_motor(0, 1.0f, 1.0f, -1.0f);
    add_omni_motor(1, 0.0f, 1.0f, 1.0f);   #this has to be motor 3 in the picture, it is the only one with 0,0
    add_omni_motor(2, 1.0f, 1.0f, 1.0f);

What would work imo:

        _motors_num = 3;
        add_omni_motor(0, 1.0f, 1.0f, -1.0f);
        add_omni_motor(1, 0.0f, 1.0f, 1.0f);   #this has to be motor 3 in the picture, it is the only one with 0,0
        add_omni_motor(2, 1.0f, -1.0f, 1.0f); #added a “-“ 


        _motors_num = 3;
        add_omni_motor(0, 1.0f, -1.0f, 1.0f);
        add_omni_motor(1, 0.0f, 1.0f, 1.0f);   #this has to be motor 3 in the picture, it is the only one with 0,0
        add_omni_motor(2, 1.0f, 1.0f, -1.0f);  

Because i’m not shure if motor0 = m1 or m3
I’m pretty shure the first collum is forward, then rotating, then lateral.

1 Like

Just compiled the firmware, twice , because the second one was correct for me, but NOT for the picture in the wiki. (i have a omni3 boat with bow thruster in front)

(The motor opposite to the forward direction can not have the same direction for turning and sideways movement, if the picture is correct.)

To get it correct, to match functionality to the picture in the wiki:

        _motors_num = 3;
        add_omni_motor(0, 1.0f, -1.0f, 1.0f);
        add_omni_motor(1, 0.0f, 1.0f, -1.0f);   
        add_omni_motor(2, 1.0f, 1.0f, -1.0f);  

Is there any reason I can’t see Ardurover 3.5 in Mission Planner yet? I’ve tried reinstalling MP and still no luck.

Thanks and apologies if this is an obvious one!