First flight after adding storm32 controlled gimbal, wind was 5Km,gusting to around 8. Short auto flight to test gimbal came off fine, craft was following flight plan perfectly, On the last (landing) waypoint craft entered an unresponsive climb. Climb continued, but would stop with “brake” command, then immediately resumed climb when released. Climb continued to the to the altitude geofence margin, then stopped. Repeated re-entering RTL and land mode in an attempt to get craft back under control failed. Finally returning to loiter mode re-established controlled flight, and I got it down, but on landing motors would not disarm, spooled back up, and resulted in a tip-over.
I can’t help but to think I managed to jack something up while trying to get the gimbal to operate, it may be a coincidence, but it seems to closely associated with the event.
Vibration seems (to a pure beginner like me) to be within acceptable limit, Insufficient yaw headroom with the weight of the gimbal? Operator headroom malfunction in setup?
Any hints a to what I have done wrong would be much appreciated. Of all the malfunctions to have, uncontrolled climb may be the worst for me, Local airport operator and I have an agreement that all flights would be held to rather restrictive condition, and altitude maximums, and I really don’t want to be “that guy” that can’t seem to get along with the locals.
It is kind a scary. At first i would say that it is vibration related, but vibrations were all the same during the whole flight. But for some reason the acceleratorZ.bias started to climb and this throws away the ekf. The result is that the copter continued to ascent even with a negative climb rate… frightening.
I think @rmackay9 or somebody else from the dev team with intimate knowledge of the EKF should take a look.
I agree it’s not vibration levels, they are quite low actually. It’s also very clear the EKF’s climb rate estimate went bad because we can see the inconsistent climb rate vs altitude (altitude climbs but climb rate is negative).
One clue is the PM (performance monitor) message shows a high load (89%) around the time the troubles start. Very high speed logging is also turned on which may or may not be related.
Could this sudden load spike be a result of the storm32 board (running on serial) acting up?
On reviewing the video recording, just as the craft starts to yaw toward the landing waypoint the gimbal drops it’s roll stabilization, and goes to it’s mechanical stop. There should have been a 180 degree yaw change between the last two waypoints, in the video it appears to only rotate about 100 degrees, then begin the uncontrolled climb. The mount does not appear to be oscillating on the roll axis, but there is every possibility that it may have been, and the camera’s built in stabilization is covering the shaking.
Would a malfunctioning gimbal controller account for that heavy of load? Seems a bit far fetched, but the airframe had been so reliable previously.
115kbaud with who-knows-what from the storm32 could have caused some load, but I am not sure there are any scenarios where storm32 could pump out unusual data, or enough of it.
Corrupted data could also have some strange effects.
I think I have it beat. The IMU in the gimbal was slowly building more and more errors, the roll axis would drift off to the left side, finally hitting the mechanical stops (when the camera sit the bottom of the yaw motor) and would begin a slow, but strong “hammering” oscillation at around 3hz, that would increase in intensity rather quickly. The camera’s stabilization was covering most of the effect. I still don’t understand why the vibration log wouldn’t pickup the hammering of the gimbal. is it just too low of oscillation frequency to be detected?
I verified the failure with a second camera, and sure enough, 4-5 of 90 degree waypoints, the gimbal started responding slower, and slower to return to level, fell over and started pounding at the same instant the indicated altitude began falling while the vehicle climbed. It has never tried to fly away with the gimbal motors disabled.
Would a low frequency hammering effect be enough to cause a big spike in load as indicated in the PM log? I am assuming the vibration was just too slow to show up on the log, but could this have caused the error that resulted in the incorrect altitude figures?
