[robocup-small] New Referee Box Protocol

[Joydeep Biswas]

Some thoughts:

1. Timestamp: Any format with precision better than millisecond is
fine. Like Angelo said, to maintain consistence, it's best to stick to
the same type for both vision and the referee.
2. Timestamp and counts: I agree with Chris. They are both useful, and
even if you drop a packet, it is important to know (for log analysis
later) that you did drop it, not that a packet was not sent.
3. UDP vs. TCP: We're currently using UDP just for the ease of
programming. Every other feature that we want, including dynamic
subscription / removal and subnet broadcast is perfectly doable in
TCP, and there are numerous programs with these features implemented
with TCP today. I do however agree that coding this would be more
involved, and especially since I'm not volunteering to do this (yet),
I'll live with the UDP solution.

On a somewhat related topic: Why not combine the referee and vision to
a single computer? The referee program takes negligible resources, and
using the same computer for vision and referee would obviate the time
sync issue between vision and the referee (especially if they both
used the same format :) ).

-Joydeep


On Mon, Nov 12, 2012 at 5:50 AM, Christopher Head <chead at chead.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> On Sun, 11 Nov 2012 12:04:42 +0100
> Michael Eischer <michael.eischer at robotics-erlangen.de> wrote:
>
>> Having followed the discussion about the timestamp, here my
>> suggestions for other parts of the protocol:
>> 1. The stage_time_left should be an optional value. That way only the
>> refbox has to check for which stages the value has to be set.
>
> This one was supposed to be optional, as the comment suggested. I guess
> I accidentally wrote “required”.
>
>> 2. Having both a command counter and a timestamp is unnecessary as
>> both values should increase along each other. I suggest to drop the
>> command_counter. It allows teams to check for lost packets, but as
>> there's no way to recover that packet and every packet includes the
>> whole information, it doesn't provide any benefit.
>
> The timestamp is the timestamp of the packet, so it changes with each
> packet. The command counter only counts changes to the command, so it
> will probably only increment once every handful of seconds. It’s OK to
> lose a packet or two, as long as you don’t lose any commands. That’s
> why the counter only counts commands. The timestamp is there so you can
> properly interleave referee box packets with vision packets.
>
>> 3. The goal yellow and blue commands are just for information, but
>> require a special case for handling correctly. As they can be easily
>> inferred from the team info, I'd drop them.
>
> A member of another team specifically asked to keep them in. Surely
> it’s not that hard to just add them as two extra cases along with “case
> Referee::Command::STOP” since they all mean exactly the same thing?
>
>> 4. It would be nice to have a way to switch the sides and team colors
>> during half time.
>
> The referee box already provides this ability, but it’s not reported to
> the teams as a command. It just swaps all the operating variables
> between the two teams (cards, goals, and names). Do we need the command
> sent over the network as well? It seems like it’s probably not worth
> it—it would save only one mouse click on a Swap Colours button in the
> AI, but it would require a way to prevent the colours from swapping more
> than once which would be some code or maybe another field in the packet
> instead of just a command, neither of which is all that nice.
>
> Chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEAREDAAYFAlCg1HgACgkQXUF6hOTGP7eqmgCcD2/4busYd5FxXI9GbFHE54Xv
> nEMAnjA0d6yI+jAjINzsBasdeefckrRT
> =9XMX
> -----END PGP SIGNATURE-----
> _______________________________________________
> robocup-small mailing list
> robocup-small at cc.gatech.edu
> https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small