UAVCAN has been made available quite some time ago, in order to bring CAN to drones. The CAN bus is renowned for it’s extreme reliability and is thus attractive for application in drones. However, to the day I think it is fair to say that only few UAVCAN devices have become available, and those which are, are clearly for the professional market, at least price-wise. So, I set out to change that, and started the UAVCAN for Hobbyists project. The initial driving force was in fact that I wanted to get rid of this dammed I2C, which we use for connecting an external magnetometer. Soo annoying. Thus, I thought, let’s build a UAVCAN-to-I2C adapter and connect that to the magnetometer, so that the long wires would be CAN now. The project however quickly went (much) farther than this.
The project presented me with initial challenges which made me considering to quit more than once. At this point I want to express my deepest thanks to Pavel, for the tremendous work he put into UAVCAN, and especially for not giving up answering my questions. Thank you so much, sir! 🙂
The project consists of several pieces, which I will present, and make available, below:
- UC4H GPS-Magnetometer Node
- UC4H Power Brick
- UC4H ESC-Actuator Node
- UC4H Notifiers: Notify, Display, OreoLEDs
- UC4H Bootloader
- SLCAN Adapter
If you want to build one yourself, please inspect the respective chapter as well as the chapter Build Information for relevant information.
- Discussion thread @ rcgroups.
- Discussion thread @ ardupilot.discuss.
- all firmware binaries, Eagle design files, and some other material, can be obtained from the UC4H Github repository: https://github.com/olliw42/uavcan4hobbyists.
First user demonstrating a successful flight using UC4H components:
TERMS OF USAGE
All material provided in the UC4H Github repository is free, and is subject to the following conditions. Firmware files: Besides unlimited private use you are 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.
0. Usage Information
For me, the UC4H nodes are working well; I didn’t had a single incident because of using them. There are of course always little things which could be improved and changed, 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:
You should flash at minimum from master. Master supports the GPS, magnetometer, ESC and actuator UAVCAN messages. With ArduPilot master you can thus use the UC4H GPS-Magnetometer and UC4H ESC-Actuator nodes out of the box.
This is a fork of ArduCopter master, and has compiled binaries for v2 (Pixhawk), v3 (3DR Solo, Pixhawk2), and v4 (Pixracer) flight controllers. It has full support for the UC4H Power Brick, the telemetry of the UC4H ESC nodes, the UC4H Notify and OreoLED nodes, as well as for the STorM32 gimbal controller. Thus, if you want to make best use of the potential of the UC4H project, you want to flash BetaCopter3.6dev
The „feature matrix“ thus looks like this:
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.
I. UC4H GPS-Magnetometer Node
The UC4H GPS-Magnetometer node provides a bridge for connecting any of the widely and relatively cheaply available ublox M8 GPS modules to the CAN bus. If the GPS module also has a magnetometer on-board, which is often the case, then also the magnetometer can be connected to the UC4H GPS-Magnetometer node.
You may ask: Why should one want to do this? I did it for several reasons:
- I really was annoyed by the I2C wires. I found them to be the most unreliable connections, repeatedly causing me troubles.
- No issues with running out of UART ports on the flight controller anymore.
- It leads to a cleaner wiring. Instead of 7 wires only 4 are needed. Also, fewer wires go to the flight controller, especially if more UAVCAN units are used. This can help with damping flight controller vibrations, and avoids having to deal with many different connector types.
- It’s just cool. 🙂
However, from the scheme it should be clear that any M8 GPS or GPS+compass module can be turned into a full-fletched UAVCAN GPS+compass module. And this at very modest costs. This is what DIY is about, right.
In the above scheme I was using a little PCB, which I layouted, and which you can see in the next picture. The board may look difficult to build, and for those who never have done SMD soldering it probably is, but when using solder paste and a hot-air station (good ones, such as the 858D, are available for ca $35) it is really much simpler to do than you might think now.
The connection diagram for the Hobbyking GPS and magnetometer module looks as this:
The UC4H GPS-Magnetometer node can also be build using cheaply and widely available STM32F103C8/CB and CAN transceiver modules. The result of course doesn’t look as snugly, but it is incredibly simple, and cheap, and works equally well. For instance, I’ve ordered this STM32F103C8 development board for $1.80, and this SN65HVD230 CAN transceiver module for $1.89. The cost for converting a GPS module into a UC4H GPS-Magnetometer node can thus be as low as $3.69. Cool, eh.
Depending on the GPS/magnetometer module which is used it can be necessary to add two pull-up resistors to the I2C lines. This is e.g. the case for the mentioned Hobbyking module. A general scheme and a practical build is shown here:
Please consult also the chapter Build Information below.
II. UC4H Power Brick
The UC4H Power Brick combines measuring the voltage and current of the battery, and a 5.3 V/3 A power source for powering the copter electronics. It thus is a substitute for modules such as the common 3DR power module, the ACSP4/5/7 modules by AUAV/mRo, or the sensor and BEC modules by Mauch.
The UC4H Power Brick has some top-notch features:
- Uavcan: Well, obviously, that’s its major point. It emits the UC4H-specifc GenericBatteryInfo message at adjustable intervals.
- Low-noise Switch Regulator: I use the LT8610A which is good for 42 V and 3.5 A. It’s a member of the LT8610 family of regulators, which is also used by e.g. the ACSP series of AUAV/mRo.
- Hall Current Sensor: No lousy resistor shunt, Hall sensors are state-of-the art and should be standard. I use the ACS770, which is the successor of the well-known ACS758, which has been widely used in the drones area (see e.g. here), and offers slightly better specs. The ACS780/1 could also be worth a consideration, but it is a bit „trickier“.
- LDO Stabilized Voltage for the Hall Current Sensor: This is actually a point which I think has been overlooked in the design of available power modules using the ACS7xx sensors (e.g. here and here): The ACS7xx sensors are ratiometric. This means that when its supply voltage varies also the current sensor output signal varies proportionally. Thus, if the ACS7xx is directly powered from the 5.3 V source, as it is usually done, then any significant power drawn from the 5.3 V source will result in a drop of the measured current value, since the voltage will drop. In my tests a draw of 2 A led to a drop from 5.3 V to 5.0 V or 6%, and the current on the main line will be measured incorrectly by 6% – which is quite a lot. In the UC4H Power Brick this is overcome by using an extra LDO regulator for sourcing the ACS7xx sensor, ensuring most precise current measurement.
- Precise Charge Calculation: This is another unique feature. Since the UC4H Power Brick has it’s own microcontroller, it can determined the consumed charge (mAh) much more precisely than would be possible otherwise. This is so because it can measure the current at a much higher rate and thus track current fluctuations much more precisely. Specifically, the node’s firmware measures the current at 1 kHz, which is several 100 times faster than with the currently available power bricks.
I do have the UC4H Power Brick in permanent operation in my test copter since several months now, and I didn’t had a single incident so far. I’m lov’in it :).
As a demonstration of the accuracy of the charge counting, which is achieved – routinely – with the UC4H Power Brick, I’d like to show this one result:
- charge recorded by power brick: 4336 mAh (the flight log is here)
- charge shown by the charger: 4391 mAh
So, that is accurate to better than 1.5 %! And note: This is without any calibration of any sort! This level of accuracy of 1-2% is achieved routinely, and is obviously substantially better than what one gets when using ArduPilot’s in-built charge counting.
If interested in in-depth bench tests of the UC4H Power Brick to ensure solid working, then you can find some reported here.
III. UC4H ESC-Actuator Node
The UC4H ESC-Actuator node provides PWM or DSHOT signals for connecting ESCs or servos (= actuators), as well as telemetry feedback where possible. It offers up to six independent PWM/DSHOT outputs, which are controlled by the uavcan.equipment.esc.RawCommand data type. The servo/actuator functionality is not yet implemented.
A major feature of the node is to provide telemetry data about the status of the connected motors to the flight controller. For each enabled output the node emits a uavcan.equipment.esc.Status data type. For DSHOT and telemetry capable ESCs (KISS, BLHeli_32) the telemetry data from the ESC are polled at an adjustable rate (default 5 Hz), and filled into the fields of the uavcan.equipment.esc.Status data type, yielding real-time data on temperature, voltage, current, and rpm for each motor.
In combination with suitable ESCs, the UC4H ESC-Actuator node thus offers these advantages:
- Uavcan: Well, obviously, that’s the major point. The cool thing about the concept presented here is that any ESC can be used, making available to UAVCAN a wide selection of excellent and cheap ESCs.
- Fast update rate and low latency: ArduCopter emits UAVCAN ESC commands at rates of up to 400 Hz. Due to the nature of the CAN bus, and the UC4H ESC node in DSHOT mode, the latency varies from ca. 160 – 300 us. This is significantly shorter than the 1-2 ms for the ordinary PWM signals.
- Real-time telemetry data: The availability of telemetry data for each motor individually is certainly another strong feature, which may open new possibilities not available to hobbyists before.
The node has been extensively tested on the bench, and also has passed flight tests in both my test copter and a 3DR Solo (see here, here, and here). In both copters I do have them in routine operation now.
The node can be build using the CAN transceiver and STM32F103 development boards mentioned in the previous chapters. A scheme is shown below. Also, the PCB of the UC4H GPS-Magnetometer node can be used, in which case up to two PWM/DSHOT outputs are offered. Furthermore, I have designed a UC4H ESC Mini PCB, which is only 21×14 mm in size, and which supports up to two ESCs (and DSHOT and telemetry of course). I have them in use e.g. in my 3DR Solo. Finally, and this is IMHO currently the best option available, I have designed carrier boards for the KISS 32A and 24A ESCs, which result in really nice UAVCAN-ESCs, and are just great.
It turned out that the UC4H ESC Mini PCB comes in handy also for other purposes, such as for overcoming the motor pod issue of the stock 3DR Solo, or building a UC4H Notify node.
A brief description of the parameters of the node and other info relevant for how to use and build the node, can be found here: https://www.rcgroups.com/forums/showpost.php?p=39144246&postcount=509
Please consult also the chapter Build Information below.
The correct configuration of the UC4H ESC nodes can be a bit of a pain, since quite many parameters need to be set correctly, and the ArduPilot project doesn’t yet offer user-friendly UAVCAN node configuration methods. Therefore, a Python script was developed, which makes setting up the UC4H ESC nodes a piece of cake. It runs through all necessary steps almost automatically, requiring only minimal user input.
This video explains the required 3 basic steps, as well as the operation of an older version of the Python script. The latest script does it all; it can be found as usual in the UC4H Github repository.
IV. UC4H Notifier: Notify, Display, OreoLEDs
The UC4H Notifier nodes denote a set of gimicks. They do have some functional use, in that they report back some information about the status of the ArduPilot flight controller, but are really not must haves. Anyways, I am liking them a lot. 🙂
The UC4H Notifier nodes work by listening to the UC4H-specif message uc4h.Notify emitted by the flight controller.
Hardware-wise the UC4H Notifiers can come in many flavors. They may come as individual boards, may come as combinations, or even as add-ons to other UC4H nodes. They can be build, as usual, using the DIY „bluepill“ approach. For me, I have realized a UC4H Notify&Display combo-node using the GPS-Magnetometer PCB shown in the above. The same PCB I also used to – momentarily – build a UC4H OreoLEDs node.
IV.a. UC4H Notify
I got a bit annoyed by the fact that ArduCopter/Pixhawk doesn’t give me the status information I’d like to see before take-off. For instance, since using ArduCopter 3.6 I often experience that I can’t switch to PosHold in the first few minutes after take-off, which is because some things have not yet settled. This information, that the GPS-assisted modes are usable, is even not displayed in ground control stations, so that a user just can’t know. One purpose of the UC4H Notify node is to make this information easily available, via LEDs. The node has LEDs to signal the
* GPS status (red: no fix, yellow: 2D fix, green: 3D fix)
* EKF and POS status (red: EKF bad, yellow: EKF OK but no POS, green: POS OK);
* pre-arm checks (red: checks failed, green: checks passed);
IV.b. UC4H Display
Much more detailed information is given by the UC4H Display node. It’s functionality is in fact very similar to ArduPilot’s Onboard Display, except that it is per UAVCAN and not I2C (and offers the POS status, which I find crucial). The display is very handy when not using a ground control station. One however needs to be close to read it, and I thus don’t consider it a substitute for the UC4H Notify LEDs.
IV.c. UC4H OreoLEDs
The UC4H OreoLEDs node adds lightning to the vehicle. It is inspired by, and in fact closely mimics, the lightning of the 3DR Solo. So, the colors and blinking sequences provide some indication of the status during startup and in flight (see e.g. here). In some sense the OreoLEDs node is the most useful one among the UC4H notifiers, i.e., if I would have to choose only one of them, I would go with the OreoLEDs.
As always, also this node can be build using the DIY approach describes repeatedly on this page. Alternatively, both the UC4H ESC Mini and the UC4H GPS/Magnetometer PCBs come in handy too, which give small and quite convenient nodes. The LEDs are made of standard WS2812 LED strips, cut down to three LEDs for the UC4H Notify node. The display for the UC4H Display node is a standard OLed dispaly.
The power supply needs some attention. The power consumption of the LEDs is in the 100 mA range, which can overload the available power on the 5 V CAN bus line. Since the UC4H Notify node is not operation critical, I power it directly from the 5.3 V source of the power brick, and not through the 5 V CAN bus output of the flight controller.
V. UC4H Bootloader
The UC4H bootloader is a piece of code and not a physical node. It is however a much needed improvement to the UC4H suite from a user perspective, as it provides us with a user-friendly firmware upgrade of the UC4H nodes using e.g. Pavel’s great UAVCAN GUI Tool.
Given the fact that the firmwares for the UC4H nodes get constantly improved and that upgrading a node using e.g. the SWD/ST-Link approach can be a pain once the node is installed in the copter, a more user-friendly method is clearly highly desirable. This is especially true with the many nodes of a fully UC4H-ized copter. Bootloaders were invented exactly for this, and the UC4H bootloader follows the established paths. Developing a UAVCAN bootloader is however a bit special since the UAVCAN concept and protocol provides some additional challenges not encountered in „usual“ bootloaders. Also, the tools are not fully fletched out and workarounds had to be found. Anyway, finally, the UC4H bootloader came to live and is now available for everyone’s use.
First the UC4H bootloader needs to be flashed into the microcontroller of the UC4H node. This is done in exactly the same way as you would have flashed a new firmware so far, i.e., by using a ST-Link and the SWD pins or a USB-TLL adapter and the system bootloader. When doing this it is recommended to also do a full erase of the flash memory.
Once the UC4H bootloader is flashed, the firmware of the UC4H node can (and should) be upgraded using e.g. the UAVCAN GUI Tool. It is not super-convenient for this purpose, but sufficiently convenient to be useful. Attention needs to be paid to which firmware is flashed, since the regular firmwares used so far would not work. The suitable or „UC4H bootlader enabled“ firmwares have a „-wobl“ in their name.
VI. SLCAN Adapter
The SLCAN adapter is an indispensable tool for checking and debugging the proper functioning of a UAVCAN network. Currently it is also required for setting the node parameters.
In simple terms, it is a USB-CAN adapter, which is connected to the CAN bus on the one side and via USB to a PC on the other side. On the PC the UAVCAN GUI Tool, which is freely available as part of the UAVCAN project, provides a nice software for doing a lot of things, such as spying the messages on the CAN bus, plotting data, setting node parameters, and so on.
Within the UC4H project, the SLCAN adapter can be build in two ways. Firstly, I’ve designed a simple PCB board, which is relatively compact, and quite handy. It also allows one to select different powering schemes for the CAN bus, and provides the fuse & diode protection in accordance with the standard.
Alternatively, the SLCAN adapter can be build using cheaply available standard components. For instance, I’ve bought this: STM32F103C8 development board at $1.80, CAN transceiver module at $1.89, USB-TTL adapter at $1.02. Total cost: $4.71. That’s very acceptable, IMHO. The connection scheme is:
Please consult also the next chapter Build Information.
VII. Build Information
Building the UC4H nodes is not very difficult, but currently few stumbling stones exist, which makes it a bit more difficult than it needs to be. This chapter aims at collecting some useful info.
- Great build report of a DIY UC4H SLCAN adapter and GSP/mag node by rcgroups user ThonTillman, here.
- Build report of a DIY ESC-Actuator node by rcgroups user mike_kelly, here and posts before.
- DIY builds: Note that the connection schemes for the DIY builds shown in the above are for the suggested CAN transceiver module. They may be, and mostly likely will be, different for other CAN transceiver modules, see e.g. here and here and here.
- GPS/Mag node: Only ublox M8 GPS units are supported. Also, the GPS must be manually configured to a baud rate of 57600 bps, using e.g. ublox‘ u-center. Sorry for the inconvenience; this will change in a future firmware.
- GPS/Mag node: Both the PCB and the DIY build shown in the above require firmware version v0.20 and later to work.
- DIY SLCAN adapter: USB-TTL adapters often use the CP2102 chip, like the one suggested in the above does. The SLCAN firmware works with a baud rate of 1000000 bps, which the CP2102 cannot handle by default. It must be configured; the procedure is however simple, see here.
- UAVCAN GUI Tool: In order to be able to decode the UAVCAN messages on the CAN bus, this tool must know about the definitions of the UAVCAN messages. The GenericBatteryInfo and uc4h.Notify messages used by the UC4H Power Brick and Notify nodes are not part of the standard set, and thus need to be made aware to the tool by copying the message definition files to a particular folder, as explained at the end of this post here.
It is important to solder the battery wires appropriately to the module. This figure may help:
Go to the Github repository: github repository.