I’ve just released the first stable release of AP_Periph, version 1.0.0. AP_Periph is a framework for creating UAVCAN peripheral firmwares. I started it as a project as I wanted to make the use of UAVCAN in ArduPilot much more widespread, and the difficulty of creating a high quality UAVCAN firmware for a new device was holding back vendors from creating new devices.
The key idea of AP_Periph is that it leverages the existing technology in ArduPilot. Specifically, it uses the existing ArduPilot sensor libraries which immediately brings a rich set of well tested sensor drivers to the project. It also uses the ArduPilot HAL (Hardware Abstraction Layer), allowing for new peripheral designs to be specified using the hwdef.dat system that has been so successful for ArduPilot over the last couple of years.
You can read more about AP_Periph here:
supports 4 different MCUs, with more added easily via hwdef.dat
dynamic or static CAN node allocation
firmware upload
automatically generated bootloader
parameter storage in flash
easy bootloader update
high resiliance features using watchdog, CRC and board checks
firmware update via MissionPlanner or uavcan-gui-tool
AP_Periph is targeted both at vendors who are looking to create a UAVCAN peripheral, and at end users who want to buy one of the convenient CAN nodes from mRo or jDrones and use those nodes to convert their existing I2C or serial periphals into UAVCAN peripherals.
The mRo nodes and jDrones gen.nodes already ship with the AP_Periph bootloader, so loading one of the prebuilt firmwares off firmware.ardupilot.org is easy. There are prebuilt firmwares for GPS, ADSB, RangeFinder and Airspeed.
I hope that AP_Periph will help to bring UAVCAN to a lot more users.
Finally, I’d like to thank @olliw42 for his great work on UC4H which led to the creation of the generic CAN nodes. While AP_Periph doesn’t share any code with UC4H, the concept of a generic CAN node that can be converted into many types of UAVCAN peripherals is brilliant and was really the inspiration for this project.
Cheers, Tridge
I’m also in the process of adding support for moving baseline RTK to AP_Periph. This will allow you to use two UAVCAN GPS modules to provide yaw for the vehicle without a compass. This will be useful for vehicles that operate in difficult magnetic environments.
You can the M8N, as well as lots of other GPS modules. You won’t get RTK support with a M8N of course, as it can’t do that, but it will give you a UAVCAN GPS.
I also sent a PM to help him. I have helped a few others that had old bootloaders and pre-stable firmware. Anyone else with CANNode issues feel free to reach out to me.
Hey @tridge
I was thinking to use F0 processor with lower flash for AP_Periph for fixed sensors with less than 5 sensor type count. I was thinking to remove all the sensor drivers which are not required and reduce flash requirement for F0. what do you suggest? And I also want to know insights on removing code and consequences of it.
Thank you.
you won’t fit the AP_HAL into a F0. I deliberately chose to use a larger flash footprint so we can share common code with the rest of ArduPilot. We’d lose that with the F0
Sorry to disturb the thread, but I have a question I have nowhere else to ask.
If, for instance, the CAN controller has three available analog pins to drive the R, G and B of a LED, a specific driver has to be written to tackle that, as opposed to having a ToshibaLED driver on I2C or a NeoPixel and making use of AP drivers ?
I’m not comfortable and I don’t have insight with code. I’m just dealing with hardware.
I’ve appropriated some DJI GPSes, soldered out all CAN stuff and used them in I2C/serial mode. And now I’m thinking of reprogramming the CAN part for AP.
DJI being DJI, they laser-erase all the markings on their MCUs. I’ll have to study the pinout to search for a match. But their RF approach feeding the classic NEO-M8N is superb, and given that M9N is a drop-in replacement, it makes them better, still.
I have been at the receiving end of I2C storms caused by QMC5883 mag clones, directly connected to FC MCU. How would they translate over a CAN connection ? Because all A2 GPS units I’ve seen so far had the original Honywell mag, while the A3 units had the clones.
@tridge Have you done any work getting a CAN Baro working? I have one in my CUAV NEO V2 Pro CAN GPS that I would like to see if I can get working, also in my Zubaks GNSS 2
My NeoV2Pro arrived today too. The baro is already supported, but is disabled by default.
You need to use either uavcan_gui_tool or MissionPlanner to change the BARO_ENABLE parameter on the GPS to 1 and then restart.
It is so nice to receive this GPS! I had a prototype that I developed the support on some time ago but really nice to see the real thing. The little light show on boot looks nice
RTK GPS works if you have a recent ArduPilot firmware and recent AP_Periph firmware. Both need to be recent (eg. current stable copter or plane) as the Fix2 UAVCAN message is needed for RTK GPS and support for Fix2 was added for 4.0.
For rangefinders we support both I2C and serial rangefinders. I’ve just spent the last 20 mins digging around on my desk for a rangefinder to test and confirm. I did find a LidarLite, but I need to make up a cable for it.
Some questions:
What vesion of AP_Periph do you have loaded?
what version of ArduPilot are you using?
have you setup the RNGFND1_TYPE correctly in the parameters on the AP_Periph node?