Danesh Auriga

ROBOCUPJUNIOR RESCUE SIMULATION 2026

                                 TEAM DESCRIPTION PAPER
                                          Danesh Auriga

Abstract
     This paper presents the design and implementation of an autonomous two-wheeled robot developed for
     efficient exploration, mapping, localization, navigation, and wall-token detection in simulated
     environments. The software is implemented in Python and integrates LiDAR, GPS, IMU, wheel-motion
     data, and three RGB cameras. The environment is represented as a high-resolution occupancy map and
     explored through A*-based path planning. A graph-based navigation strategy extends the standard grid
     representation by detecting traversable points between grid nodes, enabling the robot to pass through
     narrow passages that would otherwise remain inaccessible. For visual perception, three downward-
     angled cameras provide simultaneous coverage of the front, left, and right walls, improve the distinction
     between real and fake victims, and increase the visibility of cognitive targets at short distances. A deep-
     learning-based detection pipeline identifies wall tokens and estimates target centers for subsequent
     classification. The system was evaluated across 70 standard worlds, and the selected version achieved the
     best overall performance, with an average score of 1536.94 and a mean map-correctness percentage of
     88.28%. These results demonstrate the effectiveness and stability of the proposed integrated approach.
1. Introduction
  a. Team
     Amirsam Eftekharinia (Computer Vision)
             • Role and responsibility: Computer Vision, Evaluation
             • Experience: Two years of robotics studies, two years of participation in the Rescue
                  Simulation League
     Ryan Feizbakhsh (Mapping)
             • Role and responsibility: Mapping
             • Experience: Three years of robotics studies, two years of participation in the Rescue
                  Simulation League and one year of participation in Rescue Line League
     Artin Taleei (Computer Vision)
             • Role and responsibility: Computer Vision
             • Experience: Two years of robotics studies, one year of participation in the Rescue Simulation
                  League and one year of participation in Soccer Simulation League
     Radin Mohammadian Asl (Navigation and Decision Making)
             • Role and responsibility: Navigation and Decision Making
             • Experience: Two years of robotics studies, one year of participation in the Rescue Simulation
                  League and one year of participation in Soccer Simulation League
2. Project Planning
  a. Overall Project Plan
     The objective of this project is to strengthen the team members’ scientific knowledge, technical skills,
     teamwork, and problem-solving abilities through a practical and creative experience. It also aims to
     introduce the team to current challenges and emerging fields in science and technology worldwide. By
     participating in the prestigious RoboCup competitions, the team seeks to gain valuable experience and
     achieve first place.

                                                                                                              1
   The project began with learning fundamental skills, such as the Python programming language and various
   libraries, including NumPy and OpenCV. After reviewing some basic mathematics, such as the two-
   dimensional coordinate system, and basic trigonometry and geometry, the team learned how to work
   with the simulator, build the robot, create the map, and become familiar with the league rules. The main
   development process for the robot then began. The stages of the project are listed below step by step:

                                           Figure 1. Project Plan

                                     Figure 2. Deadlines and Schedules

b. Integration Plan
   Our team operates in a way that, although each subsystem is primarily implemented and maintained by
   its designated members, all team members remain familiar with the designs and implementations of the
   other subsystems. Different ideas and approaches are discussed collectively, and through constructive
   feedback and evaluation, the most suitable solution is selected and implemented by the members
   responsible for that subsystem. This approach facilitates the integration of different modules and
   codebases, as every team member has a general understanding of the functionality of the other
   components.

                                                                                                         2
                                 Figure 3. Robot Major Modules and their relationships

      Throughout the robot software development process, special attention has been given to maintaining a
      modular and function-oriented code structure. This significantly reduces the time required for integration,
      testing, and debugging.
      In addition, the use of the Git version control system throughout development has greatly simplified code
      integration, collaboration, and backup management.
3. Robot Design
   The robot used in the simulation environment is equipped with two wheels, each fitted with an encoder
   sensor. These encoders are used to measure the distance traveled by the robot.
   The robot is equipped with a LiDAR sensor for detecting obstacles, walls, and objects in the environment; a
   GPS sensor for localization; and an IMU sensor for determining the robot’s orientation at any given time. In
   addition, it uses three cameras (with a resolution of 40 × 32 pixels) mounted on the left, right, and front sides
   of the robot for detecting tokens, identifying different colored tiles, and recognizing holes. The camera
   resolution was selected due to the limited sensor budget of the robot while still providing sufficient visual
   information for victim detection.

                                                Figure 4. Robot Design

   Our innovation in choosing the placement of the cameras is that we have positioned them on top of the
   robot at 0.65 radians angle.
   The purpose of this is twofold:
   1- In this configuration, fake victims appear in the camera in an unusual and different way from real victims,
       thus making it possible to detect whether a victim is fake using only the camera, saving time consumed
       by the robot.
   2- In this case, when we approach cognitive targets, a larger portion of them is captured within the image,
       increasing the likelihood of detecting them.

                           Figure 5. Difference between downward-angled and straight camera

