World Record: First flight with ArduPilot using dual GPS via UAVCAN … see here 🙂
2nd generation UC4H General-Purpose Node released … see here 🙂
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 wires, 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 has grown considerably and now consists of many pieces:
- UC4H GPS-Magnetometer
- UC4H Power Brick
- UC4H ESC-Actuator
- UC4H UartBridge
- UC4H Air/Airspeed
- UC4H Notifiers: Notify, Display, OreoLEDs
- UC4H Bootloader
- SLCAN Adapter
If you want to build a UC4H node yourself, which is really easy, then please inspect the respective chapter on the node as well as the chapters General Build Information and Build Information, more Details for relevant information.
Discussion thread @ rcgroups.
- 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.
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:
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 whole family of UC4H 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 BetaCopter 3.6dev.
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 very minor changes, and it therfore 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 copter. 🙂
The „feature matrix“ thus looks like this:
|UART Tunnels||–||3 x|
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.
General Building Information
Building the UC4H nodes is not very difficult, and generally two approaches are available:
For all nodes I have designed dedicated PCBs, which allow nice and convenient builds. Most of the nodes can be realized using the general-purpose UC4H node, namely the GPS-Magnetometer, ESC-Actuator, Uart-Bridge, Notify, Display, and OreoLED nodes. For the UC4H Power Brick node and UC4H SLCAN adapter dedicated PCBs are available.
The boards 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 at first. It’s all just practicing it.
These PCBs all provide a fuse & diode protection in accordance with the standard. They also use the TJA1051 CAN transceiver, a so-called 3rd generation CAN transceiver, with state-of-the-art protections and reliability. They can be destroyed by overvoltages on the 5 V CAN bus, which should never happen since it should be clear that 5 V electronics should not be exposed to higher voltages, but in practice this has happened. 🙂 I thus started a rehaul of my PCB layouts, which I call „2nd generation UC4H nodes“, which adds overvoltage and reverse voltage protection, and makes the UC4H nodes ultra robust.
One of the promises of the UC4H project is to bring UAVCAN to the hobbyist, which means dirty cheap and hacky, right? And in fact, each of the nodes, except of the UC4H Power Brick, can also be build using cheaply and widely available STM32F103C8/CB and CAN transceiver modules. The result of course doesn’t look as snugly as with a PCB, but it is incredibly simple, and cheap, and works equally well.
For instance, I’ve ordered this, also known as the „bluepill“, STM32F103C8 development board at $1.80, and this SN65HVD230 CAN transceiver module for $1.89. The cost for a UC4H node can thus be as low as $3.69. Cool, eh.
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 build shown in the previous picture I used a little PCB, the revised version of which has become the general-purpose UC4H node, which you can see in the next picture, including the connection diagram for the Hobbyking GPS and magnetometer module:
The UC4H GPS-Magnetometer node can of course also be build using the DIY approach. With the components suggested in the above, the cost for converting a GPS module into a fully fledged UC4H GPS-Magnetometer node can thus be only $4. It hardly could be any cheaper, right 🙂
Depending on the GPS/magnetometer module 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.
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 its own microcontroller, it can determine 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 a year now, and it just works fantastic. No problems at all. 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 test its solid working, then you can find some reported here.
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. Outputs configured as servo/actuator listen to the uavcan.equipment.actuator.ArrayCommand data type.
A major feature of the node, when configured as ESC 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 general-purpose UC4H node can be used, which provides all six outputs plus telemetry. 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, for overcoming the motor pod issue of the stock 3DR Solo. Finally, and this is IMHO 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.
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.
UC4H Uart-Bridge Node
The UC4H Uart-Bridge node allows one to connect any device with a standard UART/serial port, such as a GPS module, and to communicate with it through the CAN/UAVCAN bus. It’s like a USB-TTL adapter, except that the USB frontend is now UAVCAN. The UC4H Uart-Bridge node provides two UART ports (this limit is imposed by the hardware of the used STM32F103T8/C8/CB chips).
This is supercool; these videos should explain it all.
As usual, the general-purpose UC4H node can be used, as well as the DIY bluepill approach.
UC4H Air/Airspeed Node
The UC4H Air/Airspeed node is designed to be multifunctional and measure the differential pressure of a pitot-static tube, the static pressure, and the air temperature. It uses the RSC TruStability pressure sensors from Honeywell, which from the data sheet are supposed to provide top-notch performance. It is a complex node though, and is thus described in a separate article, where also background is given: UC4H Air/Airspeed Node.
The firmware currently allows to measure differential pressure or airspeed, respectively, and the node is in practical testing. The bench test results so far look very promising. For instance, the orientational dependence is only 0.5 Pa, which can be compared to the 8 Pa of the MS5525DSO sensor. Also, the zero offset appears to be well below +- 1 Pa, after auto zeroing.
An ArduPilot branch with code for using the UC4H Air/Airspeed sensor is here: https://github.com/olliw42/ardupilot/tree/airspeed.
The UC4H Air/Airspeed node is developed in cooperation with Evan, who especially contributes the practical testing. Thanks so much, Evan!
Plot of the zero offset and orientational dependence for a sensor with full span of +- 5000 Pa:
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. The best option is however to use the general-purpose UC4H node. I have e.g. realized a UC4H Notify&Display combo-node, and a UC4H OreoLEDs node using it.
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);
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 additional info such as the POS status, which I find crucial, and IMHO has a nicer screen layout). The display is very handy when not using a ground control station. One however needs to be close to read it, and it is IMHO not a substitute to the UC4H Notify or OreoLEDs, but an addition.
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 node among the UC4H notifiers. That is, if I would have to choose if I could have only one of them, I would definitely go with the OreoLEDs.
As always, also these nodes can be build using the DIY approach mentioned repeatedly on this page. The general-purpose UC4H node however provides the best option, but also the UC4H ESC Mini PCB can come in handy too, which both 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, and 5 LEDs per arm for the UC4H OreoLED node. The display for the UC4H Display node is a standard 0.96“ OLED display.
The power supply needs some attention. The power consumption of the LEDs for the UC4H Notify node 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 UC4H Power Brick, and not through the 5 V CAN bus output of the flight controller. For the OreoLEDs the power consumption is even more critical; in my case e.g. 20 LEDs (five on each arm) need to be powered. Thus, here I have added a separate 5 V switching regulator directly powered by the battery (connected of course after the UC4H Power Brick). The general-purpose UC4H node is prepared for that, and makes this most easy.
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 „-4bl“ or „-wobl“ in their name.
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, since ArduPilot doesn’t offer any such means.
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 side 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 (all credits to Pavel!).
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, as usual, the UC4H SLCAN adapter can be build using cheaply available standard components. For instance, In addition to the bluepill and CAN transceiver module mentioned in the above, at $1.80 and $1.89, I bought this 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.
Build Information, more Details
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.
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
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:
The UC4H Power Brick can also be build following the DIY approach, which is however more cumbersome, and no suggestion is made here. The voltage and current measurement stage assumes this:
Go to the Github repository: github repository.