in addition to the voting results, the following issues have been fixed in the new rule draft:
Fixed a number of typos
Line 409: added that it is also forbidden to communicate the orientation how the robot re-enters the field (meaning from which side it enters) as a clarification to position.
Line 395: “Any other computers of team members are only allowed to communicate by tethered LAN.” is not crossed out anymore (that was a mistake)
Line 405: added that pressing buttons to start or stop general behavior is allowed as communication as well (many teams use it to soften the motors when they have to pick them up from the field and I think this should be generally allowed)
Line 1345: added "A manually placed goal keeper has to be within the team’s own goal area touching the goal line. A manually positioned striker can take any legal position within the team’s own half
Line 1358: added “The striker for dropped ball may be positioned at any legal position within the team’s own half outside of the center circle.”
Replaced “drop ball” with “dropped ball” (which is used in FIFA wording)
Line 1320: Added a robot handler in AdultSize may not communicate with a robot in any way, including verbal, while the robot is in play
Line 417: Added that only for Kid and Teen Size no humans are allowed on the field.
Added the forfeit rule to Section 2 right before “Gameplay”
Line 252: Added the clarification that “consists of” can also mean a broken robot on the side of the field: If a team has not at least one player (who may be incapable to play) at the side of the field, it is considered a forfeit.
In Section 2, added that overtime is only applied if the ball reached any of the goal lines (taken from the 2015 rules) and added that teams may agree to skip the regular penalty kicks and proceed to the extended ones right away (which was applied the last two years anyway).
Suspended the rule in line 1171 that penalty kicks continue after the five trials if both have the same amount of goals.
Moved the rule how free kicks are signaled from “free kick” to “procedure” section
Line 920: clarified that the shoot is not retaken if an opponent is closer than the minimal allowed distance, but that the opponent suffers a removal penalty
Line 650: Fixed that the ball only needs to be touched and not moved to be in play (to be consistent with the other RoboCup specific rules)
Added Philipp in the acknowledgement for his help with the LaTeX file
Line 838: No yellow cards for leaving the field
Line 838: No yellow cards for not respecting the required distance for corner kicks, free kicks and throw-ins (it is defined elsewhere that a 30 seconds removal penalty applies)
Line 1200: Inserted “(new) or which are suffering from a removal penalty or are currently in service” – otherwise some teams might not have any robot left for a penalty shoot-out
You can find the latest version of the rule draft (which is NOT final yet) in the official git repository and you can also check the specific changes by using the git function to display changes within the last commit.
If you have any concerns about the rule draft, found mistakes or feel that there is something missing from the rule discussion that has not been picked up or voted on, post it here or email the TC directly until the end of this week. We are undergoing a final review of the draft within the TC as well and will publish the final version of the rules next week.
One thing I’ve noticed:
The pdf of the rules that is in the repository has raster fonts (zoom in on the text and you will eventually see individual pixels) instead of vector fonts (as it should be), and trying to highlight text in the document and copy it somewhere else (e.g. for the purpose of a rule discussion post) results in garbage characters. I’m not sure if any post-processing was done on the pdf that could cause that, but when I clone the repository and simply compile the document without changing anything at all, I get neither of these two problems. Any ideas?
I blame Windows for it, but probably I have some weird setting in my Texmaker. I use Texmaker under Linux as well and have no problems when compiling. I’m currently traveling and could only compile this under Windows with the broken setup, but I’ll fix it for the final version and the version that is uploaded will have vector fonts and everything for sure.
If someone is very knowledgeable about Texmaker and can point me to the setting I have to change, it would be highly appreciated!
In the summary of voting results, it was mentioned that some comments were briefly heard on the concerns of the push-recovery challenge. While it is still possible to change the rules we would like to strongly re-emphasize the case that was made, and justify that they should not just be brief comments.
Originally, the challenge was unfair for small robots, until at RoboCup 2016 it was decided that the distance D would be normalised by the robot’s mass. That was definitely a good decision, but now the challenge is just as well unfair for large robots. The ground projected distance D is plainly not a suitable metric for judging push resistance.
For large disparities in mass (e.g factor of 2), it is entirely feasible that a smaller robot delivers a push recovery test that a large robot cannot even hypothetically beat because D is limited to L, while at the same time the smaller robot only has to absorb 1/7th of the energy. This is a systematic problem, not just in extreme cases.
Please refer to the following diagram (for the most part to scale) which illustrates the problem:
We think that the robots should be ranked by the amount of momentum they were able to absorb, normalised by their mass and CoM height. This makes a lot of sense, and is also illustrated in the above diagram.
Please refer to the original thread for more details and justification:
So they should be ranked by (K is the same for all robots using the same bottle)
math.sqrt(delta_H)/mRobot
However, I do not see a reason to divide by HCom, since HCom allows bigger feet (robot can compensate for larger push just using the ankles) and larger steps, so that advantage should cancel out.
So in the final version we will change “ranked by D/m” with “ranked by math.sqrt(deltaH)/m” but the rest will remain untouched for now. We invite a further discussion about this topic during the rule discussion meeting in Japan!
Great that the comments have made it into the rules.
As a final note, dividing by HCom penalises larger robots (not the other way around) to compensate for the fact that they have bigger feet, can take bigger steps etc. That was the idea.
The current ranking is given by math.sqrt(deltaH)/mRobot. This is proportional to the initial velocity of the robot after the impact. So let us suppose we have a 30cm tall robot and a 3m tall robot, and both of them receive an initial velocity of 10cm/s. By the current ranking, if both robots are successful, they will attain the same score. Clearly however, a 30cm robot that can recover from an initial CoM velocity of 10cm/s is vastly more of an achievement than the same for a 3m robot. This is what dividing by HCom accounts for.
