ULtron 2019 Team Description Paper

Benoit Verret, Philippe Babin, Marc-Antoine Dion, Gabriel Mainguy, Francis Lachapelle, Philippe Lebel

Université Laval, Québec, Canada

http://robocupulaval.com/ · https://github.com/RobocupUlaval/StrategyAI

Abstract This paper presents the work done since last year by the team ULtron in order to participate in the international competition in Sydney, Australia.

1 Introduction

ULtron is a team of undergraduate and graduate students at Université Laval in Quebec city, Canada. The team is active since 2013. The team is used to present the project to the public in local events, schools, local fairs and exhibitions to promote robotic and artificial intelligence. This will be the 3rd participation of the ULtron team to an international competition. We manage to reach the 4th place at the 2018's competition in the B Division. The team is trying its best to be part of the RoboCup Soccer Family!

For the 2019's competition, we will be perform with the new model of our robot, named Epsilon. Most of the new robot design, remains unchanged from previous years, see [1] and [2] for more details.

Fig. 1. Photo of the previous year robot, the Delta model.

2 Embedded Software

(This section contains subsection 2.1)

2.1 Improving Ball Detection

In a match, it can be hard to kick the ball when its precisely in front of the robot. When the ball is near a robot, the vision sometime does not see it. Thus almost all RoboCup teams rely on on-board sensor to detect the ball. One of our goal for this year competition is to improve our ball detector reliability. This section will first describe our previous system, then we will explain how we improve its software calibration and finally we will explains our new ball detector.

Last year, our robots relied on two active infrared sensors (OPB732) to detect the ball's position. As shown in Figure 2, these sensors are perpendicular to the ground plane with small obtuse angle. However, this solution have two main issues: they are quite sensible to the ambient infrared pollution; and they also require precise software calibration to correctly detect a ball. The former was quite a problem during 2018's competition, where the overhead lights cause a high ambient infrared.

Fig. 2. Current ball detector, it uses two infrared sensors to detect the ball's position.

The software calibration of this system is done in the following steps: We first place the ball different place in front robot and sample the sensor's values. Depending on whether the ball was place at a kickable position, the sample is labeled as with ball or without ball We then use a Support-vector machine (SVM) to find parameters of a line which best separate the sample without ball from the sample with a ball. Then, the parameter of the line are configured into the robot. An example of a calibration can be seeing in Figure 3. This calibration method works well in most case, but some of the field's white lines are falsely detected as ball.

Fig. 3. Example of the ball detector's software calibration. To correctly detect the ball, we must find a line that separate the inlier (balls) from the outlier (no ball). The sensor's value is the analog reading from our microcontroller's ADC. By no ball, we means any reading when the ball is no situated at a kickable position.

To combat this problem most team relies on a pair of photo-receptor/photoemitter parallel to the ground plane. This solution does not require software calibration and is robust to the ambient infrared pollution. However, the emitter and receptor must remain align otherwise a false detection of the ball will be triggered. We are planning on using this solution during the next competition. Our 3D print dribbler had to be redesign to make it more robust and thus reduce the chance of a misalignment (more detail in subsection 4.1). We will be using the same pair of receptor/emitter as team TIGERs [3]: the TEMD1000 photo-receptor and the VSMB2000X01 emitter. These sensors does not require any change to the main electronic board and should improve the ball detection reliability.

3 Software

Our AI software architecture is similar to last year [2]. It is entirely programmed in Python. All the code, which is public, can be found on Github at this URL: https://github.com/RobocupUlaval/StrategyAI. Most of our software improvement are about improving reliability by making more regular test in simulation and in real life. RoboCup Arena is our initiative to make it easier to test our AI against other team in simulation.

3.1 RoboCup Arena

RoboCup Arena is an open source project to make it easier to play match in simulation against another team's AI. One of the main hurdle of developing a AI is having a challenging opponent to play against. Currently, we only have support for our AI and partial support for RoboJacket's AI, but we hope that with the help of the community, the number of supported team will grow.

