We are very fortunate to be part of an amazing maker and robotics community. We strongly support open-source technology, creativity, and accessible STEM learning.
We also want students to experience one of the most exciting parts of robotics: solving problems and creating their own code and algorithms.
Because of this, some sensors from 2027, across all our RoboCup Junior Australia leagues will not be allowed in competition. This decision is not because these sensors are “bad” or poorly designed. In fact, many of them are fantastic pieces of technology, and we encourage people to continue creating, improving, and sharing them.
Our goal is simply to ensure that RoboCupJunior remains focused on student-created solutions, student learning, and problem-solving.
This is the first communication RoboCupJunior Australia challenge chairs wanted to ensure that teams, and our open source community are aware leading up to the 2027 General Rules.
This includes sensors that:
These sensors provide measurements or readings that students must interpret using their own code.
Students are expected to create the algorithms that turn this raw data into robot behaviour.
Anton’s Mindstorms 8-Channel Line Tracking Sensor
This sensor calculates the position of the line internally and provides a completed result. This means that much of the line-tracking algorithm has already been completed for the student.
Octopus 2-Channel Tracking Module
This sensor detects reflectance and provides raw readings. Students must write their own code to interpret those readings and create the robot’s line-following behaviour.
If the sensor does the thinking, it is not allowed.
If the student does the thinking using the sensor’s data, it is allowed.
We would again like to thank the robotics and maker community for the incredible ideas, open-source projects, and technologies being created and shared. These rule decisions are not intended to discourage innovation. They are designed to keep the competition:
These rules will be established as part of the 2027 General rules and, we will continue to support third-party sensors that are supported in the leagues through our Store.
In this context, “raw data” does not necessarily mean an unprocessed analogue electrical signal.
Most modern sensors perform some internal processing before providing information to a robot. For example, a colour sensor may convert analogue measurements into digital RGB values or assign a colour label before returning the result.
This type of processing is not automatically prohibited. The important question is whether the sensor provides information that students must interpret and use in their own solution, or whether it provides a complete, task-specific answer that substantially replaces the algorithm students would otherwise be expected to develop.
A sensor may therefore perform signal conversion, filtering, calibration, feature extraction, or other low-level processing and still be permitted.
Yes.
For example, a LEGO colour sensor may internally convert readings from its photodetectors into RGB values, reflected-light measurements, or named colours. Although these outputs have been processed by the sensor, students must still decide how to use them within their robot.
Students may need to calibrate thresholds for different lighting conditions, determine how colour readings affect navigation, account for uncertain or changing measurements, and write the robot behaviour that responds to the detected colour.
The sensor provides information, but it does not provide a complete competition solution.
Yes. Cameras and computer vision systems may be used, provided that the students remain responsible for developing the competition solution.
The use of existing computer vision software and frameworks, including tools such as OpenCV and YOLO, is permitted.
Students are not expected to build every software library or machine-learning framework from the ground up. However, they must be able to demonstrate that they have meaningfully developed, configured, trained, or programmed the system for their own task.
Yes, provided that the camera is not being used as a complete, factory-provided solution to the competition task.
An AI-capable camera may be permitted where the students determine which objects the camera should detect, collect or select the training data, train or configure the model themselves, select an appropriate recognition method, and write the code that determines what the robot does with the camera’s output.
The camera may return information such as a detected class, confidence value, object position, or bounding-box coordinates. The use of onboard AI acceleration or onboard image processing does not, by itself, make a camera prohibited.
General-purpose pre-trained models, software libraries, and model architectures may be used as part of a student-developed solution.
However, teams must not rely on a factory-provided or third-party model that already delivers a complete, competition-specific solution without meaningful development by the students.
Where a pre-trained model is used, students should be able to explain what the original model was designed to do, how they adapted or configured it for their task, what data they used, what limitations they identified, and how their own code uses the model’s output.
Transfer learning, fine-tuning, and existing model architectures are permitted, provided that the students have meaningfully developed the resulting solution and understand how it is being used.
Students must remain responsible for developing the overall solution.
They should be able to demonstrate that they selected what the system should recognise; collected, selected, labelled, or prepared the relevant training data; trained, fine-tuned, or configured the model; evaluated whether it works reliably; wrote the code that interprets its output; and developed the robot’s decision-making and behaviour.
Students should also be able to explain why they selected their approach and what trade-offs it involves. For example, colour recognition may be affected by changing lighting conditions, while shape recognition may be affected by occlusion, viewing angle, or object orientation.
Yes.
A camera or vision system may return information such as detected object classes, bounding-box coordinates, object positions, confidence values, colour measurements, or extracted image features.
Students must then write the code that interprets this information and controls the robot. This may include determining where an object is located, navigating towards it, activating a retrieval mechanism, collecting the object, choosing its destination, and sequencing the robot’s actions.
If the students develop these behaviours themselves, the camera is providing information rather than a complete solution.
A system may not meet the intent of the rules if it provides a complete, out-of-the-box solution to a competition task.
This may include a system that uses a factory-provided competition-specific model to recognise all required objects, determines the robot’s path, makes the required competition decisions, directly controls the motors, performs object collection and delivery logic, or completes the task without meaningful student-written algorithms.
The complete system and how it is being used will be considered. A device is not automatically prohibited simply because it contains a camera, processor, or AI capability.
No.
Processing may occur within a sensor, camera, coprocessor, or another permitted device.
The location of the processing is not the main consideration. The important question is whether the students developed the solution and whether they are responsible for interpreting the output and creating the robot’s behaviour.
Teams should be prepared to explain and demonstrate their solution if requested by judges or competition officials.
Depending on the technology used, teams may be asked to show or discuss their source code, training data, data-collection process, image labelling, model training or configuration, testing results, development changes, the output produced by the sensor or model, and how their code turns that output into robot behaviour.
The explanation should be appropriate to the age and experience of the students. The purpose is not to require professional-level machine-learning knowledge, but to confirm that the students understand and developed their solution.
Teams must be able to demonstrate an appropriate understanding of the technology used in their robot.
If a team cannot show that the students trained, configured, programmed, or meaningfully developed the system themselves, the solution may not meet the intent of the rules.
Judges and competition officials may consider the students’ explanation, source code, development process, documentation, and practical demonstration when assessing the system.
The main principle is not that every sensor must provide completely unprocessed data.
The technology may provide information and useful tools, but the students must develop the competition solution.
Students may use modern sensors, open-source software, computer vision libraries, machine-learning frameworks, and AI-capable hardware. They must still be responsible for the meaningful technical work, including training or configuring the system where relevant, interpreting its output, making decisions, and programming the robot’s behaviour.
If you are unsure whether a particular sensor, camera, model, software package, or configuration is permitted, please contact your local RoboCupJunior committee or challenge chair before the competition.
Please include the name and model of the device, a link to its technical documentation, a description of the information it returns, details of any built-in processing or pre-trained models, what the students will train or program, and how the students’ code will use the output.
If you are unsure whether a particular sensor is permitted, please contact your local RoboCupJunior committee or challenge chair before the competition or via the Contact Us page