* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time
* Added a separate mixer file for CAN quadrotor
* Sampling profiler improvements
* PMSP: Output more endpoints
* Matrix update
* libc usage workaround
* Removed UAVCAN perfcounters
* Matrix submodule update
* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time
* Added a separate mixer file for CAN quadrotor
* Sampling profiler improvements
* PMSP: Output more endpoints
* Matrix update
* libc usage workaround
* Removed UAVCAN perfcounters
This parameter, when enabled, enforces that the UAVCAN ESC driver never outputs zero throttle
while the system is armed. This feature is disabled by default, so the change will not break
the experience of current users.
The existing orb_advert_t use thoughout the code sometimes tries
to treat it as a file descriptor and there are checks for < 0
and ::close calls on orb_advert_t types which is an invalid use
of an object pointer, which is what orb_advert_t really is.
Initially I had changed the -1 initializations to 0 but it was
suggested that this should be nullptr. That was a good recommendation
but the definition of orb_advert_t had to change to void * because
you cannot initialize a uintptr_t as nullptr.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Forcing motors to keep spinning when armed should be a policy decision
up at the vehicle type level, not hard coded down in the ESC
driver. It isn't appropriate for fixed wing or ground vehicles for
example.
We could add an ioctl to enable "spin when armed" if just setting a
small value in the vehicle code is inconvenient
Daniel Agar