24/05/2011 Updates

Following the meeting with John on Friday, 20th, May :

• Vocabulary corrections : 
• Basic robot operations :   "Tasks" are know called "Commands"
• Complex sequences of commands : "Simulations" are know called "Tasks"
• AI implementation into the MVC structure has been reviewed into the Class Diagram ( the diagram isn't updated for methods and attributes in order to be less complicated )
• The Planning has also been reviewed to work on the platform and on the LeJOS API at the same time.

On Google docs, PDF files have been replaced by editable formats so that you can know directly edit them.

About the code, on John request, I'll write regularly main issues I met, and solutions I found / choices I made if there are. Here are the first :

• How quickly accessing to a specific Robot/Element/Command ?
• Solution : Lists of robots and elements are represented in Board class as two Hashtables which contain Strings (names) as keys. Same thing for commands in Robot class.
• How modeling direction vectors ?
• Choice : There are two solutions : using two integers for the Vector, or one for the angle. I chose the angle. Using degrees angles is the easiest for a user. However, as compensation, angles involve the use of trigonometric functions, more complex than simple operations.
•  About element holding, where shall I stock the elements ?
• Choice : After hesitating on stocking it on Hold Command (not really logic) or on robot (contradict the OOP), I finally made a sub class HolderRobot. However, Drop and Hold commands are now specific to Holder Robots, which contradict the OOP as well...

About the software, there is currently a basic visual interface with control panel that enable user to choose robot, configured command ( move, rotate, hold nearest element, drop it), and do it.