this fixes a problem that came up with a user where they had
BATT_MONITOR=0 and BATT2_MONITOR=7. They did not get any battery
monitoring.
There are several ways to tackle this, but this is the simplest
The Solo battery's power button needs to be held to power off. The
debounce time before it plays the power off tone is too low.
Occasionally it causes the user to not hold the button long enough.
This corrects the delay before playing the power off tone.
../../libraries/AP_BattMonitor/AP_BattMonitor_UAVCAN.cpp: In member function ‘virtual void AP_BattMonitor_UAVCAN::init()’:
../../libraries/AP_BattMonitor/AP_BattMonitor_UAVCAN.cpp:15:123: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘AP_Int32 {aka AP_ParamT<int, (ap_var_type)3u>}’ [-Wformat=]
#define debug_bm_uavcan(level, fmt, args...) do { if ((level) <= AP_BoardConfig_CAN::get_can_debug()) { printf(fmt, ##args); }} while (0)
^
../../libraries/AP_BattMonitor/AP_BattMonitor_UAVCAN.cpp:36:33: note: in expansion of macro ‘debug_bm_uavcan’
debug_bm_uavcan(2, "UAVCAN BattMonitor BatteryInfo registered id: %d\n\r", _params._serial_number);
Minlure is a port of ArduPilot to Minnow Board connected to daughter
board. Very few of those were produced and nobody is flying with it.
It served its purpose and all the the improvements to ArduPilot remain
regardless of it not being supported anymore. Now it's just adding
maintenance work with no clear benefit, so pull the plug.
See discussion here:
https://github.com/ArduPilot/ardupilot/issues/7331
we were getting some uninitialised variables. While it only showed up in
AP_SbusOut, it means we can't be sure it won't happen on other objects,
so safest to remove the approach
Thanks to assistance from Lucas, Peter and Francisco