Rover-4.3.0-beta1 released!

[rmackay9]

Rover-4.3.0-beta1 has been released for beta testing and can be installed using MP or QGC’s “beta firmwares” link or it can be directly downloaded from firmware.ardupilot.org.

The changes vs 4.2.3 are in the release-notes and copied below

1. Rover specific enhancements
   a) Aux switch for SaveWP displays, “Mission Cleared” if vehicle not armed
   b) Dock mode using modified precision landing library
   c) Manual mode steering scaling with speed can be disabled using MANUAL_OPTIONS parameter
   d) S-Curves for Auto, Guided, RTL
2. Rover specific bug fixes
   a) Wheel encoder timestamp fix (WRC_xx params may need to be changed)
   b) Auto mode stick mixing fixed (see STICK_MIXING parameter)
   c) Arming check removed to support mixed Ackerman and skid-stering vehicles
3. New autopilot support
   a) AtomRCF405
   b) CubeOrange-SimOnHardWare
   c) DevEBoxH7v2
   d) KakuteH7Mini-Nand
   e) KakuteH7v2
   f) Mamba F405 Mk4
   g) SkystarsH7HD
   h) bi-directional dshot (aka “bdshot”) versions for CubeOrange, CubeYellow, KakuteF7, KakuteH7, MatekF405-Wing, Matek F765, PH4-mini, Pixhawk-1M
4. EKF enhancements and fixes
   a) EK3_GPS_VACC_MAX threshold to control when GPS altitude is used as alt source
   b) EKF ring buffer fix for very slow sensor updates (those that update once every few seconds)
   c) EKF3 source set change captured in Replay logs
5. Gimbal enhancements
   a) Angle limit params renamed and scaled to degrees (e.g. MNT1_ROLL_MIN, MNT1_PITCH_MIN, etc)
   b) BrushlessPWM driver (set MNT1_TYPE = 7) is unstabilized Servo driver
   c) Dual mount support (see MNT1_, MNT2 params)
   d) Gremsy driver added (set MNT1_TYPE = 6)
   e) MAVLink gimbalv2 support including sending GIMBAL_DEVICE_STATUS_UPDATE (replaces MOUNT_STATUS message)
   f) “Mount Lock” auxiliary switch supports follow and lock modes in RC targetting (aka earth-frame and body-frame)
   g) RC channels to control gimbal set using RCx_OPTION = 212 (Roll), 213 (Pitch) or 214 (Yaw)
   h) RC targetting rotation rate in deg/sec (see MNT1_RC_RATE which replaces MNT_JSTICK_SPD)
   i) Yaw can be disabled on 3-axis gimbals (set MNTx_YAW_MIN = MNTx_YAW_MAX)
6. Notch filter enhancements
   a) Attitude and filter logging at main loop rate
   b) Batch sampler logging both pre and post-filter
   c) FFT frame averaging
   d) In-flight throttle notch parameter learning using averaged FFTs
   e) Triple harmonic notch
7. RemoteId and SecureBoot enhancements
   a) Remote update of secure boot’s public keys (also allows remote unlocking of bootloader)
8. Safety enhancements
   a) crash_dump.bin file saved to SD Card on startup (includes details re cause of software failures)
   b) Disabling Fence clears any active breaches (e.g. FENCE_TYPE = 0 will clear breaches)
   c) “GPS Glitch” message clarified to “GPS Glitch or Compass error”
   d) Pre-arm check that configured AHRS is being used (e.g. checks AHRS_EKF_TYPE not changed since boot)
   e) Pre-arm check that gimbals are healthy (currently only for Gremsy gimbals, others in future release)
   f) Pre-arm check that scripts are running
   g) Pre-arm messages are correctly prefixed with “PreArm:” (instead of “Arm:”)
   h) RC auxiliary switch option for Arm / Emergency Stop
9. Scripting enhancements
   a) CAN2 port bindings to allow scripts to communicate on 2nd CAN bus
   b) ESC RPM bindings to allow scripts to report engine RPM
   c) Gimbal bingings to allow scripts to control gimbal
   d) Pre-arm check bindings (allows scripts to check if pre-arm checks have passed)
   e) Semicolon ( and period (.) supported (e.g both Logger:write() and Logger.write will work)
10. Sensor driver enhancements
    a) Benewake H30 radar support
    b) BMI270 IMU performance improvements
    c) IRC Tramp VTX suppor
    d) Logging pause-able with auxiliary switch. see RCx_OPTION = 165 (Pause Stream Logging)
    e) Proximity sensor support for up to 3 sensors
    f) Precision Landing consumes LANDING_TARGET MAVLink message’s PositionX,Y,Z fields
    g) RichenPower generator maintenance-required messages can be suppressed using GEN_OPTIONS param
    h) TeraRanger Neo rangefinder support
    i) GPS support to provide ellipsoid altitude instead of AMSL (see GPS_DRV_OPTIONS)
    j) W25N01GV 1Gb flash support
