[robocup-small] [Rc-ssl-oc] New Referee Box Protocol

[Christopher Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

OK, we can add an Exchange Goalie command if we want. However this
would introduce some fairly significant changes to gameplay flow, which
is something the proposed refbox changes so far have not done—so far I
have proposed changing the protocol in ways that would not require the
people involved in the game to do anything different to the way they
did before. Adding this command, though, means that now the referee has
to communicate goalie swaps to the refbox operator. On the upside,
goalie swaps can probably now happen without the robot handler actually
touching any robots—assuming we communicate the pattern number and not
simply the fact that a swap happened, the robots can rearrange
themselves. However, because this would be more work for the refereeing
team (robot handler asks referee to swap goalies, referee has to pass
that message to the referee box operator who inputs it, which didn’t
happen before), I would like to get some input from referees on whether
they think this is good or bad.

However, this leads to a side observation: should we NOT actually have a
command for “swap goalie”, instead we just send the goalie’s pattern
number as part of TeamInfo? If we’re going to do this, we might as well
do it right—just sending a “swap goalie” command without a pattern
number is pretty much as bad as not sending the command at all, because
you still aren’t telling the team which robot to use as the new goalie.
This would also be nice because it would let the opposing team reliably
know which robot was the goalie to avoid Interference with the Goalie
calls!

As for your comment on the data time for time, IMO integers are just
plain better than FP when they make sense, as they do for microsecond
times. If anything we should change SSL-Vision to use integer
microseconds instead of double seconds, but that’s a discussion for the
future because we either change the data type of the field (breaking
backwards compatibility) or we add another field (in which case why
even bother, since it’s so easy to convert between units).

As for speed limit, I don’t see what this has to do with the referee
box? Ball speed measurement is a very complex topic because it has to
be done with incredibly reliable filtering code on the output of
SSL-Vision. IMO that’s not the referee box’s job; it should be either
inside SSL-Vision or in a separate program. To me, the referee box is a
way for humans to communicate with computers, and should be simple,
reliable, and easy to use. Ball speed calculation on the other hand is
complicated, maybe not very reliable (maybe?), and has no human input
at all—a completely different type of job!

Chris

On Sat, 17 Nov 2012 02:54:37 -0200
"Angelo Gurzoni Jr" <jgurzoni at yahoo.com.br> wrote:

> Hello
> I guess now is a good time to add a command to the protocol, so why
> not ?
> 
> On related topic, one thing I seem to keep forgetting to
> mention....if we're going to enforce ball speed limit having a
> measurement, should it be among the referee commands as well ? or
> would that be discussion for another time ?
> 
> 
> 
> Cheers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEAREDAAYFAlCnJ5cACgkQXUF6hOTGP7fJHwCeL0M63fs6+RtdV3HMkGLBEJNw
X2UAoIYvsLavGlNl6J9Y5Pg3bj5CQSt6
=FW4O
-----END PGP SIGNATURE-----