Flying robot to the competition and a bunch of rake with him

Platform

Last year we announced a contest for flying robots with a prize of one million rubles. The task would seem simple - take off, go around an obstacle and sit on the landing marker. The obstacle and the marker are shifted from task to task. The robot flies by itself, without commands from the ground (more precisely, it takes only two: "start" and "emergency shutdown").

At the time of the competition, our team of engineers and programmers from the department of information technology has never been involved in the development of UAVs. But we decided to buy our robot and participate in the competition on a par with everyone. More precisely, not quite on a par - we will not be able to take a medal place or receive a prize according to the conditions, that is, we go beyond the standings.
')
The first time we took the robot in the hands in the summer of 2012, when the package arrived from a Belgian online store. By the way, we were lucky - the robot was only 3 weeks old. Part of the teams withdrew from the competition due to the fact that their platforms did not have time to arrive.

It was the first and last luck in the preparation. From this moment began the history of a rake several months long.

At first, everything looked just

Polygon layout

So, the first task is just to take off and hover at one point. That is, you need to try so that the robot does not fall, does not fly up and does not scour. The second is, in fact, a journey through the maze, so as not to bump into the wall. The third is recognition. All these tasks can, one way or another, be solved separately. And a bunch of auxiliary tasks like filtering data from sensors (for example, due to the inconstancy of lighting conditions and various flooring textures).

At the same time, the high-level algorithms of the robot are most important to us, therefore, it was allowed to use a number of ready-made libraries and platforms: for example, not to write pattern recognition from scratch and a system for stabilizing a multi-rotor platform in space.

So, from the moment we opened the package, the tricky R & D began . There is a person in the team with a wealth of experience in managing quadrocopters, but nobody wrote software to manage them. Therefore, we began to thoroughly understand everything from scratch. I had to read a number of books and articles. Remember what we were taught 10 years ago at the university, to understand the physics of flight.

It must be said that the platform we initially acquired is rather “stupid,” that is, for example, it does not know how to stabilize itself horizontally. We worked out most of the algorithms ourselves. Now we already know how to hang, move, fly around obstacles. But we fly while we slowly and carefully, about 30 centimeters per second. We are working on this, because the robot that wins the task in the shortest time wins the competition, so we must be an example to the other participants.

Surprisingly, the easiest part was the mathematics of obstacle avoidance and the construction of the robot's trajectory. At least, so far it seems to us.

About sensors

For orientation in space, we allowed the use of a GPS signal, but we ourselves proceeded from the fact that the drone can be used in closed spaces or in the absence of a GPS signal. Therefore, in our robot there are other sensors. Fortunately, we, as representatives of one of the largest IT companies in Russia, can afford it.

Another limitation that we have introduced for ourselves is that all the computing power must be on the robot itself (under the terms of the competition, you can use an autonomous computing unit mounted not on the platform itself). We used Intel NUC, it weighs only 200 grams.


Intel NUC

Our laser rangefinder (more precisely, the lidar) on the passport hits 30 meters. That is, if the robot is at the beginning of the polygon, then it can “see” the far wall. This allows you to accurately understand where we are now. In theory. In practice, the lidar hits only 10 meters, because the data for the passport was written almost in the conditions of perfect reflection of the beam from the walls. In reality, with our covers now there are "blind zones". Therefore, the original plan with the fact that we always see the entire "box" of the landfill now does not work, and we need to somehow measure the current speed. For example, on the principle of optic flow, that is, using a sensor that looks down at the floor (as in a mouse).

The appearance of the robot from below and above somewhere in the middle of development:




And this is how the platform looks like on the website of the Belgian microcopter online store:


Adding new sensors is a lot of work . First, you need to look at the firmware. Then it is necessary to carry out field tests, which often result in structural failure. It may take several days to restore it. For example, when we tested a downward ultrasound sonar in a robot, the algorithm for hanging in place failed, and we got a bunch of curved iron instead of a flying platform. Why? Because sonars can be "deaf" or return data with an unacceptable delay. There are sonars that work well in the office, but do not work well on asphalt or other surfaces, and so on.

