Steering a mobile robot Steering a mobile robot Steering a mobile robot
There are two main techniques for steering a three-wheeled robot:
• Two drive wheels on the same axle (or perhaps with a differential gear) turned by a single motor, and usually at the rear; a single free-running steering wheel, usually at the front, with a motor to turn it in the required direction. The arrangement is that of a child’s tricycle. It is used in the Android.
• Two drive wheels on separate axles, each with its own motor. The wheels are usually about half-way along the chassis, to give the robot the ability to spin on its centre. The third wheel is a castor. It is similar to steering a tracked vehicle, such as a tank. The programming for tracks is the same as for wheels. This technique is used in the Quester.
There is a third technique, used in the Scooter, that has a castor which automatically steers the vehicle to one side when it runs in reverse. This extremely simple method is easiest to build and does not need programming, but has limitations.
Two-wheel steering relies on switching the motors individually into forward or reverse.
The table opposite lists five possible actions. These are controllable by digital output: a motor is either running or stopped. If it is running, it is either running forward or it is running in reverse. We could program it for analogue control, in which the motors are made to run at different speeds. Then the robot could follow a curved path. But analogue-based programming is complicated and digital is generally good enough.
The technique is to execute the intended curved path as a series of short straight runs alternating with frequent but small spins in the required direction.
Stop Stop Stop
Forward Forward Forward
Forward Reverse Spin right
Reverse Forward Spin left
Reverse Reverse Reverse
Digital steering.
To program a path curving to the left, for example, the actual path is a series of forward runs lasting about 0.2 s each (turn on both motors, call delay). Between each straight segment there is a short spin to the left. Breaking up the path like this has another purpose. It gives the opportunity between segments to poll the sensors, to check that the robot is heading in the right direction.
Mode 3 of the Quester programs is an example of this. The robot is programmed to follow a curved black line. The flowchart on p. 291 shows that in between the short forward-moving segments it checks its sensors to make sure it is still on the line. If it is not, it corrects the error by short spins to the left or right.
The motors are controlled by four digital outputs from Port B. The table on p. 277 gives the details. The left motor is controlled by two outputs, A (from RB7) and B (from RB6).
These go to the motor power control board which works as described in Part 4. To run the left motor in a forward direction we make A high and B low. For the reverse direction A is low and B is high. Putting these settings into bytes to send to Port B, we need
10000000 for forward and 01000000 for reverse. In hex these are 80h and 40h respectively.
To make the robot run forward we need to switch on the right motor too. This is controlled by two outputs from Port B, C (from RB5) and D (from RB4).
The complete code byte for running both motors forward must make both RB7 and RB5 high. The code is 10100000, or a0 in hex. To put both motors in reverse, make RB7 and RB5 low, and make RB6 and RB4 high. The code is 01010000, or 50 in hex. Code 00h makes all control inputs low, stopping both motors.
Typical instructions for setting both motors into forward drive are:
movlw a0h ; Code to w register.
movwf portb ; Both motors turned on.
call delay ; 0.2 s.
clrf portb ; Stop both motors.
This gives a 0.2 s segment, but we could call it longdelay instead, putting a suitable value into w before calling. Or we could let the robot run until a given event interrupts it.
This way of programming depends on the fact that Port B has only four channels (which is why the four LSBs of the code are always low). In another robot you may be controlling the motors from Port A or Port C and want to use the other channels as outputs for other purposes. As an example, suppose the motors are controlled by bit <7:4> of Port C. The same codes apply, and sending a0h to Port C will turn the motors on, but it will turn off all devices connected to the other four outputs. The easiest way is to set or clear the bits individually, using bsf and bcf.
Programming motors switched by relays (pp. 96-97) is similar, but the codes are different.
As in transistor switching, each motor is controlled by two bits, but one bit controls on/
off and the other controls direction. For a single motor the control outputs are:
On/off relay
0ah, spin left is 0ch, spin right is 0eh, and stop is 00h.
In Project 6.5 we use three motors switched by relays to move the x-frame, the y-frame and the tool to different places in the working area. These winch motors are switched on one at a time and wind out or wind in the winch cord. For a single motor, the control settings are:
The codes in the table apply when the relays are controlled by bits <1:0>. In the Gantry project the wind in/out is controlled by RC7 and the three motors by RC4 (M1, y-winch), RC5 (M2, x-winch) and RC6 (M3, tool winch). The corresponding codes are as listed on p. 339.
Controlling stepper motors is described on pp. 98-100.