we have tested small Bluetooth modules at RoboCup Junior Bangkok 2022 that provide a referee-controllable GPIO to start and stop the robot. For RoboCup Bordeaux 2023 (and only for the international competition) we have put into the rules that being able to integrate this will be required in some form. Current PDF versions of the 2023-draft-rules are linked from this thread
The idea is to build a communications system over the coming years (a little bit more every year starting 2024) that will make it easier for teams to implement robot-to-robot communications in a standardized way so that useful communication between robots from different teams can be accomplished for SuperTeam games. For this purpose we the idea would be to āupgradeā from the single start/stop GPIO to a UART (or maybe SPI or IĀ²C, suggest what you think would work best) connection that standardized messages could be sent and received through. Message types could be:
Heartbeat to let team member robots know a robot is still there (if a robot gets stopped or removed from the game this would stop and other robots could adapt)
Coordination messages for robots to choose which robot(s) play which positions (defender, attack, other roles in SuperTeams)
Ball location estimate
Robotās own position estimate
Position estimates of other robots
Custom data packets
Anything you suggest here
We would like to provide standardized data types for as many things as we can and make those the easiest to use so robots from different teams can communicate most effectively without teams having to change much of their code.
What do you think about this idea? It is in the very early stages so all feedback is welcome.
Hello David, hello forum,
yes, great idea, we should go into this direction, especially if āthe deviceā is provided by the organizer and has to have a standardized interface.
Thoughts about his:
The number of serial ports is restricted and some boards just do nor have a āfreeā UART. So I would recommend not to use UART.
SPI is a standard in computing, but due to the fact, that most sensors use I2C the SPI is not used on all robots and again I would like to see this interface without the need of a redesign of the main-board.
CAN-Bus is probably the best Bus system for robots. It is no coincidence that the whole car industry uses CAN - but again, this would mean redesign for most teams.
That leads to I2C.
It is easy to implement as every robot uses it anyway.
You even do not need an additional port for this and it is easy to implement into existing programs.
If you provide a decent protocol and documentation this is the way I would love to see.
On the āairā - side (that teams do not have to bother about) consider the following:
The major teams In Bangkok had lots of problems with their communication due to flood of wifi from local hotspots.
The communication-board provided for the junior superteams did not work. (same problem?)
If teams use bluetooth to let the robots talk to each other anyway, could we run into similar problems using bluetooth there?
Think of 12 Teams playing a superteam game. The ācontrollerā then has to use 12 different bluetooth connections and shall not have communication gaps.
Is there a better way of doing this?
(other frequencies, master-multislave modes, ā¦)
We definitely have to test this in a large scale before declaring a āmust useā - standard.
So a single switch on/off pin as mentioned in the draft rules is fine, but we should not implement any use of this into the 2023 gameplay rules.
Hi Roland,
I absolutely agree with you that I2C is the best protocol for communication with this module because it does not require any additional pins and is easy to implement. The reason why this year UART was used is that it is easiest to implement in code. Actual devices that were used this year were able to use I2C as well.
āThe communication-board provided for the junior superteams did not work. (same problem?)ā
It is not true that communication boards did not work. Why they were not used in superteam matches is because of organisation problems(some teams were not aware that it will be used even when it was in newsletters, captain and mentor meetings and bulletin boards) and we had only specific time that we were able to use SSL field so we needed to act fast. But they were tested and used in one of the technical challenges where they proved to be working even in such ādifficult conditionsā. Also, I did testing of connection stability and it worked as well as much more testing at home.
I think that we should implement it into the 2023 rules and make it a āmust useā - standard because this way we will make sure that every team will be aware that they should be ready to use it and be prepared. Anyways in the worst scenario, it is really easy just to not use them (:. Also, these modules will be tested as well as well documented. I also plan to test them in our national competition(in Slovakia, something like a technical challenge) and maybe in other national competitions as well?
Why I think Bluetooth 5.0 is the best way to go is because firstly it is really robust against interference(because of Adaptive Frequency Hopping and many more techniques it uses). Second, it uses a 2.4Ghz frequency band that is āfree to useā all around the world which is not true for example for LoRa and some others. Another thing is that is really well established and there is a lot of ICs that are really cheap that can do Bluetooth. This way I was able to push the cost down to 3$ per module(may be different in the future but no more than 5$).
the comms module is now specified to be used in the SuperTeam games at the International Competition (i.e. Bordeaux). See final rules for what details we have.
Do you have ideas for how to go about extending functionality for future years? This communications thing is going to be an ongoing topic of discussion.