- split up old module into two, one handling setpoint generation, one control
- add lateral and longitudinal control setpoints topics that can also be
injected from companion computer
- add configuration topics that (optionally) configure the controller
with limits and momentary settings
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* gz: print version number in init, remove gst plugin spam, rename function
* fix 0 timestamp issue by waiting for clock callback before subscribing to other topics. Refactor to cleanup topic subscriptions
* format
* change gzerr to gzwarn
* gz: use server config file for loading world plugins
* submodule
* use server.config in tree
* newlines
* format
* gzbridge: rename function
* format
* gzbridge: add magnetometer callback
* change gz_find_package to find_package
* fix up directory structure and cmake to allow multiple plugins
* newlines
* add comment block explaining gz_env.sh
* remove dupe readme
* remove SENS_EN_MAGSIM from all gz airframe files except spacecraft
* update gz submodule
* added optical flow to gz bridge
* log high rate sensor data
* it builds
* it builds and publishes, need to figure out build system now
* single library
* rename files
* add gz_msg for proto, fix build, test basic flow impl
* update rate, no blur
* PX4-OpticalFlow impl
* rename OpticalFlowSensor
* rename plugins
* disable gps, add plugin path
* cleanup
* fix plugin path export
* properly add OpticalFlowSystem dependency to gz
* move everything under gz_bridge
* cleanup
* add GZ_VEBOSE
* cleanup model/world build target cmake
* added GZ_DISTRO env, harmonic or ionic
* fix gz transport, unstage ark fpv bootloader
* unstage logged_topics.cpp
* cleanup
* make format
* ci fixes
* fix cmake
* remove required for gz-transport
* use model/world namespace for multi vehicle sim. Make format
* make format
* license
* remove needless member var
* made separate Kconfig for gz_msgs, gz_plugins, and gz_bridge
* move OpticalFlow build to it's own cmake
* fix clang
* cleanup comments
* fix rebase
* disable SENS_EN_GPSSIM for all gz airframes
* add GPS + noise to GZBridge
* remove mutex from gz callbacks. Callbacks run synchronously after sim update step and run() loop does not share resources.
* remove hrt check in callbacks
* format
* remove param set-default for already default params
* update submodule
* remove unnecessary comments
* overhaul of the GZBridge and px4-rc.simulator script
* remove arg
* shellcheck disable
* add bus/address
* start gz_bridge before adjusting sim speed or camera follow
Internal combustion engine control module.
New actuator functions and RPM based start/restart logic.
Not enabled by default.
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Pernilla <pernilla@auterion.com>
* fix sign error in appropriate place
In PR https://github.com/PX4/PX4-Autopilot/pull/24175 I changed the
control surface deflection signs in generate_fw_aerodynamics to make the
1103 airframe work correctly. However, this breaks the 1101 airframe,
introducing sing errors there.
So, here the change in generate_fw_aerodynamics is reverted to the state
before PR #24175. Instead, the signs are set correctly by using
the HIL_ACT_REV bitfield in the respective airframe config files.
* match control surface parameters to SIH model
We want to align the default over all vehicle types for
this param. There are still some thresholds that are
increased for FW.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- we want the drivers, sensors hub, and estimator running as soon as possible to initialize and avoid commander false positives complaining about missing data
* add standard vtol airframe to SIH.
mostly took changes from 4d930bde and applied to main.
generate_fw_aerodynamics now takes four arguments rather than using the
_u class member, because depending on vehicle type _u is used
differently.
A user configurable delay for the internal `vehicle_local_position` seems confusing in my eyes. It's a different timeout for fixed-wing and multirotor which might have made sense earlier but not really anymore since the topic is constantly published by the estimator and not expected to time out on either vehicle type and the parameter description is also misleading because it's outdated.
