The current (Summer 2011) Navigator is based on the premise that it has two responsibilities:

• To go somewhere
• To execute SweetMoves

  All the states are in NavStates.py, with supporting states in Helper files and the interface to the Navigator in, where else, Navigator.py.

The only state which deals with doing a sweetmove. Very simple. Just enqueues a SweetMove and waits for the body to stop moving. It’s too simple actually. (@TODO!) It should use the isDone method which MotionCommands expose to Python to check when a particular command is done.

Each Nav State corresponds to a different way of getting to a position, basically.

(x,y,h) point

These are speed based controls. They remember their last speeds (lastSpeedX,Y,Theta. Done in updateSpeeds in Navigator.py) and don’t send new speeds unless they are significantly different than the old ones. This helps the walk engine stay stable, as it doesn’t reset the walk queue every frame.

goToPosition

Basic idea: turn towards a position, walk towards it. When we get close to the position, switch to omniGoTo.

omniGoTo

Use all our powers of walking to get to the correct (x,y,h) quickly.

Orbit

Spins around the ball. Ask @egoogins about this one.

AvoidObstacle

Basically just sidesteps away from the offending obstacle until it is no longer in range.

This is the interface to the Navigator FSA. It is an FSA, and it holds all the commands which should be used by other FSAs to interact with it. Most of them say just what they do. The update methods at the bottom could be in a separate file. They are not for interfacing. They are for internal control of speeds and memory within the Navigator.

The getDestination method is what allows for the abstraction of “goTo” methods into only two methods. The interface methods set the destType and the goTo methods check here to get the location to which they should head. These are either given in relative or global coordinates.