Simon Rovder
0,0
0,0
Everything in strategy has access to the public static Strategy.world variable
What must be implemented for a Robot, in order for it to work with our system:
The Port class simply contains the commands that the robot understands
The task of a Drive is to mediate between the Navigation System and the RobotPort.
The Drive class only has one function, which takes in these arguments:
Controllers are a simple mechanism for automating the Robots' behaviour. Every robot can have many controllers, each of which can be turned on and off whenever.
Every Robot comes with a MotionController and an ActionController. In addition to these you may give your robot some special controllers, for example Fred had a PropellerController.
Every controller has a perform() method. Every Strategy Cycle, the perform() method of every controller of every robot is triggered.
The PropellerController simply made sure that the propeller was always spinning in the 'most favourable direction'
It also stopped the propeller from spinning when the robot was in a more tight situation (eg. touching another robot)
The Motion Controller navigates the Robot. It has two noteworthy methods:
setDestination(DynamicPoint destination)
setHeading(DynamicPoint heading)
Every Strategy Cycle, it evaluates the desired path the robot should take and computes a vector of the direction the robot should be moving in at this moment.
It then uses the aforementioned Drive class to actually move the robot.
The Motion Controller uses two main techniques to navigate the robot. These are A* Search and Potential Fields.
It automatically decides on which one of these systems is better given the current state of the world.
The Action Controller is the main Controller. It is within this Controller where the program decides what it should have the other controllers do (or whether to turn them on or off).
It has one important function:
setAction(ActionInterface action);
An Action is where you decide what to tell your other Controllers to do. Actions can be used to model any kind of behaviour in the form of a state machine.
They have two important methods:
tok() - This is where your decision making logic goes. It is where you decide what state to go into next. (For example you could check who has the ball, whether the ball is moving, where your teammate is etc.)
enterState(int newState) - This is where you actually perform things associated with the change of state. (For example you tell your robot to kick. Or you could set the destination in your Motion Controller to be the Midpoint between the two opponent robots to block a pass)
Actions also have two built-in functions (in the abstract class you extend):
delay(long millis) - Delays the execution of the action. In other words, tok() will not be called until the delay expires.
enterAction(ActionBase action, int successState, int failState) - In the spirit of Finite State Machines, you may ask your action to execute a "sub-action". If you do this, the tok() method of your higher action will not be called, instead the tok() method of the lower action will be called.
When the sub-action terminates, enterState() will be called on your higher action based on whether the sub-action failed or succeeded.
Action A
Action B
Action C
tik()
tik()
tik()
tok()
Aditional Method getState()
The code contains the text "SDP2017NOTE" in comments wherever there is an important section. grep for these comments to find all the noteworthy bits.
More support material can be found on:
https://fred.rovder.com/