Rover-4.5.6 has been released!

ArduRover Rover 4.5
1

Rover-4.5.6 has been released as the stable/official build for cars and boats. It should appear in the ground stations within a couple of hours of this posting. Alternatively you may directly download the binary (aka “.apj” file) from firmware.ardupilot.org.

Changes vs 4.5.5 are in the release notes and also copied below

  1. Board specific enhancements and bug fixes
  • 3DR Control Zero H7 Rev G support
  • CUAV-7-Nano support
  • FoxeerF405v2 servo outputs increased from 9 to 11
  • Holybro Pixhawk6C hi-power peripheral overcurrent reporting fixed
  • iFlight 2RAW H7 support
  • MFT-SEMA100 support
  • TMotorH743 support BMI270 baro
  • ZeroOneX6 support
  1. Minor enhancements and bug fixes
  • Cameras using MAVLink report vendor and model name correctly
  • DroneCAN fix to remove occasional NodeID registration error
  • GPS NMEA and GSoF driver ground course corrected (now always 0 ~ 360 deg)
  • ICP101XX barometer slowed to avoid I2C communication errors
  • IMU temp cal param (INSn_ACCSCAL_Z) stored correctly when bootloader is flashed
  • IMU gyro/accel duplicate id registration fixed to avoid possible pre-arm failure
  • Logging to flash timestamp fix
  • OSD displays ESC temp instead of motor temp
  • PID controller error calculation bug fix (was using target from prev iteration)
  • Relay on MAIN pins fixed

Thanks as always to the developers and beta testers who contributed to this release!

P.S. we hope to begin beta testing of 4.6.0-beta1 in 2 to 3 weeks

2 Likes
3

I’ve been using what amounts to 4.5.6 for some time. The following nav behavior is consistent for the 4.5 branch overall:

image
image1057×518 135 KB

I find it difficult to keep S-Curve turns from overshooting (rather than cutting the corner, as expected) despite spending significant time tweaking decel, G, and radius parameters. Above shows those S-Curve overshoots when using very small radius turns at low speed/G in an otherwise well tuned SITL model.

Likewise, pivot turns consistently still overshoot by a small margin, requiring a course correction after making the turn. I can minimize this with careful use of decel and GPS_POS* params, but it seems I almost always get a small overshoot.

I also find that turn behavior is quite sensitive to GPS_POS* parameters in relation to the Z (pivot) axis of the vehicle. This isn’t necessarily an issue, but it is not well addressed in our docs.

All negative behavior is significantly magnified any time the steering and/or speed controllers are not tuned near perfectly, which is a tall order even for experienced users, much less those less accomplished at manually tuning their vehicles.

1 Like