Rover-4.2.3-rc1/rc2 has been released for beta testing and should appear within the ground stations (MP, QGC) within the next few hours. The changes vs 4.2.2 are in the release-notes and copied below.
OpenDroneId support (aka RemoteID, not required for surface vehicles but presentation is here)
New autopilot support
a) CubeOrange+
b) Foxeer Reaper F745
c) MFE PixSurveyA1
d) Pixhawk6C and Pixhawk6X
Bug Fixes and minor enhancements
a) Battery monitor health check fixed to check all enabled monitors
b) ICE Lutan EFI update serial flood fixed
c) ICM42xxx IMU filter settings improved and allow for faster sample rates
d) INA2xx batteries may init after startup
e) KakuteH7 OSD parameter menu enabled
f) Lua script support to set desired speed in Auto mode
g) Notch filter ordering bug on loss of RPM source fixed
h) PreArm check of Rangefinder pin conflict and servo outputs
i) SCurve logs debug if internal error occurs
j) WSL2 upload fixed (developer issue only)
l) BlueRobotics Navigator autopilot filesystem fix
Any and all testing and feedback is greatly appreciated!
P.S. -rc2 was released shortly after -rc1 because we missed including the final fix for the BlueRobotics Navigator autopilot
without needing any parameter change from v4.2.2, and all seemed to work smoothly.
It seems that this bug has not yet been corrected in this version and this is good: I have tried several v4.3 development versions with the correction, and it required absurd values on ATC_BAL_D and resulted in noisy vibrating motors.
BTW, although I don’t know the code, I tried to incorporate the correction to v4.2.2 stable version, essentially:
in WheelEncoder_Quadrature.cpp and WheelEncoder_Quadrature.h leave reading in μs, moving the division to the backend (executed out of the irq handler (less times)): irq_state.last_reading_ms = timestamp * 1e-3f; → irq_state.last_reading_us = timestamp;
for time execution optimization, suppress two call/returns in the irq handler (turn it monolithic)), leaving one of the routines as uint8_t phase_after = (uint8_t)(pin_a?(pin_b?2:3):(pin_b?1:0)); (single line, easier to read).
The result was the same as with v4.3dev, requiring an absurd value on ATC_BAL_D, and producing noisy vibrating motors. So it seems that the bug is corrected in v4.2.x in some other piece of code.
Great, thanks very much for testing. Yes, you’re right that I haven’t included the wheel encoder fix because I was worried that it would lead to tuning parameter changes (which apparently it does). I have an item on my to-do list to investigate this a bit more so let’s test/fix more as part of the upcoming 4.3.0-rc1 beta testing (which will start around the end of August).
Please, see this video, also with v4.2.3rc1, without GPS, using wheel encoders for guidance:
Although the mission ends with a DO_JUMP waypoint to repeat indefinetely, and it just starts the second lap, guidance with wheel encoders is sufficiently precise for one lap.
(The GPS was taken out, so there is only one compass (Pixhawk1 internal)).
It is difficult to understand this with the x1000 μs/ms error wheel encoders bug, and the worse performance with v4.3dev, which corrects it. Won’t the bug be compensated elsewhere in the code in v4.2.x?
I looked at it briefly. I’m not sure what the bugfix was trying to fix. I have it down to, there is a configuration file that is labeled as time in milliseconds, but on 32-bit systems it is actually in microseconds and/or wheels are going faster then the max limit of 115rpm.
yes, and it doesn’t work, but I am not sure what the ‘bugfix’ was actually trying to fix. To me, it looks like numerous things need to change to get it to work right.
