[robocup-small] New Referee Box Protocol

[Christopher Head]

On Tue, 13 Nov 2012 21:28:56 +0100
Michael Eischer <michael.eischer at robotics-erlangen.de> wrote:

> I've overlooked that a refbox command also includes status
> information not just commands.
> However for proper interleaving (that is by the time the 
> packets/commands were issued) of vision and refbox packets you'd also 
> need the time when the refbox command(just ignore the status
> information for now) was originally issued. That is for the refbox
> command it doesn't matter when a team receives it. Instead it takes
> effect the moment it has been issued. As you can't guarantee that
> every team will receive a command the first time it's sent, it should
> also be accompanied with a timestamp that tells when it was issued.
> Such a timestamp should be used in conjunction with the command
> counter, unless one assumes that there's always a delay of at least
> one microsecond between two commands. The timestamp could be used to 
> synchronize timers f.e. for the free kicks time limit.

This does make some sense, but I’m not sure we really need to go that
far. The way I saw it, you might record a complete log of vision
packets and a complete log of refbox packets, and then you could use
the timestamps to interleave them later. If you lose a refbox packet,
it doesn’t really matter much because you will only be off by a
fraction of a second (and, moreover, because you lost that packet, your
log accurately reflects what your team’s AI believed to be true—the
packet was lost, so you didn’t change your internal state at that
time). We could replace the command counter with a command timestamp,
or have both, but is it worth it?

> The command and the status information represent two different
> things. Just by listening to the commands you're able to infer the
> TeamInfos (except for red and yellow cards). In addition it's only
> updated once in a while. The team info on the other hand is updated
> with every packet sent. Thus I suggest to split these into two
> messages and join both in a wrapper message.

Actually, in most packets, neither one changes, probably only once per
second the data will change. But because there might be packet loss, we
have to send both parts in every packet. So does it help to have
multiple messages? We can split it up if it’s useful, but the command
part is so small it seemed easier to just leave it inside the main
message.

> Just to mention it:
> Why do we have a goal blue/yellow command but none for yellow/red
> cards? Both can be inferred from the team infos or be sent via a
> command (No I don't want a command for yellow/red cards). Seems to be
> a little inconsistent ;-)

I originally didn’t include goal blue/yellow, but Angelo explained why
he wants them in a separate e-mail.

Chris