4. Software
  a. General software architecture

                                                                                                                  3
  Several well-known and practical algorithms in the field of robotics have been used in the
  software, including deep neural networks, the A* search algorithm, occupancy-grid mapping,
  and closed-loop PID control.

                                 Figure 6. Libraries used in robot’s software

  The general operation of the robot can be described as follows. From the moment it starts, the robot
  divides the environment into 3 𝑐𝑚 × 3 𝑐𝑚 tiles.

                                    Figure 7. Dividing space into 3cm tiles

  While moving, it continuously maps the environment, detects surrounding walls and obstacles,
  and stores this information in a two-dimensional array. The robot also records the tiles it has
  already visited in another two-dimensional array.

  Whenever the robot reaches a tile, it examines the eight neighboring tiles. Any tile that is
  accessible and has not previously been visited is added to a list of future targets. At each step, the
  robot extracts the most recently added element from this list and selects it as its current target. It
  then uses the A* algorithm to calculate a path from its present position to the selected target and
  follows this path until it reaches the destination. The same process is then repeated.
  This procedure continues until the list of future targets becomes empty. At that point, there are
  no unexplored areas remaining on the map. The robot therefore returns to its starting point and
  sends an “exit” command to the server. In addition, whenever a token is detected within the
  robot’s camera frame during the exploration process, the robot stops for one second, reports the
  detected symbol, and then resumes its operation.

b. Navigation
  Robot Movement.
  The robot’s basic movements toward a target (we call it “go_to_xy”) consist of a combination of in-place
  rotation and forward or backward motion. To maintain the robot’s accuracy during different movements,
  a PID-controller structure has been used. However, in practice, the proportional gain (𝐾𝑝 ) alone was
  enough for us.

                                   Figure 8. Feedback control structure

                                                                                                        4
        We now turn to the explanation of the algorithm implemented for reaching a nearby destination (local
        navigation). In the robot’s control system, the error is defined as the difference between the robot’s
        current orientation (𝜃: yaw), which is measured by the IMU sensor and the angle of the line connecting
        the robot’s current position to the destination point (𝛽). ⟹ 𝑒𝑟𝑟𝑜𝑟 = 𝜃 − 𝛽

                 Figure 9. Calculating the orientation of the line that connects robot’s current point to the destination

        This error is then multiplied by an appropriate proportional gain (𝐾𝑝 ). Based on the equations below, the
        control system generates the appropriate command for each wheel. In simple terms, the robot
        continuously attempts to adjust its orientation toward the destination within a closed-loop control
        structure.
                                                  𝑣𝑟 = 𝑀 + 𝐾𝑝 × 𝑒𝑟𝑟𝑜𝑟
                                                  𝑣𝑙 = 𝑀 − 𝐾𝑝 × 𝑒𝑟𝑟𝑜𝑟

        (𝑀: maximum velocity of the robot, 𝑣𝑟 : right wheel speed, 𝑣𝑙 : left wheel speed)

                                             Figure 10. Complete robot movement pipeline

        In the design of our controller, tuning the proportional gain (𝐾𝑝 ) is an important task, as an inappropriate
        value can reduce the quality of the system’s performance. The effect of changing (𝐾𝑝 ) on the system
        performance, error, and overshoot is shown in the figure below.

Figure 11. As you can see the gain of 0.8 (which is the value used in our controller) has the best Mean Square Error (MSE) and Overshoot
                                                      (OS) with respect to the others

        Path Planning.
        Our robot uses the A* search algorithm to find a path from an arbitrary point A to an arbitrary point B.

                                                                                                                                       5
The heapq library is used in our A* implementation. This library allows us to efficiently add tile coordinates
to our lists or remove them when needed. Using this library instead of manually searching through the
open list improves the execution speed of the code. More specifically, the library stores the data in the
Open Set using a min-heap data structure. As a result, the time complexity of the relevant operations is
reduced from 𝑂(𝑛) to 𝑂(log 𝑛).

                                    Figure 12. A* algorithm flowchart

Narrow-Passage Navigation Algorithm.
During the testing and development of our code, we encountered situations in which the robot may
need to pass through narrow corridors or pathways that cannot be traversed solely by moving along grid
points. An example of such a situation is shown in the figure below.

                              Figure 13. Visualizing narrow-passage scenario

