History of participation in the contest "Flying Robots". Part 1
In 2013, in order to popularize robotics in Russia and create an environment for programmers and engineers oriented on this topic, CROC (Moscow) organized a competition called “Flying Robots”. Our iKar team (3 people from Barnaul and 1 from Moscow) participated in 2013 (the competition “Fly away and return”) and in 2014 (“Catch up and overtake Krok”) did not win, but achieved good results.
1. How it all started or the conditions of the competition
Being a 1C programmer by profession, one often has to use the forum.mista.ru forum. One of my fellow friends was the first to notice an ad on "To Lemon" and offered to participate.
The conditions of the competition looked attractive: it was necessary to build or buy a flying robot and teach it how to move / navigate in the training ground, automatically take off and land, and recognize landing markers. The term for all the work is 1 year, and the prize is 1 million rubles.
There was experience in the construction of helicopters and quadrocopters, both for hobbies and for professional use in aerial photography. There were a lot of questions about various settings, PID coefficients, code, and flight controller algorithms. Using the motivation of the competition, one could deeply understand everything.
Since childhood, it was a dream to engage in robotics, participation in the competition allowed us to take the first steps in this direction. Belief in one's own strengths, a “just” cause and a “tasty” prize, did their job, the entire family budget, plus available credit funds, were used to build a “budget” drone robot and travel to Moscow for the contest.
2. The choice of aircraft platform
As an aircraft (LA) it was possible to use:
1) a ready-made drone, for example, “AR.Drone”, which already knows how to fly and a lot of buns, of the minuses:
- low iron performance;
- low carrying capacity.
2) Build your own aircraft of the required carrying capacity and with the necessary flight time.
The second point was not in doubt, a hexacopter (6-motor copter) with an estimated carrying capacity of 2 kg and an estimated time of 20 minutes when loaded with a camera and the necessary electronics was an excellent option. For tests, it was decided to make a small quadrocopter - “whipping boy”.
Hexacopter based on the Tarot-680 frame Quadcopter
Particular attention was paid to the issue of security - all copters were equipped with screw protection. Thus, after a collision with a wall or in a fall, everything remained intact. This saved money and repair time.
3. The electric circuit of the drone 2013
To solve the task more quickly and reduce labor costs, it was decided to build a drone from ready-made modules than, for example, to do everything on the basis of a single-board computer that would perform all the calculations. So, for example, you can buy a flight controller that can keep the aircraft in the horizon and stabilize the flight, and control using another device (microcontroller, computer) - an autopilot that receives data from sensors, and a radio modem (more on that later), and transmit commands to the flight controller for moving forward, backward, etc. The autopilot also does all the intellectual work (navigation, etc.).
Since analyzing the image (determining landing markers) is a rather demanding task, the calculations should be performed either on board on a sufficiently powerful microcomputer, or the analysis should be performed outside the drone at the base station (laptop), and the image from the drone should be transmitted to the base station via Wifi, or via analog video transmitter. Thus, by recognizing markers, we obtained the following scheme (with an analog video
transmitter ): 1) the image from the video camera from the aircraft was transmitted through the video transmitter;
2) was received by a video receiver at a base station;
3) the analog video signal was sent to the laptop via video capture (VIDEO-> USB);
4) on a laptop, the image was recognized using the program (OpenCV);
5) the screen coordinates of the “seen” marker (X, Y) were transmitted via the radio modem to the autopilot;
6) based on the received screen coordinates, the autopilot determined the location of the landing site marker relative to the drone and made a decision about landing or navigation for landing.
Aircraft electrical diagram 2013
4. Choose a flight controller
A flight controller was available - MultiWii ALL-IN-ONE; was removed from an existing FPV quadrocopter:
According to flight characteristics, this flight controller is not bad with manual control, but it is significantly inferior in stabilization quality to professional controllers with more powerful hardware and mathematics.
When using for a robot with standard firmware, it was not possible to configure MultiWii, because the firmware was adjusted.
Using professional controllers with open firmware such as OpenPilot or PixHawk for a project would be more reasonable, but at that time it was impossible.
5. Select sensors
For orientation in space it was necessary to choose sensors for the drone.
List of choices:
Among the affordable sensors and ease of use were ultrasonic sonars and IR sensors. Since the budget ultrasonic range was greater (up to 4.5 meters) than the IR (up to 1.5 meters), they were chosen as the main sensors for the drone.
A total of 5 pieces were required: 1 sonar was directed down to hold the height, and 4 pieces. around the perimeter for orientation from the walls.
I had to study ultrasound sensors well in order to make them work correctly. For a deeper and safer study, a ground-based robot tank with a sonar installed was built. The tank kept a predetermined distance to an obstacle, for example, a piece of paper that could be moved, and the robot moved behind it itself. The data was logged and then it was not difficult to analyze them and determine the nuances.
Ultrasonic sonars can be classified by various characteristics, such as effective angle (radiation pattern), distance measurement range, and so on. Moreover, the quality of measurement greatly depends on various characteristics of the sensors. For example, wide-directional sonars work well at large angles of deviation from the surface to which the distance is measured, while narrow-directional ones are lost. Also broadly directed “hit” further (depending on the model) and measure the distance from almost any surface (asphalt, fabric, etc.). But they have a small drawback - the measurement results slightly “jump” in contrast to the narrowly targeted, accordingly, it is necessary to filter the obtained values.
Any sonars demanded "high-quality" nutrition, otherwise their testimonies "jumped" and it was impossible to navigate them. For good nutrition, you need to use power filters or have a separate DC-DC, full recommendations can be found here . After the tank was no longer needed, it turned into a toy. With a camera installed on board (removed the sonar), it was possible to ride around the apartment via FPV.
More information about the tank: forum.rcdesign.ru/blogs/45616
6. Choose an autopilot, or rather, a little bit solder
To read data from sonars, make navigation decisions and send data to the flight controller, we needed a separate calculator - autopilot. Since there was knowledge of the Atmega family of controllers, in 2 evenings I soldered the polling board to Atmega162 (the only controller in the DIP package and having 2 UART ports that could be bought at the local radio store), and which was later replaced by Atmega128 (the firmware grew and didn’t already fit in the controller memory).
The pins on the board are connectors for connecting sonars. The main advantage of using these controllers compared to Arduino controllers was that the code could be debugged (debugged) by the debugger via JTAG! That is, at any moment you can stop the program and see everything that interests you - the values of variables, counters and other things, as well as in the case of an error, step by step find where it originated.
7. Learning to hold high
In order to expedite the development / testing in a short time, it was decided to conduct tests in the apartment instead of going somewhere and wasting valuable time. Without thinking twice, a test bench was created in a room of 12 square meters. meters.
Hooks were screwed in the ceiling and in the field, between them a strong paraglider line was stretched. A vertical rail, a carbon tube, was installed in the frame of the drone. Above there was a limiter that did not allow the copter to rest against the ceiling. As a result, the copter could only move vertically, which was required so that it was safe for itself and the copter to adjust the PID coefficients of altitude retention.
More information about the landfill can be seen in the video:
A lot of time was spent setting up the PIDs, but I managed to get a good deal with the regulatory mechanism from personal experience and practice. I also decided on a model of sonars to hold the height, which worked reasonably well - these are the wide-directional DYP-ME 007 v1.0. The popular HC-SR04 worked worse - they hung on a poor surface.
Thanks to the work on the stand “live”, I managed to achieve a good result, the copter perfectly kept the given height.
8. Holding a course or a little about the compass
One of the following problems was heading hold (Yaw axis), that is, so that the copter does not spin around its own axis. The decision to use the compass that was on board the flight controller turned out to be simple at first glance, but subsequently unacceptable, because the compass refused to work in Moscow at the organizers' training ground (power lines, etc.). However, this solution allowed us to continue testing in my apartment and move on to the following tasks - move on.
In Moscow, after finding out on the test that it was impossible to navigate the compass, it turned out to turn off the compass and write your own algorithm for holding along the Yaw axis. To do this, I entered the value of the calculated angle Yaw (by the way, on Open Pilot CCD3 flight controllers this angle is also calculated, since there is no compass on board at all, and the rotation angle can be seen in the setup program). The angle value was calculated according to the data from the gyroscope (angular acceleration along the Yaw axis), I selected the formula empirically. Then I measured in a stationary state how much this value escapes in 5 minutes (there was a slight drift in one direction), and adjusted this angle at regular intervals to reduce the resulting drift to zero. Everything worked perfectly on the table; on the copter, in the absence of strong vibrations, this should also work.
9. Keeping distance from one wall
Secured one sonar (narrowly oriented HY-SRF-05) in front of the copter to automatically hold the position in the forward-backward direction (along the Pitch axis). From the control panel manually controlled the movement of the copter left and right (on the Roll axis), and in case of unsuccessful tuning of the PID controller, corrected the drift of the copter back and forth, when the stick stick deviated by 10% from the center, the copter switched to manual control by axis back and forth (Pitch).
Having suffered a lot from tuning the PID of the controller and sorting out its coefficients, I got 3 control coefficients, at which the device almost tolerably “clung” to the wall:
P-position (P position), when the control error is considered as the difference between the desired distance from the wall and current according to sonar data.
D - position (D position), the speed of movement from \ to the wall.
D speed (D-velocity), the acceleration of movement from \ to the wall.
And (I) - the coefficient was not taken into account not in terms of speed or not taken into account = 0.
Further searches for truth have already been transferred to the code of the flight controller. As it turned out in the MultiWii code, many settings in the code are selected empirically. You can fly with your hands, but for the robot, everything did not work out very well. I decided to rewrite the PID controller and do it the same way: P and D position + D velocity, conjured with filters that I borrowed from the ArduPilot flight controller code and got the result “good”, but of course I can’t compare it with professional controllers.
When I combined everything, I got a good result for the first time: keeping it in the range of 1 meter horizontally at a height of 50 cm. I tried to do the height higher, the range of bullying also increased.
10. Connecting the remaining sonars and setting up collaboration of sonars
Since the sound has the property of being reflected, so that the reflected signal from one sonar is not caught by another, I interview the sonars sequentially. The maximum polling frequency of the used sonars is 20 Hz, it turns out, if you interview sonars sequentially in turn (and there are 5 of them), then each will be polled with a frequency of 4 Hz. Thanks to the cunning algorithm, in short, the essence of which was to interrogate “uninteresting” sonars (for example, the rear one when moving forward) less often - I received 5 Hz (5 times per second, in principle, not bad!)
Regarding stability, the following thoughts were:
Obviously, the more often sonars are interrogated (the higher the interrogation frequency), the more accurately the copter can be positioned, but not only the frequency is important, but also the response time of the system or the delay between direct measurement, for example, the distance to the wall and the effect on the motors, taking into account measured distance.
How quickly does the current system respond to the received values, how quickly (in what time) does the drone respond to measurement - will it give the control calculated signal to the engines, after calculating the PID, sending data from the autopilot to the flight controller and reading the distance from the sensor?
It is easy to imagine such a situation, for example, if the information from the video camera came into our eyes (through a monitor or glasses) with a delay of 1-2 seconds, would it be easy to move, despite the fact that the frequency would remain 25 frames per second? I would have to go very slowly so as not to fall. Well, if you try to walk the rope like this, for example?
Here's another example: a signal from a lunar rover from the moon arrives with a delay of 3 seconds, while this time is measured in minutes from Mars, and it is simply impossible to control it from the ground (either the speed of the rover would be very, very slow).
We calculate the response time for the resulting drone system:
TOTAL delay previously: 3..29 + 0 + 25 + 2 + 14 = 44..70 ms.
1) After the signal for measuring distance (trig) is supplied to the sonar, the ultrasound module emits an ultrasonic signal, a certain time passes until the signal-sound returns after reflection from the obstacle. This time is recorded in the sonar sensor and output via the analog or digital output of the sensor.
2) Since it used a digital output (Echo) of the sonar, on which the signal (+) is generated by receiving the reflected echo, it is recorded immediately on the autopilot controller (by interruption) - in fact, the measured distance is transmitted without delay, unlike, for example, the version UART or I2C transmissions, when, upon receiving an echo, the sonar controller should transmit data sequentially, and the autopilot controller should receive them.
3) The value obtained by the autopilot controller is calculated and filtered. The calculated distance to the wall or floor is “fed” to the autopilot PID controller by keeping it from the wall or floor. As a result, it gets a new value for controlling the aircraft by Roll (Roll), Pitch (Pitch) and Throttle.
4) The received control values (Roll, Pitch, Throttle) are transmitted via the UART port to the flight controller (MultiWii).
5) The flight controller reads the data into the ring buffer and after a certain time (50 times per second) “feeds” it to the PID controller (which, in fact, is a multi wii stabilization system), after which the new values of the control actions are mixed (depending on the scheme Aircraft (quadrocopter, hexacopter, etc.) and are fed to engine controllers.
Since the sequential sonar polling cycle is 20 Hz , the time that can be spent on each sonar is no more than 50 ms. The sonar takes up to 29 ms to determine the distance, and accordingly 21 ms remains for the calculations (filters, PID and path selection algorithms).
This time (21 ms) turned out to be not enough for a slow 8-bit controller, so an option was invented when the control actions from the previous sonar value are calculated in a 50 ms interval, and the current sonar value is simply read into the current cycle. This solution increased the reaction time of the system by 50 ms, but allowed it to exist in such a configuration of low-performance iron.
TOTAL delay (lag) = 44..70 ms + 50 ms = 94..120 ms, in fact this delay is the reaction of the current system to the measured distance.
Obviously, the slower the reaction, the less stable the device will behave at any PID controller and the polling rate of the sensors. That is, the stability of the device depends not only on the frequency of polling sensors, but also on the "reaction" of the aircraft system to the measured distance (lag values or response time).
11. Possible optimization
How could the lag in the current system be reduced? Optimization options:
1) Using a faster controller for autopilot, for example, AWP (172 MHz 32 bit)
value of 25 ms - which includes distance calculation and the PID controller with transmission can be reduced to 2 ms. (- 23 ms).
Due to this, it would be possible to read and perform the calculation in one polling cycle, and this is (- 50 ms)
TOTAL delay (lag) during optimization = 94..120 ms - 23 ms - 50 ms = 21..47 ms
2) An even more advantageous solution, if the flight controller and autopilot are one fast controller or computer, the circuit would be even faster, since it would be possible to save time on transferring information from the autopilot to the flight controller, as well as increase the frequency of operation of the flight controller stabilization system ( in MultiWii this frequency is about 300 Hz)
12. Autonomous hanging (keeping distance from walls + keeping height)
After we managed to keep the height along the sonar and more or less keep the distance from one of the walls, we could cling the 3rd sonar to the left or right side of the copter, and learn to hang in the room in automatic mode. But the copter dangled along each axis and eventually spun counterclockwise, gaining amplitude. The minus was also that the drone "languidly" kept its course (Yaw axis), especially twisting the device near the wall. Also, moving from one wall to another, the apparatus lost a little height, then braking in front of the wall, he tried to gain height, thereby almost firing in the opposite direction. When setting large PID values for yaw, the device tried to align as much as possible at the moment of twisting near the wall, thus
A lot of time was spent on stabilizing the device on the course (Yaw axis), selecting the PIDs of the autopilot and flight controller. I also had to come up with a couple of techniques for the behavior of the device in order to exclude buildup. The result is a more or less stable behavior:
13. Maze Navigation
There was no need to use complex algorithms and map building to go through the competitive training ground; the simplest algorithm for going around the labyrinth “rule of the right hand” came up. He modified it a little and did it on a state machine. Briefly, the essence lies in a few simple rules of movement:
To move the aircraft forward / backward / right / left, the autopilot sends the appropriate commands to the flight controller to tilt the platform in the corresponding direction. If the walls in the direction of movement are not "visible" in sonar, then the platform tilts by 5 degrees (I picked the angle manually). In order for the drone not to accelerate, at regular intervals, it takes a horizontal position and moves by inertia (without tilting in either direction). In addition, a GPS receiver was used for coarse speed control, when the speed was fixed above the critical speed (it was also selected empirically) the drone slows down, that is, deviates in the opposite direction from the direction of movement. For movement within the visibility of the distance sensor - sonar, the retention distance from the wall simply changes.
14. Detecting Landmark Markers
A camera was installed on the drone, the image was transmitted through a video transmitter to a laptop. And further, if the marker was detected (recognized), then the data on the screen coordinates of the marker were transmitted to the autopilot. Based on the data obtained, the autopilot calculated the distance to the “target” relative to the copter and visible walls (described in detail in paragraph 3). Then he tried to maintain this distance, and the landing program turned on, consisting in a slow decrease in the height of hovering.
In the final version of the robot, it was possible to implement a rotary mechanism for the camera (the camera rotated up and down along the Pitch axis). Thus, a target tracking mechanism was organized, and when approaching the cross, the camera turned down, keeping the center of the landing site in the center of attention of the camera. Thus, the time of "tracking the target" was increased and, consequently, the accuracy of landing, too.
Recognition of the cross marker in the circle was performed using Open CV, the algorithm for searching for the intersection of lines was used, an individual person in the team was engaged in this work, who joined the work in the last terms of the project, so he could not be included in the list of participants (according to the rules of the contest organizers).
15. A trip to Moscow
Having passed all the control points for participation in the competition, our team was allowed to participate in the final. At the time of the trip, not everything was ready in the new platform based on the hexacopter; therefore, it was decided to make final preparations in Moscow at a test site.
The landfill was completed during the testing process.
The competition was divided into 2 days, some photos can be viewed on the website of the organizers .
Before you start:
Waiting area in the parking lot.
The first attempt of our team failed, the robot flew over, but caught the fence and touched the floor, but took off and courageously got back.
In the second attempt with navigation, everything went well, the robot did not touch the walls, but did not land in the landing markers, although the markers were well recognized on the laptop base station.
And after the competition, it turned out to be an almost perfect version of the flight, with a round-trip landing.
4 people participated in the work on the project of the flying robot in our team. One person was responsible for recognition, one was an excellent specialist in C language and was well versed in AVR controllers, consulted in difficult moments of the project. As a team captain, I designed drones, programmed and tested, and my wife dealt with organizational issues during a trip to Moscow. Also for testing the robot required premises - testing grounds. Thanks to friends who provided their homes, garages and offices. Despite the seemingly small result, a lot of work has been done. 90% of the time was spent studying something new, organizational issues, testing and overcoming difficulties, without which the project would not have moved.
The 2013 competition gathered a lot of participants, in the final on the tests and during the competition it was possible to talk a bit with colleagues (the rest of the time was spent on finalizing and setting up the drone).
At the competitions, weather conditions spoiled the picture a bit and most of the participants, including the organizers, had problems with wireless connection (wifi). For many, including us, in the tests it came as a surprise that the compass does not work on a real training ground (power cables, etc.).
In general, for the first competition for "adults" it turned out very well.
List of sources about the competition: