[robocup-legged] 11x11 RoboCup match

[Andrew Williams]

Hello,
FYI.  The SpelBots are interested in participating in the 11x11 demo
matches.  We plan to have a total of 12 AIBOs soon.

Regards,

-- Andrew
SpelBots

On 1/12/06, Peter Stone <pstone at cs.utexas.edu> wrote:
>
> 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          :-}
>
> _______________________________________________
> robocup-legged mailing list
> robocup-legged at cc.gatech.edu
> https://mailman.cc.gatech.edu/mailman/listinfo/robocup-legged
>