[robocup-small] New Referee Box Protocol

[Angelo Gurzoni Jr]

Ops, I'm sorry, I mistakenly thought you were talking about the score, not
the command. Sorry.

Anyway, the command also has a meaning. This command cannot be inferred with
100% certainty (emphasis on the need to be certain) thus, for the AIs to be
able to compute that without the need to wait several seconds and still have
to deal with uncertainty, it should be there. Example: you shoot to the goal
from the goal kick, the ball goes in, but it's not valid by some reason, a
fault probably. Then what ? you need to wait the next command to then infer
what may have happened. To make it simple, why not issue the command 'goal'
?

It's not the same with the yellow/red, because these will show on the
counters immediately

Cheers



-----Original Message-----
From: robocup-small-bounces at cc.gatech.edu
[mailto:robocup-small-bounces at cc.gatech.edu] On Behalf Of Angelo Gurzoni Jr
Sent: Tuesday, November 13, 2012 6:36 PM
To: Michael Eischer; robocup-small-bounces at cc.gatech.edu;
robocup-small at cc.gatech.edu
Subject: Re: [robocup-small] New Referee Box Protocol

Michaele, the reason to have the goal blue/yellow is very simple: regardless
of what a team may infer, this is the official score. It reflects what the
official score keeping application has stored, and if it's wrong by any
reason (a mistaken click or any accident we may think) the teams can see it
without going over the sholder of the assistant referee.



Cheers
Angelo


------Original Message------
From: Michael Eischer
Sender: robocup-small-bounces at cc.gatech.edu
To: robocup-small at cc.gatech.edu
Subject: Re: [robocup-small] New Referee Box Protocol
Sent: Nov 13, 2012 6:28 PM

> 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.
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.


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.

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 ;-)

Michael
_______________________________________________
robocup-small mailing list
robocup-small at cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small


Sent via BlackBerry from T-Mobile
_______________________________________________
robocup-small mailing list
robocup-small at cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small