Rover-4.2.2-rc1 available for beta testing

ArduRover Rover 4.2
,
1

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.

3

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.

4

What does it mean in the changelog where it states VL53L1X rangefinder preserves addresses?

Does Ardupilot now have a way of changing the addresses of multiple VL53L1X lidars?

5

@Steve_Fox,

Here’s the PR that preserves the address. It does seem related to having multiple rangefinders connected but AP does not change the lidar’s addresses, this needs to be done externally somehow I think.

6

The problem is you cant change the addressees externally then use them on the FC, they can have their addresses changed by something like an Arduino but they dont have persistent memory and revert back to the default address as soon as they are power cycled :frowning:

7

While it’s not very elegant, you could use an Arduino as a “middleman” of sorts to read a LIDAR module’s data and send it along over UART or I2C in an ArduPilot supported format.

8

It would be great if PCA9548A based i2c multiplexers were supported but i cant find any documentation that says Ardupilot will work with them :frowning:

9

@Steve_Fox,

I’ve never used an I2C multiplexer but I think it simply changes the addresses used for each sensor and so it should work for rangefinders (lidar, sonar, etc) if the RNGFNDx_ADDR parameter is set to the correct value for the sensor. At least these rangefinder drivers seem to use this parameter:

  • LeddarOne
  • LeddarVu8
  • Lightware
  • PulsedLight LRF (another name for the Garmin lidar I think)
  • VL53L1X

If we’re talking about other sensors then I’m less sure and would need to investigate more.

1 Like
10

maybe i need to give one a try, my understanding was that it changes the address to the one you set the multiplexer to but the device the multiplexer is connected to still needs to poll it and request data from sensor 1,2,3 ect.

That is where i think Ardupilot will fail, i dont think there is a option to work like that with a multiplexer.

11

Hi! I use version 1.3.77 PC software, X7+ controller, and the latest car version 4.2.2 firmware, I found a problem, after I modified the cruise speed CRUISE_SPEED, the boat will not sail at the set speed in automatic mode , but sailing according to the WP_SPEED value, is this normal?

12

@Steve_Fox look at this project if you want to interface ardupilot with a i2c multiplexer

13

oh man, how frustrating, i have all of my serial ports used :frowning:

14

@Steve_Fox
have any CAN ports open, could try a can node? I have had good luck with mrobotics and the matek can nodes converting serial and i2c devices in to can enabled

1 Like