CANbus for Ardupilot with UAVCAN and UC4H

[mike (mike kelly)]

CANbus for Ardupilot with UAVCAN and UC4H

I think that CANbus is the single most important feature added to the Ardupilot eco-system for years. What is CANbus? Think of CANbus as the internet for multirotor devices like GPS, ESC, Barometer, Airspeed sensors, power modules and Gimbal controllers. Instead of serial, I2C, SPI, PWM and other protocols, CANbus unifies all the devices on your multirotor to one common protocol and, even more important, one cable/connector. In my blog I did a survey of Mini Pixhawks and found that the cables and connectors for the same features were all different on each of the boards. You could not unplug the GPS from one and plug it into any of the other boards. If you wanted to swap one mini Pixhawk board for a different vendor’s board you would have to re-wire everything!
Typical Pixhawk Build without CANBus

What is possible using CANbus, just three connections to the Pixhawk -Power-RC Radio- CANBus

CANbus eliminates the “rat’s nest” of wires for Ardupilot builds. All the devices connect to the CANbus with the same connector and it is a simple four-wire cable and they are all the same interchangeable cable for all devices. No more hacking and splicing cables up trying to make one to work. No more trying to figure out for hours if the serial lines go RX-TX or RX-RX. A CANBus network is a “daisy chain” which allows one device to connect to the next and then to the next. No longer do all devices have to go all the way back to the flight controller causing a “rats nest” of long cables with all the related problems they can have.

All of the devices on CANbus are smart devices. Each device knows how to talk to the other devices in the network. The gimbal controller can listen to the position information directly from the GPS rather than going through the flight controller. But this means that each device must be designed for the CANbus. But this also means novel features such as ESC telemetry, which brings real-time ESC status, or high-precision battery information during flight. In addition, a CANbus network wiring can be completely redundant bringing a much higher level of reliability to multirotors.

CANbus was originally designed by Robert Bosch GMBH for automobiles many years ago. Pavel Kirienko created a software layer which runs on top of the CANbus, made specifically for UAVs, that he calls UAVCAN. He also started a company, called Zubax, to produce high quality commercial grade UAVCAN devices: www.Zubax.com Being that they are commercial grade, they are appropriately and reasonably priced for the commercial market, but they are expensive for the DIY user and only ESCs and GPS are available now.

DJI has been using CANbus for years but they can build all the devices themselves. They did not have to wait for vendors to build CANbus devices or the flight controller firmware to be modified to use CANbus.

UC4H for Ardupilot
OlliW, the designer of the STorM32 gimbal controller, liked what he saw in UAVCAN and decided to build an interface to use standard RC components and convert them to be used with UAVCAN and Ardupilot for the DIY builder. It was ground-breaking work for Ardupilot. He created the first system that would allow a complete build using UAVCAN and Ardupilot with all devices connected using UAVCAN.
OlliW calls his project UavCan 4 Hobbyist or UC4H

The UC4H project has grown considerably and now consists of many pieces:

UC4H GPS-Magnetometer-Barometer
UC4H PowerBrick
UC4H ESC-Actuator
UC4H UartBridge
UC4H Airspeed-AngleOfAttack
UC4H Notifiers: Notify, Display, OreoLEDs
UC4H IndicatorLED
UC4H FunThing
UC4H MAVLinkBridge
UC4H Bootloader
UC4H SLCAN Adapter

Now, in version two, there is a general purpose board that can be used to interface a GPS, ESC, LED lights, Oled Notifier, etc. to UAVCAN for Ardupilot along with a Hall effect power module and KISS ESC carrier boards. These are commercially available at low cost from Jdrones Store. Now, any DIY builder can afford to use UAVCAN. This set of boards allows for complete, fully functional UAVCAN drones, with unprecedented features. With all devices using the same 4-wire cable type with locking, easy to release connectors.

In my first demonstration build using UAVCAN on a quad, I had only three connections to the flight controller - Power, CANBus, and RC radio. No PWM wires going to the ESCs, no cable going to the GPS, no wires going to the power sense on the power module. It is so much simpler to build. More importantly, it is simpler to build CORRECTLY so it will fly reliably.

