AP_Periph 1.0.0 stable released

Hardware CAN Devices
1

node
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:


The key information for the 1.0.0 release is:

  • supports GPS (including RTK), baro, magnetometer, rangefinder, airspeed, ADSB, LEDs, safety switch and buzzers
  • 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

14 Likes
2

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.

3 Likes
3

jDrones Gen.Nodes are also shipped with AP_Periph bootloader and Gen.Nodes can be used for GPS, Serial, Servos etc operations.

4

Thanks Jani! I’ve added that to the article

1 Like
5

Which GPS chips do support this then? I guess we can not use the normal M8N for that, or?

6

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.

7

That question was related to the “heading from GPS” :slight_smile:

8

ahh, sorry. That will work only for u-blox F9 GPS modules, or NMEA GPS modules that can provide yaw.

2 Likes
10

great, the f303 is a nice improvement, and you should get one if you can.

@hwurzburg is working on documenting how to use the SLCAN mode in MissionPlanner for this. It is a bit tricky.

1 Like
11

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.

1 Like
13

Thanks…it appreciated

16

You can do RTK with any RTK capable u-blox. The new moving baseline support will need a F9P however.

that is odd. Did you set the RNFND_TYPE via the CAN parameters? Do you happen to own a logic analyser so you can look at the I2C traffic?

do you mean two rangefinders on one CAN node, or two CAN nodes? We don’t support two on one node yet

18

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.

19

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

1 Like
21

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.

22

you shouldn’t use analogs to drive LEDs, you should use GPIOs (unless you want variable intensity, in which case you use timers and a duty cycle)

you can use the existing board LED driver. For 3 LEDs the pixracer LED driver is a good choice.

nice! What MCU is on the GPS for CAN?

23

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.

25

@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

26

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.
image
More information here:
https://ardupilot.org/copter/docs/common-slcan-f7h7.html
https://ardupilot.org/copter/docs/common-mp-slcan.html

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 :slight_smile:

27

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?