[robocup-legged] 11x11 RoboCup match

[Peter Stone]

Will,

OK - I agree with all of this.  Having minimal packets that just
include position information plus an agreement beforehand regarding
broad style of play sounds good to me.

Just a few comments on the semantics of the messages (which need to be
clear):

> >>    - Whether the robot can sense the ball, and if so, the ball's mean
> >> location and covariance matrix
> >>      - "sensing the ball" includes both visual sensing and whatever
> >> other mechanisms you have to detect the ball, e.g. the mouth or IR
> >> sensor during a grab.

We need to decide whether "sensing the ball" also includes hearing
about its location from a teammate.  As long as the whole team is in
communication contact with one another, I assume not.  But it should
be specified.


> That packet has the robots broadcasting a current home location :).   
> I called it the current 'destination' of the robot as the robot  
> rarely reaches it - it tends to move before they get there.  I much  
> prefer this over symbolic roles.

OK.  But home location and destination could be different things.  The
goalie's current destination may be out of the goal box to go get the
ball.  But it's home location is still in the goal:  the other robots
shouldn't deduce that there is currently no goalie....

Perhaps the packet should include both a home location ( x,y is fine -
it doesn't need to be symbolic ) and a current destination.

  Peter





> 
> On 07/01/2006, at 1:44 PM, Peter Stone wrote:
> 
> >> - Communications
> >>    I was planning to have something simple like that used in the
> >> rUNSWift/NUBots open challenge last year.  That was a UDP broadcast
> >> packet.  Each robot would broadcast:
> >>    - Its team and player number
> >>    - Its own location and covariance matrix
> >>    - Whether the robot can sense the ball, and if so, the ball's mean
> >> location and covariance matrix
> >>      - "sensing the ball" includes both visual sensing and whatever
> >> other mechanisms you have to detect the ball, e.g. the mouth or IR
> >> sensor during a grab.
> >>    - The current destination of this robot.  This might be the
> >> location of the ball, or a location on the field.
> >>
> >> I don't know that we need much else.  We might want an: "I'm going to
> >> kick the ball here", section in the packet.  I wouldn't want too much
> >> more than that: Keep It Simple and Stupid.  We didn't used any more
> >> than this in our pick-up open challenge last year.  Teams that want
> >> to use more certainly could - amongst those robots using that code  
> >> base.
> >
> > What about some sense of role or formation?
> 
> Roles are a great idea, and the above packet supports them.  rUNSWift  
> and NUBots both already use a packet very similar to this for their  
> normal teams.  As well as using a packet like this for the open  
> challenge pickup game we demonstrated at RoboCup 05.
> 
> A formation (set play, or set of roles) could be added to the packet,  
> but I don't think it is required.
> 
> Of course, you have more experience with 11x11 games than I do.  What  
> would you suggest?  (editing pass through the email: It seems like  
> one of the things you suggest lower down is already in the packet.)
> 
> > Do you envision assigning
> > the robots ahead of time to be defenders, midfielders, and forwards?
> > Or is that something they should work out on their own.
> 
> That is something they should work out on their own.  Something like  
> a bi-partite graph matching between the current robot location and  
> the central locations for the roles of the current formation.  Also,  
> because each robot is sending their current destination, you can  
> usually find the role of a robot without having to have prior  
> agreement about the roles.  That allows you to add some hysteresis.
> 
> As long as the style of play/formation that each robot thinks you're  
> using is similar, then the robot with a broadcast destination closest  
> to where-ever you'd put a role, is probably intending to play that  
> role.  e.g.  If you are playing a zone defence, then you know which  
> player is playing which zone by their destination.  If you are  
> playing a man-on-man defence then you'll be looking for the robot  
> whose destination is closest to each opponent player.  On offence,  
> the robot whose destination is the ball is the one calling for the ball.
> 
> As long as the styles of play are broadly similar, the roles are  
> pretty robust.  For the 11x11 game we might want to agree on a broad  
> style of play, but I don't think we need much more than that.
> 
> To deal with this in the pickup match last year we added some extra  
> roles that we didn't intend to play, in case Newcastle played them.   
> That way we could play with team-mates whose formation had either a  
> striker and a defender, or two defenders.
> 
> > Personally, I think it would be a nice challenge to be able to place
> > the robots down on the field without having pre-assigned roles (except
> > perhaps for the goalie), and to include enough in the protocol to
> > enable them to work out positioning.
> 
> I agree.  And the above packet was designed to support that.  And  
> this is exactly what rUNSWift and NUBots demonstrated last year in  
> the open challenge.  (Although we had some bugs in the kick-off code :).
> 
> > Perhaps the robots could then
> > also broadcast a current home location or symbolic position (e.g. left
> > defense) that would enable this.  It would be up to the robots to try
> > to make sure that they're not all playing defense or all playing
> > offense, though.
> 
> That packet has the robots broadcasting a current home location :).   
> I called it the current 'destination' of the robot as the robot  
> rarely reaches it - it tends to move before they get there.  I much  
> prefer this over symbolic roles.
> 
> Some prior agreement on broad style is required.  If we agreed on a  
> few major styles, then sending which one is currently being played in  
> the broadcast packet would make sense.  For a first game, I'd KISS  
> and just pick one style.
> 
> > This is something that we've all thought about in the context of a
> > single coherent team.  But I think it's a much greater challenge, with
> > interesting scientific implications, to think about how to get the
> > robots to self-organize without any previous coordination.
> 
> Yup - and this is what NUBots and rUNSWift demonstrated in the open  
> challenge last year.  We didn't agree on roles.  We didn't agree on  
> formations (as I said, rUNSWift used the union of the sets of roles  
> from two formations when deciding what the team-mates were doing).
> 
> Kick-off is an interesting one.  Last year in the challenge we used a  
> randomized algorithm.  We assigned the forwards to lanes (left,  
> middle, right) based on their location.  If you detect a conflict  
> with another player (i.e. receive a packet with another robot's  
> destination in your lane) then you choose the empty lane with 50%  
> probability, otherwise stay with your current lane.  A similar  
> algorithm is applied to see which of the left or right players is  
> forward, and which is behind the 1/4 line.
> 
> This all gets more complex with an 11x11 team of course.  I was  
> assuming that there would be some flocking behaviours to try and stay  
> in open regions, etc.  I'd rather a demonstrated need before we go to  
> a more complex packet though.
> 
> Be well,
> 
> Will          :-}