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 of 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: movement 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 fabrication of the carrier to the mounting of sensors and intelligent control. And while 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 KirienkoSpymtalked about the protocol at the PX4 Developer Summit , a major drone community conference using the open-source ecosystem around the PX4 autopilot , of which UAVCAN is a part. And Pavel also prepared a detailed article for the Russian-speaking community on Habré in the wake of 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 airplane that can last longer than a copter due to the aerodynamic lift of the wing and does not require a runway or a launch device 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:

• the all-electric air taxi Lilium Jet of the German company Lilium ;
  
  
• the low-noise Heaviside electric aircraft of the Kitty Hawk company by Sebastian Trun (whom many know from unmanned vehicles);
  
  
• Airbus' Vahana project .
  
  

Vertical take-off and landing aircraft of Innopolis University



We have developed three models of small unmanned aerial vehicles 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 PX4 autopilot. Source The



motors are controlled by speed controllers (ESC), to which setpoints from the autopilot are supplied via 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 was a matter of course for us: PX4 already has its support, even there were no disputes in the team about this. Initially, we wanted to replace long PWM lines with a digital interface in order to scale our solutions to aircraft with different wingspan.





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



There were two options for how to do this. The first is to use motor governors and servo drives with UAVCAN interface. Such are, for example, at 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. At first we used adapters of the UAVCAN for Hobbyists ( UC4H ) project , then we decided to make our own devices with a built-in DC-DC converter, our 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. The board can be powered directly from the battery up to 60 V; it includes a DC-DC converter, which provides the board and the consumer with a voltage of 5 V (3 A) (for example, a servo machine);
  
  
• GPS / Magnetometer / Barometer;
  
  
• , Power Management Unit (PMU): ( ). . — , DC-DC . 1000 . CAN ;
  
  
• ;
  
  
• ;
  
  
• ;
  
  

Technically, these devices are based on the STM32 microcontroller. We design ourselves, and order production at pcbway.ru. The 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 them on an airplane:





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





As a result, our scheme looks like this: Scheme of our VTOL aircraft using UAVCAN sensors and actuators

What advantages UAVCAN will give us in the future

Reservation

The most important task when selling 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 takeoff weight of more than 30 kg, although this is difficult to certify. The scalability of the architecture based on UAVCAN allows you to make ambitious plans.

True HIL simulation

Now the topic of UAV operation in the 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 it becomes necessary 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 , we use the Innopolis Simulator in conjunction with Gazebo for photorealistic simulation , control testing 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? It's just that instead of devices, we connect a computer with a simulator to the controller.



Now HIL simulation in PX4 is done using special HIL_ * messages MAVLINK (telemetry protocol, works on a serial port or UDP / TCP), which simulate 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. The proposed scheme of PX4 operation in HITL mode using UAVCAN This solution increases the reliability of the debugging results on the simulator, so you can more safely proceed to flight tests. Aviation HIL simulator. Source A similar approach, when devices are simulated at the interface level,



















used 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 what PX4, ROS and Linux are, 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, rather than building a long "infrastructure" for work, which, I hope, we have shown with our example in this article. 





We drink cold brue after successful flights