We went over six sonars. The first time we tested the retention solution in the office. Then they went outside and realized that the sonar on the street of the earth no longer sees. Then we started screwing the optic flow sensor, and it also has a sonar. So, we have to throw out the old sonar.

Or landing. After our robot flies through the gate (obstacle), the image from the camera begins to be analyzed for the search for a landing marker. As soon as the marker is in the picture - it is necessary to solve the geometrical problem and give the robot coordinates for landing. And then there are more tests: somewhere the error of the sensors interferes, somewhere we incorrectly take into account the mathematics, somewhere the iron fails and so on.

Tests

To test the algorithms, we use the gazebo simulator, in which we created a fairly accurate model of our kopter and sensors, and also recreated the polygon model. As for the real tests, at first we flew in a room about 10 by 10 meters. To do this, it was necessary to do everything neatly and accurately, because: a flying robot in such a small space can make a lot of things. There he held a position with us with an accuracy of 10 centimeters.

After that, we made a copy of the competitive testing ground on the roof of the KROK main office parking lot, and we already started checking the robot in “combat” conditions.

If we learn to quickly go through the maze - we can ease the robot by replacing the battery with a less capacious and therefore lighter. This will facilitate the design - now it weighs 2.3 kilograms, and this is already the limit for comfortable control.

About iron

Our platform is the Mikrokoper quadro XL. Here is the original hardware layout:



The scheme was eventually changed from the originally planned. For example, we assumed that one battery would, in fact, be on the flying structure itself (on motors), and one battery would be used to power the sensors and the computer. Now it is combined in one battery. Plus, as I said, the sonar model has changed. Rather, instead of a sonar, there was another motherboard, the Px4flow, which already includes the sonar. While we are optimistic about her. Perhaps the accelerometer will be added to the circuit.

In the first scheme, we planned a calculator based on ARM processors. But then we stopped on the software architecture based on the ROS Framework (Robot Operating System). This Framework has rather strict requirements for operating systems, they guarantee certain functions only on certain versions of the Ubuntu system based on Linux. And not all ARMovskie computers this system is installed cloudless, so to speak. NUC weighs more, and eats more food, but on it everything goes fine. It saved us a lot of time. Some of the teams also tried it.

Here is the actual software architecture:

Polygon

There were many problems with the fact that the main peak of the tests of the robot came in the winter. And for us on an open platform to land in a snowdrift is not the most desirable situation. Even shook the film.

When we built the test site, we had plywood walls with film (something like laminate), and everything went smoothly on it. But it was enough to paint them - and that was all, the accuracy of the sensors dropped sharply due to a drop in the reflectivity of the material.

The other robot came to us from Belgium the other day. We will need it as a reserve for the competition, if something happens to the first one.

Video

We shoot videos of everything that happens during test flights and post it on YouTube.

Here you can see how we test the robot in strong wind conditions:


Here is an old video from the time when we flew in a small room:


And here is a small sketch from the simulator - a test for speed limit:


This can also be interesting:

Other commands

The first teams began to fall off at the very beginning due to delivery problems. The next significant dropout was in April-May, when the teams trivially smashed their models. And it is very disappointing, when there are already developments, there is an understanding of how to solve problems, there are two thousand lines of written code. They wrote how sorry it was to throw it all away.

There are teams that fly on the standard AR.Drone. On AR.Drone there are sonars and two cameras: a front HD and a low-resolution camera that looks vertically down. That is, in principle, you can do everything as needed, but the task will be quite complex algorithmically. You can, of course, put the robot nose to the landing marker and solve the problem of finding a marker directly below him. But it is necessary to intervene and everything will fail.

There are guys who do not use any ready-made platform. It is possible that they poisoned part of the schemes themselves.

There are teams that are far from programming, but they have a 20-year experience in aircraft modeling, they have been doing this since the days of the Soviet Union. Take to yourself the developer, try.

We try to help other teams: we still have good access to the hardware.

Now, at our test site, test flights have already passed within the framework of the competition, and the developers of the UAVs not participating in the battle could come: check out the test site, fly. Now it is flying within the last checkpoint (the last day is July 21) among residents of Moscow and the region. If you participate, just write to robots@croc.ru, we will make a pass. I advise you to hurry with the record, in the days from Thursday to Sunday is already a stir.