Editor’s note : The contents of this page were extracted an archived entry found on the Internet Archive’s Wayback Machine. The page, originally on Carlos Puchol’s web space at The University of Texas – Austin, was archived on 1996-12-31.
Introduction to the Mobile Platform
The mobile platform project is designed to provide ground-based mobility to experimental sensor and control systems, allowing them to traverse level surfaces such as building floors, and possibly streets and backyards. Think of it as a Hero robot on steroids.
Mobile Platform Mechanical System
The mobile platform is supported by two main drive wheels, with stability augmented by fore and aft caster wheels. Depending on distribution of weight in the platform and payload, it may be self-righting through balancing about the main wheel axis. Possible caster wheel heights are bounded on the low end by the need to negotiate unlevel surfaces and, on the high end, by the need to maintain the platform more or less level during dynamic maneuvers. Caster wheel mounting heights and possibilities for controllable height adjustments need to be investigated.
The vehicle platform is designed to fit within a 2-foot circle so it can navigate doorways and turn within its width. Currently equipped main wheels are 11.5 inches high. The platform structure is made up of 1-inch square steel tubing in a box structure. Vertical hard clearance when level is 2 inches. The top of the box structure is 12 inches above the floor. In general, platform structure below the 12 inch height is intended to be dedicated to platform mechanicals, and passenger equipment will mount to the top surface. The upper surface consists of a perimeter structure of 1-inch square tube, 10 inches wide by 11 inches fore-aft. We will equip it with mounting holes or tabs, or studs, or tape things on top with duct tape.
Platform main wheels are driven from wheelchair motors via #35 roller chain. Based on preliminary observations, motive force of the system will be limited primarily by tire friction. Based on measured motor torque of _____, and a _____ : _____ reduction ratio, the horizontal stall force will be _____. Thus a heavily-loaded platform will be able to push over or drive through certain static objects. Some motor current sensing or other safety mechanisms may be appropriate. A perimeter bumper system with contact switches will likely be installed eventually.
Mobile Platform Electrical / Electronic System
The mobile platform electronics are designed for control via a Motorola 68HC11 microcontroller Evaluation Board (EVB). The EVB receives movement commands from a higher authority and performs the necessary control functions to drive the platform motors. The EVB has been used as a basis because it is a handy development system. Eventually the motor drive circuit board will probably have an on-board HC11.
Control is currently passed to the EVB via a standard serial port for testing in conjunction with a data terminal. Eventually control will be migrated to the HC11 Serial Communications Interface (SCI) for interprocessor communication.
The motor drive power electronics reside on a circuit board with the same dimensions as the EVB and similarly placed 60-pin connector. It is capable of being mounted, with a suitable connector, as a daughter board on top of the EVB. Logic and motor drive circuitry are separate, with optical coupling of control and status signals in both directions. Motors are controlled via enable and direction signals. The enable is pulse width modulated (PWM) to control motor speed. In addition to the individual motor enables, a global driver enable allows shutdown of the entire power output stage. An overcurrent sense signal is sent back from the motor driver circuit to the HC11.
Each motor driver consists of four MOSFET transistors in an H-bridge configuration, controlled by a _____ IC. The most recent circuit version is equipped with IRF540 MOSFETS, giving it current capability of 27 A continuous, 108 A peak. This appears to be a reasonable transistor size for efficient operation at anticipated motor power levels. MOSFETS with higher current ratings may be substituted as required. The motor driver circuit is currently programmed for overcurrent limit of approximately 20 A, which may be modified by changing the current sense shunt.
Optical encoders on the motor output shafts are used to feed back motor position to the HC11. Each encoder consists of a pair of optical interrupters and an encoder wheel. The encoder sensors use a Schmitt trigger buffer to control encoder hysteresis. Optical encoder outputs are fed to the HC11 via connectors on the motor driver board. Connectors are 4-pin .100 type.
The motor driver circuit board is designed to operate with input voltage in the 5V-30V range. Full turn-on saturation of the MOSFETS is not guaranteed below 10V, so operation is not recommended in this range with a large motor load. Power connectors on the power board are Molex .093 series 2-pin connectors, connecting to male connectors on batteries and female connectors on motors. The motor drive circuit is fused with a standard automotive type fuse. The fuse should protect against melted wires and boiling batteries in the event of an output short. Current limiting by the transistor driver IC should protect the MOSFETs to some degree. This will no doubt be determined experimentally at some time.
There is an undesirable and potentially exciting design defect on the current version of the power board, resulting in runaway full-speed drive of the motors when power is removed from the control logic. This will be corrected on future versions. For the moment, it is necessary to ensure that logic power is applied prior to application of motor drive voltage, and motor drive voltage disconnected prior to disconnection of logic power.
Control Algorithm
General
The HC11 program which controls platform motion is mainly interrupt-driven. Encoder transitions are serviced as they occur. A real-time counter schedules updates of the trajectory generator and control loop. PWM transitions are controlled by HC11 internal timers, which are reset at the PWM frequency. Implementations of these functions are more or less similar to HC11 databook examples.
Movement Command Set
Platform movement is directed through commands to the HC11 via the serial port. The following is a summary of currently implemented commands :
- Calibrate – sets setpoint position equal to current position (overrides move in progress)
- Translate (direction,magnitude) – forward or reverse increment to current setpoint position
- Rotate (direction, magnitude) – rotates right or left about platform centerline
- Velocity (direction, magnitude) – gives platform velocity in specified direction
- Radius (direction, length) – specifies curve radius in conjunction with velocity commands
- Motor (direction, magnitude) – allows independent increments topology motor setpoints
- Control (various parameters) – allows resetting of control equation constants and limit values
“Magnitude”, a parameter in many commands above, is expressed in terms of encoder counts, and the relation to physical movement distance is a function of encoder resolution, gear ratio, and wheel size. Encoders should eventually be sized such that some whole number relation exists between counts and distance in standard units of measure. Radius is specified in increments of half the vehicle track.
Commands as currently implemented return prompt strings to the data terminal. Such information will be omitted for interprocessor control via the SPI.
Wheel Position Settings and Trajectory Generation
Each wheel has an associated destination position counter. The count values are modified through addition and subtraction of increments for instantaneous movements. Velocity commands cause the velocity value to be added to the wheel counts at the trajectory generation timestep interval. When a non-straight path is directed via the Radius command, the destination counts are incremented differently to achieve the desired radius. Operation at large radii is not smooth; the algorithm may be modified someday.
Translation, rotation, and velocity commands may be overlaid with predictable, though not always intuitive, results. In general, translation and rotation commands are intended to be applied disjointly, and separately from velocity commands. Velocity and radius commands are intended to be used together in a smooth manner. All commands take effect immediately but translations and rotations modify endpoint positions, whereas velocity and radius commands modify the incremental setting of new endpoints.
Eventual additions to the command set may include profiled moves, consisting of acceleration, maintained velocity, and deceleration. Other means of limiting acceleration and jerk forces via programmable limits are possible. Another feature, primarily applicable to translation and rotation commands, would be the ability to queue commands, i.e. move forward 5, turn left 2, move forward 8. Eventually the command set will probably need to be divided into two or more distinct modes of operation.
Encoder Sensing and Actual Position Determination
Optical encoders send two digital signals in quadrature to HC11 inputs. Transitions on one signal are recognized, at which point an interrupt routine reads the other signal and determines direction of encoder motion. New position is compared with previous position for the possibility of encoder error which is not really handled correctly right now anyway. Then the wheel position count is incremented or decremented as appropriate.
Generation of Motor Force Function
Voltage applied to each motor is determined via a comparison between destination position and actual position. If there is any difference, the control algorithm exerts force through the motor to drive the error to zero. The position control is implemented in a proportional-integral-derivative (PID) loop, with command-settable gain values for each term. The motor PWM duty cycle is also subject to a command-settable limit. The result of the control calculation is a duty cycle, which is used by the PWM logic to generate a PWM output from the HC11 for the motor driver circuit.
Error / Failure / Problem Resolution
Some work needs to be done in recognizing problems with platform motion such as bumping into objects, motor overcurrent, encoder / drivetrain / wheel slip, etc., and acting on these problems accordingly. The control algorithm will need to shut down activities which are causing problems and report back to its higher authority.
Balancing Act
Since the platform has two wheels, fairly responsive motors, and a dedicated controller, it may be possible to perform active balancing of top-heavy loads without relying on the caster wheels. This is actually not that farfetched, but would require some attitude-sensing hardware and algorithm development. It would also be totally cool.
