This post will contain all the changes that apply to the current rules that are posted on the RoboCupJunior Website.
Section 2.4 - Tiles, Areas, and Walls
The dimensions should read:
- Tiles are 12cm by 12cm
- Quarter tiles are 6cm by 6cm
- Walls are 1cm thick and 6cm tall
Reason for change: To match the simulated environment.
The two statement describing Areas 2 and 3,
“However, the robot’s path must have at least a full tile worth of space.”
should be removed.
Instead the statement
“For areas 2 and 3, regions where the robot cannot physically traverse (i.e.: openings that are half tile length) will not contain victims and hazard maps. Such regions must be fully viewable from the opening.”
should be added.
Reason for change: To broaden the possible field design configurations without creating an impossibility for robots to obtain a perfect score.
Section 3.1 - Construction
- An upper bound to the budget is introduced. Each sensor and wheel costs a certain amount which can be viewed in the Robot Customiser Tool. The upper bound is 3000. The number of sensors are also limited, which can be also viewed from the same tool.
Reason for change: To introduce a more realistic scenario for robot design.
Section 3.2 - Sensors
- Add the option to use inertial measurement unit (IMU) sensors: gyroscopic sensor and accelerometer.
Reason for change: To introduce a wide variety of sensors.
- Remove the necessity of blinking an LED when a victim is detected.
Reason for change: Inability to detect LED flashes by the Main Supervisor.
The whole section should be re-written to this:
4.6.10 Mapping bonus (MB). When the game ends, the robot may submit a matrix with the map of the maze encoded in a particular format. The aim of the map is to encode the geometry of the environment, key elements such as holes, and victim locations. The mapping bonus is a multiplier between 1 and 2.
a. Each quarter tile and its surrounding edges and vertices will be represented by a cell (value).
b. Walls are marked by ‘1’; holes as ‘2’; swamps as ‘3’; checkpoints as ‘4’; starting tile as ‘5’; connection tiles from 1 to 2 as ‘6’, 1 to 3 as ‘7’, 2 to 3 as ‘8’; victims as the corresponding victim code, and any other tiles/edges/vertices should be zero.
c. For curved walls in area 3, the vertex should be represented by a ‘0’
d. The presence of a victim should be marked on the cell that represents the corresponding wall. If more than one victim is on a wall, the entry should be concatenated.
e. Maps can be stored in any rotation as long as it is a multiple of 90°
f. The correctness of a submitted map matrix will be checked against the matrix representing the real map (real map matrix).
i. The starting tile will be used to align the two maps matricies.
ii. For every non-zero entry on both the real and submitted map matrices, the two values are compared.
iii. If the two values match, the correct count is incremented. Otherwise, incorrect count is incremented.
iv. The correctness is given by the ratio of the correct count over the sum of the correct count and incorrect count.
v. The correctness will be calculated for each possible orientation of the submitted map matrix aligned to the real map matrix. The maximum value will be used.
g. The mapping bonus multiplier will be the correctness + 1
h. Ambiguous edge cases will be noted in the official documentation. For new edge cases that were are not defined, please contact the TC and/or the platform development team.
i. Method of submitting a map matrix is described in the documentation (when made available) and in example codes located in the platform releases.
Reason for change: Fixing simple mistakes and aligning it to the platform implementation.