Updating UAVCAN support in APM

[Holger Steinhaus]

In recent master, the UAVCAN stack is still based on a very early experimental version of the protocol. The protocol and the driver in PX4 have evolved quite a bit in between, offering many interesting new features like node id auto configuration and device firmware updates via UAVCAN. It is to be expected that new devices sold today with recent firmwares are not working with ArduPilot at all. This is especially annoying, as new UAVCAN hardware seems to become available.

I made an effort to backport the latest stack from the PX4 project into ArduPilot's fork of PX4/Firmware (there are no source changes in APM involved). The preliminary results could be found in the submodules of my branch:

https://github.com/hsteinhaus/ardupilot/tree/uavcan_update

The result is working fine with a UAVCAN 1.0 GNSS module, however there are a few things to consider and maybe to be resolved before merging any changes:

1. the libuavcan repository (formerly knwon as "uavcan") now contains submodules on it's own (UAVCAN DSDL, DSDL compiler, UAVCAN Python bindings). All of them are needed for our purposes, so we should define how to handle them. 

2. We should decide if we still need our own fork repository of libuavcan (currently diydrones/uavcan) at all. The UAVCAN driver in the PX4 repo now contains libuavcan as a submodule (src/modules/uavcan/libuavcan). All device firmwares will depend on the official repo anyway, so maintaining an independent (incompatible) version does not make too much sense to me. Going the same way like the PX4 project here would also obsolete point 1. 

3. The NuttX version used in ArduPilot master has a few bugs regarding the namespaces of C standard library functions. The repo PX4/NuttX contains fixes for these problems. Regarding to the commit comments, the Solo FW seems to suffer from the same problems. Maybe this would be a good opportunity to pull in these fixes instead of working around them in the UAVCAN driver?

4. Node id autoconfiguration (new feature of UAVCAN 1.0) is not implemented in APM yet. While this feature would be a great usability improvement, it is in no way mandatory. All UAVCAN devices still can be configured manually the same way as the have to be today with the old stack. 

5. The status of UAVCAN device firmware update from SD card is untested (code is there, so it might work). 

I am looking forward to hear any feedback.

Regards,

  Holger

[Andrew Tridgell]

Hi Holger,

I have updated one of my Zubax GPS to the v2 firmware and I've
successfully got ArduPilot using it with your patches (thanks!).

As you said in your email there is a bit of work to be done with the
build system. I'll see if I can get something sorted out. We really just
need to fix the python path to find uavcan.dsdl for compiler.

I'd also like the autoconfigure to work, but the build system comes
first.

Cheers, Tridge

[Holger Steinhaus]

Hi Tridge,

 

 

As you said in your email there is a bit of work to be done with the
build system. I'll see if I can get something sorted out. We really just
need to fix the python path to find uavcan.dsdl for compiler.

I did not see any problems here on my machine, could you give me a hint how to reproduce it? 

 

I'd also like the autoconfigure to work, but the build system comes
first.

Just updated my branch with a commit that enables automatic node ids as well as automatic firmware updates. 

The BRD_CAN_ENABLE param now has three allowed values: 0: off, 1: enabled, manual node id assignment as before, 2: plug-and-play mode, automatic node id assignment and automatic node firmware update enabled.

I have tested booth, the node id assignment as well as the firmware update successfully with the GNSS module. The firmware update still has some issues, it accepts images that it better should not. So for the moment, please be super-careful about the file that you provide if you decide to try it (or have a BlackMagic probe at hand for recovery).

Regards,

  Holger

[Andrew Tridgell]

Hi Holger,

> Just updated my branch with a commit that enables automatic node ids as
> well as automatic firmware updates.

thanks!

> The BRD_CAN_ENABLE param now has three allowed values: 0: off, 1: enabled,
> manual node id assignment as before, 2: plug-and-play mode, automatic node
> id assignment and automatic node firmware update enabled.

ok, that makes sense

One slight concern is this uavcan update adds about 40k to flash, taking
us to about 978k for plane. That is pretty close to the 1MByte limit for
older silicon. I think we'll update anyway, and we'll just need to
disable some other things (such as EKF1) when we hit the limit

Cheers, Tridge