11. Bug fixes
    a) Accel calibration throws away queued commands from GCS (avoids commands being run long after they were sent)
    b) Cygbot proximity sensor fix to support different orientations (see PRXx_ORIENT)
    c) Lutan EFI message flood reduced
    d) Missions download to GCS corruption avoided by checking serial buffer has space
    e) Safety switch disabled if IOMCU is disabled (see BRD_IO_ENABLE=0)
    f) Script restart memory leak fixed
12. Developer items
    a) Fast loop task list available in real-time using @SYS/tasks.txt
    b) Parameter defaults sent to GCS with param FTP and recorded in onboard logs
    c) ROS+ArduPilot environment installation script
    d) Sim on Hardware allows simulator to run on autopilot (good for exhibitions)
    e) Timer info available in real-time using @SYS/timers.txt

While we think this beta is safe, this is the first beta release of 4.3.0 so it includes a lot of changes and certainly the chance of issues is much higher than with other beta releases so please be careful and be ready to re-take control in Manual or Hold.

We are very much looking forward to any and all feedback on this new major release and we will be answering and investigating all reports.

Thanks to all the developers who contributed to this release!

[Webillo]

@rmackay9

feedback

Great amount of work! Thanks a lot to all developers.

I flashed this version on a Balance Bot, maintaining parameters from v4.2.3. As had happened with other 4.3dev previous version, initially it started oscillating heavily back and forth, even disarming by itself (CRASH_ANGLE=45). So I changed ATC_BAL_D 0.1->0.5, and oscillations stopped; it kept vibrating back and forth a bit, and was manageable but noisy exactly as in here.

I started the same indoor mission (no GPS, with wheel encoders) I had installed on it (back and forth on a straight line), and the straight line was followed much better:

I observe that the irq handler for encoder signals includes the division µs->ms:
WheelEncoder_Quadrature.cpp:
irq_state.last_reading_ms = timestamp * 1e-3f;
so this seems to me executed at both edges for both signals edges for both encoders. Reading in µs and moving the conversion to the backend would save divisions, with a faster irq handler.

In adition in that irq handle the call to AP_WheelEncoder_Quadrature::pin_ab_to_phase() can be supressed with:
phase_after = (pin_a?(pin_b?2:3):(pin_b?1:0));
saving one call/return, with more clear coding. Better make the irq handler monolithic (no call/returns at all).

@rmackay9

WRC_xx params may need to be changed

I have been using WRC_ENABLE=0. If changing that can stop vibrations, please illuminate me.

[JIXIANG_HE]

Big thanks to the workers for the update to fix these features!
I downloaded the 4.3 beta firmware and found some issues.

1. In the Basic Tuning interface, there are several parameters that cannot be modified directly, but can only be modified in all parameter tables, which makes the test inconvenient and it is uncertain whether the parameters are written to the controller.
2. In the flight data interface, the mode in the mode selection is not the car mode, but the drone mode, which greatly affects the mode control of the ground station.
3. In this update I didn’t find any instructions for turning on the panning function and the device pivoting when turning or turning in place.
   
   
   
   
   

[rmackay9]

@Webillo,

Thanks very much for the report. I’ve added the WheelEncoder noise to the 4.3 issues list and I plan to look for a fix in the coming week or two.

[rmackay9]

@JIXIANG_HE,

Thanks for the report. These are really both ground station issues but in any case, yes we need to update Mission Planner’s Basic Tuning screen to match the new S-Curve navigation parameters. I’ve added this to our 4.3 issues list.

By the way, those parameters do not exist any more and instead we have different parameters for tuning the position controller. I plan to update the wiki to provide advice on this.

Re the flight mode display, I tried to reproduce this but on my Mission Planner it seems to be working OK. I wonder if you could try again and make sure that you’ve got an internet connection. I suspect the problem is temporary but if it keeps happening we can raise an issue with Mission Planner developers.

[JIXIANG_HE]

First of all thanks for your reply.
I have switched computers and tested many times, and this problem has always existed. Hopefully it will be resolved by updating the ground station. Please let us know the wiki link for the S-curve and other parameter descriptions for subsequent updates.
thank you very much!

[loyaltothefoil (Brian)]

Thanks for the update, you listed support for the Mamba F405 Mk4 does that include the mini 20x20 version?

[rmackay9]

@loyaltothefoil,

