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.
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.
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.
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.
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
As a result, the scheme looks like this:
What advantages UAVCAN will give us in the future
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.
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.
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.
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.
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