RoboCup Arena is simply a set of scripts which: 1) install all required tools (GrSim, refbox and Autoref) and configure them; 2) install, configure and patch a team's AI; 3) run team's AI for specific field side and color. To prevent collision between different versions of the same tool, all software are install in a local folder. Currently, the main challenge to this project is interaction between GrSim (the simulator) and the AI. Most RoboCup SSL teams have there own fork of GrSim with there own specific modification. For instance, a team might add a control system closer to how there robots are controlled, another team might add a TCP connection that send ball detector status to the AI. This make it impossible to have a single version of GrSim for every team. A solution to that problem is to add plugin support to GrSim. Each team would provide a dynamic library plugin with there custom behavior and GrSim will load it at the start of the match.

The project is still in its infancy, we are planning releasing it when the plugin support is stable.

Fig. 4. Rendering of the mechanical parts of the new Epsilon robot

4 Mechanical Design Upgrades

The team currently works on improving the reliability and performance of the robots in games. The Espilon model will feature many improvements such as a new design of the dribbler, new encoders and new designs to facilitate maintenance. Figure 4 presents this new design.

Fig. 5. Rendering of the new dribbler system.

4.1 Dribbler System

After a year of working with the previous dribbler model, we decided to improve some important features such as the reliability of the transmission system, the assembling, the ball centring and the ball detection. This new design can be seen in Figure 5. First, we changed the transmission from a chain to a timing belt. We had some issue with the chain that was breaking quite often in games. The timing belt is more reliable but the pulley is larger than the previous sprocket. We had to liberate space for the pulley and we did offset the right part of the dribbler to guaranty no collision with the wheel. To improve the efficiency of the dribbler's maintenance, we changed the pivot system. Now, it's a screw mounted on a bearing for both sides. The new ball detection is a laser beam. So it has to be at the bottom of the dribbler. This sensor need a high precision and for this reason, we made the moving piece in on block to ensure the alignment between the emitter and the receptor. Also, to facilitate the maintenance on the roller and on the laser hardware, there's two brackets fasten to the main block and tightening the bearings. This way, it's easy to remove the roll and change the bracket for a new one. The roller is made off molded rubber from Smooth-On's products. We 3d printed the mold with our Creality CR-10 3d printer. We added the screw features to center ball. The last improvement consist on the damping system. We limited the damping to a maximum of 10 degrees. The same elastic material is used which consist of rubber o-rings. But our new design allow to change the tension applied by the o-rings. The way it works is similar to chain tensioner. When the tensioner screw is fasten, it slides following the conic profile which applies a higher tension.

4.2 Wheels

We kept the same Omni-wheels with 65 mm in diameter presented in Figure 6. The design is great and it's reliable. Although, we will change the base material from aluminium to steel to ensure the quality over time of the internal teeth. We modified the assembling method of the wheel, which is presented in Figure 7. With the previous model, the wheel swayed a little because of the bad positioning of the o-ring. Furthermore, the snap ring made the disassembling quite difficult, damaging the wheel sometimes. Now, the wheel cannot move cause it is retained by a washer and a screw. The disassembling is also easier and doesn't damage the wheel.

Fig. 6. Rendering of the new omni-wheel system

Fig. 7. Improvements to the wheel assembly

5 Conclusion

A description of the technology used to produce the ULtron robot team has been presented. The team's third competition robots are ready to be used to implement more complex strategies. Currently, the team is working on making the mechanical and electrical system more robust as well as improving the ball detection and the AI.

References

P. Babin, A. Blanchard-Lapierre, S. Bouchard, M. Gagnon-Legault, A. Gingras-Courchenes, L. Gagnon, P. Lebel & P. Turgeon. ULtron 2017 Team Description Paper, 2017
S. Bouchard, F. Lachapelle, P. Lebel & B. Verret. ULtron 2018 Team Description Paper, 2018
A. Ryll, N. Ommer, D. Andres, D. Klostermann, S. Nickel, F. Pistorius. TIGERS Mannheim - Team Description for RoboCup, 2013