I’m not sure but maybe @andyp1per knows because it appears he added support for this board.

EDIT: ah, looks like you’ve already discussed with AndyP over on the Copter release discussion.

[loyaltothefoil (Brian)]

Yes he responded there, thanks. Still not sure whats the difference between version A & B he speaks of tho.

[Webillo]

@rmackay9

look for a fix

Here are two mission tests, indoors, without GPS, using Pixhawk1’s compass, with two balance bots:

20220916 12:49:10 Barbie-12 347 Barbie-13 109 ArduRover v4.3beta Balance Bot PIP indoor mission 5K

and three balance bots:

20220921 Barbie-12 373 Barbie-13 120 Barbie-14 208 ArduRover v4.3beta Balance Bot PIP indoor mission

all with ArduRover v4.3beta 20220913.

Tuning parameters was essentially:

• Starting with v4.2.3 parameters, all balance bots start oscillating heavily back and forth, even disarming by itself (CRASH_ANGLE=45). These oscillations are stopped increasing ATC_BAL_D to around 0.5, but this causes a lot of vibrations and noise (motor gearing teeth are heard knocking exactly as in here (ArduRover v4.3dev firmware dated june 16)).
• Teeth knocking can be greatly reduced increasing ATC_BAL_P and ATC_BAL_I and reducing ATC_BAL_D, and enabling WRC_ENABLE with a slow rate PID for both wheels, such as:
  ATC_BAL_D,0.3
  ATC_BAL_I,7
  ATC_BAL_P,7
  WRC_ENABLE,1
  WRC_RATE_D,0.01
  WRC_RATE_I,2
  WRC_RATE_P,0.1
  WRC2_RATE_D,0.01
  WRC2_RATE_I,2
  WRC2_RATE_P,0.1
  with a lot of “Parameter outside range” messages.

Is there an easier way?

In adition, at times there are communication failures such as this:

at t=305 on the second video (three balance bots), which has happened always (they last a few seconds) and I wonder if it has to do with the wheel encoders code, so I think that optimising the duration of its irq handler as described above can be tried.

[Webillo]

@Webillo

can be tried

Here is another video with a test mission, indoors, without GPS, using Pixhawk1’s compass, of the three balance bots:

20220926 Barbie-12 387 Barbie-13 131 Barbie-14 218 ArduRover v4.3beta Balance Bot PIP indoor mission

but this time with the irq handler modified as described above, including additionally a modification for the rounding division μs->ms (add the remainder to the next conversion).

The files modified in libraries/AP_WheelEncoder are:

• WheelEncoder_Quadrature.h,
• WheelEncoder_Quadrature.cpp,
• WheelEncoder_Backend.h,
• WheelEncoder_Backend.cpp,
• AP_WheelEncoder.h,

and can be found here. CAUTION: I don’t know the code (even I don’t know a proper place to initialize the remainder to 0, although possibly the compiler does it, and is not too important).

Anyhow, possibly the best would be to work entirely in μs, including the SITL encoders simulation (surely with a compiler error with above files (_state change)).

[rmackay9]

Hi @Webillo,

Txs for this. It’s still on my to-do list to produce a PR with the changes and ask you to test. Sorry about the delay I’ve got a search & rescue competition in a couple of weeks that is consuming a lot of my time.

[Yuri_Rage]

Had an excellent test/tune session with the mower and 4.3-beta1 this evening. I was finally able to increase the PSC_VEL_D value to a point where oscillations are well dampened under S-Curve nav.

There is a bit of an annoyance with having a high D term for the position controller on a vehicle with castered wheels (such as a zero turn mower). After a pivot turn, the casters are very misaligned with travel direction. When forward speed is commanded again, the casters very quickly align with the direction of travel, but not before momentarily “kicking” the vehicle in the previous direction of the pivot turn, which sets up an oscillation that the D term must fight. At a high PSC_VEL_D value, that “fight” becomes violent.

I wrote the attached Lua script to help tame post-pivot behavior while still maintaining straight line tracking at speed. It reduces PSC_VEL_D when speed is low, then increases it when speed is regained.

rover-PSCTuner.lua (3.3 KB)

[rmackay9]

@Webillo,

I wonder what you think about this possible fix? It is done a little differently than your suggestion but I think the result is probably the same. Essentially it just keeps all the timestamps in microseconds. The EKF only consumes the timestamps in milliseconds still but I think it should be OK because overall, any remainder will be passed to the EKF eventually.

[Webillo]

@rmackay9

Essentially it just keeps all the timestamps in microseconds.

I fully agree that the best is have everyting in μs, so also in the wheel encoders signals interrupt handler (and the SITL simulation). Anyhow, I don’t know the code but I downloaded your code from GitHub and compiled it getting:

