Individual Lessons Learned
Kip
Carr Jr. darchon1100@hotmail.com
EEL
4884 Software Design Fall ‘04
The contents of the paper are as follows:
- Easiest and hardest parts of
class:
- The easiest part of this class was the
planning and design of our projects.
Our group was able to plan and figure out most of the
functionality the first time. The
actual detailed design was a bit more difficult than the high level
design in terms of being able to come up with all of the requirements and
the variables that are going to be used in the actual program. We could come up with the obvious ones
but some of the temporary variables needed to pass information to the
server or for comparisons was a bit more difficult to predict. Besides the shortcomings of these
things the actual documentation wasn’t to difficult just time
consuming.
- The hardest part was actually parsing
the information from the server and storing it correctly. We were provided with a parse class
but it was still difficult to figure out the format of the actual
messages that were being sent from the server to us. We had to change the way we searched
for things several times so that we could correctly find the information
and then store it correctly into our appropriate data storage class. We had to create several different
arrays in order to correctly store and compare flag information to figure
out our position. The next
biggest thing was the calculation of our position as well as passing
using this information and other player’s information. We had to find a masters thesis to
look up some ways to calculate our absolute position on the field. This was also made more difficult in
that the coordinate system is not what you would think. The coordinates are relative to the
center of the field and changes depending on the side of the field that
you play. For example, if you are
the team on the left side of the field then your positive x is to the
right and the positive y direction is down. Also all of our angles were different in that if you turn clockwise
it was a positive angle and if counterclockwise was considered to be
negative. This made some of the
calculations a bit more difficult to do when adding the angles of
players. We found how to calculate or position
using one of the lines on the field and a flag. This was the easiest to calculate and only required us to
see one flag in addition to a flag.
We probably worked on this problem for about 2 weeks until the
dead line and then were able to finally come up with the position. In the passing scenario we had the
problem of figuring out which direction the player was running relative
to the absolute direction. This
also came into play when we were trying to calculate how to intercept the
ball. This was actually the more
difficult of the two because the direction the ball is traveling is never
given and needs to be calculated from the previous value of the position
of the ball. Once we figure out
the trajectory of the ball we needed to figure out exactly which
direction it was traveling and figure out how many cycles we needed to
lead the ball in order to keep up with the ball but still be able to turn
and compensate for a change in direction. All these issues were resolved in the end and our code
works.
- Lessons learned:
- This project gave us a
good idea on how deadlines work in the real world. Work was pressed for time and some
things were omitted due to these time constraints. Figure that in the case of the actual
work force the time would be considered all together and you could have
more time to work on some of the harder things.
- I learned that due to
the deadlines that were given to us we were not going to get the work
done unless we used a division of labor and assigned each of us to a task
or function to work on for each week.
Usually we would do it weekly or sometimes daily if we needed to
get several of the functions done in time.
- In order to get things
done sometimes information would have to be searched for and would not be
readily available. This showed us
that much of the time was actually spent on research and not on implementation.
The implementation was very little
of the time we needed to do the code it just took forever to fix the
little things that we couldn’t figure out from our research or had to piece
together due to incomplete data given to us by the server.
- Data structures such
as trees or linked list would have been very useful. Unfortunately we didn’t realize this
until the second phase of the project and a lot of code would have to be
revised in order to incorporate these changes.
- Suggestions for future students:
- Expect to spend many hours on this
class and if you are taking other classes try to make sure they don’t require
a lot of your time.
- The University of Amsterdam’s Robocup
masters thesis is much help and should be looked for to find ideas on how
to do things.
- The more experience you have in C++ and
especially the string class, the more it will help.
- Group members:
- Rob Pescatore
- Code Grade = 5
- Rob contributed a lot of time
figuring out many of the AI functions used in our project.
- He found much of the information
needed on the Internet and was able to implement them into the code.
- Management Grade = 5
- Rob was in charge of most of our
documentation and was able to cleanly show our results.
- He came up with many of the ideas on
how to test things for our algorithm for our player.
- Kristen Cannava
- Code Grade = 5
- Kristen contributed much of the basic
functionality to our program and the communication back to the server.
- She came up with
several of the algorithms for calculating the trajectory we need to
plot for passing.
- Management Grade = 5
- Kristen came up with
most of the high-level design and initial documentation used in our
project.
- Kip Carr Jr.
- Code Grade = 5
- I implemented most
of the parsing for the messages from the server as well as calculating
the trajectory of the ball with Rob.
- I was able to find a
lot of the problems when we did implementation.
- Management Grade = 5
- I did the detailed
design for the group for our different phases.
- Came up with many of
the functions and how they would be implemented in our code.
>
Template
created by G. Walton (GWalton@mail.ucf.edu)
on August 15, 2000.
This
page last modified by Kip Carr Jr. (darchon1100@hotmail.com) on April 13, 2004