Did the first Testflight today with rc2, MOT_THST_HOVER is working as far as i can tell. Did set the default to 0.3 and it adjusted it down to 0.2427… during alt hold. Are we supposted to disable the hover learn function once the copter is tuned well?
Anyway while hovering the failsafe triggered FS_BATT_VOLTAGE “7” in rc1 it did not do anything but in rc2 there was a sudden climb once the fs triggered. Switched over to stab and recovered the climb. I could not find a RTL in the log. Am i missing something?
Well 2 more flights both the same behaviour once bat fs gets triggered it enters rtl which is bad news when not having a fix and in alt hold mode despite FS_BATT_ENABLE is set to 0, so i guess it is a bug in the ac code.
tommal,
Ah, we’ve seen this a few times. It’s not the battery failsafe that’s the issue. It’s the buzzer!
It’s very likely that the buzzer is placed too close to the main flight controller and when it goes off it upsets the IMU. The accelerometers read the sound waves as accelerations and I believe it leads to “aliasing”. The solution is just to move the buzzer further from the flight controller.
The graph below shows how the Z-axis accelerometer suddenly becomes noisy after the battery failsafe starts. The other graph shows how the actual climb rate (green) separates from the desired climb rate (red). Also note the climb rate goes lower (to 20cm/s) but you saw the vehicle go up. This is the classic sign of the EKF getting confused by accelerometer aliasing.
Or turn off NTF_BUZZ_ENABLE so this can’t happen in flight. Would it be possible to add another mode to this parameter that keeps the arm/disarm sounds (the arm sounds are particularly useful) but to turn off the buzzer whenever the craft is in flight? This would be a great compromise between usefulness and safety.
thanks for having a look into the log randy. this makes sense somewhat as i’m using a pixfalcon from holybro with onboard buzzer. i will try to test it with deactivated buzzer again. Oddly this issue only appears in the most recent ac3.4rc2 version and not in any older one afaik.already linked this post to rcgroups.
Ok sounds good. By the way, AC3.4 includes an NTF_BUZZ_ENABLE parameter which, if set to zero, will disable the buzzer I think (I’ve never actually tried it). This could be an easy way to test that the problem goes away without having to do any surgery on the board.
@tommal, thanks for finding this issue, and glad to hear it didn’t cost you any $$ repairs.
Can anyone (Tridge?) tell me if this issue would also apply to PixFalcon running on ArduPlane 3.6? I suspect it would, if there is any occasion in which buzzer would go off in flight. I once had battery failsafe enabled, but have since been convinced to disable it. That said, I don’t know the full domain of possible buzzer events in flight. Fixed wing here, obviously, but still would like to know. I also agree with tommal’s suggestion of buzzer active on the ground, optionally inactive during flight.
