Homemade Autopilot on a Single Board Computer (SBC) Tinker board and Arduino DUE

The idea of ​​building an autopilot came about 2 years ago. I wanted to create a fully autonomous apparatus capable of getting from point A to point B with the possibility of avoiding collisions and flying around obstacles, able to overcome jamming zones or the absence of a satellite signal. I also wanted to have a convenient and simple control with the mouse as it is implemented in games (strategies) controlling the movement of the aircraft with the help of points. I had to start everything from scratch, like this article, so if there are errors, write about it in the comments. I'll start in order.

Hardware

Initially, I did not know which iron is better to use for this project, but in the end I came to the conclusion that the best option would be a bunch of microcontroller (MK) + single-board computer. Where MK solves the problem of stabilization of an aircraft (LA), its movement at a given course and altitude, and a single-board computer solves the problem of navigation and movement along a route. Since the plan was to avoid collisions, the computer had to be powerful enough to process information from obstacle detection sensors, compact and not too expensive at that time TinkerBoard was the most suitable for this description, then Raspbery was 3B + and was much inferior in characteristics. As MK, I wanted to have an arduino compatible controller because arduino had a huge base of ready-made sketches and therefore the choice fell on DUE 84 MHz, 32bit ARM Cortex-M3 becausehe was the most powerful and had to compensate for the directness of my hands)).

Initially, I planned to use the MPU 9250 with a Majevik filter as orientation sensors, and its results were excellent. The main advantage of this option was that all the calculations, including the calibration of the sensors (accelerometer, gyroscope and magnetometer), were on the MK. But there was a problem, the filter poorly compensated for the linear acceleration, which constantly occurs during shocks or a sharp change of course. This is expressed in the readings of pitch and roll, at the moment of acceleration they begin to float away, and passing through the proportionally differential (PD) regulator and especially the differential part, the floating created problems. Therefore, I had to use a sensor with an already implemented BNO 055 filter.

Unlike the MPU 9250, the BNO has onboard the integrated Cortex M0 MK, which immediately calculates the orientation in Euler angles, the absolute orientation quaternine and calculates linear acceleration, although this sensor also has several disadvantages. The main problem of this sensor is auto-calibration, or rather, that it cannot be turned off, it is such a “fit” of this sensor and this calibration has an unpleasant property to disappear, sometimes absolutely suddenly even just being in one place without movement. This is mainly reflected in the yaw that is attached to the magnetometer in this sensor and should show the direction to the magnetic north pole (course), but sometimes it shows 100 degrees in strona, and then after calibrating it can go back))). In other matters, the course problem can still be solved using synchronization with GPS. Otherwise, the sensor works fine,he always determines the pitch and roll correctly, and linear accelerations do not greatly affect his work, unless, of course, the acceleration does not exceed 2G, because this threshold is used to measure the gravity vector and compensate for the drift of gyroscopes.

The rest of the iron set is as follows: GPS Ublox Neo M8N with USB output,
BMP 280 barometer, HSCR 04 sonar for receiving data on ground availability and more accurate vertical speed, EEPROM 24c16 for storing calibration data and PID settings, Neoway M509E GSM module for sending messages about the coordinates of the aircraft in case of an accident.

The functional diagram is shown in Figure 1:


Figure 1 - Functional diagram of the Autopilot .

Software

For software development, I use QT along with the QT Creator IDE. he is most familiar to me, and also thanks to cross-platform functionality, I can run my programs on both a single-board PC with Debian and a desktop with Windows, which is very convenient. For the development of microcontroller software, the Arduino IDE is used. For clarity, I will try to present all sections in Figure 2.


Figure 2. - Architecture of the AP (BNO 080 added for the future).

1) Graphical control interface - is a satellite map with the help of which the aircraft is controlled. The satellite image display program itself is not mine, it was stolen by me here (its author also tried to do something similar).

You can control the aircraft using dots (markers) or WADS buttons. To control points, it is necessary to lay the flight route with green markers, they are put with the mouse (RMB), and click load route, or use the (red) instant move marker (LMB) and then the aircraft from the current position will fly to this point, for its operation it is necessary to set checkbox in the "Manual" checkbox from accidental clicks.

All marker parameters are entered in the appropriate fields on the form, you can remove the markers by double-clicking the middle mouse button, while they will still remain in the aircraft’s memory, to delete the memory, use the delete route button. Upon reaching the point, as in the strategies of the aircraft, it will revolve around it. Button control WADS directly controls the steering wheels using PD controllers. When each button is pressed, a value is input to the input of the controller, for example, when S is pressed, pitch 30 and when released is 0. When W -30 is pressed, etc. WADS is turned on using checkboxes: “manual”, “buttons”. This mode helps to check the functionality of all the rudders before starting. The graphical interface runs on the laptop, control commands from the graphical interface using the TCP socket are transferred to the kernel. The graphical control interface is shown in Figure 3:


Figure 3 - Graphical management interface.

2) The core of autopilot is that part of the software that is calculated on a TinkerBoard single board computer. The kernel is responsible for navigation and movement along the route. To do this, a GPS sensor is connected to the computer. Using it, you can get the current position of the aircraft (latitude and longitude) and compare this position with what is in the flight route. As a result of this operation, the azimuth to the target is obtained, which is sent to the microcontroller along with the rest of the flight parameters. In the future, the kernel can be equipped with its IMU sensor to implement the ANN. For example, you can use BNO 080 to integrate, accelerate and get speed, and by integrating speed, get the distance. The distance received from the ANN will need to be translated into the GPS coordinate system (latitude and longitude) for its use in calculating the azimuth.

Such ANN can be used in conjunction with a GPS sensor in case of temporary loss of communication with the satellite so that the aircraft does not miss a “turn” to a point. At the time of operation from GPS, the ANN will be constantly adjusted by its readings and fill in the gaps between the periods of GPS sensor update. In the same way, the machine vision algorithm or SLAM should be adjusted by changing the height of the point and creating biases of the calculated azimuth. After the route calculation is completed, the kernel sends UART data: azimuth, altitude, angle of attack, type of point, and also whether rotation around this point is necessary.

3) The microcontroller performs the core commands, the main task of the MK is to follow the given course at a given height. For this, the MKU is equipped with an IMU BNO 055 sensor, a bmp 280 barometer and a sonar. For movement along the course, the azimuth obtained from the core is used, it is compared with the current rate and the resulting mismatch is transmitted to the PD controllers for yaw and roll. Pitch control is carried out by 2 PD controllers: the 1st determines the mismatch of the current and predetermined heights, which is fed to the input of the 2nd controller, while the output of the height controller is limited by the current angle of attack to control its set. If in the graphical interface the type of point is selected for takeoff or landing, a sonar is used to determine the height. His testimony is combined with the data of the barometer,to most accurately determine the distance to the ground and the vertical speed. In addition to the main functions, the MK also collects telemetry about the operation of IMU sensors, the current direction and altitude, transfers them to the kernel, where these data are supplemented by data from GPS and enter the graphical interface.

Conclusion

At the moment, the autopilot is still at the flight test stage and is not fully configured. However, I spent only two starts and have not yet picked up the coefficients for the regulators.

In general, PD regulators seem unstable to me and I want to replace them with something more reliable, especially since they are already outdated. It is also necessary to replace calculations with Euler angles with calculations in quaternions, because the latter behave more stably when turning the aircraft at angles greater than 120 degrees and flying during the wind.

A more detailed shot of avionics

Link to the source code of the poison (with libraries) Github here only the source but newer