This issue was found by @khabir and reported over slack.
It resulted from the split up of the big pr #12072 into #13262.
I took over the interface while the internal states still stayed the
hard to understand internal ones. One of the follow up refactors will
fix this completely and the entire legacy setpoint restore block can
be removed.
The plot of the attitude setpoint in the log did not show any values
because the message timestamp that the position control module sets
was overwritten by the PositionControl attitude generation.
by applying it directly to the attitude setpoint which is the output of
the position controller.
The problem was that before the input to the attitude setpoint generation
was adjusted to generate a level attitude with zero thrust keeping the
heading. I refactored the PositionControl class in #13262 to directly
generate the attitude setpoint output. So here I'm adjusting the attitude
setpoint to do the exact same thing as before but without interleaving
with the PositionControl logic.
and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
Some of these perf counters were useful during initial development, but realistically aren't needed anymore, some are redundant when we can now see the average interval from `work_queue status` and some of them simply aren't worth the cost at higher rates.
This adds a flight task to catch the case where we want to do an
emergency descent without GPS but only a baro.
Previously, this would lead to the navigator land class being called
without position estimates which then made the flight tasks fail and
react with a flight task failsafe. This however meant that landed was
never detected and a couple of confusing error messages.
This applies if NAV_RCL_ACT is set to 3 "land".
See issue #12307
Since commander should still handle all failsafes we should only run
into this case as last resort to not crash.
If all failsafe actions are disabled but data is missing
e.g. RC loss action disabled but flying in manual and no RC
this can be tested.
* Add kdevelop to gitignore
* Add test stubs
* Rename px4_add_gtest to px4_add_unit_gtest
* Add infrastructure to run functional tests
* Add example tests with parameters and uorb messages
* Fix memory issues in destructors in uORB manager and CDev
* Add a more real-world test of the collision prevention
- vehicle will fly less aggressive
- it does not make sense to set the lower acceleration limit to something
that exceeds gravity if most of the vehicles do not support reverse thrust
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- we have set the maximum yaw-rate MC_YAWRATE_MAX to 200 degrees and it
makes senses to leave a bit of margin between what the user can demand
and what the limits of the vehicle are
Signed-off-by: RomanBapst <bapstroman@gmail.com>
the vehicle yaws towards the next waypoint before accelerating. This is
required for drones with front vision and aerodynamic multicopters such
as standard vtol planes or highspeed multirotors.
Matthias Grob