Rover-4.2.2-rc1 available for beta testing

Rover-4.2.2-rc1 has been released for beta testing and can be downloaded using MP or QGC’s beta firmwares links or it can be directly downloaded from firmware.ardupilot.org.

Changes vs 4.2.1 are in the release-notes and copied below:

  1. MambaH743v4 and MambaF405 MK4 autopilot support
  2. Second full harmonic notches available (see INS_HNTC2_ parameters)
  3. UAVCAN memory usage reduced (see CAN_Dn_UC_POOL parameter to control DroneCAN pool size)
  4. Watchdog (caused by hardfault) saves crash dump logs to SD card
  5. Bug fixes
    a) CRSF protection against watchdog on bad frames
    b) CRSF reset in flight handled
    c) FFT init watchdog fix when ARMING_REQUIRE=0
    d) OSD flight modes menu includes newer flight modes
    e) Param download (via MAVFTP) fixed for params with overlapping names
    f) PWM rangefinder bug fix and added SCALING parameter support
    g) Replay bug fix when EK3_SRCs changed
    h) SERIALx_OPTION fix when “Don’t forward mavlink to/from” selected (resolves MAVLink gimbal detection)
    i) VL53L1X rangefinder preserves addresses

Any and all feedback is greatly appreciated! If all goes well we will release this as the official version in about a week.

For the following, consider that I don’t know the code internals, so may be completely wrong (if so, please correct me).

As discussed here about wheel encoders in Rover Balance Bot (and possibly other rovers), in this issue and in this PR, in recently changed line (floating point multiplication added):
irq_state.last_reading_ms = timestamp * 1e-3f;
in this module (WheelEncoder_Quadrature.cpp), the μs to ms correction introduces additional code in a code that is going to be executed thousands of times per second (two quadrature signals per motor, at least two motors…), and I wonder if in interrupt time (and if both signal edges produce interrupt, for all quadrature signals in all encoders).

But what most surprises me is that I cannot find (grep -r in sources) any use for struct member irq_state.last_reading_ms, so it seems informative only (again: I don’t know the code).

So even not knowing the code, I think that what would be better is change the name of the struct member to irq_state.last_reading_us (WheelEncoder_Quadrature.h), and change line above to:
irq_state.last_reading_us = timestamp;
supposing that timestamp is indeed in μs.
(As appears there, I have tested the compilation and linking with this changes (but not flashed): no problems and 24 bytes saved, which is significant in a code executed thousands of times per second).

If it is only informative, for faster execution the struct member can be commented as well as that line.

Moreover, here is mentioned another possible code size reduction. There seem to be two coding alternatives in function AP_WheelEncoder_Quadrature::pin_ab_to_phase(…), and the longer one in bytes (and possibly in execution time) is chosen (perhaps the programmer has a good reason for this).

Sorry for the length: I don’t know the code internals.