I think we can just directly use send() and don't need to use the
workaround of resetting the send flag to trigger one send.
Also, we don't need to override it if we don't need to check any params.
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)
In particular this together with the previous commit reduces timesync
round-trip time spikes by more than 10ms, and makes it generally more
stable.
Other streams are reordered according to onboard priority.
- create common uORB::PublicationBase
- uORB::PublicationQueued types are now type aliases
- ORB_PRIO use enum type everywhere to avoid accidental misuse
- PX4Accelerometer/PX4Gyroscope/etc driver libs explicitly advertise on construction, unadvertise on destruction. This is a workaround for any potential issues that might appear when accel/gyro cdev and uORB indexing doesn't align.
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.
* Enhancement: State of health, and max_error value is added. Both shows battery health of SMBUS smart battery.
* Enhancement: BAT_C_MULT parameter is introduced. This is for high-current capable SMBUS-based battery.
As SMBUS only provides 16-bit for current, it could only be +-32768mA which is about +-32A.
But with proper treatment, it could be extended with little accuracy loss.
This factor can be set for individual battery system with available information.
* Relative SOC introduced. Proper SMBUS battery should provide percentage of remaining battery
directly. Therefore it does not have to be computed like before.
* State of Health introduced. Proper SMBUS battery should provide SOH value.
* Max error: this shows estimation error of BMS.
* Enhancement: With smart battery, precise estimation of time remaining is provided
with impedance track. It is unit of minute, so 60 seconds multiplied.
Update rate of this is not fast, but very useful.
Co-authored-by: Hyon Lim <lim@uvify.com>
Matthias Grob