Supporting direct down loads from ROMFS with preferece give to the
files fould on the SD card first. This will allow a user to provide
an updated uavcan firware on the SD card, and there is no overhead
of coping files from the ROM FS to the SD card.
This will ensure that the CRCs will match with deployed units to avoid unnecessary incompatibilities while we are figuring out how to best standardize these between stakeholders.
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
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
Adds automatic control of more light types via UAVCAN. Publishes
commands for beacon, strobe, nav, and landings lights. Each is
automatically controlled based on arming state and this behavior is
configurable per light type via params. For example, nav lights can be
set to be always on while beacons turn on when the system is prearmed
and strobes turn on only when armed.
Forwards messages on the gps_inject_data uORB topic as
uavcan::equipment::gnss::RTCMStream messages on the UAVCAN bus. This
enables differential/RTK GPS over UAVCAN to work.
Tested with CubePilot Cube Orange, Here+ base and Here3 rover.
Signed-off-by: Alex Mikhalev <alexmikhalevalex@gmail.com>
I observed stack overflows when executing `uavcan params list`, so the
stack size probably needs to be increased.
Signed-off-by: Alex Mikhalev <alexmikhalevalex@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>
* X7Pro adds CAN driver
* UAVCAN timer selection moved to default.cmake
* Modify some details about @CUAVcaijie UAVCAN timer selection moved to default.cmake
* Put some timer parameters to micro_hal.h from board_config.h. Fix all h7 boards
Co-authored-by: honglang <honglang@cuav.net>
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.
- 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.
This moves the handling of the BAT%d_SOURCE param inside of the battery
library. Users of the library now pass the source instead of the flag
whether to publish. The battery library then checks if the source is
selected using the param and publishes accordingly.
Since we removed the strange system_source flag, we now need to look at
all batteries in commander.
For current estimation - I think - it makes sense to sum them up.
Fixes case where a UAVCAN SensorBridge has callback channels available,
but NuttX / uORB does not have an additional driver / topic instance
available.
Ubuntu 20.04 and latest Cygwin come with no Python 2 and no link
from python to python3. To not mess with the system we detect
python3 for seamless support.
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.
Daniel Agar