Make possible to define chip-select pin for internal SPI.
By defining chip-select pin, it's possible to start specific SPI device only.
This allows to have several same type of sensors on the same bus with different orientation.
- fix confusion between estimated bias and calibration offset when
saving after each flight
- when the stable bias estiamte is retrieved during flight it's
immediately converted to a sensor offset and saved
- fixes https://github.com/PX4/PX4-Autopilot/issues/18658
In MPC_YAW_MODE 3 (along trajectory), the flight task is asked to
produce a yaw setpoint. If the previous yaw value was NAN (e.g.: during
early takeoff), the setpoint should then be reset to the current
estimate.
It was meant as an example for an easy to use interface of a
motion primitive with a minimal implementation. But the implementation
is much worse than the jerk optimized trajectory. We rather
work on making it easier to use. #18390 was a first step towards that.
- sitl_gazebo in PX4/Firmware (f5d9b01f5c73c850267b5839edd5ebe89735238f): 1c8c919710
- sitl_gazebo current upstream: 607aa4d990
- Changes: 1c8c919710...607aa4d990
607aa4d 2021-11-15 Alexander Funke - Wind Plugin: Fixed typo in windGustVelocityMean. Closes#825, fixes#812 Fixed the typo in windGustVeloctiyMean to windGustVelocityMean, so that the parameter in the world file can be correctly read and the mean gust velocity properly set to the parameter's value.
- cmake NuttX build wrapper compile in place instead of copying source tree to build directory
- slightly faster skipping necessary copying (depending on system)
- allows debugging in place
- easier to work directly in NuttX following official documentation
- simplifies overall build which should make it easier to resolve any remaining NuttX dependency issues in the build system
- the downside is switching back and forth between different builds always require rebuilding NuttX, but I think this is worth the improved developer experience
- also no longer builds px4io and bootloader in every single build, for most users these rarely change and we're wasting a lot of build time
The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
