Eurobot Open is an international competition of autonomous robots. The tasks, the battlefield and game elements change every year, but the essence remains the same - the team must create two autonomous robots that will compete with the opponent's robots in a small field for limited resources for 100 seconds. This short sentence conceals a huge number of tasks that the team must solve, because robots must be fast, maneuverable, be able to carry out tasks independently and not face the enemy. And every year it is necessary to develop new robots. Nevertheless, the experience and achievements of past years can give a great advantage. From year to year, we need localization systems, predictions of enemy movements and avoid collisions, route planners, flexible behavior management systems, our own electronics and mechanics. Yes, for a lot of this there are standard algorithms and libraries, however, most of it still has to be strongly modified or written from scratch due to the specificity of the functionality and the requirements for resource consumption.
Our team at the Russian final in Moscow.
Cool video about our participation in 2019:
The main gaming theme in 2019 was Nuclear Energy. But this does not mean that the teams were required to make a robot powered by a nuclear engine. Just different game tasks and elements were given thematic names. The only game objects of manipulation were hockey pucks - electrons. They have different weights, different colors, and one, “gold”, of a different size. It is necessary to collect a maximum of washers located in different places of the field, in different positions, at different heights, and then sort them into zones on the field depending on what kind of chemical element it is.
This is what the playing field looked like in 2019.
The code names for our robots this year were Chip and Dale. Why? I think the answer is clear from the photo:
Let's go over the basic technical solutions in our robots last season. This year we tried as much as possible to unify everything and we had two twin robots. The block diagram of our robots in the picture below.
The upper level was represented by a single-board tested Odroid xu4 with ubuntu 16.04 and ROS Kinetic on board. All the “difficult” tasks are spinning on it.
At the lower level, the STM32F407VGTX-DISC1 is working, stuck in a shield of its own design, which allows you to conveniently connect a dozen motors, serv and a garland of sensors. By the way, they are always gaining an impressive amount. Each of our robots contains lidar, 7 dc / bldc motors, 9 servos and about 25 different sensors (colors, weights, distances, currents). And all this, plus another 6 volumetric mechanisms, was placed in compact robots with a perimeter of 850 and a height of 350 mm. FreeRTOS is spinning on STM itself, which serves tasks that require real-time execution, processing of all sensors and state machines.
View of the omnicholes of the robot.
An interesting feature is the use of an omni-wheeled platform as a drive, which allows us to drive in any direction and on either side without performing unnecessary turns, which dramatically increases the robot's maneuverability.
So, for example, in the next video from the match held in France, it can be seen how, despite the fact that we were blocked (due to a gross violation of the rules by an opponent), the robot got out of the jewelry trap.
However, due to omni, the accuracy of wheel odometry is very lame: the wheels are not perfectly round, the rollers play and have a small contact spot. To solve this problem, you can periodically beat into the wall, throwing an error, or apply external adjustment systems. Relatively often, lidars are placed on robots for this. A couple of years ago, another solution appeared: a place was added to the field where you can put the camera. Last year, we traveled only through an external camera with detection of aruco markers applied to the robot, but in this we simultaneously worked on localization using a lidar on the robot and an external camera (localization and navigation will soon be another big interesting article). We did not have time to test the lidar, so we rode around the camera and used the lidar as a stand for arucomarkers. Advantages of the system - we know the position of all robots on the field. Of the minuses - a high sensitivity to external light and calibration accuracy, which, unfortunately, has failed us more than once. But in general, the combination of odometry and arude detector allows us to position ourselves with an accuracy of several millimeters on a 2x3 meter field.
Our developed rangefinder board.
The rules prohibit collisions with other robots (for this they can also disqualify), therefore it is important for the robot to notice obstacles in its path on time. Usually, for monitoring the near zone, ordinary threshold IR infrared rangefinders or Sharp GP2Y0A21YK are used, which are extremely sensitive to the surface, for example, they can work on polished aluminum from a half meter and still not see carbon in focus. Ultrasonic rangefinders are also often used, but they are sensitive to the angle of the reflecting surface and are afraid of mutual interference. Recently, ToF rangefinders, for example, VL53l0x or VL53l1x, are rapidly gaining popularity. Having tried these sensors once, it is hard to refuse them - they have a weak dependence on the material of the obstacle, high accuracy, compactness, low price. However, last year we tried to use the VL53l0x and a number of nuances surfaced. What can happen when you put a dozen and a half dozen rangefinders on i2c, among a bunch of motors and serv? In addition, the sensors can not set a constant address, well, and the cherry in their phantom hang. Therefore, this year we made the board switching to rs485, which greatly simplified the use of rangefinders. In the photographs of the robot, the blue lights are them.
Here we are in every possible way preventing the robot from going directly between two points, and it stubbornly turns out to be smarter than us:
Using an external localization system, a full-fledged glider, as well as an awesome collision avoidance of the near zone allows you to do these things at a speed of 1m \ s. In the upcoming articles, we will try to tell the maximum about the most interesting things from our solutions (and discover the best practices), but today we want to talk about the feature of mechanics this year.
The design of mechanics for Eurobot is distinguished by its specificity. Firstly, since this is a competition, everything should work as quickly as possible and one hundred percent reliable. Secondly, the task is set so that the more points you want to earn, the more difficult the mechanics need to design. And the more complicated the mechanics, the greater the likelihood of its failure, which, according to Murphy's law, will occur at the most inopportune moment.
Tasks may seem simple at first glance, but this is not at all the case: the task of manipulating objects (to take, reorient, set) is still extremely difficult to solve. Unlike industrial manipulators, which are usually located statically, which have all the coordinates moved, and which work under ideal conditions, everything is cooler: I put the robot on the field, pulled the key and the robot works until the race ends. The possibility of some kind of coordinate adjustment and additional debugging is practically absent. It is necessary to take into account possible serious localization errors or inaccuracies in the manufacture of the field (for example, the robot thinks that it is in front of the puck that it plans to take, but in fact it is offset x 15 mm from the desired coordinate), so put the manipulator with a neat grip, moving from point to point will not work: in the real conditions of competition you will have serious problems.
Arrangement of mechanisms in the robot.
We managed to construct two identical robots, each of which solved the whole range of possible tasks within the competition. The robot housed a conveyor of a revolver type with 6 washers, and at any time we could unload any of them. On the field, the washers are in two positions: lying on the floor and standing on a special shelf. For each option, its own collection mechanism was designed. The washers from the shelf were assembled using a special flap roller that threw the washers onto the ramp, along the ramp the washer drove into the lower cell of the revolver, after which its color was detected, the revolver scrolled, and the robot pulled up to the next washer.
The supporting frame of the robot was made of sheet aluminum and 204 printed parts, 6 pieces of Dynamixel AX-12A, one Dynamixel MX-64 and two nine-grams, 3 pieces of maxonmotor 16mm and one maxonmotor 22mm were responsible for the mechanisms. The chassis was of three maxonmotor 22mm and 60mm omnicholes . All this is seasoned with 106 bearings.
Why dynamixels and not standard servos? They have many protections, digital control and many settings, convenient serial connection and generally good quality. Our experience also shows that cheap servos per season change in a circle several times, and expensive servos cost almost the same.
Since most of the washers on the floor were not in specific coordinates, but were randomly located within a certain area, it was difficult to use the manipulators, so a special mechanism for absorbing washers was developed.
The washers are unloaded in two zones: on the scales, where the washers can fall in any position, and in the accelerator zone, where the washers are placed in a vertical position. Here the robot ideally unloads everything into the accelerator on the home field (which was in 90% of cases):
However, in the decisive races, this, unfortunately, worked through once.
When unloading into the accelerator, it is possible to throw off the washers both immediately on an inclined surface, and first drop them onto a horizontal surface, and then push them onto an inclined surface. The second option allows you to throw two more goals and score more points. Therefore, this option was chosen, which, as it turned out later, was a critical mistake. It was extremely difficult to drive up to the wall, throw out the puck, discard it with a roller and repeat it N more times. Washers can stand up crookedly, not accelerate, crash into the wall and, most importantly, block the passage of subsequent washers.
As shown by the experience of competitions and, in particular, the constructive decisions of other teams, the simpler the decisions in mechanics, the better. The current solution required the coordinated and debugged work of a large number of complex mechanisms, the failure of any of which led to a malfunction of the entire system, and this, as is known from the theory of reliability , is not very cool. Also, the mechanics required regular adjustment and minor repairs, which stopped the process of debugging software on the robot. Where it is better to make a robot with one suction cup on a single link lever, which puts the washers in a pile, but fulfills in one hundred percent of cases as intended. On the other hand, participation in competitions can be considered not just as scoring competitions, but as a good way to implement the most interesting and cool engineering solutions.
In general, despite the not very successful performance in France, we are pleased with the results. We learned a lot of lessons: that the state of readiness of a task is not a binary parameter, that the development speed is often inversely proportional to the number of people involved, that simple and specialized in a small task mechanisms and modules can be better than complex and, in theory, beautiful ideas. And getting ready for the new season.
Video links and a more in-depth review: Eurobot official rules page . Detailed review from team mentors .
Eurobot is not the only thing trainees can do at the Sberbank Robotics Laboratory; there are other internships, for example, in intellectual manipulation of objects, mobile robots, anthropomorphic robotics on the iCub platform. And you can do joint research, write a diploma, a master's degree (if this intersects with the theme of the lab). Send your CV and application in free form to robotics@sberbank.ru
Our Telegram: t.me/SetUpSber