But first the RULES. There are always rules. OlliW does not sell anything. He makes no money off all the STorM32 gimbal controllers out in the world nor UC4H. He is a hobbyist who is kind enough to share his work with the rest of us. You can use his hardware designs to build your own hardware if you like and you can use his firmware for free. You can use both to make your own commercial product if you like. But this is not open-source firmware. THAT IS HIS RIGHT. He can do anything he wants with it because he wrote it. You can use it for free all you want. You just cannot take it and change it. So let’s not debate open source here.

Now back to fun. On my first UC4H build I used junk box parts to hack together a spyder quad based on some plates from a DAYA 680 Folding Quad. The finished quad flew better than any of my previous 12 builds. But I was tired of hacking boards together trying to get everything to fit. So I sketched out a spyder quad with holes for all the things I would need to mount, like the power distribution board, the ESCs, the landing gear, etc. This time I was just going to bolt everything in because it was designed to work. So I sent the drawing to Nick at CNCMadness and he cleaned up the drawings and cut me some beautiful plates. It is a folding spyder quad designed for 17” props. So check out the build log here: CANbus Quadcopter using UC4H : Son of FrankenSolo

I am going to take a pause now and reserve some posts below and copy all of OlliW’s UC4H posts on his blog to here so there is a reference. But I encourage you to visit OllW’s blog to see the latest and greatest article. http://www.olliw.eu/2018/uavcan-for-hobbyists-blog/

More information at

UAVCAN for Hobbiests

Configuring Ardupilot for UAVCAN

UAVCAN: CANbus for the rest of us

[mike (mike kelly)]

TERMS OF USAGE
The material provided in the UC4H Github repository is subject to the following conditions. Firmware files: All firmwares are free (but not open source). Besides unlimited private use you are also granted the permission to use them for commercial purposes under the condition that (1) you don’t modify the firmware, e.g. remove or change copyright statements, (2) provide it for free, i.e. don’t charge any explicit or implicit fees to your customers, and (3) correctly and clearly cite the origin of the firmware and the project web page in any product documentation or web page. Hardware files: All hardware, for which material is provided, is open source hardware, under the terms of the TAPR Open Hardware License as published by the Free Hardware Foundation, see http://www.tapr.org/ohl.html. The TAPR license explicitly permits essentially unlimited commercial use, with only few conditions such as that copyright logos are not removed.

Usage Information

For me, the UC4H nodes are working great; I didn’t had a single incident because of using them. There are of course always little things which could be improved, but overall I’m very satisfied. It’s working, I like my UC4H-ized copter, and in this sense the project has accomplished its goals. I’d like to leave some comments on its applicability.

In principle, the UC4H nodes can be used in any UAVCAN network. That’s the idea of UAVCAN. I only can speak for ArduPilot, however, since that’s what I’m using. With ArduPilot, these restrictions apply:

ArduPilot
ArduPilot master has recently seen substantial changes in the UAVCAN section and is not totally compatible with earlier ArduPilot versions. So, I currently would recommend ArduCopter 3.6.x, to which I refer here.

ArduPilot 3.6 supports the GPS, magnetometer, barometer, ESC, actuator, and IndicatorLED UAVCAN messages. With ArduPilot you can thus use the UC4H GPS-Magnetometer-Barometer and UC4H ESC-Actuator nodes out of the box.

BetaCopter 3.6
This is a fork of ArduCopter 3.6, and has compiled binaries for v2 (Pixhawk), v3 (3DR Solo, Pixhawk2), and v4 (Pixracer) flight controllers. It has full support for the whole family of UC4H nodes, as well as the STorM32 gimbal controller. Thus, if you want to make best use of the potential of the UC4H project, then you want to flash BetaCopter 3.6 (you need the ‘u’ version, e.g. BetaCopter 3.6.1 v0.14u, see the github repo for details).

