Dear RoboCup Junior Rescue Committee and Community,
First of all, I would like to thank the committee for all the effort and care put into organizing this year’s competition. I’m writing this post/reply not as a competitor, but as someone who just completed their final year in Rescue Line, as I’ll be starting college next fall, but also as someone who cares about the future of this league.
As was suggested during the competition in Salvador, I’m writing to share some thoughts on the topic of AI use, especially in light of this year’s clarification that was released less than two weeks before the competition. While this post isn’t about this year’s timing, I believe it’s important to reflect on how AI use could be handled going forward, especially as its role in robotics becomes increasingly relevant and unavoidable.
Our team, Airborne, used YOLO-based models for victim and silver line detection. We collected thousands of images using a custom capture system we developed directly on the robot, retrained the models multiple times with different configurations, and deployed them in real-world field conditions. Beyond that, we opened two issues in the Ultralytics repository related to bugs we encountered, and also submitted a pull request to improve another part of the framework. While these contributions weren’t changes to the model architecture itself, they were essential to making the models usable for our application. In other words, we contributed to the development of the surrounding infrastructure, something that is often just as important as model training. At the end of all of this, we got placed in bucket 5, meaning we only got a 7% bonus (out of 10%).
Looking ahead to 2026 and beyond, I’d like to offer a few suggestions and reflections:
-
AI should not be restricted simply because it is effective and “simple to use” or “plug and play”. Penalizing or limiting the use of tools just because they perform well risks discouraging teams from applying real-world, cutting-edge solutions to relevant problems. RoboCup Junior should be a space for learning, creativity, and innovation, not for avoiding the best tools available. (I do believe that Neural Networks have already surpassed traditional computer vision models when it comes to perception).
-
Development should be understood more broadly. It’s not just about changing the architecture or the loss function of a model. Contributions like building custom data collection methods, solving integration bugs, contributing to open-source tools, or adapting models to embedded hardware all represent real, meaningful and time-consuming development work. These efforts should be recognized, not discouraged.
-
If the goal is to promote originality and avoid using too many pre-trained models or tested architectures, then the challenges themselves can be designed to require more context-aware or creative solutions. In other words, if there is a tool that can already easily solve a part of the competition ruleset, it might be a better idea to evolve the ruleset to be better solved using other “more desirable” methods.
-
Pre-trained models and standard architectures are not shortcuts when used responsibly. They are starting points, just like sensors, motors, or libraries, and should be treated as such. What matters is how teams adapt and integrate them, not whether they built everything from scratch. (I haven’t seen many teams messing around with copper coils to create their motors from scratch
Finally, I know from experience how much effort teams put into preparing for this competition, and I believe clear, forward-thinking rules will help teams plan and innovate with confidence. I hope the committee continues to provide an environment where exploration of AI is welcomed, not penalized. A nice compromise is redesigning part of the competition to not be so effectively solved with AI/Neural Networks.
Thanks again for your attention and consideration! I’m open to discuss further. Please note that this is just my opinion/suggestion and not intended as criticism in any way.
Best Regards,
Francisco Gaspar
Team Airborne
TLDR: In short, applying import taxes on the line “from ultralytics import YOLO” may not be the way forward. At this rate, we’ll need a visa to import YOLO and a license to debug it.
(This TLDR is a joke, please do read the full points made above, thank you : )