[robocup-small] New Referee Box Protocol

[Michael Eischer]

>> 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?
To reconstruct the view your AI had, you need the timestamp at which the 
packet arrived. There's a small chance that, even if the clocks of 
vision and refbox are synced via NTP, some packets arrive in a different 
order then the timestamps suggest.
The only use for such precision that I can think of would be an 
automated refbox. As some commands have time limits even a fraction of a 
second could matter.
>> 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.
I meant to include the command and the status in one packet, but in 
different submessages to highlight which timestamp the data belongs to, 
just in case of having to timestamps.