(Difference between revisions)

## Navigation names, definitions, and classes as agents, their skills and dependencies

Roger 19 November Updated 5 December

Definitions of terms

• Navigation: control of movement in the plane.
• Directions in a the plane are relative to the direction of the X axis ; the direction of the Y axis is 90 degrees.
• Heading: the direction the robot travels while moving forward. (if it moves backwards, the direction of motion is the heading + 180 degrees)
• Pose: the current coordinates of the robot and its heading

In probabilistic robotics, the pose is a random variable, the value of which is never known exactly. But decisions are based on a belief about the pose. This belief is represented as a probability distribution, the two most popular representations being the multi-variate normal and particle set. In this context, I use the term pose to mean “belief about the pose”

• Elemental movements. There are three:
• travel in a straight line – change coordinates but not heading
• rotate in place – change heading but not coordinates
• trace a circular arc

While it is true that a straight line is an arc with infinite radius, and rotation in place is an arc with zero radius, these special cases are the most commonly used and each deserves its own method. This allows the amount of movement to be specified by a single parameter.

The various tasks involved in navigation can usefully be classified by their complexity.

1. Execute elemental movements.
2. Update the robot pose
3. Move to a specified location
4. Path planning and Obstacle avoidance

In the following, I use the language of agents that have skills on their own, and use other agents as helpers. I hope this focuses on concepts and not on the details of the API.

### Level 1 Basic Movement Control

Motor

• Skills:rotate to a specified angle, report start and stop and tacho count to a listeer

=== Level 2 Pilot Skills

### Level 2 Update pose

The robot pose needs to be updated (1) upon the completion an elemental movement and (2) if another class needs a information about the pose while the robot is moving. The first update is initiated by the MoveController, and the second is initiated by the Pose.

Pose class (now known as UpdateablePose)

• Skills:
• provide x,y and heading at any time
• Calculate distance and heading to a point
• register as a listener to a MoveController
• request update from a MoveController
• Uses:
• lejos.geom.Point, Math, MoveController

MoveController interface extends Pilot

• Skills:
• updates a Pose at the end of every elemental movement and when requested by a Pose.
• Uses : Pose
• See Pilot
• Implementing classes:
• DifferntialMoveControl (new name for DifferentialPilot) extends TachoPilot
• CompassMoveControl extends CompassPilot

ArcMoveController interface extends ArcPilot

• Skills:
• updates a Pose at the end of every elemental movement and when requested by a Pose

SimpleNavigator (stripped down version of current class only has goTo(x,y)

• Skills: moves the robot to a desired Point.
• Uses: DifferentialMoveControl , Pose

This class should replace proposal.PoseController

ArcNavigator (new name for proposal.ArcPoseController

• Skills: moves the robot to a desired Point and desired heading when it arrives
• Uses: ArcPilot extended for automatic update of pose.

Simplification possibilities: I think the following classes and interfaces are not necessary : UpdateablePose (rename as Pose) MotorEvent and Movement - these only hold data items which could be itemized in method calls to listeners. DeadReckonongPoseProvider - the MoveController/Pose combination can manage the dead reckoning pose updates

This section rather tentative. I have not studied the MCL classes carefully enough verify that this is a good framework for them.

ProbabilisticMoveControl interface extends MoveController

• Skills: also provides variance of distance traveled and heading change to ProbabilisicPose
• Implementing classes;
• ProbabilisticDifferentialControl extends DifferentialMoveControl

ProbabilisticPose externds Pose

• Skills: Returns x,y and heading with mean and variance.
• Uses: a probabilistic representation of a pose belief
• Implementing classes: NormalPose, ParticleSetPose

NormalPose implements ProbabilisticPose

• Skills: Returns x,y and heading with mean and variance.
• Uses: a three variable normal distribution to represent pose.

ParticleSetPose implements ProbabilisticPose extends NormalPose

• Skills: Returns x,y and heading with mean and variance.
• Uses: particle set to represent a pose.

ProbabilisticPoseProvider interface

• ImplementingClasses: KalmanPoseProvider, MCLPoseProvider

KalmanPoseProvider implements ProbatilisticPoseProvider(probably an abstract class with sub classes for different sensor models)

• Skills:
• Update a NormalPose using data from external sensors;
• Uses:
• NormalPose
• various sensors and motors to direct the sensors;
• Navigator (to aim the robot if sensors are fixed)
• Updating algorithm using Kalman filter
• Map (to determine where to point sensors)

MCLPoseProvider implements ProbabiliseicPoseProivder (probably an abstract class with sub classes for different sensor models)

• Uses:
• ParticleSetPose
• various sensors and motors to direct the sensors;
• Navigator (to aim the robot if sensors are fixed)
• Uses Monte Carlo update.
• Map (to determine where to point sensors)

ProbabilisticNavigator extends SimpleNavigator

• Skills: moves the robot to a desired destination Point as accurately as possible
• Uses: ProbabilisticPilot, ProbabilisticPose, ProbabilisticPoseProvider

### Higher levels of complexity

I have not studied this enough to make constructive suggestions. My feeling is that class to deal with things like path finding, obstacle avoidance and mapping will need to be customized for the particular environment, so generic solutions to these problems may not be useful.