The code additions in BetaCopter are basically vehicle independent, i.e., it should be possible to compile the source also for other vehicles such as planes and rovers with only minor changes, and it therefore probably should be called BetaPilot. However, I’m using only copter, and only can test for copter, and for (only) that reason I speak of only copter. ��

The BetaCopter sources and binaries are available from my github repo: here.

The "feature matrix“ thus looks like this:

(1) Not available in ArduCopter 3.6, only in ArduPilot master.
(2) The UC4H Airspeed sensor is not supported by current BetaCopter; there exists a special branch for it however, which is recommended for testing.

The UC4H SLCAN adapter is of course independent on any flight controller support, and is in fact also independent on UAVCAN. It thus can be used in any CAN bus network.

Supported UAVCAN Messages

The UC4H nodes support a variety of UAVCAN DSDL data types, which are listed in the following. Each node configures its hardware CAN filters to those DSDL messages, which it is listening to, i.e., all other received messages are rejected at the hardware level.

Messages supported by all UC4H Nodes

uavcan.protocol.GetNodeInfo
uavcan.protocol.NodeStatus
uavcan.protocol.RestartNode
uavcan.protocol.debug.LogMessage
uavcan.protocol.dynamic_node_id.Allocation
uavcan.protocol.file.BeginFirmwareUpdate
uavcan.protocol.file.Read
uavcan.protocol.param.ExecuteOpcode
uavcan.protocol.param.GetSet

UC4H GPS-Magnetometer-Barometer

uavcan.equipment.gnss.Fix
uavcan.equipment.gnss.Auxiliary
uavcan.tunnel.Broadcast
uavcan.equipment.ahrs.MagneticFieldStrength2
uavcan.equipment.air_data.StaticPressure
uavcan.equipment.air_data.StaticTemperature
uavcan.equipment.indication.LightsCommand

UC4H PowerBrick

uavcan.olliw.uc4h.GenericBatteryInfo
uavcan.equipment.power.BatteryInfo

UC4H ESC-Actuator

uavcan.equipment.esc.RawCommand
uavcan.equipment.esc.Status
uavcan.equipment.actuator.ArrayCommand

UC4H UartBridge

uavcan.tunnel.Broadcast

UC4H Notifiers: Notify, Display, OreoLEDs

uavcan.olliw.uc4h.Notify
uavcan.equipment.indication.LightsCommand

UC4H IndicatorLED

uavcan.equipment.indication.LightsCommand

UC4H Airspeed-AoA

uavcan.equipment.air_data.RawAirData
uavcan.equipment.air_data.StaticTemperature
uavcan.equipment.air_data.AngleOfAttack

UC4H FunThing

uavcan.equipment.esc.RawCommand
uavcan.equipment.actuator.ArrayCommand
uavcan.equipment.ahrs.MagneticFieldStrength2
uavcan.equipment.power.BatteryInfo
uavcan.equipment.power.CircuitStatus
uavcan.equipment.air_data.RawAirData
uavcan.equipment.air_data.StaticPressure
uavcan.equipment.air_data.StaticTemperature
uavcan.equipment.indication.LightsCommand
uavcan.tunnel.Broadcast
uavcan.olliw.uc4h.GenericBatteryInfo
uavcan.olliw.storm32.Command
uavcan.olliw.storm32.Control

[mike (mike kelly)]

2nd Generation UC4H ESC KISS Carrier Boards installed and tested
23. Nov. 2018

The v1 UC4H ESC KISS Carrier board worked great for me, but it has two design issues. First, it also should be upgraded to the „2nd generation“ principle (see the main thread for an explanation), to make its CAN frontend electrically fool proof. Second, I wanted it to be also able to drive an OreoLED, but the pin which was accessible turned out to be not usable because of a hardware fault in the STM32F103 chip, and the layout wasn’t optimal anyhow. So, here they come, the v2 UC4H ESC KISS Carrier boards. I’ve build and installed them and am flying them since some days. They fully satisfy my expectations :).

[mike (mike kelly)]

