A standard player/stage position2D interface is implemented on the Meercat driver. The diagram shown in Figure 7.1 helps to explain the total functionality of the implemented system.
Control System Design and Experimentation 71
Figure 7.1: Meercat position2D interface and linkages
The postion2D interface’s data, known as pose information, is defined as an X (px), Y (py) position and platform orientation value Theta (pa). In the position structure, the data is interpreted as an x and y position in metres and theta as a platform rotation in radians. In the velocity structure, the x and y parameters are velocity values in metres/seconds and theta is a platform rotational speed in radians/seconds.
Most of the algorithms that are provided on player/stage, algorithms that perform obstacle avoidance, routing and planning, use velocity control mode. As a result, most of the position2D drivers on other robotic vehicles implement velocity control mode only.
On Meercat, two separate control modes are implemented: velocity control mode and position control mode. The position control mode was added in order to be able to perform scripted position control commands. The position control mode was added in order to be able to perform scripted position control commands. This control mode is used mainly for calibration of the odometry of the vehicle, but also so that a fixed movement pattern can be run from a known waypoint. Initial attempts at open loop control in this mode proved impossible as the left and right side of the vehicle reacted differently to motion commands resulting in the vehicle veering of course within a few meters of travel. The implementation of a PID control loop which takes feedback from the wheel sensors into account such that both wheels operate correctly at the required rate solved this problem. As an example, one of the experiments that was done using the Meercat simply ran an indoor movement on a fixed pattern without any obstacle avoidance,
Control System Design and Experimentation 72
and for this a scripted move was used. The UMBmark calibration procedure in paragraph 7.2 was also performed using this method.
The driver switches between velocity and position control mode depending on the type of control messages it receives from the higher level software.
The behaviour of the driver and embedded controller in velocity control mode is shown in Figure 7.2.
Figure 7.2: Velocity mode control diagram
An x (Vx) and y (Vy) speed is received in metres per second from higher level algorithms, as well as a rotational speed (Va) in radians per second. This needs to be translated into a left and right wheel speed by the driver as shown in 7.3 to 7.5 below, which is then passed on to the embedded controller.
Two speed components are calculated: the first component as a result of the requested angular speed and the second component as a result of the requested x and y speed. Based on the formula used in the UMBMark literature where b is platform width between wheels:
Control System Design and Experimentation 73
0 =1− 1
2 3
(7.1)
Note that rotation is around the axis of the platform, which means that:
1= −1 (7.2)
Therefore:
1=10 3
(7.3) And:
1= − 10 3
(7.4)
The speed component due to the requested Vx and Vy speeds:
145667 = 145667 = 819:+ 1;: (7.5)
The speed component and rotation component are then added together for each wheel and passed on to the hardware controller. A ramping function limits the positive and negative acceleration of the vehicle to ensure a smooth, non jerking behaviour.
In velocity mode, the embedded AVR32 controller implements separate PID controllers for the left and right wheel motor, and these control the motors on the difference between requested velocity and measured velocity. The functioning of the PID controllers was very apparent as without this control the robot tends to wander off course. With the PID velocity control, a straight line can be achieved. The parameters for the P,I and D values are stored in the player driver configuration file, and are sent to the embedded controller when the driver starts up.
The odometry calculations are performed on the embedded controller and the results are passed back to the driver, which publishes this information on its position2D interface.
In position control mode, the scheme works differently. Here the embedded controller follows a state machine procedure to achieve the requested position. The driver inspects the state of the embedded controller so that it knows when new position commands can be passed on.
Control System Design and Experimentation 74
Meercat Driver
Pass px,py,pa parameters
Position Commands from
Higher Level Control
Position and Velocity Feedback to Higher Level
Control
Embedded Controller
On each new position request:
1. Rotate toward requested x,y point 2. Travel √(x2+y2) distance
3. Rotate toward requested orientation Publish Pose Information
Interpret Encoder Information to calculate position and velocity
Encoder Encoder
M M
Figure 7.3: Position mode control diagram
A similar handshaking system is used between higher level software and the driver, where a client program can inspect the motor state of the position2D interface. Motor stalled means that the move has been completed. In addition, the driver will simply not accept any new position commands until the platform has either achieved the last requested position or a time-out has taken place. A position move starts with a rotation of the platform towards the intended target, followed by a high-speed movement, and then a lower speed movement. The low-speed move is intended as a means to approach the target slowly and avoid overshoot. The high and low speeds during this movement can also be controlled by setting the velocity part of the positon2d interface. Some special non-standard trickery is used here as follows: px defines the high speed, py the low speed, and pa is a special control code which determines the threshold at which to change from high speed to low speed.