Rover-3.4.0-rc1 released for beta testing!

Rover-3.4.0-rc1 should soon appear in the Mission Planner (and perhaps other GCSs) and any beta testing that people can do would be greatly appreciated!

This new beta release’s are in the Release Notes and also copied below:

  1. Loiter mode for boats
  2. Omni rover support (three wheeled rover with lateral movement)
  3. vision-position-estimate support for use with ROS
  4. Control improvements:
    a) reversing control improvements
    b) ATC_DECEL_MAX allows deceleration to be faster or slower than acceleration
    c) PIVOT_TURN_RATE allows slower pivot turns
    d) turn-rate I-term reset when switching in from manual modes
  5. NMEA Echosounder support for underwater depth monitoring
  6. Bug fixes:
    a) fix forward/back acceleration limiting
    b) MaxsonarI2C driver fix

For those who are wondering, “what happened to Rover-3.3.1?”, a bug was found in the acceleration limiting but because so many other improvements have gone into master since 3.3 was release a month ago, I thought it made more sense to jump forward to Rover-3.4.


thank You!
How can I change the flight mode to Loiter?

A real improvement over previous releases. The wet dog shake is gone. I am getting waypoint overshoots by at least 1 meter. One bug I found; if your last direction to a waypoint was in reverse, you’ll be in reverse when you restart the mission. Simple workaround: 1) reboot or 2) do set reverse forward at the beginning of your mission.



1 Like

I’ll load this tomorrow and give it a shake down on Monday.

1 Like

This release fixed several issues and the acceleration and deceleration limits are working perfectly. It has allowed me to tune the system much differently than before as I didn’t have to compromise my tuning options. There is also no I-Term leftover on mode switching as well with makes the rover much safer. One other thing that is fixed but not sure why is the twitchy-ness in acro… before the throttle servo speed vs steering servo speed were massively different… now they are well balanced with each other… like the steering inputs are following the throttle slew rate limits. l believe I am still getting waypoint overshoot as well, more testing is needed to know for sure. Great work @rmackay9, Ammarf and any others who worked on this release. Great work!



To switch into Loiter you’ll probably need to set one of the MODEx parameters to “5”. Once Rover-3.4 becomes the official release then the mode will appear in the flight mode setup screen in Mission Planner (and other GCSs). I’ve added a note to the Loiter mode wiki page as well.


Great, thanks for the testing and report! I’ve created an issue here to track the reversed bug. I think it will be an easy fix.

1 Like

Hi Kevin,

Thanks very much for testing! This really helps.

Re acro improvements, I’m guessing but it could be the reversing control improvements. If ATC_BRAKE was set to 1 and the speed controller momentarily set the throttle output to reverse (in order to slow down the vehicle) the skid-steering vehicles could suddenly turn the wrong way.

Great work!

Slight bug in the changes to AR_AttitudeControl at line 509:

