The hrt_abstime value used to control the 1s pub rate was the value of
the timestamp_usec of the CanardTransfer, which has a timeout of 100ms
added to it.
Since hrt_abstime is an unsigned datatype, if the hrt_elapsed_time()
check was called <100ms apart, the negative value would result in a
large hrt_elapsed_time, and the bus would be spammed with Heartbeat
messages (or error messages from canardTxPush).
Now sets the GDB serial device to the path of a DroneCode Probe by
default, with option command-line option override.
A few usage instructions added to the top of the file.
Also add commented-out code for use with PR-16808
(MixingOutput + output_control)
Bench-tested PWM output on a Pixracer via UAVCANv1 ESC commands from a
Pixhawk 4.
Now running into issues with running out of stack frame memory
For now I'm going to leave the relevant code in so it's at least
readable, but in its current state it will not compile
Add new DeviceBusType_SERIAL to Device::DeviceId union
Add DRV_DIST_DEVTYPE's for all distance sensors
Change distance_sensor_s.id to distance_sensor_s.device_id
Modify all distance_sensor drivers to apply 'proper' device_id
Took the existing uavcan_stm32 driver and replaced all bxCAN code with
the equivalent for FDCAN following ST Reference Manual RM0433.
Note: There is still a bug somewhere in regards to FDCAN2 (probably
incorrect setup of the message RAM? Not sure.) But (FD)CAN1 is fully
functional (Classic CAN only, no CAN-FD).
Also TODO: Configure CAN filters. Right now there are no filters; all
incoming messages are accepted.
Fixes case where a UAVCAN SensorBridge has callback channels available,
but NuttX / uORB does not have an additional driver / topic instance
available.
Supposedly multiple sensor callbacks were supported; in reality, this
was not the case, as the mag SensorBridge in particular can only
calibrate one compass, leading to a race condition on which compass
appears first on the bus to get published and calibrated (with no
warning to the user that the 'wrong' compass is being used).
For sensors with existing generic driver classes (baro and mag) the
sensor bridges use these classes for the driver registration, and uORB
publication, and calibration interface (ioctl) handling.
UavcanGnssBridge did not support more than 1 GNSS callback/publisher.
This has now been fixed; it works the same as the baro, mag, and flow
sensor bridges. The EKF2 still doesn't support more than 2 GPS
publishers, however.
JacobCrabill