Rover-4.5.2-beta1 has been released for beta testing and can be installed using MP or QGC’s beta firmwares feature or the .apj file can be directly downloaded from firmware.ardupilot.org.
The changes vs 4.5.1 are in the ReleaseNotes and copied below
Board specific enhancements and bug fixes
FoxeerF405v2 support
iFlight BLITZ Mini F745 support
Pixhawk5X, Pixhawk6C, Pixhawk6X, Durandal power peripherals immediately at startup
System level minor enhancements and bug fixes
Camera lens (e.g. RGB, IR) can be selected from GCS or during missions using set-camera-source
Crashdump pre-arm check added
Gimbal gets improved yaw lock reporting to GCS
Gimbal default mode fixed (MNTx_DEFLT_MODE was being overriden by RC input)
RM3100 compass SPI bus speed reduced to 1Mhz
SBUS output fix for channels 1 to 8 also applying to 9 to 16
ViewPro gimbal supports enable/disable rangefinder from RC aux switch
Visual Odometry delay fixed (was always using 1ms delay, see VISO_DELAY_MS)
fixed serial passthrough to avoid data loss at high data rates
AHRS / EKF fixes
Compass learning disabled when using GPS-for-yaw
GSF reset minimum speed reduced to 1m/s (except Plane which remains 5m/s)
MicroStrain7 External AHRS position quantization bug fix
MicroStrain7 init failure warning added
MicroStrain5 and 7 position and velocity variance reporting fix
Other minor enhancements and bug fixes
DDS_UDP_PORT parameter renamed (was DDS_PORT)
Thanks very much for helping us test the betas! It really does help us produce more stable releases if we can get feedback before the official release.
I’m afraid I can’t answer your question but here’s the PR with the change in case this helps.
All I know is that when GPS-for-yaw was enabled and COMPASS_LEARN was set to 3, the EKF would lose it’s attitude estimate which would lead to a crash on flying vehicles at least.
I suspect I’ve reached the end of the line for my Pixhawk (“1” or 2.4.8), rather than a bug.
Perhaps you can help me confirm that.
Is this build expected to work on that old hardware?
4.2.3 works fine, even with LUA scripting, but none of the builds since - 4.4.x, 4.5.0, 4.5.1, nor the new beta. They all generate a 0x800 error and I believe some watchdog messages. It’ll boot, sometimes even arm, but things go south right after that. It hasn’t made it beyond waypoint 3 on any missions.
If it SHOULD work, I’ll take another run at it and see what I might do to eke a little more life out of the old FC.
(I already disabled scripting in my attempts to run 4.5.x, that helped, but didn’t resolve all runtime errors)
Yes, AP 4.5.x supports the Pixhawk1 but Lua scripting won’t work.
The Internal Error: 0x800 is a watchdog error that should never happen actually so I’d be very interested in seeing the onboard log and ideally the crash_dump.bin file which can be downloaded following the instructions here.
We discussed the watchdog on this morning’s developer call and @peterbarker believes it is likely caused by a known bug that is fixed in this PR.
I don’t know quite how PeterB knows that you’re using a LD06 lidar but in any case, if I create a Pixhawk1 firmware that includes this fix do you think you’ve be able to test it for us? Testing could be as simple and confirming you see the watchdog with 4.5.1 and then testing again with the firmware I’ll create to confirm that the watchdog doesn’t appear.
While I do have a Sonar, TF Mini Luna, and TF Mini Plus LIDARs (all via I2C) working with 4.2.3, I went so far as to disable - and then physically disconnect - them while trying the new firmware last weekend.
I’d be happy to try any new builds in a more measured manner and report back. I was inconsistent in my testing methodology - I originally thought it was just a bad flash (or three).
Thank you!
Found at least one note from the last session:
WDG: T-3 SL0 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM0 MC0 IE2048 IEC1 TN:
TIme stamps are incorrectly, they’re from a replay…
5/14/2024 12:46:47 PM : Internal Errors 0x800
5/14/2024 12:46:47 PM : RCOut: PWM:1-14
5/14/2024 12:46:47 PM : Forcing safety off for watchdog
Witnessed behavior - armed, got my RTK fix, loaded a small plan I’ve run before.
It tries to navigate to waypoint with a predefined fence (circle, around a tree) in the way - it doesn’t route around via Bendy Ruler, it just goes slower and slower and stops without going around the fence. I manually navigated around a bit and tried again to re-engage auto. It then threw the errors.
With the older (4.2.3) firmware, it navigates around the tree/fence just fine - there’s a well defined circle of tall grass that doesn’t get cut (when running a tighter mission).
Are you certain you’re running the correct firmware for that board? While I don’t have a specific root cause in mind, and I don’t have intimate knowledge of the watchdog triggers, I can surmise that a firmware mismatch could lead to an issue like this. For example, there’s a Pixhawk1-1M target for boards with 1MB vs 2MB of flash.
In theory, you shouldn’t be able to mix and match Pixhawk1 and Pixhawk1-1M very easily, but I wouldn’t be surprised if some of the cheap clones misreport their hardware ids.
I’ve been using this Pixhawk for 6 years now without trouble, though I think it had trouble last year when I tried 4.4, and I just reverted to 4.2.3. I thought I’d try 4.5.x - and then over the weekend I went back and forth on several revisions between 4.2.3 and 4.5.2-beta and everything after 4.2.3 failed in some fashion.