Target         Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
--------------------------------------------------------------------------------
bin/ardurover   1395052      2116   194708               1397168          683584

for a Pixhawk1.

I tested it on a mission indoors (rover balance bot, no GPS, using wheel encoders and the Pixhawk1 internal compass):

20220930 Barbie-12 477 v4.3beta Randy Balance Bot PIP indoor mission 5K (no GPS, wheel encoders).

As in here, it completes a lap and a bit more. Obviously wheel encoders positioning doesn’t last forever.

To test on your code the monolythic irq handler with code simplifications, no call/returns and no division μs->ms, I substituted the five files above, resulting:

Target         Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
--------------------------------------------------------------------------------
bin/ardurover   1395016      2116   194704               1397132          683624

(40 bytes less, even with the remainder computations)
and tested the same mission:

20220930 Barbie-12 478 v4.3beta Randy Balance Bot PIP indoor mission 5K (no GPS, wheel encoders).

with almost identical results.

BTW1, note that function AP_WheelEncoder_Quadrature::pin_ab_to_phase() in WheelEncoder_Quadrature.cpp contains two code alternatives and the not executed one is incorrect. The correct code can be put in a single line within the irq handler as:
uint8_t phase_after = (last_pin_a_value?(last_pin_b_value?2:3):(last_pin_b_value?1:0));

BTW2, tuning could be improved if I knew how (compromise tilt oscillation/motors teeth knocking, possibly worse at low speeds in above videos).

BTW3, the lap is quite difficult with reduced space, having to pass four doors (D1, D2, D3, D4) and passing beside a refrigerator R which affects the Pixhawk1 internal compass:

[rmackay9]

@Webillo,

Great, thanks very much for testing and pointing out the other issue.

So just to be clear, in your testing, the new branch performs better than Rover-4.3.0-beta1? The balance bot is able to travel further indoors using the new branch?

[Webillo]

@rmackay9

the new branch performs better than Rover-4.3.0-beta1? The balance bot is able to travel further indoors using the new branch?

I think externally they perform equal, with no new errors. I don’t know the program, so can’t see processor occupancy, or if some parts take a lot of time. I think moving to μs is an excellent decision. I think calls/returns/branches at code executed frequently (specially irq handlers) is like reactive energy.

The 40 bytes saved above can mean a lot in processor time saved.

Please, see this video:

20221001 ArduRover Barbie-12 wheel encoders test

It corresponds to a very easy wheel encoders test, and it even doesn’t require arming. Place the balance bot (with parameters those for wheel encoder position estimation) over something so that you can move easily one wheel. Have the MP hud show the coordinates and start with known ones. Mark the wheel for knowing the origin for those virtual coordinates.

(For that balance bot in above two videos the motors have CPR=11, and for the last coordinates figure to move one unit the wheel has to be moved around 1/8 turn. The virtual coordinates are (40.1 -3.1), somewhere in Spain (choosing the north or south pole can be funny). In the video the right wheel is moved.)

Now move the chosen wheel one turn CW and one turn CCW: the start and end coordinates should be the same, but the latitude shows errors (it is not the same). The version tried in the video is your version with the irq handler optimization. Repeat with 10 turns CW and 10 turns CCW (as in the end of the video (see the video index)).

So if the latitude has no errors and your code with the irq handler optimization makes no latitude/longitude distinction, everything should be correct, but there is elsewhere some error or lack of precision for the latitude coordinate; I have no idea where. Solving it can permit longer wheel encoder positioning based missions.

[Webillo]

@Webillo

I have no idea where

I’ll respond to myself: I had an error in WENC_POS_Y/WENC2_POS_Y measurement. Correcting it it seems that both coordinates maintain values. I’ll keep testing shortly.

[Yuri_Rage]

I have a few hours/acres on the mower with beta1 and have no major issues to report.

However, I think it’s worth discussing my aforementioned post-pivot turn oscillation issue when a vehicle has caster wheels. @rmackay9, this is likely a common enough physical configuration to warrant a firmware-level fix rather than relying on a Lua script.

I’ve attached an updated copy of the script that alters PSC_VEL_D for some distance following a pivot turn. I’m referring to the desired post-pivot behavior as a “nudge” - a short rollout distance to allow the casters to align with travel direction.

The script is customizable via two parameters:

• WP_NUDGE_DIST: the “nudge” rollout distance (recommend 1-3 meters)
• WP_NUDGE_VEL_D: the PSC_VEL_D value to use during a “nudge” (recommend 0.01 to 0.05)

rover-WPNudge.lua (6.6 KB)