- Refactor and split set_pitch_max_limit method.
- New _update_pitch_limits to encapsulate all relevant functionality.
- Automatically reset if pitch and throttle are overriden.
- nullified TAKEOFF alt_dem offset on external throttle.
- Simplify use of TKOFF_THR_MIN.
- Prevent takeoff altitude overshoot by capping the altitude setpoint offset.
- Move pitch limits after vertical acceleration limitation.
this replaces the two booleans used to mediate TX and RX buffer
protection with mutexes.
The booleans were a hangover from the very early HAL_ChibiOS code, and
can lead to a deadlock. The sequence is as follows:
- a very high CAN bus bandwidth usage, triggered by MissionPlanner
requesting CAN_FORWARD on a CAN serial port. That causes a
"infinite" number of CAN_FRAME messages which saturates the bus,
and leads to the DroneCAN thread looping with no pause
- a serial port configured as GPS type AUTO, auto-probing for a GPS
that isn't there. This calls begin() periodically
- the UART TX thread assocated with that UART not making progress as
the TX thread priority is below the DroneCAN thread priority
- this causes the begin() in main thread waiting for _in_tx_timer to
loop forever, which triggers a watchdog
This is also from the older version of the generator.
Note that as documented, some of the equations have been removed and
rearranged slightly as it is assumed their terms are zero. Additionally,
the result is taken as the sum of the diagonal entries of the matrix.
It's from the older version of the generator as well.
Update variable names in the real code to be the same as the generated
code. Skip generation of the unused alternate form of the equations.
Delete `acc_bf_generated.cpp` as we know exactly how to generate it now.
Requires digging up old versions of the generator script.
The equations have been rearranged somewhat after generation to choose
the appropriate method but they do match overall. The auto-substitution
of the power functions caused slight changes to the generated syntax so
we make those to the real code as well.
Delete `yaw_generated.cpp` as we know exactly how to generate it now.
Validated that the generated code matches exactly the code in AP_NavEKF3
(except for the early exits).
Delete `covariance_generated.cpp` as we know exactly how to generate it
now (and it was out of date anyway).
Document exactly which versions were used when generating the code.
Sympy is the most important so it is explicitly checked.
Also add an alternate generate script which uses `nix-shell` to make it
convenient to automatically use these versions.
Add a shell script to run the generate_1.py file. Foresight tells us
that we will need multiple such files.
Also ignore the generated code files as they are already out of date and
we are aiming to document provenance and make them unnecessary anyway.
- modification of CMakeLists to use new component names of idf 5.3;
- removing big sdkconfig, which changes a lot, when upgrading idf and to use sdkconfig.defaults, which contain only non default defines;
- Updated idf installation packages list, according to espressif documentation;
- Updated README.md to reflect changes in sdkconfig handling;
- Fixed WDT in Scheduler, it was broken with idf 5.3;
- fixed compilation issues with GCC 13 (which is used by idf 5.3);
- fixed bug in case when HAL_ESP32_WIFI defined as 0 (disable wifi)
- Added ESP32 targets sdkconfig (auto generated) to .gitignore
if our target loiter radius is unachievable then we can reach the
loiter target on initial capture but be unable to maintain it. This
ensures that once we capture we return true on reached_loiter_target()
This is critical for any mission type where we take an action on
reached_loiter_target() and another condition (such as being lined up
for a waypoint). Otherwise we may continue loitering forever
for some flight profiles (such as glider pullup) the EKF airpeed
consistency check may be triggered, leading to a valid airspeed being
ignored, which can lead TECS to be in non-airspeed mode
Added Param MAX_RETRY which If set 0 or less, then there is no limit to retrials. If set to a value greater than 0 then the engine will retry starting the engine this many times before giving up.
The CAN port as it was is a valid CAN port for the nucleo, but on the development board the CAN silkscreen is actually on PD0 and PD1. This change makes it easier to get the example running on the Nucleo
Randy Mackay
Leonard Hall
George Zogopoulos
Bayu Laksono
Stephen Dade
Ryan Friedman
Andrew Tridgell
Peter Barker
Iampete1
Bob Long
Henry Wurzburg
tompsontan
Thomas Watson
ARg
Nick Exton
Tdogb
juvinski
muramura
Loki077
Andy Piper
Rhys Mainwaring
Robert Taylor