As shown in the figure, the only path between the two walls passes through the purple point, which is
located between two standard grid points. This limitation led us to move beyond the grid-based
representation and model the environment as a graph instead. We refer to this approach as “graph-based
navigation”. If two adjacent grid points are not traversable, the points between them are examined using
a step size of 0.1 cm. If a traversable point is found, it is added to the graph as a new vertex, and the
robot’s current vertex is defined as one of its neighbors. This process is repeated whenever the robot
reaches a new graph vertex.
In this way, the map of the environment is constructed as a graph while the robot is moving. Each edge in
the graph represents the robot’s ability to move between the two corresponding vertices. This graph-
based map is then used for path planning (A* algorithm).
The desired graph is implemented using the NetworkX library.
By constructing a graph-based representation of the environment, the robot is able to navigate through
narrow passages. The figure below shows an example of a narrow passage that would not have been
traversable without this algorithm. The red point represents the position outside the standard grid.

                                                                                                            6
  Figure 14. Occurrence of narrow-passages in real maps and how our algorithm with off-grid nodes can solve the problem

c. Wall Token detection
   The system must operate reliably under varying viewpoints, rotations, and perspective distortions while
   maintaining real-time performance during exploration. To achieve this, our team developed a deep-
   learning-based vision pipeline using YOLO26-Pose. The model detects wall tokens and estimates the
   center point of cognitive targets.
   Camera Configuration.
   During early testing, a forward-facing camera configuration showed two main limitations. First, real
   victims and fake victims often appeared similar. Second, when the robot was close to a wall, the outer
   rings of cognitive targets were often outside the vertical range of the image.
   To solve these problems, the cameras were tilted downward. This configuration exposes the side surfaces
   of fake victims. In addition, the downward viewing angle increases the visible wall area at close distances.
   The angled camera position introduces perspective distortion in the vertical direction. However, this effect
   is compensated through image warping techniques that map image coordinates to real-world
   proportions.
   The final camera orientation was selected after evaluating multiple configurations and comparing victim
   recognition performance in representative competition scenarios.
   A custom dataset was collected directly from the simulation environment. Images were recorded while
   the robot navigated through different worlds and encountered various wall tokens and environmental
   features.

                                     Figure 15. Dataset contains the following cases

   The "Background" class contains walls and other environmental elements that do not correspond to valid
   wall tokens, helping the model distinguish targets from non-target objects.
   Special attention was given to collecting samples under a wide range of conditions, including different
   viewing angles, large victim rotations, different distance from the wall, partial visibility and occlusions,
   and various positions within the camera frame
   The dataset was collected in a way to cover the full rotational range. Additional samples were recorded
   from different locations and orientations to improve the model's ability to generalize to unseen
   environments. The final dataset was manually labeled using bounding boxes for all classes. For cognitive
   targets, an additional center keypoint was annotated to support precise center localization.
   Synthetic Cognitive Target Generation.
   The total number of possible color combinations for cognitive targets is 55 = 3125 and hence, Collecting
   and manually labeling all combinations would be time-consuming and inefficient. Therefore, a synthetic
   data generation pipeline was developed.
   The generator automatically creates cognitive target images with editing the labeled images and creating
   random color rings. This approach significantly increases dataset diversity while reducing manual labeling

                                                                                                                          7
effort.
Annotation Strategy.
The victim detection model is trained using the pose-estimation variant of YOLO26. The network is
configured to detect four classes: Φ victims, Ψ victims, Ω victims, Cognitive targets
For letter victims, standard bounding-box annotations are used. Since only the victim type and location
are required, no keypoints are assigned to these classes. For cognitive targets, a single keypoint is
additionally annotated at the center of the target.
After detection, the center position is used to extract color information from the concentric rings. The
colors are then converted into their corresponding numerical values and summed to determine the
cognitive target type. After training, the network is exported from Ultralytics format to ONNX and
simplified then converted into a TensorRT engine.

                            Figure 16. Training results and Confusion Matrix

                             Figure 17. Computer Vision algorithm pipeline

TensorRT optimization significantly reduces inference latency and increases frame rate, allowing victim
detection to run continuously during navigation without affecting other subsystems.

                                 Figure 18. Victim detection (Φ, Ψ, Ω)

                                                                                                          8