UC4H ESC KISS Carrier Boards v2 with integrated OreoLEDs
2. Dec. 2018

This is something I wanted to do since about 10 months, since I’m installed the v1 UC4H ESC KISS Carrier boards, namely to operate and drive the OreoLEDs directly from the carrier boards. The main advantage is obviously the massively simplified wiring, and that one UC4H node less is needed. With the v2 KISS carrier boards this now became possible. Doing the firmware was not really difficult since I gladly had essentially all modules at hand, and the synchronization scheme I had in mind, and which is required to keep the OreoLEDs to blink in sync, turned out to work well out of the box.

Initially I thought that I will have to do a special firmware for that application, but gladly I could avoid this. So, the OreoLED support is now part of the „standard“ esc-actuator firmware, v0.22. Available as usual from the UC4H github repository.

[mike (mike kelly)]

2nd Generation UC4H PowerBrick
2. Dec. 2018

Also this was long overdue, the remaking of the UC4H PowerBrick. First, it now also follows the „2nd generation“ guide lines (see the main thread for an explanation). Second, I removed some pin headers from the design which made it slightly smaller. And finally, the 5.3 V voltage is now available on two pin header ports, which is very convenient for powering the flight controller and realizing a more reasonable CAN bus power scheme.

It passed all test flights without any issues. Well, why should there be any, the predecessor I had in use for more than a year without any issues :).

[mike (mike kelly)]

Dual UC4H Magnetometer Setup: First Tests
6. Dez. 2018

Since I’ve installed the dual GPS setup about a year ago or so on my flame wheel, I also wanted to use the magnetometer on the second GPS module as an additional external magnetometer. However, at that time back I couldn’t get it to work with ArduPilot. I now decided to look at this again. First, things have progressed since then and it should work now. Also, my current external magnetometer on the first GPS module started to develop a strange behavior in that it wouldn’t startup properly if it is too cold outside (I could proof that beyond doubt). So, I installed a UC4H general purpose board with a second external magnetometer, configured things, et voila:

MAG is the internal magnetometer, and MAG2 and MAG3 are both external UAVCAN magnetometers on node id’s 44 and 80. Calibration was a bit of a pain, but that’s normal for ArduPilot. Otherwise the setup was straight forward.

Clearly, it would be cool now if things would work such that ArduPilot would select the better external magnetometer at startup, and would choose the proper calibration data if one of them should be found to be unhealthy at startup. Unfortunately, ArduPilot itself can’t do that (which is a longstanding complain), so trying to improve that in BetaCopter would be the next step.

[mike (mike kelly)]

UC4H Airspeed v0.3 arrived
6. Dez. 2018

The new UC4H Airpseed v0.3 PCBs just arrived, so I had to assemble two of them. The „new“ feature of the v0.3 board is that it allows installing different differential pressure sensors using a small add-on PCB. Per default it hosts a DLHR sensor, and I also did one hosting an RSC sensor. I plan to do some comparative tests of these two sensors.

[mike (mike kelly)]

Differential Pressure Sensors: DLHR vs RSC Comparison II
8. Dez. 2018

Both the Honeywell RSC Trustability and AllSensors DLHR differential pressure sensors are very promising candidates for application in state-of-art airspeed sensors. I’m interested in understanding better their relative advantages. So, I’ve added support of the DS18B20 temperature sensor to the UC4H Airspeed node firmware, for independent temperature measurement, and built a setup there both sensors are connected to one and the same pitot-static tube. In this first set of experiments I focused on the zero-pressure offset, with respect to its noise and dependence on temperature variations. For achieving different temperatures I put the setup repeatedly in ambient air, in the fridge, and the freezer.

The RSC sensor datasheet provides an autozero algorithm, so the data were taken first without this being done, which shows the „raw“ offset and then with autozero applied. The autozero procedure is not simply an offset subtraction, so it was interesting to see if it does anything.

In the comparison of the data the different pressure ranges of the two used sensors has to be considered. RSC: ±20 inH2O, DLHR: ±10 inH2O (±20 inH2O correspond to ±5000 Pa).

