Using UAVCAN for modular UAV electronics, or how not to burn a drone by confusing wires

Hello! My name is Roman Fedorenko, I am an associate professor at the NTI Competence Center in the direction of “Technologies of Robotics and Mechatronics Components” at the Innopolis University. I work with a robotics team that specializes in unmanned aerial vehicles. For the most part, we focus on “high-level” UAV control: traffic planning, obstacle avoidance, filming and terrain scanning solutions. Although we also assembled our own small copters and worked with hardware. Last year, we began development of a large vertical takeoff and landing aircraft, which includes all levels – from the manufacture of the carrier to the mounting of sensors and intelligent control. And when developing this project, we got acquainted with UAVCAN…

UAVCAN is an open lightweight protocol for the on-board mobile network. Recently its developer and maintainer Pavel Kirienko Spym spoke about the protocol at PX4 Developer Summit, a major conference for the drone development community using the open-source ecosystem around autopilot PX4of which UAVCAN is a part. And Pavel prepared a detailed article for the Russian-speaking community on Habré following his report.

In this article I will talk about the practical side of using the protocol from the standpoint of developers of automatic control systems for UAVs: how we chose UAVCAN, what we do with it, and what opportunities we see in the future.

Hybrid UAVs

A vertical take-off and landing (VTOL) aircraft is a hybrid of a copter and an aircraft that can last longer than a copter due to the aerodynamic lift of the wing and does not require a runway or a launcher and a parachute like conventional aircraft drones. The development of such devices is now a popular and promising direction. Such a device can be used for delivery, mapping, monitoring and other purposes. Most flying taxi projects are based on the same design principle, for example:

German company Lilium Jet fully electric air taxi Lilium;
low-noise electric plane Heaviside Kitty Hawk by Sebastian Thrun (known to many for his self-driving cars);
project Vahana from Airbus.

Innopolis VTOL plane
Vertical take-off and landing aircraft of Innopolis University

We have developed three models of small drones with different wingspan, payload and power sources – all electric and with internal combustion engines. We cooperate with the Kazan Aviation Institute and aviation enterprises of Kazan on aircraft designs, and the focus of our work is electronics, algorithms and automatic control.

What does UAVCAN have to do with it?

For those in the drone business, a typical control structure looks something like this:

Typical UAV layout based on the PX4 autopilot. Source

The motors are controlled by speed controllers (ESC), to which setpoints from the autopilot are supplied via PWM (PWM) signals. Sensors are connected via a bunch of different interfaces – UART, I2C, SPI. Plus telemetry, remote control, power supply – and you get such a “spider” from wires. But this is not the main problem.

The longer the wires, that is, the larger the apparatus, the more this circuit is susceptible to pickups. We had to think about this from the very beginning, because our aircraft have a wingspan of 2 and 4 meters, and this is not the limit.

Previously, for the project of a 40-meter airship, we worked with CAN (only the protocol was based on CANOpen). And the decision to use UAVCAN for us was a matter of course: PX4 already has its support, even no disputes in the team about this have arisen. Initially, we wanted to replace the long PWM lines with a digital interface in order to scale our solutions to aircraft with different wingspan.

It turns out that UAVCAN is not CAN for UAV

Earlier we perceived UAVCAN as CAN for UAV (UAV). It may have been so initially, but now it is positioned as Uncomplicated Application-level Vehicular Communication And Networking and is not tied to either UAV or CAN, but is used on a number of moving objects and over different interfaces. There is even sentence about using UAVCAN as middleware for ROS (Robot Operating System). But more about this in the article from the creator of the protocol.

By replacing PWM connections with UAVCAN connections, we have stopped worrying about long wires and noise issues, and we have significantly reduced the number of autopilot connections.

There were two options for how to do this. The first is to use motor governors and servo drives with UAVCAN interface. There are, for example, Zubax… The second is to make UAVCAN adapters that are installed directly next to the ESC. We went for the second option, because the choice of ESC with UAVCAN interface is small. First, we used adapters from the UAVCAN for Hobbyists project (UC4H), then they decided to make their own devices with a built-in DC-DC converter, their own circuitry, firmware and boring diodes.

Innopolis UAVCAN devices
Our devices with UAVCAN interface

Got the taste

Then we realized that instead of a dozen wires, we could use the UAVCAN bus to interact not only with actuators, but also with most external devices. It also has a good effect on the vibration isolation of the controller installed on a special platform. As a result, we developed a number of devices for our own use, but now we see that they are interesting to others:

