- drivers/tone_alarm: move to ModuleBase and purge CDev (/dev/tone_alarm0)
- drivers/tone_alarm: only run on tune_control publication (or scheduled note) rather than continuously
- drivers/tone_alarm: use HRT to schedule tone stop (prevents potential disruption)
- msg/tune_control: add tune_id numbering
- systemcmds/tune_control: add "error" special case tune_id
- move all tune_control publication to new uORB::PublicationQueued<>
- start tone_alarm immediately after board defaults are loaded to fix potential startup issues
- for SITL (or other boards with no TONE output) print common messages (startup, error, etc)
- 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>
* Enable offboard gliding position setpoints
Adds a capability to make the vehicle glide when given position setpoints.
Gliding setpoints are enabled by setting POSITION_TARGET_TYPEMASK_Z_IGNORE, POSITION_TARGET_TYPEMASK_VZ_IGNORE, POSITION_TARGET_TYPEMASK_AZ_IGNORE on the typemask of position setpoints.
Include zero cruising throttle
Invalid setpoints with nan
* Handle nans for curise_throttle
This Commit includes a update of the mavlink submodule
since the CELLULAR_STATUS message was updated, the necessary changes were done together
Add enums
Instead of creating the stream and deleting it again, we now create it
with a rate of 0 and trigger it once.
This should avoid heap fragmentation by continous allocations.
- IMU integration move from drivers (PX4Accelerometer/PX4Gyroscope) to sensors/vehicle_imu
- sensors: voted_sensors_update now consumes vehicle_imu
- delete sensor_accel_integrated, sensor_gyro_integrated
- merge sensor_accel_status/sensor_gyro_status into vehicle_imu_status
- sensors status output minor improvements (ordering, whitespace, show selected sensor device id and instance)
Instead of blocking the receiver thread while playing a tune we now copy
the tune to a buffer and check if we can play the next note on each
iteration of the receiver thread.
The buffer and tune object is only created on the heap if we receive a
tune to play once and doesn't use resources otherwise.
The old tune device interface is not working anymore and we need to
publish to uORB tune_control.
This solution is not optimal though because blocks the receiving thread.
When disconnecting USB poll returns successfully, but the read returns
-1 with ENOTCONN.
In addition this also ensures there's no busy loop when poll returns an
error.
MAVLink continues to work after reconnecting USB.
* add support for unmanned underwater vehicles:
* airframe uuv_generic + uuv_hippocammpus including mav_type = 12 for submarines
* mixer for UUVs with X-shaped thruster setup similar to quadcopter
* add module uuv_att_control for underwater robot attitude control
* add rc.uuv_defaults/apps for autostarting e.g. ekf2 and uuv_att_control app
- split out integrated data into new standalone messages (sensor_accel_integrated and sensor_gyro_integrated)
- publish sensor_gyro at full rate and remove sensor_gyro_control
- limit sensor status publications to 10 Hz
- remove unused accel/gyro raw ADC fields
- add device IDs to sensor_bias and sensor_correction
- vehicle_angular_velocity/vehicle_acceleration: check device ids before using bias and corrections
* Treat UAVS diffrently from manned aviation
* Added fake_traffic testing functionality,
* Added NAV_TRAFF_AVOID Hold and Landmode
* Added Behavior: HOLD Position to collision avoidance mode and implemented Landmode to collision avoidance.
Boards where no Hardware GUID is defined will send 0 as GUID.
Right now collision avoidance for more than one FMU without Hardware GUID is not possible.
We should consider adding a randomly generated HW GUID as a placeholder for legacy Boards
Daniel Agar