Hi Running 4.2.3 on a Matek Slim V3. Autotune and Hnotch setup now.
I had a reboot whilst disarmed (evident by beeping motors) and I couldn’t recreate it
Tried a hover flight in strong wind today (48kph) in PosHold and it seemed to be responding to controls ok. Switched to RTL and noticed LEDs didn’t change colour and copter continued to hover. I reduced throttle and the copter started to descend slowly at first then faster (looked like the max 300cm/s). I increased throttle to decrease descent speed without response.
Weather station nearby was reporting 48-65kph wind but I suspect it was less where I was.
The logs stop whilst in the air and doesn’t show the change in RC3IN or the mode change. Looks like a reboot happened at 10m high and something clever kept control of the copter. It is obvious the GPS, IMU were being used to land the copter otherwise it would have been blown away.
Video of the flight (note wind gusts was causing the barometer height to vary and GPS was not using RTK so the slight variation in position was expected).
Again I can’t recreate. I’d like to understand this so it doesn’t happen again.
Much appreciated the great help from the team here!
EDIT: wrong log file!
Ignore all below, it doesnt relate to Tim Boyles log.
I definitely dont see any reboot in-flight in that log. After what appears to be a landing (even though there is no land detect) logging continues.
The trouble is landing is not detected, so the copter thinks it should still be flying. Also if you look on the map it looks like you took off in the car park, but it was landing in the roof of a building according to the GPS position. The copter may have been trying to use a wandering GPS position. The baro altitude doesnt support landing on a building.
In the final flight you do switch into Stabilise mode and almost lose control probably because of the wind.
A lot of the time (in previous flights) is spent in Guided and Land, there are small sections of Loiter and Stabilise.
There are many Auto Arm messagess, so you might want to investigate whatever the GCS is doing.
Try setting these to improve the GNSS performance
BRD_BOOT_DELAY,3000
GPS_GNSS_MODE,7 or 3
I strongly recommend setting
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2 or 3
It is a mistake to think “I’m only testing, I don’t need these yet”
You could set these to improve control:
ATC_THR_MIX_MAN,0.5
INS_ACCEL_FILTER,10
PSC_ACCZ_I,0.4
PSC_ACCZ_P,0.2
and
INS_HNTCH_ENABLE,1 ← set this then refresh params to see the rest
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.14
INS_HNTCH_FREQ,100
INS_HNTCH_BW,50
INS_HNTCH_FM_RAT,0.7
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
MOT_SPIN_MIN,0.13
There is no way you had a mid-flight reboot and kept flying. If that happened, the “clever” thing that would keep things going would have to be a combination of bizarre coincidence and black magic.
Many times when these inexplicable issues occur, a power problem is to blame, but there is no indication of such. If there is a power supply issue, the log quit before indicating it as a possibility.
There isn’t much reason to remain on the 4.2 branch - recommend updating ASAP.
Yea, I don’t see any evidence of a reboot in-flight. Flight Controller power loss would be my guess. Out of curiosity which version of the Matek H743 is this?
Right see you mentioned that in the 1st post. Vbat will be steady in the logs up until it stops logging. Common signature of an FC loosing power. But granted there are other reasons for it. I have 2 of those FC’s but not in front of me to check. I noticed that the IMU temp is high which I have seen on the mini version but it hasn’t ever caused an issue. Perhaps it’s not here either.
I don’t know what to make of the Watchdog messages with a reset in the crash dump file. A reset means the firmware crashed. If that did happen an even better reason to update to latest Stable.
You can see in the video the copter lands itself and maintains control and position in the wind. A power loss to the FC would result in no outputs to the motors and falling from the sky? You can see the logs stop whilst 10m off the ground.
It was a 37deg C day
I would definitely upgrade to latest stable right away!
I can see certain logging stops before others, like all MCU-related logging stops before attitude and other logging. Then all logging stops completely. No errors or warnings are present.
I dont think the problem is the SD Card, or all logging would stop at the same time, and there would probably be logging errors. @tridge@andyp1per Could this be a bug? Because this is a recent firmware version (4.2.3), I’m wondering if a possible bug still exists in newer versions. FC is MatekH743
I see there’s lots of work going on in this PR, but maybe that’s unrelated and just work for a future chibios update.
In other news:
Vibrations are just a bit on the high side, and if you look at the map you can see the IMU position and GPS positions dont align much at all. I would check the GPS_GNSS_MODE and GPS_GNSS_MODE2 values, something like 5 or 65 should work.
I would turn off Fast Harmonic logging
LOG_BITMASK,176126
and FFT which is not helping you at the moment
FFT_ENABLE,0
Also you could set this but it’s not critical
INS_ACCEL_FILTER,10
Power problems can be very strange indeed, which is why they are hard to diagnose. Ever notice that sometimes when your house power blinks momentarily, some appliances keep working while others lose their clock time or switch off? Same thing can happen at a micro scale on your autopilot when there is a power supply inconsistency. A momentary arc, vibrating wire that is on the verge of breaking, stray bit of metal causing a brief short, failing or stressed component, etc can all cause behavior that is otherwise inexplicable.
I hope Shawn’s got the real explanation, as otherwise, the problem could be very difficult to track down.
Ok, so I’ve upgraded to 4.3.3 (latest stable the fork I’m running)
Turned off Fast Harmonic logging and FFT. (Could this be using up memory and causing an issue?)
INS_ACCEL_Filter to 10
Both GPS to 65. Should I also enable Bedoui constellation for the Here3 (M8P) on the primary GPS (CAN bus)?
I’ll revisit all the wiring before flying but I’m pretty careful with it.
I’d be very interested if anyone can find some information on what the watchdog error was. I can’t read the crash_bin file so I’m in the dark.
After looking through the forum there appears to be quite a few similar issues and almost always with Matek FCs. Is this something that the developers are aware of? Is it because the Matek runs 1 MB of RAM?
How do I check in the logs how much RAM is used/available?
Is there some computations I should turn off to reduce the chances of this reoccurring?
I though Matek had a good name and I know @dkemxr has had success with them.
The Matek H743 boards in all versions have 2mb flash like all other H7 boards. The Slim’s and Mini have worked well for me. I haven’t had any issues, perhaps it’s the fork.
So I can shed more light on this. It only occurs when changing modes although not 100% of the time it does within 4 or 5 mode changes. In every case of this occurs you can see the channel 5 which controls the mode go to mid point of 1,500 PWM but the logs stops before the PWM completes the change and before the FC changes mode. Changing to RTL seems to be the biggest culprit.
@dkemxr@xfacta
Here is the log file from the original flight (original link expired): WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Here is the plot of mode change channel on the original log when I switched from POS to RTL you can see the logs stop immediately after the switch position change and before the FC changes mode.
Hi Randy @rmackay9 are you able to check this please?
I havent checked this latest log or tried anything in simulator yet, but the earlier log showed no apparent reason for some logging stopping, then moments later all logging stopped although the copter could still fly enough to land.
Probably power related. I had something like this before. Thank goodness its on the ground on a orange cube. The cube basically fry probably due to connection. But surprisingly it stay operational until I manually reboot the FC… Could be a safety feature.
