Introducing AP_Periph - easy UAVCAN firmware creation

Applications & Usage
1

I mentioned this in the ArduPilot thread
but I thought this really should be it’s own topic.
I have been working for quite some time on ‘AP_Periph’, a framework for easy creation of UAVCAN firmwares for STM32 micros. It leverages two key things:

  • the hwdef.dat system for defining a board (pinout etc)
  • the ArduPilot sensor libraries and HAL

The result is the ability to create a new UAVCAN peripheral very quickly. I always think that examples help with frameworks, so here is a port to the ZubaxGNSS:

If you look at that file you’ll see it really is just the pinout, the sensors and some things like the default node ID and name.
With this framework we now have firmware for GPS, mag, airspeed, baro, ADSB, rangefinder, buzzer, LEDs, buttons etc. You can combine them as you like. For example, here is the one for a GPS with mag, baro and LEDs:

There is a bit more info here:

Some important details:

  • AP_Periph is under GPLv3+, using the rich set of sensor drivers in ArduPilot. Some vendors won’t like this, and that is fine, they just need to do their own system
  • it doesn’t yet support dual-CAN. See ZubaxGNSS above, which has dual CAN on a STM32F105. I do plan on support dual CAN nodes, but haven’t done so yet
  • the app signature and bootloader CRC system is deliberately compatible with what Mission Planner uses to do firmware updates. Again for the ZubaxGNSS which uses a different (though very similar) signature scheme it means the existing Zubax bootloader needs updating to use this fw. I do plan to go back and make the signature scheme selectable in the hwdef.dat to fix this.
  • it is only UAVCAN v0 for now. See the discussion with Pavel linked above regarding v1
  • I’ve been fortunate enough to have support in building this system from several vendors who are now working on UAVCAN peripherals based on AP_Periph. Many thanks to mRo, jDrones, CUAV, Matternet and others.
  • as it is based on the ArduPilot HAL which was designed for boards with at least 1M flash it isn’t as small as it could be. The UAVCAN bootloader it generates is 18k, whereas it could be well under 10k. You need at least 128k of flash to think about an AP_Periph board. The upside is the HAL makes the hardware abstraction very easy.

The creation of AP_Periph was in response to the fact that UAVCAN hasn’t become nearly as widely used as it should be. I concluded that a large part of this was that the effort of both creating and then maintaining a UAVCAN firmware was just too hard, even with nice tools like libcanard. I wanted to make it as close to trivial as possible. This strategy worked wonderfully well with the ChibiOS port of ArduPilot, where creating the hwdef.dat system took us from supporting just a few boards to dozens of completely different board types in a few months. You can go from a schematic to a working firmware in a few hours.
Cheers, Tridge

1 Like
2

Thank you, Tridge, this is huge. We have been acutely aware of the entry barrier problem, and projects like this are important for the wider adoption of UAVCAN in the UAV field.

Are there plans to support high-reliability MCU alongside STM32? Such as, for example, the newer automotive Cortex-M7 based chips from Microchip or the NXP S32K family? The latter ones are extremely interesting because they support 5V supply, ASIL-B qualified, CAN FD interfaced, and equipped with ECC.

Regarding the bootloader in Zubax GNSS: we will be migrating to Kocherga soon, it’s an MIT-licensed library for construction of reliable brick-proof bootloaders. It’s a fresh implementation of the ideas that we’ve been working on together with David Sidrane and Ben Dyer in 2015. The signature used by Kocherga is backward-compatible with the current one used in Zubax GNSS, and it’s documented better. I don’t think it requires any action from your side, but I figured that you may want to be aware of it.

P.S. I moved this post from Development & Maintenance to Applications & Usage.

3

We can trivially support any MCU that ArduPilot supports, which is currently STM32F103, 105, 303, 41x, 42x, 74x, 76x and H74x.
We haven’t done ports to the NXP chips and I haven’t looked at what is involved. Basically we can support chips that ChibiOS supports, but the effort required for non-ST parts may be quite considerable.
The only MCU with built-in CANFD we support is the H743. There are some people building CAN peripherals with H743, but the part cost is high so it will only be for premium parts.

ok, I could add an option in hwdef.dat to use a signature that is compatible with the Kocherga bootloader. That shouldn’t be hard

4

The scheme used in AP_Periph is very similar to the one I saw in the ZubaxGNSS code, but I’ve added an extra tweak. At the time the bootloader sets up the IWDG it also sets up a RTC backup register with a known value. After the app code has been running happily for 30 seconds it changes that RTC backup register to a “I’m happy” value. That way the bootloader knows when a watchdog happens if it was a watchdog after 30s of running or not.
If the watchdog happens in under 30s then it stays in the bootloader as it assumes it is a dodgy app firmware. If it is after 30s then it assumes it should re-launch the app code, so you get fast reset and the sensor available again as fast as possible if a watchdog occurs in flight.

1 Like