Eric is an embedded-systems design engineer in Redmond, Washington. You can contact him at 206-885-4107 or 72223,1242 @ CompuServe.com.
The Motorola 68HC16 microcontroller is a 16-bit device which, among other things, features queued communication for two integrated serial channels, a general-purpose timer with two 16-bit counters, and support for digital-signal processing. As with any powerful tool, however, having flexibility and functionality like that of the HC16 can--if you're not careful--cause more problems than it solves. In particular, a microcontroller that's capable of running multiple independent periodic processes could produce erratic results when several of the interrupts occur at more or less the same time.
In a general sense, this is the design problem I faced with a HC16-based system which involved many time-based processing routines whose synchronous execution was critical to safe operation. I had the option of using the very flexible on-chip timer capabilities, but my previous real-time design experience cautioned me to take another approach. I wanted to have explicit control of processing in this system. I also wanted to be able to collect operational data proving that the system was safely handling its processing requirements.
The project itself was my entry into a 68HC16-based project design contest sponsored by Motorola. To be reimbursed for the contest evaluation kit, designers had to go through a set of evaluation exercises, of which the final result was the creation of a 5-band audio-spectrum analyzer. I was impressed that the HC16 had enough horsepower to process a 20 kHz audio sample stream through five digital filters, display a bar graph output, and still have CPU time to spare.
After seeing a wheelchair-bound person negotiate a ramped curb on a city street, it seemed that a wheelchair controller would be a good application for an HC16-based design. The person I saw was controlling the wheelchair with a chin joystick. The interactions between the acceleration of the chair and his body's inertial motion, along with the bump of the curb, produced erratic movement. I was sure I could design something that would be easier to operate than the equipment he was using. To me, the obvious approach was a voice-activated wheelchair controller.
The controller I had envisioned would be capable of "learning" how a particular operator wished to convey commands using arbitrary combinations of voice, motion, and other inputs. Operators need only be able to reasonably repeat their versions of commands. They shouldn't be required to give a particular command in any otherwise predetermined fashion. This allows ease-of-use by someone with a speech impediment, and makes the controller independent of the spoken language. Voice and other analog command inputs are processed utilizing the on-chip DSP features, while the 16-bit CPU controls inputs from ultrasonic sensors and outputs to drive motors, LCD displays, and audio communication devices.
Table 1 lists the command set the controller recognizes. The interpretation of some of these commands depends on the state of the controller. For example, none of the motion commands are enabled if the wheelchair is stopped. The operator must first issue the Go command to precondition the controller to accept subsequent motion commands. This prevents accidental wheelchair movement.
The Faster and Slower commands can be issued repeatedly for additional increase or decrease of speed. The directional commands (Left and Right) start a graceful turning motion. If issued repeatedly, the turn rate will increase. If issued when the wheelchair is stationary, but preconditioned by the Go and About commands, Left and Right cause the wheelchair to rotate about itself. The Stop command, if issued once, causes a graceful slowing to stop; if issued twice in a row, it will cause a maximum deceleration stop. The Status command reports controller status in a manner understandable by the operator. The output mechanism for status can be aural (speech) and/or visual (display panel). Status information includes estimations of battery reserves, distance traveled, current time, diagnostic status, and other useful data.
To be safe, the speeds of the drive wheels are monitored and compared with expected values based on motor drive current. External forces, loss of traction, and component failure can all cause excessive differences. These situations are handled by digital motor-control routines which attempt to keep the drive wheels powered below the "break loose" threshold.
The design includes front and rear ultrasonic ranging. Control software prevents the operator from hitting any detected obstacle. The anti-collision processing considers speed so that a wheelchair going full-tilt towards a wall will be slowed to a graceful stop right at the wall. A docking mode, assisted by a special power receptacle, controls the fine maneuvering motions necessary to insert the power plug into a receptacle. All operational features of the system are monitored during use. Any detected malfunction causes the controller to take appropriate action, including, but not limited to, stopping motion and notifying the operator. Figure 1 shows a block diagram of the control system.
The master command patterns used for comparison with incoming commands, and the propulsion dynamics of the wheelchair-operator system are determined empirically during an initial training period. The infrared communication devices (shown at the top of Figure 1) allow the controller to communicate with a training computer and technician to facilitate this process.
The control processing for this system requires running a Discrete Fourier Transform (DFT) on the voice input. The spectral output is grouped into frequency bands for use by the recognition algorithm. The prefiltered voice signal is sampled and processed at 6 kHz. Audio output values are also produced at 6 kHz. The strain and position inputs are examined at 10 Hz by taking a group of conversions of the analog signal and averaging the results. The ultrasonic transducers are fired at a rate proportional to the speed of the wheelchair. The transit time of any echoes are computed and compared with closure threshold values. Finally, the wheel encoder values are sampled at 20 Hz and the resulting values are processed into the digital control filters which govern the dynamic motion of the wheelchair. The pulse width modulated (PWM) control to the motors is adjusted at the same rate.
When I was laying out the processing algorithms, I was struck by two things. There was a lot of real-time processing to be done, and the processing routines were mostly independent of each other. I was pretty sure the HC16 could handle the average load. Its built-in hardware helped in that department. For example, the analog inputs, the PWM outputs, and the audio output were all handled directly by hardware in the microcontroller. There are enough independent timer interrupts available in the HC16 to allow most of the processing to proceed in assorted timer-interrupt handlers. I was concerned however that a system with several independent synchronous processes running at different frequencies might create problems that could be extremely difficult to debug. The hardware-based interrupts just didn't leave enough of a debug trail for me.
The best approach seems to be to force all the processing to be controlled from one routine. This is accomplished by using the basic 6 kHz voice input interrupt service routine as the base dispatch handler. This handler is re-entrant as shown in Figure 2 and its code is listed in Listing One (page 92). After the basic DFT processing is done, a series of counters are decremented and examined. If none of the counters reach 0, the interrupt handler returns. However, if a counter does hit 0, dispatch code is executed.
The dispatch code does an uninterruptable check and set of a flag. If the flag was already set, a processing overrun has been detected. Otherwise, the processing handler is called via the counter index. When that routine returns, interrupts are disabled, the flag is reset, and the counter is reloaded by adding its reload value (300 for 20 Hz routines) to its current value (which may have been decremented below 0 by subsequent passes through the 6 kHz handler). The result is placed back into the counter and interrupts are enabled. The now somewhat old instance of the 6 kHz interrupt handler exits.
At start-up, the counters for the various processing handlers are loaded with values that keep the handlers widely separated in time. See Figure 3 for a diagram of this. These steps assure that the handlers are always invoked with an unvarying period.
There are several advantages to this approach. The negative counter values read during the counter reload indicate how many 6 kHz "ticks" the handler consumed. If you have some idea of the maximum processing time required by each of your handlers (don't forget to include 6 kHz interrupt processing), you can convince yourself that your handlers won't ever overrun each other. This assurance would be elusive if all processing were handled by separate interrupt handlers.
I'm happy to say that the wheelchair-controller described here won first place in last year's Motorola-sponsored M68HC16 design contest. (Other winners included Eric Becks of Cheboygan, MI for his EKG recorder design; Larry Korba of Ottawa, Ontario for his design for a DSP metal detector; Tom Schmit of Syosset, NY with a single chip modem/controller for a high frequency radio; and Tom Seim of Kennewick, Washington for his design utilizing the 68HC16 in pattern recognition and control using neural networks). More importantly, I hope that systems like this will make life easier for wheelchair-bound people in the future.
Command Name Explanation Go Enables subsequent motion commands, if currently stopped. Right Turn right. Left Turn left. Forward Stop turning and/or proceed straight ahead. Stop Decelerate and stop all motion. Faster Speed up. Slower Slow down. Back Stop turning and/or proceed straight back. About Enables subsequent direction for rotate right or rotate left. Dock Enables "Dock for Charging" mode. Park Same as Stop, but actively maintain stopped position. Status Give status report.
_AVOIDING MICROCONTROLLER PROCESSING PILEUPS_
by Eric McRae
[LISTING ONE]
/* 6 KHZ interrupt handler. Called from timer ISR. Makes use of INTSOFF
** and INTSON macros which disable and enable interrupts. */
void
sixkhz()
(
int hit, i;
do6kdft(); /* Handle voice DFT processing */
hit = -1; /* Assume no counter hits zero */
for( i = 0; i < MAXCTRS; i++ ) /* Decrement each Counter */
(
if( ! counter[i]-- )
( /* if this counter hit 0 */
if( hit != -1 ) /* If another counter already expired */
{ /* Oh No! Processing Pile */
}
else hit = i; /* Else save index of ctr hitting 0 */
)
) /* end of for each counter */
if( hit != -1 )
( /* If a counter did hit zero */
INTSOFF; /* Disable Interrupts */
if(busyN++) /* If already running a handler */
{ /* Overrun Error if get here (Busy was already set)*/
)
INTSON; /* Enable interrupts */
(do_handler[i])(); /* invoke processing handler */
INTSOFF; /* Disable interrupts */
counter[i] += resetval[i] ) /* Reload ctr considering */
/* time already used */
busyN = 0; /* clear busy flag */
INTSON; /* enable interrupts */
) /* End of it counter expired */
)
Copyright © 1993, Dr. Dobb's Journal