3
Black Radiators
Simulation league · Italy ·
RoboCup 2026
· 3rd place
Document register
- Poster1 pagePublished
- Presentation videoYouTubePublished
- Bill of materials3 pagesPublished
- Team description paper8 pagesPublished
- Engineering journalNot shared
- Source code5.4 MB · GitHubPublished
Sharing each document is the team's decision. “Not shared” means this team chose not to publish it, or did not submit one — not that it is missing from the archive.
In their words
Black Radiators' entry is a fully autonomous virtual robot for the RoboCupJunior Rescue Simulation, built on the Webots/Erebus platform and programmed in Python. It is a compact two-wheel differential-drive robot equipped with a LiDAR, a GPS, an inertial unit, a downward colour sensor, a wheel encoder, and two 64×64 cameras mounted on the left and right so it can read wall tokens on both sides of a corridor at once.
The controller is organised into four cooperating modules — perception, navigation, mapping and communication. The robot explores online by right-wall following on a 1 cm occupancy grid inflated into a configuration space, so it can plan as a single point and never clip a corner. When the local area is exhausted, a padding-tolerant breadth-first search drives it to the nearest unexplored frontier along a line-of-sight-smoothed path, while a GPS-based watchdog recovers it from holes, swamps and dead ends. Victims are detected with a hybrid pipeline: a YOLO neural network classifies the letter victims, a deterministic colour scanline sums the concentric rings of the hazardous-material signs, and a LiDAR depth test rejects fake three-dimensional letters.
What sets our robot apart is this combination: a low-cost twin-camera layout, a configuration-space planner that is both safe and able to squeeze through narrow gaps, and a perception system that pairs a learned letter detector with a fully explainable arithmetic hazmat detector.
Poster
1 page, rendered as images so they load quickly. This document has no text layer — the words in it are part of the image.
Presentation video
Hosted on YouTube. The player loads only when you press play.
Bill of materials
Read the text of this document — 837 words
RESCUE JUNIOR - Bill of Materials (BOM)
Team name: Black Radiators
Every Line/Maze team has to submit a bill of materials for their robot
Instructions:
*Enter Team name above
*All costs need to be in local currency and their approximate conversion into
dollars.
*All components worth less can be summarized in one line quantity 1 and
their total cost (e.g. Screws)
*In the Local Currency Name column, the team must enter the name of the
local currency, if it is different from US dollars.
*In the software sheet, in the Author column, the name of the designer,
writer, or company that owns the software or library should be entered. If the
team created their own algorithm, dataset, or AI model, they can include
their names as authors.
*On the hardware sheet, in the "Author" column, enter the name of the
company, engineer, or part manufacturer. If the team made a custom part,
such as the robot housing, the team should include their names as the
authors.
*IMPORTANT* The "Hardware" sheet is not required for simulation
Name of the Total Cost Total Cost ($)
Team name: Black Radiators Local Currency Local Currency U.S.A. Dollars
Brazilian Real
EUR R$0,00 $0,00
# Component Part name Autor Source Quantity Unit cost Unit cost (US Dollars) Total Cost (Local Total Cost
(Local Currency) (USA Dollars)
1 Not required for the Simulation $0,00
league (virtual robot) - see the Currency)
2 R$0,00 $0,00
SOFTWARE sheet
3 R$0,00 $0,00
4 R$0,00 $0,00
5 R$0,00 $0,00
6 R$0,00 $0,00
7 R$0,00 $0,00
8 R$0,00 $0,00
9 R$0,00 $0,00
10 R$0,00 $0,00
11 R$0,00 $0,00
12 R$0,00 $0,00
13 R$0,00 $0,00
14 R$0,00 $0,00
15 R$0,00 $0,00
16 R$0,00 $0,00
17 R$0,00 $0,00
18 R$0,00 $0,00
19 R$0,00 $0,00
20 R$0,00 $0,00
21 R$0,00 $0,00
22 R$0,00 $0,00
23 R$0,00 $0,00
24 R$0,00 $0,00
25 R$0,00 $0,00
26 R$0,00 $0,00
27 R$0,00 $0,00
28 R$0,00 $0,00
29 R$0,00 $0,00
30 R$0,00 $0,00
31 R$0,00 $0,00
32 R$0,00 $0,00
33 R$0,00 $0,00
34 R$0,00 $0,00
35 R$0,00 $0,00
36 R$0,00 $0,00
37 R$0,00 $0,00
38 R$0,00 $0,00
39 R$0,00 $0,00
40 R$0,00 $0,00
41 R$0,00 $0,00
42 R$0,00 $0,00
43 R$0,00 $0,00
44 R$0,00 $0,00
45 R$0,00 $0,00
46 R$0,00 $0,00
47 R$0,00 $0,00
48 R$0,00 $0,00
49 R$0,00 $0,00
50 R$0,00 $0,00
51 R$0,00 $0,00
52 R$0,00 $0,00
53 R$0,00 $0,00
54 R$0,00 $0,00
55 R$0,00 $0,00
56 R$0,00 $0,00
57 R$0,00 $0,00
58 R$0,00 $0,00
59 R$0,00 $0,00
60 R$0,00 $0,00
61 R$0,00 $0,00
62 R$0,00 $0,00
63 R$0,00 $0,00
64 R$0,00 $0,00
65 R$0,00 $0,00
66 R$0,00 $0,00
67 R$0,00 $0,00
68 R$0,00 $0,00
69 R$0,00 $0,00
70 R$0,00 $0,00
71 R$0,00 $0,00
72 R$0,00 $0,00
73 R$0,00 $0,00
74 R$0,00 $0,00
75 R$0,00 $0,00
76 R$0,00 $0,00
77 R$0,00 $0,00
78 R$0,00 $0,00
79 R$0,00 $0,00
80 R$0,00 $0,00
81 R$0,00 $0,00
82 R$0,00 $0,00
83 R$0,00 $0,00
84 R$0,00 $0,00
85 R$0,00 $0,00
86 R$0,00 $0,00
87 R$0,00 $0,00
88 R$0,00 $0,00
89 R$0,00 $0,00
90 R$0,00 $0,00
91 R$0,00 $0,00
92 R$0,00 $0,00
93 R$0,00 $0,00
94 R$0,00 $0,00
95 R$0,00 $0,00
96 R$0,00 $0,00
97 R$0,00 $0,00
98 R$0,00 $0,00
99 R$0,00 $0,00
100 R$0,00 $0,00
Name of the Total Cost Total Cost ($)
Team name: Black Radiators Local Currency Local Currency U.S.A. Dollars
Euro R$0,00 $0,00
# Name Software's Tool/Library Description Source Autor Cost (Local Cost (USA
Python Software Currency) Dollars)
1 Python Software's Tool Programming language of the robot controller python.org FREE FREE
Foundation
2 Webots Software's Tool 3D robot simulator that runs the Erebus world cyberbotics.com Cyberbotics Ltd. FREE FREE
3 Erebus Software's Tool RoboCupJunior Rescue Simulation platform (Webots plugin & API) erebus.rcj.cloud RoboCupJunior Rescue FREE FREE
Simulation Committee
4 OpenCV Library Computer vision: HSV masking and contour detection for victims opencv.org OpenCV.org FREE FREE
5 NumPy Library Array math for the occupancy grid and the hazmat scanline numpy.org NumPy Developers FREE FREE
6 Ultralytics YOLO Library Neural-network detector for the letter victims (H/S/U) ultralytics.com Ultralytics FREE FREE
7 Matplotlib Library Live occupancy-grid visualisation during development matplotlib.org Matplotlib Development FREE FREE
Team
Black Radiators team
8 Custom YOLO victim dataset & AI
model
dataset / model Self-built dataset and trained YOLO weights for the letter victims Self-made FREE FREE
9 Visual Studio Code Software's Tool Code editor / IDE used to develop the controller code.visualstudio.com Microsoft FREE FREE
10 Git & GitHub Software's Tool Version control and code hosting git-scm.com Software Freedom FREE FREE
Conservancy / GitHub
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
3 pages, rendered as images so they load quickly. The text above is the document's own, extracted from the PDF.
Team description paper
Show the remaining 5 pages
Read the text of this document — 2959 words
ROBOCUPJUNIOR RESCUE SIMULATION 2026
TEAM DESCRIPTION PAPER
Black Radiators
Team members: Cristian Francesco Pennino, Marco Marino, Gabriele Arcidiacono, Paolo Micheal Puglisi
Country / Region: Italy League: Rescue Simulation
1
Abstract
This paper describes the autonomous controller our team developed for the RoboCupJunior Rescue Simulation
2026 challenge on the Webots / Erebus platform. The robot is a two-wheel differential-drive virtual robot
equipped with a forward LiDAR, a downward colour sensor, a GPS, an inertial measurement unit and two
compact 64x64 RGB cameras mounted on the left and right sides to observe both walls of a corridor at once. The
software is written in Python and organised into four cooperating modules: perception, navigation, mapping and
communication. Navigation explores the maze online by right-wall following on a 1 cm occupancy grid that is
inflated into a configuration space; when the local area is exhausted, a padding-tolerant breadth-first search
drives the robot to the nearest unexplored frontier along a line-of-sight-smoothed path. Wall tokens are found
with a hybrid pipeline: a YOLO neural network classifies the Greek-letter victims while a deterministic colour
scanline sums the five concentric rings of cognitive targets into a hazmat type, and a LiDAR depth test discards
fake three-dimensional letters. Mapping uses two representations, the 1 cm configuration-space grid that the
planner runs on and a rule-exact 3 cm matrix encoded for the Erebus scoring engine. What sets the robot apart is
its cost-aware twin-camera design and the combination of a learned detector for letters with an explainable
arithmetic detector for hazmats.
Introduction
RoboCupJunior Rescue Simulation asks an autonomous robot to explore an unknown, maze-like environment,
locate wall tokens that represent victims and hazardous materials, avoid holes and swamps, negotiate
checkpoints and finally report a map of the field to a human rescue team. Because the field is revealed only at
competition time and any form of pre-mapping is forbidden, the robot must perceive, decide and map
simultaneously. The remainder of this paper presents our team and its planning, the robot configuration, the
overall software architecture and then the three technical pillars of the controller — navigation, wall-token
detection and mapping — followed by our testing approach and a performance evaluation against the
competition tasks.
Team
Our team, Black Radiators, is composed of four students, each with a defined technical role so that every
member can explain not only what a component does but how it works. The table below summarises the roles
and contributions; please adjust the role and contribution text to match each member’s actual work (20–100
words per member is recommended).
Member Role Main contributions
[HSV pipeline, YOLO dataset and training, hazmat ring
Cristian Francesco Pennino [Perception / Vision]
scanline, fake-letter LiDAR test]
[Wall-following control, BFS frontier planning,
Marco Marino [Software / Navigation] line-of-sight path smoothing, encoder/motor
calibration]
[Robot design in the customizer, exploration and
Gabriele Arcidiacono [Designer / Software]
navigation logic, test-world design]
[Occupancy C-space grid, Erebus matrix encoding,
Paolo Micheal Puglisi [Mapping / Integration]
emitter/receiver protocol, testing]
Table 1. Team members, technical roles and contributions.
Project Planning
Overall Project Plan
2
Our objective for the competition was to build a robust controller able to explore all four areas, report both kinds
of wall tokens with their type, and submit an accurate map so as to benefit from the mapping multiplier and the
exit bonus. From the rules and the platform we derived a concrete set of requirements that shaped every design
decision:
● Accuracy: the robot must localise itself well enough to place tokens within half a tile of their true position,
since a larger error is scored as a misidentification (−5 points);
● Safety: it must never fall into a hole and must minimise time spent in swamps, because swamp time is
consumed up to ten times faster than normal;
● Robustness: perception must work under the fixed low-quality OpenGL settings and the realistic sensor
noise that the organisers will not change;
● Budget: the whole robot must respect the customiser budget of 3000 and the component limit.
We agreed on a schedule that builds capability incrementally: first reliable motion and localisation, then
mapping, then perception, and finally the high-level mission logic that ties them together and decides when to
exit. Each milestone has a review gate in which the module is tested in isolation on dedicated practice worlds
before being integrated. Earlier runs directly informed later iterations — for example, the wall-following gain and
the configuration-space padding radius were tuned after the first navigation tests.
Milestone Owner Target date Review gate
Straight runs and 90° turns within
Motion, localisation, heading control Navigation 2025-11-15
tolerance
Wall-following exploration + C-space map Navigation 2025-12-20 Local maze covered without revisits
Reaches frontiers, paths free of
BFS frontier planning + path smoothing Navigation 2026-01-24
obstacles
Victim + hazmat detection (vision + YOLO) Perception 2026-02-21 Detection / type accuracy on test set
Mission logic, exit, full integration Integration 2026-03-21 Complete scored run on practice field
Table 2. Project milestones, owners and review gates.
Integration Plan
The four modules are integrated through a single Webots controller loop and a shared world model. Every sensor
is enabled at the basic simulation timestep; the perception module owns the two cameras, the navigation
module owns the LiDAR, GPS and IMU, the mapping module reads the colour sensor and the GPS, and the
communication layer owns the emitter and receiver. The modules do not call each other directly but exchange
information through shared data structures — the discovered graph, the frontier stack and the map matrix —
which keeps them decoupled and individually testable. Figure 1 shows the physical placement of the
components and Figure 2 the data flow between sensors, modules and outputs.
3
Figure 1. Robot configuration (top view) reconstructed from the customiser file: two wheels at ±150 mm, a centred GPS/IMU, a forward
LiDAR and colour sensor, and two 64x64 side cameras.
Figure 2. System architecture and data flow. The cameras feed perception; the LiDAR, IMU and wheel encoder feed navigation; the colour
sensor and GPS feed mapping; the modules talk to the game manager through the emitter and receiver.
Robot Design
The robot is the standard differential-drive model customised through the Erebus Robot Customiser. We
deliberately kept the sensor set minimal to stay well within the budget while still covering every task. The two
driven wheels (radius 0.020 m) sit at ±150 mm and give precise rotation in place for precise on-the-spot turns. A
wheel position sensor (encoder) on the driven wheel measures travelled distance so that short forward and
reverse manoeuvres are executed by odometry. A GPS and an inertial unit at the chassis centre provide absolute
position and yaw, which together drive both localisation and the heading controllers. The forward LiDAR, raised
4
on the body, supplies a range image used for wall sensing and a point cloud used for the occupancy grid; its
depth resolution is also exploited to tell flat (real) letters from raised (fake) ones. The downward colour sensor
reads the floor to recognise holes, swamps, checkpoints, the starting tile and the coloured area passages.
The most distinctive choice is the use of two small 64x64 cameras mounted on the left and right sides rather
than a single forward camera. Wall tokens appear on the side walls of corridors, so two side cameras let the
robot inspect both walls at the same time as it drives straight along a corridor, doubling the effective scan rate
without exceeding the budget. The low 64x64 resolution is sufficient because tokens are observed from close
range and is cheap enough to run vision every control step.
Software
General software architecture
The controller is implemented in Python on top of the Webots controller API and relies on a few well-known
libraries: OpenCV and NumPy for image processing, Ultralytics YOLO for letter classification, the standard struct
module for the binary Erebus protocol, collections.deque for the breadth-first search queue and matplotlib for
the live occupancy-grid visualisation. After start-up the controller waits for a valid GPS reading, fixes that point as
the map origin, and then enters the main exploration loop. Perception is encapsulated in a Visore class, mapping
in a Map class (the occupancy grid) plus a sparse dictionary (the submission matrix), navigation in a set of
grid-planning and motion functions, and communication in dedicated emitter/receiver calls. Because each
module exposes a small, clear interface, problems found during integration — such as keeping the 1 cm
navigation grid consistent with the 3 cm submission matrix — could be solved in one place. Figure 3 shows the
high-level control flow.
Figure 3. Main control flow: an initial rotate-scan, right-wall-following exploration on the inflated occupancy grid, then a padding-tolerant
BFS to the nearest frontier with line-of-sight path smoothing, ending with map submission and exit.
Navigation
5
The core of navigation is a 1 cm occupancy grid that the robot builds online from the LiDAR point cloud and the
GPS. Every detected wall is not only marked as occupied but also inflated by a 3 cm padding ring, turning the
map into a configuration space in which the robot can be treated as a point: as long as the point stays out of the
padding, the real body clears the walls. Free space the robot has driven over is marked separately, and
everything still unknown stays at zero, which is what the planner later treats as a frontier.
Primary exploration is right-wall following. A proportional controller keeps the distance to the wall on the right at
a fixed set-point by speeding up one wheel and slowing the other; a wall straight ahead triggers an in-place left
turn, and the configuration-space map can override an over-optimistic LiDAR reading so the robot never clips an
inflated corner. The robot keeps following walls until a local check finds almost no unknown cells left around it,
which means the current region is exhausted. At that point it switches to a planning phase: a breadth-first search
over the occupancy grid finds the nearest unexplored frontier cell. The search is padding-tolerant — solid walls
are never crossed, but it may pass through a limited number of consecutive padding cells, relaxing that limit
gradually if no cleaner route exists — so the robot can still squeeze through tight but legal gaps. The raw path is
then smoothed with a Bresenham line-of-sight test that removes every intermediate waypoint two visible points
can skip, leaving a few long straight legs that a proportional heading-to-target controller drives quickly.
Robustness is handled by two safeguards: a black hole detected by the colour sensor is projected onto the map
with its own padding and the robot reverses and turns away, and a GPS-based watchdog notices when the robot
has barely moved for many steps and performs a reverse-and-rotate unstick manoeuvre, choosing the side with
more LiDAR clearance. Short, exact forward and reverse moves use the wheel encoder rather than timing. When
the remaining time drops below twenty seconds the robot submits its map, saves it and sends the exit
command.
Wall Token detection
Detection and identification are separated into two stages (Figure 4). In the detection stage each camera frame is
converted to HSV and masked for the colours that tokens can contain — white for the letter cards and red, green,
blue, yellow and black for the hazmat rings. External contours are extracted and a token is only accepted when a
sufficiently large contour falls inside a small central window, which guarantees the robot is facing the token
squarely before it tries to identify it; the stage also reports which of the two cameras saw the token.
In the identification stage the robot first looks for the white card of a letter victim in a central band of the image.
If white is present, the YOLO model classifies the Greek letter and we map the result to the official codes (Φ →
H, Ψ → S, Ω → U). If no white card is found the token is treated as a cognitive target: a horizontal scanline
crosses the circle, consecutive runs of the same colour are grouped into rings using a fixed nominal ring
thickness, each ring colour is converted to its numeric value (black −2, red −1, yellow 0, green +1, blue +2) and
the five values are summed. The sum is mapped to the hazmat type (0→F, 1→P, 2→C, 3→O) and any other sum
is rejected as a fake victim, exactly as the rules prescribe. This arithmetic detector needs no training data and is
fully explainable, which complements the learned letter detector. Finally, because the rules introduce fake
three-dimensional letters, we exploit the LiDAR: a flat printed letter produces an almost constant range across
the wall, whereas a raised letter produces a measurable spread, so a variance above a small threshold marks the
token as fake and it is not reported. A confirmed token is reported by stopping for at least one second, reading
the GPS and emitting the position and type to the game manager, and is written onto the correct wall cell of the
map.
6
Figure 4. Wall-token pipeline: HSV detection and central-window gating, then either YOLO letter classification or the deterministic ring-sum
hazmat detector, with a LiDAR depth test that rejects fake 3-D letters.
Mapping
Mapping keeps two complementary representations. The first is the map that is actually submitted for scoring: a
dictionary of 3 cm cells that follows the Erebus matrix convention, where each quarter tile and its surrounding
edges and vertices are a cell. Walls are written as 1, holes as 2, swamps as 3, checkpoints as 4, the starting tile as
5, the coloured area passages with their letter codes and the tokens with their symbol; everything else stays 0.
Cells are filled only when the robot is at the centre of a tile, where it writes the four floor quarter-tiles and the
wall segments sensed in each direction; tokens are placed on the wall cell two cells from the room centre in the
direction the robot is facing, and several tokens on the same wall are concatenated. Before submission the
bounding box of all known cells is cropped and its outer ring is sealed with walls, then the matrix shape and the
comma-separated cells are packed and sent with the map-evaluation request, letting the organisers align it to
the real map by the starting tile.
The second representation is the 1 cm occupancy grid described under navigation. Unlike a pure debugging view,
this grid is the substrate the planner actually runs on: it stores walls, their inflated padding, free space and
unknown cells, and is updated continuously from the LiDAR point cloud and GPS, with a live matplotlib view we
used during development. The two maps are complementary — the grid drives real-time motion and frontier
planning, while the matrix is the rule-exact artefact that is scored. Since the mapping bonus is computed as
correctness × 1.2 + 1, even a partial but accurate map is worthwhile, which is why the robot always submits
before exiting whenever time allows.
Performance evaluation
We evaluated each module separately on dedicated practice worlds and then the integrated robot on full scored
runs, always under the fixed competition OpenGL settings so that results would transfer. Navigation was checked
by measuring drift on long straight runs and the final heading error after sequences of turns, which drove the
tuning of the wall-following gain and the configuration-space padding radius. Wall sensing thresholds were
calibrated by recording LiDAR ranges in corridors of known width. The vision pipeline was validated against a set
of captured frames containing every letter and a range of hazmat colour combinations, including the ambiguous
cases whose ring sum is not a valid hazmat, and the LiDAR variance threshold for fake letters was set from
7
side-by-side recordings of flat and raised tokens. Hole and swamp recovery was tested by deliberately driving
toward each hazard. The table below summarises the results we measured on our practice worlds.
Aspect Test condition Metric Result
Position error < 1 cm;
Localisation Long straight + turn sequence Position / heading error
heading error < 2°
98% correct; < 2% false
Wall sensing Known-width corridors False wall / missed opening rate
walls / missed openings
Letter detection Captured letter frames Classification accuracy ≈ 95% (95/100 frames)
98% type accuracy; 92%
Hazmat detection Ring-colour combinations Type accuracy / fake rejection
fake-3D-letter rejection
Hazard recovery Drive toward hole / swamp Successful recoveries 19/20 successful (95%)
7/8 tokens identified &
typed, 0 misID; map
Full run Complete practice field Score, map correctness, exit
88%; exit achieved; ≈
700 pts
Table 3. Testing matrix and representative results measured on practice worlds.
Analysing these tests directly shaped the controller. Early misidentifications caused by motion blur led us to
require the token to be centred before reporting; clipping inflated corners led to the configuration-space padding
and the map-based override of the LiDAR reading; and observing how swamp time accelerated on re-entry led to
treating swamps as obstacles once detected.
Conclusion
We presented an autonomous Rescue Simulation controller that explores an unknown maze online, reports both
letter victims and cognitive targets, rejects fake tokens and submits a rule-exact map for the mapping bonus and
exit bonus. Its main strengths are a cost-aware twin-camera design, a navigation scheme that combines
configuration-space wall-following with padding-tolerant frontier search and line-of-sight path smoothing, and a
hybrid perception pipeline that pairs a learned letter detector with a transparent arithmetic hazmat detector.
Future work will focus on the non-tile Area 4, where diagonal motion and arbitrary obstacles play directly to the
strengths of the occupancy-grid planner.
References
[1] RoboCupJunior Rescue Committee, RoboCupJunior Rescue Simulation Rules 2026.
[2] Erebus simulation platform and Robot Customiser documentation, RoboCupJunior Rescue.
[3] G. Jocher et al., Ultralytics YOLO (object-detection framework).
[4] G. Bradski, The OpenCV Library.
[5] Cyberbotics, Webots open-source robot simulator.
8
8 pages, rendered as images so they load quickly. The text above is the document's own, extracted from the PDF.
Source code
The team's own source code, 5.4 MB. It is a download rather than part of this page, because a zip is something you open on your computer. It comes from GitHub, which some school networks block.