The noise analysis reproduces the findings I’ve obtained earlier here. The temperature dependent results indicate a significantly better offset stability of the DLHR sensor.

[mike (mike kelly)]

C4H Airspeed v0.4 released
8. Dez. 2018

The v0.3 version of the UC4H Airspeed node PCB is working very well, but I realized I easily could do a minor but significant improvement which furthers its usage range. So I did that, yielding the UC4H Airspeed v0.4 version. The design of this node was a long story now, and went through 5 different versions. However, the v0.4 version I expect to last for quite some time, so I just have released it. The Eagle files and other material you’ll find as usual in the github repository.

[mike (mike kelly)]

ifferential Pressure Sensors: DLHR vs RSC Comparison III
13. Dez. 2018

In continuation of my efforts to evaluate the Honeywell RSC Trustability and AllSensors DLHR differential pressure sensors, I’m trying to also get some „dynamic“, actual airspeed data. An article by xDevs.com reported a scale error of ca 5% for the RSC sensor; the DLHR was found to be within specs. Unfortunately, I don’t have the means for reliable measurements. I did had the chance to use a simple wind generator with airspeed meter. It was clear that it won’t be very accurate, but I thought it might be worthwhile to use. I was wrong.

The setup and recorded data are shown below. The DLHR data I corrected by subtracting an offset of 4.85 Pa, and the RSC data by subtracting 0.83 Pa. There is some info in here: The DLHR zero-pressure offset reported some days ago (here) was ~5.4 Pa, which implies a „zero-offset stability“ of ~0.6 Pa. For the RSC the offset was ~0.6 Pa, and now is 0.83 Pa. With that correction, the data of the RSC and DLHR are pretty consistent – within experimental error – which is pretty low here as seen by the huge noise in the data with the wind turbine on. A further point to note is the quantization in the temperature data of ~0.25 K. The resolution of the temperature sensors themselves is much better than that. The 0.25 K comes from the airspeed UAVCAN message, which uses float16 and Kelvin as units; the offset of 273.14 K significantly cuts down the resolution which would not happen with Celsius. This is just another example of the general observation that the UAVCAN messages of the standard DSDL set are very poorly designed. I also tried to „calibrate“ the RSC/DLHR against the simple pitot tube. The reproducibility was some few m/s, but a clear mismatch has to be noted. For two wind speed settings the simple pitot tube was measuring 160-165 Pa and 80-85 Pa, and the RSC/DLHR sensors were reporting 140-145 Pa and 75-80 Pa. Clearly, this experiment wasn’t even close to accurate enough to draw any conclusions as regards the scale accuracy of the RSC and/or DLHR sensors. I need to find a way to do better. LOL.

[mike (mike kelly)]

UC4H AngleOfAttack Node
15. Dez. 2018

The second SPI port on the UC4H Airspeed Node needs some usage, right? So I did this little, quick addition, for the sake of the fun, and because I could. LOL. Thanks to the T-STorM32 project I was already familiar with magnetic rotary encoders, such as the TLE5012B or AS5048A. I had the code pieces and hardware pieces available; I „just“ had to put them together. The result you see below. Please don’t tell me that this is a very crude setup mechanical wise, I know this You are welcome to do better. The good message: If you decide to do so, you now get a UAVCAN AngleOfAttack sensor. Maybe I do a test-flight with the AoA sensor mounted on a copter … not that this makes sense, but … it’s fun. LOL.

I guess I should start to consider getting me a plane … UC4H servos, airspeed, AoA, ESCs …

[mike (mike kelly)]

UC4H PowerBrick: Cell Voltage Support by using a FrSky MLVSS
23. Dez. 2018