Converter CAN-PWM up to 4 channels: the device is connected to the CAN bus, receives and processes control signals, outputs PWM. You can power the board directly from the battery up to 60 V, it includes a DC-DC converter that provides the board and the consumer with a voltage of 5 V (3 A) (for example, a servo machine);
GPS / Magnetometer / Barometer;
Power Board, Power Management Unit (PMU): Provides connection of multiple batteries (in parallel or in series as required). The device is connected in series with the entire power load and ensures its commutation. The design includes voltage and current sensors for the battery, a DC-DC converter to provide power to the autopilot. Such a board is designed for high currents up to 1000 A. In the development, a CAN device as part of the board gives information about voltage and current;
Laser altimeter;
Airspeed sensor;
Fuel level sensor;

Technically, these devices are based on the STM32 microcontroller. We design ourselves, and order production at pcbway.ru. Firmware is implemented using libcanard…

Our feeling for working with UAVCAN is a fairly low entry threshold. It took the new employee less than a week to figure out and program the distance sensor on both the STM32 and PX4 autopilot sides.

We test new devices on a small dark drone

And then we use it on the plane:

A short video of a test flight of our VTOL aircraft in all modes

Organization of flights

By the way, in the Republic of Tatarstan there is Association pilotsallowing registration of drone pilots and obtaining permission to fly with the push of a button. They also help us out of friendship.

It’s even possible to get permission here fly over the Kazan Kremlin.

As a result, the scheme looks like this:

Diagram of our VTOL aircraft using UAVCAN sensors and actuators

What advantages UAVCAN will give us in the future

Reservation

The most important task in the implementation of a product based on an UAV is to ensure reliability. We have already started working on this. For example, several of our GPS and airspeed sensors can be connected and used in parallel. But there is still much to be done. Most likely, duplicating sensors and controllers using the CAN bus will be made easier. You can connect two buses to Pixhawk, and leave several identical sensors on the bus for redundancy.

Scaling

In the future, we want to make large vehicles with a take-off weight of more than 30 kg, although this is difficult to certify. The scalability of the architecture based on UAVCAN makes it possible to build ambitious plans.

True HIL simulation

Now the topic of UAV operation in an urban environment is actively developing – Urban Air Mobility (UAM). To implement UAM tasks, you need to rely more on sensors such as cameras and lidars. Here there is a need to develop and debug intelligent control systems, as well as to increase their reliability. For these purposes, another Innopolis University team is developing the Innopolis Simulator for autonomous moving objects based on Unity 3D for testing, debugging and training.

Innopolis Simulator

For our VTOL aircraft use Innopolis Simulator in conjunction with Gazebo for photorealistic simulation, testing of control and processing of sensor data – lidars and cameras.

Now we are working on our own dynamics simulation module instead of Gazebo with more accurate aerodynamics, as well as on another feature – true HIL simulation (from hardware in the loop, or software and hardware simulation, PAM).

In our solution, all data comes from sensors, and controls to motors and servos are sent via the UAVCAN bus. Why not make a module for simulating these sensors at the same bus level? Instead of devices, we simply connect a computer with a simulator to the controller.
Now HIL simulation in PX4 is done via special HIL_ * messages MAVLINK (telemetry protocol, works over a serial port or UDP / TCP), which imitate sensors and actuators.

Diagram of PX4 operation in HITL mode. Source

Simulation, as it is currently implemented in the PX4, is a separate mode of operation for the flight controller, different from the “combat” flight configuration. We simulate UAVCAN messages directly, ideally the autopilot may not even know what is working in the simulated environment. But I must say that the problem of simulating IMUs, which are inside the autopilot and are not connected via CAN, has not yet been conceptually solved.

Proposed scheme for PX4 operation in HITL mode using UAVCAN

This solution increases the reliability of the debugging results on the simulator, so you can more safely move on to flight tests.

Aviation HIL simulator. Source

A similar approach, when devices are simulated at the interface level, used by and in large aviation, but with UAVCAN we make it more accessible and easier.

Output

It’s great that the issues of lightness, reliability and “realtime” of the UAVCAN protocol have already been thought for us, as well as the fact that there are PX4, ROS and Linux, in the end. It would be very difficult for us to make our copters, airplanes, control systems and planners if all this was not there.

Standardization of protocols and software enables developers to speak the same language. At the same time, not only standardization is important, but also accessibility, which to a high degree provides an open-source approach. This allows, standing on the shoulders of giants, to quickly move on to their tasks, and not first build a long “infrastructure” for work, which, I hope, we have shown with our example in this article.

We drink cold brue after successful flights