Soccer rules for 2019 released

[mareksuppa]

Hello everyone,

I am pleased to announce that the draft of the 2019 rules for RCJ Soccer can now be found at http://junior.robocup.org/rcj-soccer-open/

Although it is still a draft, we expect very little (if any) changes. The rules you find on the link above are very close to the rules that will be used in Sydney, 2019.

If you have any questions, comments, remarks or other feedback, please feel free to either reply to this thread or create a new on this forum in the RoboCupJunior Soccer category.

Thanks!

-- Marek

[pmolzer]

Hi,
my team is building robots that use both Raspberry Pi and Arduino. The Arduino controls the motors and can be powered off independently of the Pi.

With regards to the rule that states a robot must be powered off when taken out of the field, would this rule apply to both the Arduino and the Pi? The problem is that the Pi must be shut down gracefully and the boot sequence an software preparation can take some time to complete. I believe the intention of the rules is to ensure that the wheels are powered off. If so, then it would be sufficient to power off the Arduino.

Could the rule be reworded to require the "wheel motor controller" to be powered off instead of the "robot"?

thanks
Phil

[mareksuppa]

Hi @pmolzer,

With regards to the rule that states a robot must be powered off when taken out of the field, would this rule apply to both the Arduino and the Pi? The problem is that the Pi must be shut down gracefully and the boot sequence an software preparation can take some time to complete. I believe the intention of the rules is to ensure that the wheels are powered off. If so, then it would be sufficient to power off the Arduino.

The intent of the rule is indeed to ensure that once a robot is taken out of the field it can no longer affect the game, whether by spinning wheels or sending information to other robots (that may be still in the game).

At the same time, however, we understand that the RPi needs to shut down gracefully and its boot sequence takes some time to complete. We would therefore consider the robot "turned off" once everything but the RPi would be powered off.

Do let me know if this helps.

Thanks!

-- Marek

[pmolzer]

Hi Marek,
Yes this is helpful. They still face a technical challenge because the serial cable between RPi and arduino also sends power. So even though the power is disconnected to the motor controllers, the Arduino is still awake. I suggest changing the wording of the rule to state simply that motor power must be turned off, rather than saying that the robot must be shut off.

I realize that this leaves in place the possibility for the robots to communicate with each other. Although they are not using the feature, I suspect that RPi can talk to each other over bluetooth.

[mareksuppa]

Hi @pmolzer,

I understand where you are coming from but the rule was explicitly design to prevent complains that usually go like this:

This robot still sent information to the other one in play whilst being out-of-play!
Oh, and they are also pushing some buttons on that out-of-play robot -- how do we know they are not remotely controlling the other one?

It is therefore quite improbable we would go for just the motor power being turned off as opposed to the whole robot.

---

With regards to your technical challenges, to be completely honest, I would find a serial cable attached to Arduino still acceptable (even though the other option of attaching Arduino to RPi via GPIO and logic level converter may be a worthy technical challenge in and of it self ).

With regards to slow boot of RPi, I do believe you can get it down to about 20 seconds in total (this is not more than an educated guess based on experiences of others). If you would like to get deeper into this on this forum, please do so by creating a new thread and providing the output of systemd-analyze critical-chain and systemd-analyze blame. As RPi is used by many teams, it can be of great value to others as well.

Thanks a ton for keeping the conversation going!

-- Marek

[Ardi123]

Maybe adding an additional table where teams have to put their robot when it is out of bounds (and not touch it) could do it?
Of course if the team plans to repair the robot they have to turn it down, but otherwise, it should stay on that table.

This way the out of bounds robot cannot send any information, except the fact that it is not playing, it looks less suspicious and it is harder to cheat.

I personally think it is really hard to control the robot that is in the field since it is playing in a very dynamic environment and robots are much faster and more precise in decision making than humans, but of course, someone may get creative.

[Andrea]

Hello all
I have been following this thread because we as well intend to use a Raspi.
I find the rule make sense in its way, but at the same time I think it should be considered, that it already is hard to set up a bluetooth connection with the robots because of the heavily used frequencies. Given the rule to shut down a robot every time completely makes it nearly impossible to maintain a communication. I see that this would give teams the opportunity to cheat. But I do think that Ardi123's suggestion would adress this issue and in addition solve, in my opinion, all above mentioned issues.
Have a great day and thanks for consideration
andrea

[mareksuppa]

Hello everyone,

Thanks for the discussion here.

We discussed the problem in the TC as well. As I said in https://junior.forum.robocup.org/t/final-soccer-rules-and-rubrics-for-2019-are-online/806 and despite my claims above, the TC concluded that it would indeed be better for the next year not to require robots to be turned off when taken off the field.

Let me also highlight an important lesson here: do not be afraid to challenge my view on this forum. Although I represent the TC here, we try to listen and do what is best for the whole league -- even if some of us may not fully agree .

Thanks again!

-- Marek