Want to know about the latest development? … 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) further 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-Barometer
- UC4H PowerBrick
- UC4H ESC-Actuator
- UC4H UartBridge
- UC4H Air/Airspeed
- UC4H Notifiers: Notify, Display, OreoLEDs
- UC4H IndicatorLED
- UC4H FunThing
- UC4H Bootloader
- UC4H 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. The chapter Supported UAVCAN Messages may also be of interest.
You also can buy UC4H boards from jDrones and at the same time donate to the ArduPilot project.
For the latest developments in the UC4H project please inspect the UC4H Blog.
- UC4H Github repository, hosting the firmware binaries, Eagle design files, and some more material.
- jDrones UAVCAN and UC4H Wiki
First user demonstrating a successful flight using UC4H components:
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.
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 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.
This is a fork of ArduCopter 3.6.x, 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.x (you need the 'u' version, e.g. BetaCopter 3.6.1 v0.14u, see the git 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 „feature matrix“ thus looks like this:
|dual UAVCAN GPS||–||x|
|ESC Telemetry (DataFlash, BattMonitor, MAVLink)||–||x|
|Actuator (= Servo)||x||x|
|UART Tunnels||–||3 x|
(1) The UC4H Airspeed sensor is experimental, and 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.
General Building Information
Building the UC4H nodes is not very difficult, and generally two approaches are available:
For all nodes I have designed suitable PCBs, which allow nice and convenient builds. Most of the nodes can be realized using the General-purpose UC4H Node, such as the GPS-Magnetometer-Barometer, ESC-Actuator, UartBridge, FunThing, Notify, Display, OreoLED, and IndicatorLED nodes. For the UC4H PowerBrick node and the UC4H SLCAN adapter dedicated PCBs are available. Dedicated UC4H ESC KISS carrier boards were also designed, which are the recommended ESC nodes.
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 about practicing it.
The „1st generation“ versions of these PCBs all provide a fuse & diode protection in accordance with the standard. In addition, they use the TJA1051 CAN transceiver, a so-called 3rd generation CAN transceiver, with state-of-the-art protection and reliability features. These chips can however 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 such things appear to happen. 🙂 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. An example is the 2nd generation General-purpose UC4H Node shown in the above picture, but also the UC4H PowerBrick and UC4H ESC KISS Carrier boards have been reworked already.
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 PowerBrick, 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-Barometer Node
This had been the very first UC4H node, introduced in early 2017, starting off as the UC4H GPS-Magnetometer node. In the meantime it however has seen the addition of the tunnel, indicator LED, and barometer, and is now referred to as the UC4H GPS-Magnetometer-Barometer node. So, if you find a UC4H GPS-Magnetometer being mentioned somewhere, it is this node here. 🙂
The UC4H GPS-Magnetometer-Barometer 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.
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.
The UC4H GPS-Magnetometer-Barometer node also allows us to connect a barometer module, such as a BMP280 or MS5611 module. Furthermore, it comes bundled with the UC4H IndicatorLED node. This allows us to build a GPS and magnetometer and barometer unit with LED indication lights. How cool is that. 🙂
The UC4H GPS-Magnetometer-Barometer firmware can be configured, by setting of a parameter, to behave as a UC4H GPS, UC4H Magnetometer, or UC4H Barometer node, or any combination thereof. For instance, it can become a UC4H GPS-Magnetometer node. This configurability is very useful in case you have several of them in your system – which is quite likely, 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. It also shows a connection diagram for the Hobbyking GPS and magnetometer module:
The UC4H GPS-Magnetometer-Barometer 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:
Node Configuration Parameter
As mentioned, the node can be configured to present itself in different ways. The parameter which controls this is „Node Configuration“: It is a bitmask, where bit 0 enables the GPS functionality, bit 1 the magnetometer functionality, and bit 2 the barometer functionality:
1 = 0b001 = GPS
2 = 0b010 = magnetometer
4 = 0b100 = barometer
Per default its value is zero (= all enabled), and the node presents itself as UC4H GPS-Magnetometer-Barometer node, and all parameter fields are accessible. If this parameter is set to e.g. 3 = 1 + 2 = 0b011, the node presents itself as a UC4H GPS-Magnetometer node, and all parameter fields which are related to the barometer functionality are hidden and cannot be accessed. If the node should become a UC4H barometer node, a value of 4 would be written, and all parameter fields related to the GPS and magnetometer functionalities would be hidden. In order to get back to the default, just do an ERASE. Configuration changes need a restart of the node to become effective.
Screenshots of the parameters of the node in different configurations can be found here:
Generally, the health status becomes ERROR or CRITICAL only during start up, if a senor is not detected, but it does not change during operation. The heartbeat LED blinks fast if the health status is not OK. The conditions which lead to an error are:
* If MagneticFieldRate > 0 and if a magnetometer module could not be found during startup, then: ERROR
* If BaroRate > 0 and if a barometer module could not be found during startup, then: ERROR
* The handling of a GPS is different: If the tunnel is not activated (Uart1 ChannelID = -1), then the node waits until it detects a GPS, which is indicated by a mode INITIALIZATION. Once the GPS is detected and configured the mode will change to OPERATIONAL. Thus, if a GPS module cannot be found, this won’t raise an ERROR, but makes the node to stay in INITIALIZATION for indefinite.
The UC4H PowerBrick 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 PowerBrick 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 PowerBrick this is overcome by using an extra LDO regulator for sourcing the ACS7xx sensor, ensuring most precise current measurement.
- Precise Charge and Energy Calculation: This is another unique feature. Since the UC4H PowerBrick has its own microcontroller, it can determine the consumed charge (mAh) and consumed energy (Wh) 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 PowerBrick in permanent operation in my development 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 PowerBrick, 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 PowerBrick to test its solid working, then you can find some reported here.
The UC4H PowerBrick emits the UC4H-specific uavcan.olliw.uc4h.GenericBatteryInfo message. It can be configured to emit the standard data type uavcan.equipment.power.BatteryInfo for compatibility reasons, but this is really not recommended since it deprives the UC4H PowerBrick of its best features.
UC4H ESC-Actuator Node
The UC4H ESC-Actuator node provides PWM or DSHOT signals for connecting ESCs and 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 or the uavcan.equipment.actuator.ArrayCommand data types, depending on the configuration of the output channels.
A major feature of the node, for the channels configured as ESC output, is to provide telemetry data about the status of the connected motors to the flight controller. For each enabled ESC 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. Furthermore, the telemetry data is used to feed a battery monitor, which provides additional data for checking the status of the power train.
As another great feature, the node comes with UC4H OreoLEDs support integrated, i.e. can drive the OreoLED strip of the arm associated with the ESC. This really makes it easy to add lightning to the copter with an unprecedented clean build.
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.
- OreoLEDs: It never was easier to build a copter with cool lightning.
The node has been extensively tested on the bench, and also has passed flight tests in both my development copter and a 3DR Solo (see here, here, and here). In both copters I do have them in routine operation for many months now.
The node can be build in several ways. For ESCs, my clear favorite is the UC4H ESC KISS Carrier board, which is now also available in 2nd generation. The board is designed for carrying KISS 32A or 24A ESCs. I really like it and just can recommend it; IMHO the best option available. Also, the general-purpose UC4H node can be used, which then provides all six outputs, plus telemetry, plus OreoLED, depending on parameter settings. Furthermore, I have designed a UC4H ESC Mini PCB, which is only 21×14 mm in size, and which supports up to two ESCs (with 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. Lastly, as usual, the node can be build using the CAN transceiver and STM32F103 development boards mentioned in previous chapters. A scheme is shown below.
A brief description of the parameters of the node, and other info relevant for using and building the node, can be found here: https://www.rcgroups.com/forums/showpost.php?p=39144246&postcount=509
A screenshot of the parameters of the node can be found here:
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 UartBridge Node
The UC4H UartBridge 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 UartBridge 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 report back some information about the status of the ArduPilot flight controller, but are not must haves. I am however liking them a lot. 🙂
The UC4H Notifier nodes work by listening to the UC4H-specif message uavcan.olliw.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.
The firmware for the UC4H Notify and Display node comes bundled with the UC4H IndicatorLED node.
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 PowerBrick, 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 PowerBrick). The general-purpose UC4H node is prepared for that, and makes this most easy.
The UC4H IndicatorLED node also reports back some information about the status of the ArduPilot flight controller, like the UC4H Notifier nodes. However, in contrast, it listens to the uavcan.equipment.indication.LightsCommand standard data type, which is emitted by ArduPilot (with light_id = 0). It works like any other RGB LED which ArduPilot uses as indicator LED.
The UC4H IndicatorLED node actually doesn’t come stand alone, i.e., there is no dedicated firmware for it. Instead it is bundled with other nodes, that is it is integrated into the UC4H GPS-Magnetometer-Barometer and the UC4H Notify and Display nodes.
This allows supercool builds, such as a GPS and magnetometer unit, which also has LED indicator lights.
The UC4H FunThing node doesn’t really serve a purpose in the sense that you ever would install it on your vehicle. Its main use is to have a thing to play with when you’re starting to get into the UAVCAN world. It can also be used for some level of testing or developping.
In more detail: The UC4H FunThing node allows you to connect two potentiometers and a button, and to configure it to emit various UAVCAN messages those fields are filled with values derived from the ADC readings of the potis and the button state.
The node supports emitting a large number of messages, which includes the ESC, actuator, magnetometer, barometer, airspeed, battery and tunnel messages, as well as the UC4H-specific GenericBatteryInfo and STorM32 gimbal UAVCAN messages. For the complete list check out the chapter Supported UAVCAN Messages: UC4H FunThing. So, by connecting the UC4H FunThing you can observe these messages using a SLCAN adapter and the UAVCAN GUI Tool, and e.g. plot their field value. You also can use the UC4H FunThing to actually control things such as two ESCs, two servos, or a STorM32 gimbal by UAVCAN, to name some examples. Obviously, for controlling ESCs or servos, the UC4H Esc-Actuator node would be a natural counterpart.
As always, also this node can be build using the DIY approach. The firmware is however targeted at the general-purpose UC4H node, which thus provides the best option.
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 vehicle, 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 normally flash firmware, i.e., by using a ST-Link and the SWD pins or a USB-TLL adapter and the system bootloader on the UART1 pins. 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 be upgraded using e.g. the UAVCAN GUI Tool. It is not super-convenient for this purpose (and slightly buggy), but is sufficiently convenient to be useful. Attention needs to be paid to which firmware is flashed: The UC4H Bootlader enabled firmwares have a „-4bl“ in their name; the regular firmwares won’t work (but don’t worry, it won’t crash the bootloading capability).
Lastly, it probably should be mentioned that the UC4H Bootloader is not a general-purpose UAVCAN bootloader. For instance, it wouldn’t work with non-UC4H firmwares. This is so because of the somewhat unique needs for UC4H nodes.
UC4H SLCAN Adapter
The SLCAN adapter is an indispensable tool for checking and debugging the proper functioning of a UAVCAN network. Currently it is also absolutely 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 chapter Build Information.
Build Information, more Details
Building the UC4H nodes is not very difficult. 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.
Screenshots of the parameter list can be found for each node in the UC4H github repo:
Note that the bootloader’s Node ID is 0 by default, that is, the dynamic node id allocation server in the UAVCAN GUI Tool must be activated in order for the node to show up! It is generally recommended to always enable the dynamic node id allocation server. Without it the UAVCAN GUI Tool is not always reflecting what’s going on on the CAN bus, which sometimes can be quite confusing.
GPS Mag Baro Node
For the GPS it is highly recommended that the UAVCAN tunnel is used (Uart1 ChannelId >= 0), and not the UAVCAN uavcan.equipment.gnss.Fix message (this requires using BetaCopter). Using the latter works fine (I flew with it for a year or so 😉 ), but it is somewhat clumsy. I stopped developing it further once I saw that the tunnel approach is going to come. It’s (only) advantage is compatibility with current ArduPilot. If it shall be used, please note: The GPS needs to be configured to 115200 bps by hand, using e.g. the ublox software tool. Description of how to do that can be found in e.g. the rcgroups discussion thread.
General-Purpose UC4H Board v2
The usage of the pins of the General-Purpose UC4H Board v2 by the various firmwares is as follows:
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 UC4H-specific uavcan.olliw.uc4h.GenericBatteryInfo and uavcan.olliw.uc4h.Notify messages used by the UC4H PowerBrick and UC4H Notifier nodes, as well as the STorM32 UAVCAN messages, are not part of the standard set. They thus need to be made aware to the tool by copying the message definition files to a particular folder: Move the folder „olliw“ with the .uavcan dsdl definition files to the folder „C:\Program Files (x86)\UAVCAN\UAVCAN GUI Tool\uavcan\dsdl_files\uavcan\equipment\power“. Now, after a restart, the UAVCAN GUI tool should show the new messages in e.g. the bus monitor, and not display „unknown“.
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.
DIY SLCAN Adapter
USB-TTL adapters often use the CP2102 chip, like the one suggested in the above. The SLCAN firmware works with a baud rate of 1000000 bps, which the CP2102 does not handle by default. It must be configured to it. The procedure is however simple, see here. Note: This does not apply to the newer CP2102N chips, as they are used e.g. on the UC4H SLCAN adapter PCB; these do handle 1000000 bps out of the box.
It is important to solder the battery wires appropriately to the module; the PCB traces shall not carry high currents. This figure may help:
The UC4H PowerBrick 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 scheme:
Go to the Github repository: github repository.
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
UC4H Notifiers: Notify, Display, OreoLEDs