Odd/Unusual Crash running ODID enabled 4.3.7

@xfacta Here’s a topic for that crash I had with 4.3.7 ODID. This was Copter-4.3 compiled for CubeOrangePlus-bdshot with ODID. I set the board ID to 10063. Hopefully I picked the right log. Here’s the link:

Commentary on what happened. The flight was fairly uneventful although I pulled a stupid maneuver with a lawn chair on take-off and sort of wound up lucky I didn’t crash it straight away due to my incredibly graceful physical disposition. At least I was out in the front yard where neighbors at least had a chance to laugh at me. What was really weird was when I landed, it refused to disarm and I sort of was lost momentarily. I should have set up a button to disarm it, but didn’t, and I didn’t have the presence of mind to try disarming using the QGC interface on my herelink. Anyway, it wound up flipping over and I suppose disarming due to the errors that came from grinding my props on the concrete driveway.

I am 50% thinking this was entirely pilot error but 50% thinking this never happened before so something had to be wrong. I reverted to stock bootloader and code and replaced a couple props and have had successful flights since then with no repeats.

So I appreciate you taking a look. I am certainly unafraid to load my ODID build back on there and do it all again.

In the spirit of full disclosure, about a week ago I loaded a bad bootloader on this thing and bricked it. No USB activity or anything. I ordered a replacement cube, but decided with nothing to lose, I might be able to make this a dev cube. So I tore it apart and soldered a wire to feed 3.3v to the DFU pin. So it’s been flying fine since then, but you never know with this sort of thing. Best laid plans and a steady hand can still impact things like IMU isolation, etc. I’m hoping that is no factor and I can continue to develop things until remote ID is good to go and then swap in the new cube and load it up after all my testing and flailing about. Those things are too expensive to just throw them away.

Thanks for taking a look.

I think what happened is the GPS position was wandering during landing, so the copter thought it was still moving and didn’t disarm.
You can try switching to Stabilise mode (with throttle down probably) and this will ignore the position controller and should have caused a disarm.

I find it’s a good idea to have a motor emergency stop switch too, especially for larger more expensive/dangerous copters. Pick an unused channel and switch and set RCxx_OPTION,31

If we look at the map, you can see the GPS position and IMU-calculated position dont align well.

Your vibrations are low, which would be a typical cause.
You could try GPS_GNSS_MODE,7 and see if that gives a better result.
I was trying to get this log opened in the new Filter Review Tool but couldnt. It looked alright in the MissionPlanner FFT graphs anyway.

I’ll think about this one some more and let you know if I come up with anything.
I also wanted to mention that it looks like you’ve done a good job on all the parameters.

There is a definite physical yaw bias - CCW motors have to work harder to counteract the CW motors.

So check for twisted motor mounts, arms or frame.
Fixing this will improve yaw attitude control, and possibly help out pitch and roll somewhat.
Also the Harmonic Notch Filter will have an easier time with less spread of frequencies.

This bias issue is the total bane of my existence. Someday I will figure out how to fix it, but I haven’t so far.

The GPS thing; sometimes it seems to work better than others. I’m starting to wonder if there is an intermittent connection. It’d be an easy thing to eliminate anyway. I’ll see what I can do. Barring that I would be inclined to try a completely different GPS module.

Tomorrow is volunteer day for some underprivileged but very bright young children who need school supplies. But if it isn’t raining I might try to tear this thing up some more afterwards. I want to try your suggestion with the GPS_GNSS_MODE setting.

Is that the EDU450 frame? If not can you supply a picture?

EDIT:
Also set BRD_BOOT_DELAY,3000 to ensure the GNSS unit always boots up before the FC, so it’s ready to do CAN comms and talk about ID’s and so on…

Yes, this is the EDU-450. I can take some updated pics of it but have to get out of my chair to do that. Probably be tomorrow, lol.

That delay makes a lot of sense. So maybe it’s a race condition. That would be a comfortable conclusion.

I feel fairly confident the boot delay had a positive impact on startup and operation of the here3 GPS module. I’ll keep an eye out for weirdness going forward, but it seems to be having a good day with that change made. I also set it to 7 on the networks setting as suggested.

I took some pictures of it as it sits now at least around the FC and such. Also to show off my slick hood I made for it. lol

https://drive.google.com/drive/folders/191ZIC5CBTOmnmwEok38ez16gxfsyQpr3?usp=sharing

Thanks again for helping me diagnose the previous failure. Here’s a log for my last flight. I re-calibrated the compass to see if that might help things as well.

If things keep going this way I will re-load my ODID firmware and try flying with that on there again. Definitely will set up a kill switch too, just in case.

Carlton

Good work!
You’ll need to get some black cable ties :slight_smile: and maybe some orange ones too.
For the “looks” of the GPS stand and cable you can get some self-amalgamating tape that looks much neater than a cable tie and more professional.

Flight looks good.

Agreed. I really want to put the GPS wire back through the mount like it is designed for, but I have to take my reinforcement plate back out and bore a hole through it or eliminate it altogether. I haven’t decided how to handle that yet. The cover actually creates some support through that area too, so I may be able to eliminate the plate. Anyway, it’s a work in progress.