// acceleration limit desired speed
float speed_change_max;
if (fabsf(desired_speed) < fabsf(_desired_speed) && is_positive(_throttle_decel_max)) {
speed_change_max = _throttle_decel_max * dt;
} else {
speed_change_max = _throttle_accel_max * dt;
` return constrain_float(desired_speed, speed_prev - speed_change_max, speed_prev + speed_change_max);`

You check if _throttle_decel_max is positive before applying it, but not _throttle_accel_max. If _throttle_accel_max is set to 0, then the vehicle never accelerates, whereas the parameter notes say that 0 should give unlimited acceleration.

Also, if throttle_decel_max is zero, then you become limited by your ACCELERATION max.

This would be my suggestion (noting I don’t understand the role of the abs on the speeds):

if (is_positive(_throttle_decel_max)) {
    _dec_change_max = _throttle_decel_max * dt;
    _dec_change_max = 1000; // Or something similarly huge
if (is_positive(_throttle_accel_max)) {
   _acc_change_max = _throttle_accel_max * dt;
    _acc_change_max = 1000; // Or something similarly huge
return constrain_float(desired_speed, speed_prev - _dec_change_max, speed_prev + _acc_change_max);

It’s not quite as streamlined, but it covers acceleration and deceleration and behaves as documented for the zero case for each.

1 Like

Also, did you say you’d fixed the sudden deceleration at each waypoint? If you set up a very high deceleration rate and a low acceleration rate you can still see the vehicle slow down dramatically every time it passes a waypoint.

With more sensible values, it hides the deceleration (e.g. decel of 10).

Hi @mroberts,

Yes, we’ve mostly fixed the sudden deceleration after passing waypoints. There are still two situations where it accelerates or decelerates too quickly:

  • if the vehicle is put into Auto mode while disarmed and then armed, the desired speed will immediately jump to the CRUISE_SPEED/WP_SPEED. The work around for this issue is to arm in another mode and then switch to Auto.
  • at the end of a mission (when vehicle reaches the WP_RADIUS around the final waypoint), the vehicle switches into Hold mode and the throttle output is immediately set to zero. The vehicle will likely have slowed before reaching the waypoint but the vehicle will still likely come to a slightly sudden stop.

Both these issues are captured in this issue so I’m pretty sure we will fix them in a follow-up release. These issues are not new though.

Ah, thanks for the note on finding the code issue re the accel/decel. I’ll have a look at it or perhaps @Ammarf will.

I’m comparing sim performance between 3.3 and 3.4. I find that 3.4 makes MUCH wider turns than 3.3. Running both at 1.0m/s gives the same performance, but where 3.3 followed the same path at increasing speed until you hit turn_max_g, 3.4 seems to increase the turn radius as you increase speed.

Is it possible to upload logs here?

I’ve increased the turn radius in SIM_Rover.cpp to 5m (otherwise it’s very hard to replicate due to minimum speeds). This is for a conventional steering rover - have the other people in the thread been running skid steer?

The biggest change in the code I can see is the removal of the 1/speed scale factor in AR_attitudeControl, but that seems like removing that should INCREASE the steering input, and make it turn tighter (comparatively) as speed increases - you’re no longer dividing the error by 5 for example.

1 Like

A little video of Position Holding with 3.4rc1. It also ran a survey grid flawless.

Impressive performance!


Great video. I think it’s quite clear when the vehicle is switches into Loiter that it initially drifts and then it behaves like it’s front is caught on a string (which is how it should act). Thanks!

Boat loiter looks like it’s working very well indeed. Can’t wait to test myself!

Is there anywhere I can find out about the Omni Rover support?

Thanks to everyone working on this project, it’s amazing stuff!


Re the omnirover, I think we will add a page to the Reference Frames section of the wiki and also add a section to the Motor and Servo wiki page but I’m afraid for now all I have is a picture. There’s only one motor configuration supported at the moment which is three wheels positions at 120degree increments around the frame. the SERVOx_FUNCTION values for the three outputs should be set to motor1 (33), motor2 (34) and motor3 (35) respectively.

That’s no problem, thanks for getting back to me. These are very exciting developments!

Greetings. Very good development of beta tests v3.4.0 rc1. An incredible video clip. I have a question: I want to use the Loiter mode for an inflatable fishing boat with a 3,3 m long. I’m using a 30 lbs DC submersible motor. I’ve also set up a preset model. There is no good test of orientation of the model to a given point on a mission. The servo 1 is 360 deg and has a gear with i = 2,5. Is this configuration of mechanics appropriate? Do I have to set additional parameters?

@rmackay9, I’ve been digging into the changes to AR_AttitudeControl and AP_MotorsUGV and I’ve found something that makes me go “hmmm”.

3.3: AR_AttitudeControl applies a 1/speed scaling factor in calculation of the steering output through the PID, then constrains the result to +/-1.0 before returning it. That steering is then sent out unchanged in AP_MotorsUGV.cpp

AR_AttitudeControl.cpp line 253 from this change:

3.4: You remove the 1/speed scale factor in AR_AttitudeControl (so the calculated values will be a lot larger), but you still constrain it to +/1 before returning it.

The output (now constrained to +/1) then gets divided by the speed in the updated AP_MotorsUGV - line 410 here:

This (I think) explains some of the funky behaviour I’ve been seeing where servo output is clipped at high speeds in Acro mode. If my servo range is 1000-1500-2000, the most steering I can get at 10m/s is 1450 or 1550. Set up 3.4 with a high turn_max_g (like 7), a high FF (2), and speed_turn_gain of 100%, then run your kart track at 10m/s. It will go nuts, but if you watch the ch1out, once it’s at speed it will never go outside of 1450-1550.

The same thing in 3.3 will show a greater range of steering output.

I think the fix is removing the “constrain” at the end of get_steering_out_rate, and from “set_steering” in AP_MotorsUGV to leave the clipping to the final output.

The alternative would be to do the speed correction / scaling in mode.cpp (calc_steering_from_lateral_acceleration) since that’s where you have a direct link between the steering and the velocity, just before it gets sent to g2.motors.set_steering(). There’s almost no need for the motor to manage that side of things. (IMHO).

It wont show up at low speeds if your required steering is less than 1/speed % - i.e. if you need less than 20% steering at 5m/s it wont clip.

1 Like