Fixed already, perhaps? KDECAN doesn't appear to be working · Issue #22952 · ArduPilot/ardupilot · GitHub
1 Like
today I encountered another WDG on another pixracer frame. the logs from it flying pre-wdg are here Copter-4.4.0-beta1 available for beta testing - #16 by 406FPV they are labled 6in in all those logs. I set log disarmed to 1 but have been unable to capture anything and the crash_dump on mavftp errors out when using the latest beta MP. I can consistently get PreArm: Internal errors 0x8000 l:442 main_loop_stk and was able to get it to reproduce the wdg 3 times now but cannot get it to log anything. using sandisk 16 gb cards so not a quality issue with the sd. kind of at a loss here updated to 4.5 dev and errors persist
5/26/2023 19:01:46 : C246 IE32768 IEC15 TN:
5/26/2023 19:01:46 : WDG: T46 SL870 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM76 M
5/26/2023 19:01:38 : Frame: QUAD/X
5/26/2023 19:01:38 : IMU1: fast sampling enabled 8.0kHz/1.0kHz
5/26/2023 19:01:38 : IMU0: fast sampling enabled 8.0kHz/1.0kHz
5/26/2023 19:01:38 : RCOut: DS300:1-4 PWM:5-6
5/26/2023 19:01:38 : Pixracer-bdshot 002F002E 32375112 38343932
5/26/2023 19:01:38 : ChibiOS: 1ec9f168
5/26/2023 19:01:38 : ArduCopter V4.4.0-beta1 (867ff238)
5/26/2023 19:01:38 : Frame: QUAD/X
5/26/2023 19:01:38 : IMU1: fast sampling enabled 8.0kHz/1.0kHz
5/26/2023 19:01:38 : IMU0: fast sampling enabled 8.0kHz/1.0kHz
5/26/2023 19:01:38 : RCOut: DS300:1-4 PWM:5-6
5/26/2023 19:01:38 : Pixracer-bdshot 002F002E 32375112 38343932
5/26/2023 19:01:38 : ChibiOS: 1ec9f168
5/26/2023 19:01:38 : ArduCopter V4.4.0-beta1 (867ff238)
5/26/2023 19:01:38 : Frame: QUAD/X
5/26/2023 19:01:38 : IMU1: fast sampling enabled 8.0kHz/1.0kHz
5/26/2023 19:01:38 : IMU0: fast sampling enabled 8.0kHz/1.0kHz
5/26/2023 19:01:38 : RCOut: DS300:1-4 PWM:5-6
5/26/2023 19:01:38 : Pixracer-bdshot 002F002E 32375112 38343932
5/26/2023 19:01:38 : ChibiOS: 1ec9f168
5/26/2023 19:01:38 : ArduCopter V4.4.0-beta1 (867ff238)
5/26/2023 19:01:36 : C246 IE32768 IEC15 TN:
5/26/2023 19:01:36 : WDG: T46 SL870 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM76 M
2023-05-26 19-08-03.tlog (319.5 KB)
can anyone also explain this tone as this is how all this started today with a very weird boot up sequence where it was taking almost 2 minutes to boot had to go teach class and came back to investigate further to find that WDG. The only thing that was done to that quad after the logs posted above was I flew it a cpl more times to get some logs for magfit updated all that and flew again without any issues. drove about 600 miles back home then put it in a case and flew to Redmond didn’t get a chance to fly there and then drove to Portland to teach where I got a chance to fly and encountered all these issues. this actually was not the quad that was having the earlier wdg issues but was one that I had flown without issue multiple times.
20230526_065436.mp4 - Google Drive
1 Like
I was told roughly a year ago that 8kHz of fast sampling for both IMUs is maybe too much for a F427-based Pixracer. Especially if you augment that by any kind of FFT-based filtering, which the bdshot version suggests.
I guess the issues in this case are timing-related and can really be transient, e.g. the CPU flies well in the first flight and then goes wild in the second flight, or it works normally with one firmware version and starts crashing with the next one. Something like that happened to me already in the past, precisely with Pixracers.
I have a sneaking suspicion that I may be pushing things but I do not have the fft based filtering just rpm and a simple m8n gps with a crossfire. I did not have the rc module fired up last time and I have seen some issues with crsf and rc a cpl weeks ago. The firmware is defaulted or at least to my knowledge is for that sampling at least I do not remember changing it.
If I remember things right (please devs correct me if not), RPM-based filtering is still Fourier-based in its nature, so it may fail to cope with the big data rates from IMUs.
I ran a Pixracer with fast sampling on both IMU’s with FFT referenced Notch for quite awhile before changing ESC’s. Load was a bit high but I never experienced any problems. Now it’s using ESC RPM from Bdshot, no problems with that.
It can depend on what else you have enabled. I had scripting enabled at the same time (so had huge issues with fitting all that into the memory). The scripts were not hot, but probably in the time frames they were running the filtering machinery failed to finish in time, all the prop noise was getting further into the controls, and everything was going SNAFU pretty much - as the PIDs were good enough with filtering and too much without it.
No scripting enabled just crsf and terrain following, and rpm filtering pretty generic really. I will post a param file once I land later. Looks like its time to update my little test platforms to a H7. I just have a bunch of pixracers laying around guess they will make good ap_periph’s hahah
Not quite the same. It’s the backend rate at 8Khz that is too much. A backend rate of 1Khz is fine
Ah, yes, this is what I missed, thanks. I’ve tuned mine to 8/8.
Thanks very much for the detailed report including logs. I’ve added it to the 4.4 issues list so it won’t be forgotten.
Well I think I may have found the culprit of this misbehaviour and it was a cracked sd card
Here is a link of the flight on the latest beta should be labeled PDX in the beginning. It flew great had no issues just a quick hover in the backyard. @rmackay9 would that sd card have caused the watchdog reset? Here is a param file just in case anyone cared.
4.4.0 MASTER Param.param (17.1 KB)
Hi @406FPV,
Thanks for the follow-up. A bad SD card should never cause a watchdog… it might be but it shouldn’t so we will have a look at the WDG message and see if we can find the cause.
@406FPV can you check if you have a crash_dump.bin file on your microSD card? it may also be embedded in a bin log from a later flight (if a crash dump is present in flash we embed it in all logs)
@tridge
Unfortunately my logging failed due to a sd card crack and then I reverted back to stable and then back to latest beta so I do not have a crash_dump I am very sorry.
any word on the previous wdg reset I received? are f427 EOL after the recent update to beta 4.4.0 seems I have had two mro pixracers throw 2 wdg’s first was not allocating cores to ekf3 the second I have not heard anything about what it was. when they previously had never had one. has there been any word on if 4.4.0 is pushing cpu’s harder?
As reported on the other thread, it seems that Gremsy is aware of the problem and has a fixed Pixy WE firmware coming that resolves the issues. Txs again for the report.
How did you solved the Bad Gyro Health error? I’m having the same too
Most errors can be mitigated by good hardware construction followed by methodical configuration and tuning: How to methodically tune (almost) any multicopter using ArduCopter 4.4.x
All processes are covered there, if you have any questions, or something is not clear, ask in there.
Noted. Thank you for the info.