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.