- all sources of optical flow publish sensor_optical_flow
- sensor_optical_flow is aggregated by the sensors module, aligned with integrated gyro, and published as vehicle_optical_flow
Co-authored-by: alexklimaj <alex@arkelectron.com>
This type (23) doesn't specify a motor number, so it can't be properly handled.
There are duo (19) and quad (20) tailsitter types that still work in simulation.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- sensor_baro.msg use SI (pressure in Pascals)
- update all barometer drivers to publish directly and remove PX4Barometer helper
- introduce baro cal (offset) mainly as a mechanism to adjust
relative priority
- commander: add simple baro cal that sets baro offsets to align with
GPS altitude (if available)
- create new sensors_status.msg to generalize sensor reporting
change motor_count variable to 'pos_thrust_motor_count'
This is more specific to what is actually happening in the code.
'pos_thrust_motors_count' indicates number of motor channels which are configured with 0..1 range (positive thrust) all other motors are configured for -1..1 range
submarine only have motors with -1..1 range.
Thus, pos_thrust_motor_count = 0
Co-authored-by: Thies Lennart Alff <33184858+lennartalff@users.noreply.github.com>
* Added an option to the Simulator module to connect to remote Gazebo servers.
This is usefull when the Gazebo simulation is running on a different host than the PX4 instance.
For example, we are running instances of PX4 with a companion application in multiple Dockers, for swarming simulations, which then connect to a remote Gazebo server.
A "-t" input argument has been added and can be called from the rcS startup script as: simulator start -t "192.168.178.122" $simulator_tcp_port
* _tcp_remote_ipaddr defaults to nullptr. This way testing against nullptr it can be determined if localhost or remote host is desired by the user.
* Documented the option in usage().
Signed-off-by: Peter Blom <peterblom.mail@gmail.com>
This commit increases the send thread stack size and changes the thread affinity of the lockstep clocking topic. It also improves verbosity in case error states occur.
using unified way to decide which output should be scale as rotor
fixed case that actuator that wasn't set (value 0 "PWM") results output of -3
make default actuator mode to set all actuator to range of -1 to +1
cleanups
- ekf2 can now run in multi-instance mode (currently up to 9 instances)
- in multi mode all estimates are published to alternate topics (eg estimator_attitude instead of vehicle_attitude)
- new ekf2 selector runs in multi-instance mode to monitor and compare all instances, selecting a primary (eg N x estimator_attitude => vehicle_attitude)
- sensors module accel & gyro inconsistency checks are now relative to the mean of all instances, rather than the current primary (when active ekf2 selector is responsible for choosing primary accel & gyro)
- existing consumers of estimator_status must check estimator_selector_status to select current primary instance status
- ekf2 single instance mode is still fully supported and the default
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
- new sensors work item that subscribes to N x sensor_gps and publishes vehicle_gps_position
- blending is now configurable with SENS_GPS_MASK and SENS_GPS_TAU
Co-authored-by: Jacob Crabill <jacob@volans-i.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
- avoids the need for ekf2_timestamp publications by q and lpe
- adds logger to the lockstep cycle and makes it poll on ekf2_timestamps
or vehicle_attitude. This avoids dropped samples (required for replay).
