OOMRM Navigational (Updated 2007.10.01)

Navigational Usage

The following provides a summary of the most useful navigational methods. For Simple movements forward and backwards, capablities of the Primtive_Driver can be used like

driver.primitive_motion(TRAVEL_FORWARD, 150,true);

Navigational Overview

There are many ways to design for dead reckoning mechanism. The design was recently rewritten for optimization (sigh). All low level encoder math is now done in encoder units; i.e., the basic distance between two encoder "clicks" or Encoder Units (EU). This unit is chosen because it is the smallest unit needed; i.e., you can't possibly measure smaller than that anyways. This is measured in nanometers (nm) and on my robot is about 7463 nm.

The navigational design follows an object hierarchy as follows:

The Local_Waypoint_Driver is designed to work in tandem with the mission_profile and the world_model_store to execute the current mission plan. In concept, it is the world model information store (WM-IS) that maintains the world map and all information in it. Thus, the A* search algorithm is confined to the world_model_store. The A* algorithm returns a full expanded motion chain whereas the search method returns a compressed motion_chain where only points that require a vehicle change are recorded in the chain. This mission profile plan executed by the Local Waypoint Driver is usually built via the Moboile Robot Workshop (GUI) and consists of the following elements:

  1. Waypoint - destination to travel to
  2. Waypoint Final orientation - Once each destination is reached, the vehicle will turn to final orientation.
  3. Action to perform at waypoint - This is supplied via a callback function table that must be previously buillt.
These activities occur in the order listed above. Thus, once a mission_profile is built, the begin method can be called to perform the designed mission.

The Motion_Driver is used to ensure vehicle continues to move along the motion chain currently being traversed. Usually, this includes setting up the next starting and destination point in current path.

The Geometry_Driver or Local_Vector_Driver has responsibility for keeping the vehicle along the specified path between the source/destination set up by the motion driver. Usually, this entails checking currect position compared with where robot should be based upon geometry of path (straight, circular, etc.). It (typedef) provides two most often used methods. The First is heading which allows you to specify an absolute direction of travel and speed and it has responsibility to turn vehichle to specified direction. In addition to heading, it provides a foundational method travel which is used to command the vehicle as follows:

  1. Type of motion
  2. Speed of motion
  3. Radius of circular arc to turn (0 for pivot) in Encoder Units (EU)
  4. Final orientation (absolute)
  5. Distance to travel in radians (or millimeters if traveling forward). Since I have the final orientation, I'm not sure if this is redundant or not. Need to research that.

The Primitive_Driver contains two oEncodedMotors which do the grunt work of keeping track of wheel "ticks". The Primitive_Driver is just a wrapper for these with initialization and the ability to set velocity of vehicle and add ability to provide a user Proportional gain (PID type) to left or right wheel independently. These methods, Rpower and Lpower and used heavily by lower classes.

The formulas are based upon A Tutorial and Elementary Trajectory Model for the Differential Steering System of Robot Wheel Actuators by G.W. Lucas.

Navigational RTOS Tasks

The dead reckoning is achieved through the following tasks in order priority (highest to lowest):

  1. task_encodedmotor: this tracks speed of each motor. Additionally, it uses the speed to determine the pose of the vehicle (x, y position and angle).
  2. task_primitive_driver: Really is a cruise control. This task simply uses PID to try to get the wheel to reach the stated speed.
  3. task_motion_driver: Determines if the vehicle has completed the path to the next necessary point along the chain; note, waypoints are traversed by following a set of necessary points or poses. If the desired coordinate is reached, then it acquires the next necessary point in the motion chain to achieve the desired waypoint.
  4. task_local_vector_driver: Uses position to determine if the vehicle is within tolerance for the next necessary point in the chain. If so, it flags this leg of the course as completed.
  5. task_keep_straight: This task is active when using the Local_Vector_Driver and its function is to use a PID control function to keep the vehicle close to where it should be. For instance, if a line is being traversed, then it is determined if the current position lies on the line determined by the starting position and the next necessary point. It adjust speed accordingly to achieve this position. Note, there are two PIDs active, the cruise control and this one, when trying only one active at a time, it turns out, the cruise control almost never engages, thus both are engaged simeoutenously.
  6. Local Waypoint Driver: Contains no task but uses a semaphore pending until the local_vector_driver semaphore indicates, the path has completed. the Waypoint Driver Has two modes of operation:

    Currently, both modes determine a linear path. Thus the vechicle stops every time so it can make turn to the next direction; thus the future challenge is to transform the motion chain into another geometric besides a simple linear path.

Formula Derivations

This section contains calculations used within the Mobile Robot Model.

Circular paths

Although still valid, I do not believe I directly use this one now. In Local_Vector_Driver, I used to measure "distance to go" to know when to stop, but now simply stop when:
  1. The vehicle is near destination (within a fudge factor).
  2. The vehicle starts to move away from destination. This is in case you're not within the required fudge factor, it guaranttes it does not keep going infinitely if it misses the destination--a problem I had at the beginning.
The wheel base is mainly used in calculating how far a 90 degree turn is in the turn method. The encoder resolution and wheel diameter are both used in distance calculations and in making the turns. It is derived thus:

NOTE: The PDF version of this document is missing the greek symbols. Please see the HTML version.

then
     D = πb/2, and one click, C = πd/R
thus we want to know how many clicks in total pivot distance traveled,
 nC = 	D or
 nC = 	πb/2 or
 n(πd/R) = πb/2 and finally solve for n to obtain n = (bR)/(2d). 

Wheel Speed

To simplify the equation, in making turns, one of the vehicles wheels will maintain a constant velocity and the other wheel will vary--it is the varying wheel's speed that we wish to determine. The Local_Vector_Driver calculates based upon wheel diameter, turn radius, etc., the needed wheel speed to attain that turn.

Thus, given a wheel base L, radius of turn R, and Vr, a fixed velocity of one wheel (right in this case), solve for the needed velocity of the other wheel to achieve a 90 degree turn.

Let:
L = wheel base
R = radius of turn
Vr = velocity of right wheel (fixed in this case)
Vl = velocity of left wheel (solve for this)
ω  = angular velocity of robot

From Mobile Robot Locomotion by Prof. Jizhong Xiao's Differential steering 
Kinematics equations (unfortunately, his presentation has changed since then, and the previous used equations are not there) 

1)	Vl = ω(R - L/2)   [slide 17]
2)	ω = Vr -Vl/L	[slide 18]

Let α = (R -L/2) 
NOTE: this is constant term; hence it works, thus from eq. 1 we obtain,
3) Vl = ωα

A) Vl = (Vr/L -Vl/L)α	[substitute eq. 2 for ω into eq. 3]

B) Vl = Vrα/L - Vlα/L	[multiply out by α]

C) Vl+Vlα/L = Vrα/L 	[add +Vlα/L to both sides]

 = Vl*((1+α)/L)
D) Vl/L(L+α) = Vrα/L	[factor out Vl in left]

 = Vl((L+α)/L

E) Vl(L+α) = VrαL/L     [mulitpy both sides by L]

3) Vl = Vrα/(L+α)		[cancel L on right and divide both sides by (L+α)]

Thus Vrα/(L+α) is final equation.  For sanity check, put in R=0; 
i.e, do a 90 degree pivot at some speed, say 400 mm/sec.
  
  a = (0-200/2) = -100
  400(-100)/(200-100)
  = 400(-100)/(100)
  = -400

Which corresponds with common sense. It is the same speed but in the opposite direction.

References