====================================================
README added by Peter 1/13/98 --- Original to follow
====================================================

The signal method is interesting.  Consider adapting it.  There might
be some busy-waiting going on when waiting for seeinfo, but that
should be dispensible.  Memory could be updated as info comes in, the
command list allows for multiple commands to be stored up at once.  It
could be cleared if more recent info renders it obsolete.

The kicking could be easily incorporated into my players.  I would
just need to conver the infor that they're keeping track of into my
own structures.  Also, the ball velocity estimation should be pastable
into my own code---it's from the server.  It might also be useful for
ball interception.

Performance isn't perfect---the ball sometimes get stuck on the player
as it's being swung around.  Why?  Also, the ball gets lost
sometimes.  Why?  Is it prediction error (inevitable), or a more
fundamental bug?  

In any case, the code is very useful for spinning the ball around to
shoot in a given direction.  It's also good at producing hard shots.
Is this code a lot different than the Humboldt code?  Can't tell

Vector class looks useful too....

Models everything in terms of relative coords and then allows you to
transform to globals....

====================================================
Original README
====================================================

This client has been written as sample of the ball handling implementation used 
by the PaSo client in RoboCup97 simulation league. 

Our structures in command timing and sincronization are quite different from
the ones used in the available libraries. 
The difficulties encountered led me to the decision to write a self-running client 
which does a single thing: turns the ball around the player.
  
The code is written in C++ and uses Unix signals for sincronization and timing.

It works by this way:

- a message arriving from the soccerserver generates a SIGIO. 
  The SIGIO handler sets the timer to generate a first signal after 30ms and the followings 
  every 100 ms. It also parses sensor information and sets a flag.

- a timer signal causes the handler to send the first command in the list, if present.

- the main loop is : 
    1 wait for new info (flag),
    2 estimate the ball state from visual information
    3 insert commands in the list
    4 go to 1  

The ball handling functions are based on internal simulation of ball trajectory.
The same calculations done by the soccerserver are accomplished. An important thing that
we have to consider in the decision of the kick direction is avoiding collision with the 
player body. 
So when there would be a collision, the kick function take the nearest direction tangent 
to a circle a little bigger than the player. 
We can also give multiple kicks. It happens when we want to kick very strong (a sort of 
cheat probably no more possible in the new server) or when we need to turn the ball around
the player. In both cases every kick must be based on the ball state after the
execution of previous kicks. So it is useful to have a command list that keeps track of
the given commands.

This is all I can say about this code. Naturally it could have bugs and can be improved, 
mainly in the prediction of position and speed when the ball is out on our visual range.
It is also highly dependent on the soccerserver, so new versions could make it not 
working.

 Alessandro Bissacco, student at 
 Universita' di Padova - Dipartimento di Elettronica e Informatica 
 35125 Padova
 e-mail: hacker@dei.unipd.it
 




