This makes SIM_ENGINE_FAIL work a little more intuitively, since it is
usually used to simulate a complete failure.
Also, drive-by fix of the SIM_ENGINE_MUL documentation.
kills heavy peripherals
../../libraries/AP_Quicktune/AP_Quicktune.cpp: In member function 'void AP_Quicktune::update(bool)':
../../libraries/AP_Quicktune/AP_Quicktune.cpp:177:32: error: 'vehicle' is not a member of 'AP'
177 | const auto &vehicle = *AP::vehicle();
| ^~~~~~~
compilation terminated due to -Wfatal-errors.
[ 688/1225] Compiling libraries/AP_TemperatureSensor/AP_TemperatureSensor_TSYS03.cpp
Waf: Leaving directory `/home/pbarker/rc/ardupilot/build/CubeOrange-periph-heavy'
CubeNode was trying to check a parameter which doesn't exist
../../libraries/AP_Airspeed/Airspeed_Calibration.cpp: In member function 'void AP_Airspeed::send_airspeed_calibration(const Vector3f&)':
../../libraries/AP_Airspeed/Airspeed_Calibration.cpp:179:23: error: 'class AP_Airspeed_Params' has no member named 'autocal'
179 | if (!param[i].autocal && !calibration_enabled) {
| ^~~~~~~
compilation terminated due to -Wfatal-errors.
We are hoping to pull more target calculations into the frontend.
Having these non-private threatens for calculations to move into the separate backends instead, so privatise them
../../libraries/AC_Avoidance/AC_Avoidance_Logging.cpp: In member function 'void AP_OABendyRuler::Write_OABendyRuler(uint8_t, bool, float, float, bool, float, const Location&, const Location&) const':
../../libraries/AC_Avoidance/AC_Avoidance_Logging.cpp:23:46: error: 'ahrs' is not a member of 'AP'
23 | yaw : (uint16_t)wrap_360(AP::ahrs().yaw_sensor * 0.01f),
| ^~~~
compilation terminated due to -Wfatal-errors.
the AP_CANManager::log_text() gets called from debug logging in
AP_DroneCAN. It is a method on a common AP_CANManager object which is
shared by multiple AP_DroneCAN threads.
if two threads call the debug log messages at the same time then we
can end up with _log_pos greater than LOG_BUFFER_SIZE (1024) and
overwrite past the end of the buffer
in the crash_dump we have for this case the next piece of memory was
hal.can[0], and the overwrite of the buffer had corrupted the
MessageRam_ structurre in the ChibiOS CAN interface code. That led to
a hardfault on receive of a CAN message
Note that this issue only happens if CAN_LOGLEVEL is set to greater
than zero, and the default is zero. So users can avoid the bug by
checking they have not changed CAN_LOGLEVEL.
Also, this is likely an issue that only happens on startup, as once
the two AP_DroneCAN threads are fully running they have the same
thread priority so can't pre-empt each other. During startup some
messages are sent from the main thread which has a different priority
to the AP_DroneCAN threads, and can thus trigger this issue