One feature which was missing so far was monitoring of the voltages of the individual cells of the battery. I was actually pondering about this for a while, and how a solution could look like. I didn’t wanted to have the required additional electronics on the UC4H PowerBrick board, since it would make it bulkier. So I ended up thinking that if a FrSky lipo voltage sensor (MLVSS or FLVSS) is good enough for many it should be good enough for us here too. The advantage: It is readily available, relatively cheap, folks are used to how to use it, and anyone can decide freely if she/he wants to add this feature or not. Gladly, I had put a solder pad on the UC4H PowerBrick, which I now could use to connect to the FrSky sensor. Also, gladly, I had prepared the uc4h.GenericBatteryInfo UAVCAN message for cell voltage support. So, adding respective code to the PowerBrick firmware and the BetaCopter code wasn’t very difficult. And this is the result:

One disadvantage of the FrSky sensor is that it is very slow. For a 3S/4S cell it provides a new data set only every 0.6 s. However, it’s main purpose is to detect battery issues, and this should be good enough, right? And after all, this is the same sensor everyone is using so happily

I am of course planning to design a new PCB for the UC4H PowerBrick, which offers a FrSky S-Port port. I in fact started already, but this will take time LOL.

[mike (mike kelly)]

UC4H Mavlink-Bridge: First working Prototype
30. Dez. 2018

Another feature which was badly missing is the possibility of configuring the UAVCAN nodes seamlessly in a user-friendly way with „ArduPilot tools“, i.e., without the need to connect an extra SLCAN adapter and use special software, such as the UAVCAN GUI Tool. I’m not claiming to have solved that completely now, but this might be a significant step forward.

As regards configuration of parameters, a solution has in principle been defined several years ago as UAVCAN-MAVLink bridge, see here (and it appears to be implemented in PX4 since 2016). As usual with UAVCAN, ArduPilot is behind, and doesn’t have anything of this. Interestingly, MissionPlanner in contrast has already some support!

In principle, the MAVLink bridge should be part of the ArduPilot code, but this I couldn’t yet achieve. However, I could do it with a „piece of on-board equipment“, such as a general-purpose UC4H node. As usual with UAVCAN, the UAVCAN messages have not been well designed, which results in some not-so-nice issues code-wise and makes it trickier and more resource-hungry than needed. I guess I’m going to add my own UAVCAN messages. Anyway, a first well-working prototype I have now completed:

Finally, I have to say that I’m not convinced that the UAVACN-MAVLink bridge concept is the final answer. An alternative approach would be an integrated on-board SLCAN adapter, which would decouple the development of the UAVCAN configuration tools from the ArduPilot development, which would be much more efficient workload-wise and likely would give the user much better tools. I guess I’m going to try this approach too.

[mike (mike kelly)]

** OlliW’s latest project allows viewing and editing CANbus parameters from inside Mission Planner!! **

UC4H Mavlink-Bridge II
2. Jan. 2019

The UC4H MavlinkBridge has matured. It now also has passed flight testing, i.e., is ready for prime time. A short demo video:

Many thanks to Michael_Oborne, the MissionPlanner maintainer, for having swiftly added some UAVCAN Interaction features to MissionPlanner. Thx, sir!

[LuisVale (Luís Vale Gonçalves)]

Thanks @mike and @olliw42 and also @jpkh for bringing up this excellent tutorial on top of an excellent development.

[khancyr]

Hello,

Thanks for the very details post! I am sure everybody will love the information in it

[Marc_Dornan]

Great posts Mike. Glad these are all in one place here.

[MartyMcFly (MartinKeilloh)]

Thank you Mike,im going to be a lot grayer by the time ive done can bus but all part of the Ardupilot journey

[mike (mike kelly)]

OlliW’s work is really valuable to the Ardupilot community and needs to be integrated into Ardupilot master.

The new Mavlink Bridge brings parameter control of UAVCAN devices right into Mission Planner.

It could not get any easier. People complain about the difficulty of a Ardupilot build. Well this project makes it not only much easier to succeed but with a more reliable aircraft. If it was integrated into Ardupilot we might get a manufacturer to build native UAVCAN devices for Arudpilot using his free designs.

[MartyMcFly (MartinKeilloh)]

Mike,im sorry if you took what i said wrong,I dont find ardupilot to difficult and am looking forward to the can expeirence