d. Mapping
  This section examines how the robot determines its position within the environment, as well as the shape
  and characteristics of its surroundings.
  Localization.
  We designed a localization system based on the robot’s equations of motion. In this system, the changes
  in the robot’s position along the x-axis and y-axis can be calculated based on the rotational speeds of its
  wheels and its orientation.
  Therefore, by adding ∆𝑥 and ∆𝑦 to the previously estimated position values, the robot can obtain an
  estimate of its new position. The equations of motion for our two-wheeled robot are presented below.
                                                𝑣𝑟 + 𝑣𝑙
                                        ∆𝑥 = (          ) × ∆𝑡 × cos(𝜃)
                                                   2
                                                𝑣𝑟 + 𝑣𝑙
                                        ∆𝑦 = (          ) × ∆𝑡 × sin(𝜃)
                                                   2
   (∆𝑥: Displacement along the x-axis, ∆𝑦: Displacement along the y-axis, 𝐿: Distance between two wheels, ∆𝑡: Time
                difference, 𝑣𝑟 : Right wheel velocity, 𝑣𝑙 : Left wheel velocity, 𝜃: IMU yaw measurement)
  For the equations, since the wheel velocities are commanded directly (also can be measured by encoders)
  and the time interval and robot orientation are known, the change in the robot’s position can be
  calculated at each step.
  Mapping.
  The LiDAR sensor provides the distances to obstacles and walls at different angles around the robot,
  covering a full 360-degree field of view. Next, trigonometric transformations based on the sine and cosine
  relations are used to determine the positions of obstacle points in the robot coordinate system, also
  referred to as the “local coordinate system”. However, this alone is not sufficient to construct an accurate
  map of the environment, since the map must be represented relative to a global coordinate system.

                          Figure 19. Calculating obstacle coordinates in the global frame

  The exact equations used to convert the sensor data into the obstacle coordinates in the global
  coordinate system are presented below.
                𝑥𝑜𝑏𝑠          𝐿 × cos(𝛼)      𝑥𝑜𝑏𝑠𝑔𝑙𝑜𝑏𝑎𝑙     cos(𝜃) − sin(𝜃) 𝑥𝑜𝑏𝑠𝑙𝑜𝑐𝑎𝑙        𝑥
               [𝑦 𝑙𝑜𝑐𝑎𝑙 ] = [            ] ⟶ [𝑦          ]=[                ] [𝑦         ] + [𝑦𝑟𝑜𝑏𝑜𝑡 ]
                 𝑜𝑏𝑠𝑙𝑜𝑐𝑎𝑙     𝐿 × sin(𝛼)       𝑜𝑏𝑠𝑔𝑙𝑜𝑏𝑎𝑙     sin(𝜃) cos(𝜃)      𝑜𝑏𝑠𝑙𝑜𝑐𝑎𝑙        𝑟𝑜𝑏𝑜𝑡
  Here, 𝛼 denotes the angle of the corresponding LiDAR laser beam, and (𝐿) represents the distance
  measurement returned by the LiDAR sensor at angle 𝛼. The remaining variables are defined in the above
  figure.
  Finally, the generated map is stored in a two-dimensional array. The resolution of our map is set to 1 mm.
  Two examples of the outputs generated by the environment-mapping system are shown below.

               Figure 20. Some results of the mapping algorithm after robot explores the environment

                                                                                                                 9
        During navigation, the robot maps the environment and records colored tiles and each tile with its
        associated room. Before exiting, it converts the map into 12 cm × 12 cm tiles, generates a 5 × 5 matrix for
        each tile, and combines them into the final array sent to the server.

                                Figure 21. construction of server-type map from our 2d-array

5. Performance evaluation
        The robot’s performance is evaluated through comprehensive tests designed to closely resemble the
        conditions of the actual competition day across different arenas. Certain parameter settings may
        significantly improve performance in a specific arena while reducing the robot’s overall performance
        across a wider range of environments. To avoid this issue, each version of the code is tested on several
        different maps, and the average of the resulting scores is used as the basis for decision-making.

                                                Figure 22. Evaluation results

        As the data indicate, Version 3 has a higher average score, a higher Map Bonus percentage, and a higher
        exit score. In addition, according to the histogram, Version 3 does not produce a large number of very
        low-scoring runs. Therefore, we conclude that Version 3 is more stable and is the preferred version.
6. Conclusion
     In this project, we aimed to design and implement a capable robot for exploration, mapping, and decision-
     making in a simulated environment by drawing on the technical expertise of the team members and
     employing intelligent methods. The results demonstrate that the careful integration of sensors, learning-
     based methods, and motion-control techniques can improve the robot’s accuracy, speed, and stability.
     Furthermore, evaluations conducted across different maps indicate that the system has a suitable level of
     reliability and can be further optimized in the future. Continuing this work can enhance the team members’
     technical expertise and contribute to improved results in future competitions.

References
●   https://www.ultralytics.com/
●   https://cyberbotics.com/doc/reference/index
●   https://developer.nvidia.com/cuda/toolkit
●   https://aleksandarhaber.com/tutorial-on-simple-position-controller-for-differential-drive-robot-with-
    simulation-and-animation-in-python/

                                                                                                                10

Open as plain text