Servers by jDrones

Rover-4.0.0 released!

Rover-4.0.0 has been released as the default/official version and is available through the ground stations including Mission Planner and QGC or via direct download from This version is exactly like -rc4. The list of major changes vs 3.5.2 are in the release notes and also copied below:

Changes vs 3.5.2:

  1. Path Planning for Object Avoidance (aka Bendy Ruler and Dijkstra’s) replaces “Dodge” avoidance
  2. Complex Fence support (aka stay-out zones)
  3. Flight mode changes:
    a) LOIT_SPEED_GAIN provides tuning of loiter mode aggressiveness
    b) NAV_DELAY command support for clock-based start of mission commands
    c) Simple mode (was present in 3.5.2 but was undocumented and untested)
    d) SPEED_MIN parameter allows setting minimum speed during missions (reducing slow down at
    e) Follow mode offsets reset to zero when vehicle leaves follow mode
    f) Boats loiter instead of circling at end of RTL/SmartRTL
    g) Warning sent to GCS when SmartRTL buffer is nearly full
    h) Vehicle stays in Auto mode after completing missions using RTL-within-Auto, Hold-within-Auto
  4. Sailboat improvements:
    a) motor support
    b) tacking improvements
    c) NMEA windvanes
    d) Sailboat gets dedicated parameters SAIL_LOIT_RADIUS and SAIL_XTRACK_MAX
  5. New flight controllers:
    a) Hex Cube Orange
    b) Holybro Durandal
    c) Sparky2 autopilot firmware available
  6. Sensor and peripheral related changes
    a) Fuel flow battery battery types
    b) IBUS R/C input support
    c) “Inflight” compass calibration
    d) NTF_BUZZ_VOLUME allows controlling buzzer volume
    e) OSD support
    f) UAVCAN improvements including dynamic node allocation
    g) WS2812 LEDs
    h) Yaw from some GPSs
    i) IMU heater control parameters (see BRD_IMUHEAT_P/I params)
    j) RangeFinder type parameter clarified for Benewake lidar
    k) UAVCAN RTK GPS support
    l) UBlox F9 GPS automatic configuration
    m) Lightware SF40c lidar driver for latest version
  7. Safety Improvements:
    a) Improved watchdog logging allows distinguishing between brown-outs from software failures
    b) FS_OPTIONS parameter allows enabling failsafes to trigger while in Hold mode
  8. Bug fixes:
    a) Wheel encoder fix to use both wheel encoders (if present)
    b) EKF failsafe and pre-arm checks fixed when only wheel encoders used for non-GPS navigation
    c) Pre-arm message fix to reports AHRS/EKF issue (was blank)
    d) BLHeli fix to RPM calcs and telemetry (aka 0x8000 error)
    e) SET_YAW_SPEED in Guided mode made consistent with Auto mission command handling (yaw in degrees, speed in m/s)
    f) Barometer PROBE_EXT parameter description improvement
    g) Pixhawk4 board LED brightness fix

Thanks very much to all the developers, beta testers, documenters and others who contributed to this release!


Nice! Did not have time to test rc4 so moving to stable.

Did anything change regarding dshot?

@OldRaven, nothing fixed regarding DShot on the Matek boards but it’s still on the to-do list to resolve. It affects Copter as well if that’s any condolence so we will sort it out eventually.

@rmackay9 for a skid steer rover, what are the advantages of enabling wheel encoders in ardurover? Mine is a a 150kg rover with 2 wheelchair motors. Right now I’m using a compass and an RTK GPS to navigate, and it’s working quite well, especially on long straight segments where I’m getting 6-10cm tracking variability between runs using a RTK correction source that’s 21km away. I am in the process of adding a 2nd GPS to replace the onboard compass.

Based on your knowledge of how the encoder data is used in the autopilot software, would you expect that wheel encoders would improve the accuracy of the vehicle’s navigation? In what ways or in what sort of scenarios or maneuvers?

For me the maneuver with the most room for improvement is pivot-in-place. When pivoting on a lawn, especially on a particularly uneven surface, the rover can sometimes be 10 or 20 degrees off after a pivot, which causes a slight tracking error when it departs that waypoint for the next waypoint. Another maneuver with room for improvement is short segments (on the order of 1 meter). On short segments sometimes the rover overshoots or undershoots the end of the segment by 10-20 cm.

Relatedly, I’m using the roboclaw motor controller (controlled by PWM outputs from my Pixhawk), and it has the capability to use encoders itself (although roboclaw supports both velocity and position modes; I would just use the velocity mode). What are your thoughts on using the roboclaw encoders vs the ardurover encoder?

Thanks in advance! If any of this is written down anywhere then please feel free to point me to it…


I don’t think the wheel encoders will help with the two issues you’re seeing (pivot-in-place and short segments) because I think these are control issues rather than estimation issues. I think the vehicle probably knows it’s heading but the issue is that there is a difference between the heading to the next waypoint (which is the direction it turns to during a pivot turn) and the target heading back to the line between the origin and destination.

@lthall is planning to resume work on the “S-curves” for Copter and Rover in the coming months and I hope this will resolve some of these problems.

As a refernce, I’ve uploaded a diagram I often use at the drone school to show developers (or pro users) the major components of the system. It’s not super helpful but often new developers (or users) focus on the incorrect part of the system when trying to resolve a problem.


Thanks @rmackay9. I observed the problem you describe (difference between the heading to the next waypoint and the target heading back to the line between the origin and destination) much more when the GPS antenna wasn’t located exactly between the 2 powered wheels (which is the center of rotation when pivoting). When the antenna was 15cm in front of the center of rotation, pivoting would move the GPS antenna along an arc (rather than rotating about a point). This resulted in the GPS antenna being located to one side of the line between the origin and destination at the end of a pivot (as long as it wasn’t exactly a 180deg. pivot). Moving the GPS antenna exactly between the 2 wheels helped this a lot. Next time I’m up and running I’ll send a logfile. But I’m deprioritizing the encoders for now…

1 Like

You can enter offset values for the GPS antenna position.


I’ve disabled all compasses on my little wheel chair rover. Using GPS position and the wheel encoders I get very good heading estimation (with bad compass health warnings, though). The tradeoff is that the rover heads in a random direction for 2 to 3 feet while it determines its heading, corrects its orientation, and then runs like a charm. This was on an asphalt surface though, with more wheel slippage on grass your mileage may vary.

I think it would be cool if there was a way to have Ardupilot read the compass values for an initial guess for heading, but then rely on GPS position and wheel encoder measurements for heading thereafter. I find the compass reliability and consistency is not very robust, at least the way I’ve got my rover set up.

I second your desire for more pivot in place functionality. Any new developments on your mowing rig?

1 Like

What’s this “drone school”? How much is the tuition? :grinning:


The drone schools is listed here on our training centers wiki page and I train students on how to modify the ArduPilot software to do what they want. New flight modes, new features, etc. I think tuition is about $1000 for 4x 3h classes. The school is based in Tokyo so difficult for many to attend but much of what I teach ends up on the developer wiki.

Drew, a bunch of changes in progress but none complete, will let you know…

Servers by jDrones