the university of michigan - semantic scholar...movers’ system architecture is shown in figure 1....
TRANSCRIPT
The University of Michigan
User Guide for the
Micro-Controller Interface Board (MCIB) Last Revised November 10th, 1999
by
Johann Borenstein1 (Contributing authors Iwan Ulrich, Jaebum Son, Lars Ferner, Jeff King)
MCIB V3.1: Actual Size
An electronic copy of this document is available at http://www-personal.engin.umich.edu/~johannb/MCIB.html
1 POC: Johann Borenstein, The University of Michigan, Advanced Technologies Lab, 1101 Beal Avenue, Ann
Arbor, MI 48109-2110, ph.: 734-763-1560, e.Mail: [email protected].
ii
TABLE OF CONTENTS
INTRODUCTION AND BACKGROUND ................................................................... 1
1. THE ELECTRONIC HARDWARE................................................................... 3
1.1 System Overview.............................................................................................................................. 3
1.2 The Electronic Interface.................................................................................................................. 4 1.2.1 The MC68HC11 Micro-controller ................................................................................................. 5 1.2.2 The HC11 Master.......................................................................................................................... 6 1.2.3 The HC11 Slaves........................................................................................................................... 8 1.2.4 The PC - HC11 Communication.................................................................................................... 8 1.2.5 The SPI Communication ............................................................................................................. 11 1.2.6 The FIFO .................................................................................................................................... 12 1.2.7 The HCTL Quadrature Decoders................................................................................................. 14
2 THE MCIB FIRMWARE .................................................................................... 14
2.1 The Master HC11 Firmware ......................................................................................................... 14 2.1.1 Task #1 - Communication and Program Execution...................................................................... 15 2.1.2 Task #2 - Generation of the PWM Signals................................................................................... 15 2.1.3 Task #3 - A/D Conversions ......................................................................................................... 17
2.2 The HC11 Slave EERUF Implementation..................................................................................... 17 2.2.1 The Multitasking Architecture .................................................................................................... 17 2.2.2 Task #1 - Communications and Treatment of the Buffer.............................................................. 18 2.2.3 Task #2 - The Generation of the Fire Signals .............................................................................. 18 2.2.4 Task #3 - Checking for Echoes.................................................................................................... 19 2.2.5 Task #4 - The Generation of the BINH Signals............................................................................ 19 2.2.6 The Fire Signal Table.................................................................................................................. 19
3 THE PC SOFTWARE LIBRARY ...................................................................... 23
3.1 Constants........................................................................................................................................ 23 3.1.1 Limits ......................................................................................................................................... 23 3.1.2 Return Codes............................................................................................................................... 23 3.1.3 Parameters .................................................................................................................................. 23 3.1.4 Communication Timing .............................................................................................................. 24
3.2 Data Structures .............................................................................................................................. 25
3.3 Interface Functions ........................................................................................................................ 25
3.4 Internal functions........................................................................................................................... 28
iii
APPENDIX A: EERUF SCHEDULES ..................................................................... 30
APPENDIX B – INSTALLATION ............................................................................ 31
B1. Parallel Port Cable............................................................................................................................... 31
B.2 Power Supply........................................................................................................................................ 31
B.3 Sensors.................................................................................................................................................. 31
B.4 Software................................................................................................................................................ 31
B.5 Initial Power-up ................................................................................................................................... 31
APPENDIX C: CONNECTOR PINOUT................................................................... 32
APPENDIX D – TEST PROGRAM.......................................................................... 32
D.1 Source Code.......................................................................................................................................... 32
D.2 Binary File ........................................................................................................................................... 33
D.3 Functionality ........................................................................................................................................ 33
4 BIBLIOGRAPHY............................................................................................... 34
1
INTRODUCTION AND BACKGROUND
The University of Michigan’s (UM) Mobile Robotics Lab has specialized for over 12 years in the area of mobile robot obstacle avoidance. UM’s obstacle avoidance systems have been implemented successfully on a large variety of mobile robots, on a power wheelchair, on a portable system for the blind, and on a novel, wheeled guidance device for the blind, called GuideCane. Common to all of these systems is the need for fast obstacle avoidance, on the order of 1 m/s or faster. UM has demonstrated the ability of its systems to function at such speeds, and we believe that UM’s reflexive obstacle avoidance systems are the fastest of their kind (i.e., performing near-range, ultrasonic sensor-based, reflexive obstacle avoidance).
One key component of UM’s obstacle avoidance systems is a very sophisticated sonar firing algorithm, called Error Eliminating Rapid Ultrasonic Firing (EERUF). With EERUF individual sonars can detect and reject false readings caused by stray echoes from other sonars onboard (i.e., crosstalk) or off-board (i.e., from other mobile robots), or even from ultrasonic noise in the environment (i.e., gun fire in an urban combat scenario).
To avoid crosstalk, conventional methods mandate lengthy waiting periods in-between firing individual sonars, to allow the echo of each sonar to abate before the next sensor is fired. Conventional systems are also susceptible to ultrasonic noise from other sources (such as other mobile robots). With EERUF, on the other hand, about 97% of crosstalk and other ultrasonic noise is detected and rejected, allowing for substantially faster firing, and hence, faster travel.
For a recent development of UM’s Mobile Robotics Lab, the GuideCane guidance device for the blind, a new “hardware-only” implementation of EERUF was developed. This work is of immediate applicability to the DARPA’s Tactical Mobile Robots (TMR) program because the basic functionality requirement – reflexive obstacle avoidance in indoor and outdoor environments at speeds above 1 m/s – is the same for both applications. The size-, weight-, and power-limitations are also essentially the same for both applications (see Table I).
Table I: Similarity between UM’s GuideCane and the Pioneer AT platform. The scale is the same for both pictures.
Size: 50-cm class Speed: > 1m/s Obstacle Avoidance: 10+ sonars Environment: Indoor/outdoor
Size: 50-cm class Speed > 1m/s Obstacle Avoidance 7+ sonars Environment: Indoor/outdoor
2
UM redesigned, ruggedized, and rebuilt the original hardware-only implementation of EERUF from the GuideCane, and created the Micro-Controller Interface Board (MCIB). This document provides sufficient technical details on the MCIB to allow end-users of the MCIB to use this product successfully in their mobile robot applications.
We should note that the MCIB also provides these additional advantages and features:
§ Is designed to replace and perform most of the functions of the single-HC11 board built into the Pioneer AT or other small mobile platform.
§ Has built-in control of 16 ultrasonic sensors, and it implements the EERUF sonar noise rejection method.
§ Allows fast communication with onboard high-level PC through parallel port, while most other mobile robot interfaces use slow serial links.
§ Software works directly with UM’s VFH obstacle avoidance software.
§ Readily interfaces with additional mobile robot peripherals: § total of 4 motors § total of 4 wheel encoders § fluxgate compass § tilt sensors
MCIB users are strongly encouraged to familiarize themselves with the EERUF method. A
good starting point is [Borenstein and Koren, 19995]. A summary of this paper is provided at http://www-personal.engin.umich.edu/~johannb/eeruf.htm and a link for downloading the full paper (“Paper32”) is also provided at that site.
The steps necessary for connecting and operating the MCIB for the first time are outlined in
Appendix B. Some cables need to to be prepared according to the pinout of the connectors on the MCIB, given in Appendix C. Appendix D explains the installation and use of the supplied test program.
3
1. THE ELECTRONIC HARDWARE
This section explains the hardware components of The University of Michigan’s (UM) Micro-Controller Interface Board (MCIB). To better understand the function of the device, we first present an overview which shows how the board is being used in UM’s Part A development effort under the TMR program. UM’s system, which is based on the RWI Pioneer AT mobile platform, is called “MOVERS.” We present the MOVERS system as an example for an actually working and fully functional implementation of the MCIB.
1.1 System Overview
MOVERS’ System architecture is shown in Figure 1. The main onboard computer is a Toshiba Libretto 100 CT mini-notebook. For simplicity we will refer to it as the “PC” in the remainder of this document. The PC, shown in Figure 2, is a full-featured Windows 95/98 enabled laptop of diminutive size. It features a 166 MHz Pentium processor, 32 MB RAM, and a 2.1 GB hard disk. The foremost advantage of this type of PC over widely used embedded controllers of the equally diminutive PC 104 format family is the built-in 7.4” LCD active matrix color display and a keyboard. During development the availability of an onboard monitor and keyboard are invaluable.
X-, Y-tilt sensors
Computer #1, Libretto 100CTwith enhanced port expander:
Pentium 166 MHz, 4x PCMCIA type 2
1xLPT, 1xCOM
TVINS collaborative positioning
system
GPS Receiver
PCMCIA II Slot #2
PCMCIA II Slot #4
PCMCIA II Slot #3
PCMCIA II Slot #1
LPT1
COM1
PCMCIA-to- 24-I/O lines & 3 timers
R/F joystick receiver
Radio modem for remote
communication
UM-designed custom Micro-Controller Interface Board (MCIB)
with three 68HC11 chips
Platform PWM
amplifiers
Platform wheel
encoders
Electronic compass
System
10.flo, 6/25/98
Fiber-optics gyroscope
PCMCIA-to- COM2&3
Communication with 2nd onboard
PC (Vision)
Com2
Com3
16 ultrasonic sensors
Figure 1: System overview. The Micro-Controller Interface Board (MCIB) uses three 68HC11 chips to read-and pre-process most of the onboard navigation sensors.
4
The PC is connected to the MCIB through its bi-directional parallel port. The MCIB serves as the interface between the PC and most of the sensors and actuators. The MCIB consists of three MC68HC11E2 micro-controllers, four counters, and some logic devices.
The MCIB executes many time-critical tasks, which would take too many resources if executed by the main PC. The MCIB receives commands from the PC and then takes care of the sensors and actuators without any further involvement of the PC. Most of the sensor data is preprocessed by the MCIB before being communicated to the PC. This approach minimizes the bandwidth requirements for the communication between the PC and the MCIB, and it reduces the computational power required by the PC to control the sensors and actuators.
1.2 The Electronic Interface
The architecture of the MCIB is shown in Figure 3. The communication between the PC and the MCIB is based on the PC’s standard parallel port. The parallel port consists of an 8-bit bi-directional data bus, four digital outputs and five digital inputs. In the present design all but two digital inputs are in use. The 8-bit bi-directional data bus together with the four digital outputs and an additional 3-8 decoder allows the PC to communicate with the master micro-controller, the First-In-First-Out (FIFO) register, and the HCTL quadrature decoders. Two of the digital inputs are used for the handshaking with the HC11. Another digital input is used to supervise a FIFO flag. This bus architecture permits parallel communication at high speed. Furthermore, most communications are buffered to minimize delays. As of 11/99 UM is shipping the newly size-reduced version 3.1 of the MCIB, shown in Figure 4.
Figure 2: The Toshiba Libretto 100 CT is a 2.2-pound miniature notebook computer that serves as the main onboard PC. It features a 166 MHz Pentium processor, 32 MB RAM, and a 2.1 GB hard disk.
5
1.2.1 The MC68HC11 Micro-controller
The master- and the two slave micro-controllers are identical Motorola MC68HC11s. The block-diagram of a typical MC68HC112 is shown in Figure 3.
The peripheral functions of the MC68HC11 include:
• Eight-channel A/D converter with eight bits resolution.
• Asynchronous serial communications interface (SCI).
• Synchronous serial peripheral interface (SPI).
• 16-bit timer with three input-capture lines, five output-compare lines and a real-time interrupt function.
• An 8-bit pulse accumulator can count external events or measure external periods.
• Self-monitoring circuitry: watchdog, clock monitor system and illegal opcode detection.
• Two software-controlled power-saving modes, WAIT and STOP, are available to conserve power.
2 Motorola, M68HC11 Reference Manual, 1991.
Mai
n P
C -
Par
alle
l Po
rt
Counter 1HCTL 2016
Counter 2HCTL 2016
Counter 3HCTL 2016
Counter 4HCTL 2016
FIFO7202
Main HC11
HC11Sonars 1-8
HC11Sonars 9-16
Decodingand
ExtendedControlRegister
chipsCP
/SEL/OE
/SEL/OE
/SEL/OE
/SEL/OE
Y0
RS HC11/RS CNT/RS FIFO
Y1Y2Y3Y4Y5
3
43
4
34
34
/STRA/STRBMODE MODE
/R/EF
/R FIFO
PD5 PD5
PA3 PA3
BUS!/?
PB5PB6
25 253635
/SS1/SS2
/W /W FIFO
/STROBE/AUTOFD
/INIT
/SEL 17
15/ERROR
/ACK
BUSY
10
18
2
24
/EF
/EF
46
/OE CNT1
/OE CNT2
/OE CNT3
/OE CNT4
/SEL CNT
/STRB
PB438
31 31
8-bit SONAR DATA
SPI
8-bit BUS
Wheel Encoder 1
Wheel Encoder 2
WheelEncoder 3
WheelEncoder 4
HC11_board_V31.cdr, .wmf, 11/2/99 Figure 3: Schematic overview of UM’s Micro-Controller Interface Board (MCIB).
6
The MC68HC11 name actually refers to a family of advanced 8-bit micro-controllers3. The difference between the MC68HC11 family members lies mainly in the amount and kind of memory. The version used here is the MC68HC11E2, which has 2 K of EEPROM (more than any other family member). For simplicity we will refer to this chip as the “HC11” in the remainder of this document.
Since the HC11 bus runs at only 2 MHz and EEPROM space is limited, it is preferable to program it in assembly instead of a higher level language. Fortunately, the HC11 has a quite comprehensive, orthogonal instruction set. As the software can be stored in the internal EEPROM, the micro-controller can be used in single-chip mode with no external memory.
1.2.2 The HC11 Master
A simplified diagram of the HC11 Master is shown in Figure 6. Port A is used to generate the PWM signals for up to four motor amplifiers. The three unused pins on this port are input capture lines available for future extensions.
Port B is used to independently control the direction of the four motor outputs, to select one of the two HC11 slaves for serial communication (SPI), and for hand-shaking with the PC.
Port C together with the R/W and AS lines is used to communicate with the PC through its bi-directional parallel port.
3 Motorola, M68HC11 Reference Manual, 1991.
Figure 4a: The size-reduced version 3.1 of the Micro-Controller Interface Board (MCIB) measures about 3.5”x3.75”.
Figure 4b: For size comparison: A 3.5” floppy disk printed to the exact same scale as the MCIB photo in Figure 4a.
7
Port D provides two independent serial ports: the asynchronous Serial Communications Interface (SCI) is used to upload the program from the PC into the HC11’s internal EEPROM. For future extensions, a standard serial port device can be connected to this port.
The synchronous Serial Peripheral Interface (SPI) is used to communicate with the two HC11 slaves (see Section 1.2.5, below).
Port E is the eight-channel A/D converter with eight bits of resolution. In the present design one of the eight analog inputs will be used for the electronic compass and two analog inputs will be used for the tilt sensors.
The E signal, a clock output running at 2 MHz, is used to drive the quadrature decoder devices (see Section 1.2.7, below).
Figure 5: The MC68HC11A8 block diagram
8
1.2.3 The HC11 Slaves
A simplified diagram of an HC11 slave is shown in Figure 7. Both slaves are identically integrated into the hardware system. However, there are a few minor differences in their software. Because of the limited number of input and output lines and because of speed considerations, each HC11 slave operates only eight of the maximal possible 16 sonars.
Four outputs of Port A together with a double 2-4 decoder are used to generate the eight BINH signals for the sonars. Port B is used to generate the fire signals for the sonars. Port C together with PA3 is used in an open-collector mode to write the sonar results into the FIFO. Port D is used the same way as for the master HC11. The R/W and PA0 signals are used to synchronize the access to the FIFO bus.
1.2.4 The PC - HC11 Communication
The communication between the PC and the HC11 micro-controllers is done through the master HC11 and the FIFO. The communication between the PC and the master HC11 is based on handshaking supported by the HC11 hardware. The procedure of writing a command (from the PC) to the master HC11 is explained in Section 1.2.4.1. The procedure of reading from the master HC11 is explained in Section 1.2.4.2.
PA4PE4
PD4
E
PB4
PC4
PA1PE1
PD1 PB1
PC1
PA0 NUNUNU
PWM right motor #2PWM left motor #2
Ready
Mode
DIR3NU
/STRB/STRA
/CLK Counters
DIR0
WAIT
PWM right motor #1
DIR1
/SS1
PWM left motor #1
DIR2
/SS2
PE0
PD0 PB0
PC0
PA5PE5
PD5PB5
PC5
PA2PE2
PD2
R/W
PB2
PC2
PA6PE6
PB6
PC6
PA3PE3
PD3
AS
PB3
PC3
PA7PE7
PB7
PC7
HC11Master.
Par
alle
l Por
t
Ana
log
Inpu
ts
SC
IS
PI
Fluxgate compassTilt sensor - XTilt sensor - Y
Current sense from motor R1Current sense from motor L1Current sense from motor R2Current sense from motor L2
Battery Voltage
TxD
MISO
RxD
MOSISCK
HC11Master.cdr, .wmf, 11/2/99
Note: Line assignementsshown in are optionalred/italic Figure 6: The HC11 Master
9
The PC can not communicate directly with the two HC11 slaves. To send a command to the HC11 slaves, the PC sends the command to the master HC11 which will then send it to the HC11 slaves through the SPI as explained in Section 1.2.5. To read the sonar data from the HC11 slaves, the PC reads the buffered data from the FIFO as explained in Section 1.2.6.
1.2.4.1 The Write Command
The timing diagram for a write command is shown in Figure 8. The STRB signal is automatically generated by the HC11 hardware. The STRA signal and the data are controlled by the PC through its software. The STAF is an internal flag of the HC11. The ReadPORTCL represents the corresponding HC11 software command .
Normally, the master HC11 is in input mode waiting for a new command from the PC. The STRB signal indicates to the PC that the HC11 buffer is ready for a new command byte. It is important to note that even though the HC11 may be busy executing some task, the PC can latch a command byte into the HC11 buffer whenever the buffer is empty. However, in order to implement the more generic PWM handling (compared to the “GuideCane” MCIB) we had to extend the command format to two bytes which means that the PC has to wait for the “Master” HC11 to read the first byte from the buffer before it can send the second byte.
Figure 7: The HC11 Slave(s).
10
If the STRB signal is high, the PC can output the command data on the bus and latch it into the HC11 buffer by asserting the STRA signal (falling edge). This operation will automatically deassert the STRB signal indicating to the PC that the HC11 buffer is full. It will also assert the STAF flag, which tells the HC11 that there is new data in its buffer. When the HC11 detects that the STAF is asserted, it will read the data from the buffer. This action will deassert the STAF flag and automatically assert the STRB signal. The asserted STRB signal indicates to the PC that the HC11 is ready for another command. Meanwhile, the HC11 interprets the new command byte and executes the desired operation.
1.2.4.2 The Read Command
The timing diagram for a read command is shown in Figure 9. All signals have the same meaning as in the previous section. In addition, the Mode signal indicates to the PC if the master HC11 is in the input or output mode, and the WritePORTCL represents the corresponding HC11 software command.
To read a byte from the HC11, the PC first has to send a command to the HC11 indicating the desired information. Therefore, the entire communication consists of a write operation followed by a read operation. The write operation is identical to the process described in the previous section. However, once the command byte is interpreted, the HC11 retrieves the desired information and puts it into an internal register. This automatically changes the HC11 port to a
Figure 8: Timing diagram for the Write command
Figure 9: Timing diagram for the Read command
11
readable output mode and deasserts STRB. To indicate to the PC that the data is ready, the Mode signal is set high. The PC then reads the data and asserts STRA indicating to the HC11 that it received the data. The STRA signal also automatically resets the HC11 output port into an input port to liberate the data bus for other communications. The HC11 then clears the STAF flag by reading its buffer, and deasserts the Mode signal to indicate to the PC that it is ready for a new command.
This mode is currently not used. For future extensions, this mode will be useful to read additional sensors connected to the master HC11 analog port. It will also be useful to read data from devices that can be connected to the master HC11’s SPI or SCI port.
1.2.5 The SPI Communication
Both HC11 slaves are connected to the master HC11 through the synchronous Serial Peripheral Interface (SPI). The SPI interface is used primarily to allow the micro-controller to communicate with peripheral devices. Peripheral devices range from simple shift registers to complete subsystems, such as an A/D converter or another HC11. The SPI system is flexible enough to interface with numerous standard peripherals from several manufacturers. Data rates as high as 1 Mbit/sec are accommodated with one of the HC11 as the SPI master.
An example with four SPI devices connected to the master HC11 is shown in Figure 10. In the current interface architecture, there are only two SPI slaves. The master HC11 acts as the SPI master while the two HC11 slaves act as SPI slaves. This architecture allows one to easily add more SPI devices for future extensions.
During an SPI transfer, an 8-bit character is shifted out one data pin while an 8-bit character is simultaneously shifted in a second data pin. So, one byte is simultaneously transmitted and received. The serial clock line (SCK) synchronizes
Command
Byte
Parameter Byte
Command
0000’0000 0000’0000 Get version number of MCIB firmware
0001’0xxx xxxx’xxxx Set PWM parameters (direction, duty cycle)
0010’0000 0000’0xxx Read A/D converter channel
1001’xxxx 0000’0000 Fire single sonar (0-15)
1001’xxxx 0000’0000 EERUF (0: stop, 1-15: start execution of specific schedule)
Table II: Command bytes that can be sent from the PC to the master HC11.
Figure 10: Implementation example for the synchronous Serial Peripheral Interface (SPI) architecture, here shown with four slaves (the MCIB uses only two slaves.)
12
shifting and sampling of the information on the two serial data lines (MOSI and MISO). The slave select line (SS) allows individual selection of a SPI slave.
The use of the SPI is extremely simple as it is fully supported by the HC11 hardware. All SPI transfers are started and controlled by a master SPI device, in this case the master HC11. To transfer a byte to an HC11 slave, the master HC11 simply asserts the corresponding slave select signal and writes the byte into its SPDR register. The hardware of the two involved HC11s then takes care of the communication. At the end of the communication, the bytes that were originally stored in the two SPDR registers are swapped. To indicate the end of the SPI communication, the SPIF (SPI Transfer Complete Flag) is asserted.
1.2.6 The FIFO
The interface is equipped with a FIFO whose purpose is to buffer the outputs of the two HC11 slaves. The currently used FIFO is a high-density buffer with a depth of 1024 bytes. This buffer allows the HC11 slaves to write their data into the FIFO whenever they have a sonar reading as explained in Section 1.2.6.1. It also allows the PC to read the sonar data from the FIFO whenever the PC wants to, as explained in Section 1.2.6.2. Hence, due to the FIFO, the PC can asynchronously read the data from the HC11 slaves. This buffered communication allows the architecture to take full advantage of its distributed computing power.
1.2.6.1 The HC11 - FIFO Communication
The two HC11 slaves share an output bus and the /W FIFO output to write the sonar data into the FIFO. To avoid access conflicts, the HC11 slaves use their Bus? and Bus! lines. The Bus! output of each slave is connected to the Bus? input of the other slave. Asserting the Bus! output means that the slave is in control of the bus or that it desires to be in control. A problem only occurs when both slaves try to take control of the bus simultaneously. To resolve this conflict, the first slave is given priority. The algorithms for the two slaves are shown in Figure 11. The
a b
Figure 11: FIFO bus control for: a) slave 1and b) slave 2
13
precedence of the first slave over the second one is realized by the different reaction to the case when the result of the second Bus? inquiry is positive.
If this method failed for whatever reason, one or both slaves could become damaged by short-circuiting each other. To eliminate this risk, however unlikely it is, the nine shared output lines are used in an open-collector mode with pull-up resistors. Therefore, if both slaves put their data on the shared bus no damage would occur. The only effect would be that wrong data would be written into the FIFO. However, in most cases, this would be detected by the PC reading the wrong data from the FIFO.
1.2.6.2 The PC - FIFO Communication
The PC can easily determine if there is any data in the FIFO by checking the FIFO’s “empty flag” (EF). If the EF flag is deasserted, the PC knows that there is new sonar data in the FIFO. The PC can then read out all sonar data by continuing reading until the EF flag asserts again. This method is very efficient, as the PC only has to check one input line to determine if new sonar data is available.
The PC could also be connected to the “half full” (HF) and “full full” (FF) flags of the FIFO. These flags are currently not used to save some of the parallel port input lines for future extensions. The HF could be used to tell the PC that it should read out the FIFO data. If the FF flag was asserted, it would indicate that probably a data overflow occurred because the PC waited too long before reading the FIFO. The PC would then have to send a reset command to the master HC11 to reset the two slaves and the FIFO. Next, the PC would have to send the command to start the sonars again. Therefore, if for whatever reason the FIFO filled up, the PC would instantly be aware of the problem and could go on without any interaction by the user.
A potential problem of the parallel port is “ringing.” Misreadings due to ringing occur if the FIFO lines are directly connected to the PC parallel port. To eliminate ringing, each of the eight data lines is terminated by a resistor/capacitor network.
1.2.6.3 FIFO Data Encoding
Since both operations, writing to- and reading from the FIFO, are very fast, there is no need to encode the sonar data in as few bytes as possible. For each sonar reading, five bytes are transmitted:
1. Start byte, currently $604. 2. Sonar index between 1 and 16. 3. High byte of 16 bit time of flight in increments of 8 µs. 4. Low byte of 16 bit time of flight in increments of 8 µs. 5. Stop byte, currently $80.
The start and stop bytes are not necessary, but they increase the probability of detecting a communication problem. Even without these two bytes, the PC could detect a problem by verifying that the sonar index is between 1 and 16. Since the extra time required by the start and stop bytes is negligible, these two bytes are kept for safety reasons.
4 The ‘$’ symbol indicates that the following number is in hexadecimal format.
14
1.2.7 The HCTL Quadrature Decoders
The output of each encoder consists of two quadrature signals. By quadrature decoding these two signals, the encoder resolution is multiplied by a factor of four as each edge, rising and falling, is taken into account. However, quadrature decoding is a time-intensive task with restricting requirements.
A very effective and simple solution is the use of the HCTL quadrature decoder interface integrated circuits from Hewlett Packard. The HCTL-2016 features full quadrature encoding with a 16-bit up/down counter, latched outputs, and high noise immunity due to Schmitt trigger inputs and digital noise filters. Moreover, due to the 8-bit tristate output, the two quadrature encoders can simply be connected to the 8-bit PC-interface bus.
The quadrature decoders require a clock signal. Rather than adding some clock circuitry, the E output of the master HC11 is used instead. The E output is a clock signal with a frequency of 2 MHz. To read the 16-bit content of the counter, the low and high bytes can be accessed independently by the use of the SEL signal as shown in Figure 12.
2 THE MCIB FIRMWARE
Although we describe the MCIB as a “hardware only” implementation (because it can be used as such by third party developers, the HC11s micro-controllers require, of course, some operating software. Software for the master and slave units is discussed in this section.
2.1 The Master HC11 Firmware
The master HC11 takes care of most of the communications, samples up to eight analog inputs, resets other devices, and generates the PWM signals for the motors. Since these tasks have different time constraints, the software is organized in a multi-tasking architecture. The tasks running in parallel are summarized in
.
In the current implementation, the main program is interrupted about every 200 µs by tasks #2 and #3. Because the interrupt service routines are small (47 µs, 25% of PWM base period) most of the computing power is reserved for the main program. Currently, only a small portion of the master HC11’s computing power is used, so that there is enough computing power and program space left for future extensions.
Figure 12: Timing of quadrature decoder reading
15
Table III: Master HC11 tasks
# Task Type Time constraints
1 Execute command as requested by PC
Main program Low
2 Generation of PWM signals
Software interrupt: OC1 Hardware interrupts: OC2 - OC5
200 µs
3 Continuous A/D conversions
Software interrupt: OC2 Low
2.1.1 Task #1 - Communication and Program Execution
The main program spends most of its time waiting for a new command byte from the PC. When it receives a new command, it will decode it according to Table II (see page 11) and execute it. If the command is for the motors, the HC11 will put the corresponding value in an internal register, which will be read later by the PWM interrupt routine (see task #2).
If the PC needs to know the value of an analog input, the HC11 starts the A/D conversion (16 µs), calculates the average of the four conversion and sends it back to the PC trough handshaking as explained in Section 1.2.4.
If the command is for one of the HC11 slaves, the master HC11 will forward it to them trough the SPI line as explained in Section 1.2.5.
2.1.2 Task #2 - Generation of the PWM Signals
Task #2 generates the PWM signals for up to four motors, as shown in Figure 13. Specifications for the PWM signals required to drive the Pioneer AT’s power amplifiers were not available at the time of writing this document. For this reason we will assume here a typical PWM control signal that repeats every 20-30 ms with a variable pulse width ranging from 1 to 2 ms in duration:
The generation of these signals can be implemented by two different methods. In the first method, the master HC11 generates the PWM signals with a 32.77 ms period. Even though this period is higher than the typical period, the PWM amplifier will still work properly. The reason for the choice of this particular period is that the internal timer of the HC11 overflows after 32.77 ms. Therefore, the PWM signals can be generated based on hardware interrupts only, without requiring any software interrupt servicing. This is very efficient, as it takes no computation power of the HC11. However, if a new command with a smaller pulse width is given to the HC11 in the time span between the falling edges of the new and old command, the PWM signal will stay high for an entire period. Since the critical time span is rather small, this problem occurs rarely. If it happens, the effect is small as the momentarily wrong command is filtered by the inertia of the motors and platform body.
Figure 13: Typical PWM control signal (may be different on actual Pioneer AT).
16
In the second method, the PWM signals are generated with the typical period of 20 ms. This method eliminates the potential problem of the first method. It is also advantageous over the first method if the sampling rate of the UM software is smaller than 32.77 ms. As a disadvantage, this method requires software interrupt servicing, and therefore takes some computation power of the HC11. However, since the interrupt service routine is small and the master HC11 has more than enough computation power for its other tasks, the second method was implemented as it is safer and allows higher sampling rates.
This second method can be implemented with the HC11 output compare functions. These real-time interrupt functions allow one to efficiently implement up to four PWM signals. In the Pioneer AT configuration, two (or four5) PWM signals will be used. A basic and an enhanced method of implementation are shown in Figure 14.
With the basic method, the OC1 (output compare 1) hardware interrupt is used to simultaneously generate the rising edges of the two (or four) PWM signals every 20 ms. The OC2-OC5 hardware interrupts are used for the falling edges of the four respective PWM signals.
In the enhanced method, the OC1 hardware interrupt is used to simultaneously generate the falling edges of the two (or four) PWM signals every 20 ms. The OC2-OC5 hardware interrupts are used for the rising edges of the respective PWM signals.
With both methods, only the OC1 interrupt is serviced. This interrupt service routine calculates the output compare timer values for the next set of events and writes them to the corresponding registers. For the basic method, as shown in Figure 14, these values must be updated no later than 1 ms after the OC1 interrupt occurred. In the current implementation, 1 ms is more than sufficient. However, if the master HC11 has to take care of more parallel tasks in future extensions, this time limit could be a problem. With the enhanced method, the time limit is 18 ms, so that there should be no problem even if several more tasks were added. For this reason, the enhanced method was implemented.
a b Figure 14: Generation of PWM signals: a) basic method, b) enhanced method
5 UM will investigate the feasibility of its newly proposed method for detecting wheel slippage on the Pioneer
AT: Taking advantage of the four built-in motors of the Pioneer AT, UM will decouple the currently mechanically linked wheel pairs on each side of the platform and drive each wheel independently. Then, using an additional set of wheel encoders (currently only the two front motors have encoders), conclusions about wheel slippage can be drawn by comparing the encoder readings from all four wheels.
17
2.1.3 Task #3 - A/D Conversions
Analog-to-digital (A/D) conversion of signals will likely be necessary for some of the auxiliary sensors, such as UM’s proposed 2-axis tilt sensor and, possibly, for a KVH fluxgate compass. The master HC11 can read the analog output values of these sensors. The HC11 allows for single or continuous A/D conversions, there are always four measurements taken: it’s possible to measure four different signals once or a single signal four times. Since the HC11 can convert only four out of eight signals continuously, we need to do single measurements whenever a conversion for one of the eight channels is requested by the PC. The HC11 is configured to make four conversions on the chosen channel.
The results of these conversions are stored in registers, which can be read by task #1. These four measurements are averaged before being sent to the PC.
2.2 The HC11 Slave EERUF Implementation
One of the foremost advantages of the MCIB is its built-in implementation of the EERUF algorithms for crosstalk and noise rejection with ultrasonic sensors. This section discusses some of the implementation details, but not the theoretical background for this approach.
2.2.1 The Multitasking Architecture
Because of the limited number of available input/output lines and because of concerns over the speed of program execution for the time-sensitive EERUF algorithm, one HC11 is dedicated for each group of eight ultrasonic sensors. In the current implementation there are two such slave HC11s, allowing a total of 16 ultrasonic sensors to be controlled accurately. Each slave HC11 has to accomplish several tasks at different rates and with different time constraints. To implement this efficiently, the slave HC11 software is also organized in a multi-tasking architecture. The four different tasks with their properties are summarized in Table IV:
Table IV: slave HC11 tasks
# Task Type Time constraints
1 Compute TOF and write into FIFO
Main program Low
2 Generate fire signals and set time for next BINH interrupt
Software interrupt: OC4 13 times in 200 ms according to EERUF schedule
3 Check echo signals Software interrupt: OC5 Every 50 µs
4 Generate BINH signals Hardware interrupt: OC1 Exactly 0.6 ms after corresponding fire signal
18
The main program (task #1) is constantly interrupted by the two software interrupts (tasks #2 and #3) which generate the fire signals and check the echo signals. The fourth task (task #4) is supported by the HC11 hardware so that it does not require interrupt servicing. However, the times at which the BINH signals are changed are set during the interrupt servicing of task #2. Tasks #2 and #3 communicate with task #1 through an internal FIFO buffer and several global variables.
2.2.2 Task #1 - Communications and Treatment of the Buffer
Task #1 reads the internal FIFO buffer containing the data from tasks #2 and #3. It analyzes this data and computes the time of flight (TOF). This task also takes care of all the other not time-critical tasks, e.g. the SPI communication with the master HC11.
The time constraints of task #1 are low. However, if it is not executed often enough, the internal buffer may overflow. As the timing of task #2 is fixed by the EERUF schedule and task #4 is only a hardware interrupt, only the timing of task #3 can be changed to influence the time allocation of task #1. Basically, the higher the execution rate of task #3, the better the sonar resolution, but also the less time is allocated to task #1, and hence the higher the risk of an internal buffer overflow. However, tests have shown that task #3 can even be executed every 25 µs without problems. The algorithm of task #1 is summarized as following:
1. New request from master HC11? If yes execute, e.g. start sonars, stop sonars, change EERUF mode, fire single sonar.
2. Check internal buffer. If empty go back to step 1.
3. Read next byte from internal buffer.
4. If the byte is equal to No_Echo, the corresponding sonar(s) has not received back an echo. Write index and TOF equal to zero into FIFO. Go back to step 1.
5. Otherwise, compute the TOF for corresponding sonar(s). Write index and TOF into FIFO.
6. Go back to step 1.
2.2.3 Task #2 - The Generation of the Fire Signals
Task #2 is responsible for generating the fire signals and setting the time for the next BINH interrupt. The fire signals must be generated as specified by the EERUF time schedule. This task is executed 13 times in an interval of 200 ms. Its algorithm is the following:
1. If a fire signal is deactivated, check if the corresponding echo was received. If not, write the No_Echo byte and the index of the corresponding sonar(s) into the internal buffer.
2. Output new fire signals and save time into array p_list_fire[index].
3. Set time and output for next BINH signal.
4. Set time for next fire signal event.
5. Increment EERUF table pointers.
6. Execute task #3.
19
2.2.4 Task #3 - Checking for Echoes
Task #3 is the most time intensive as it checks for new echoes every 50 µs. The more often this task is executed, the better the sonar resolution. Hence, it is important to make this routine as short and fast as possible. For this reason, task #3 only checks for new echoes, but neither identifies the sonar(s) nor computes the TOF. It just saves the current time and a representative byte into the internal buffer. The representative byte contains bits set to one for sonars with new echoes. This data is then treated by task #1. The algorithm of the interrupt service routine is as follows:
1. Read echoes.
2. Check for new echoes with: ¬(previous echoes) ∧ (current echoes).
3. If the result is not zero, save it and the current time in internal buffer.
4. Save current echoes as previous echoes.
5. Set time for next interrupt.
2.2.5 Task #4 - The Generation of the BINH Signals
Task #4 is the most time constrained as the BINH signal must be activated exactly 0.6 ms after the fire signal. This can be done by using the hardware interrupt OC1 without any interrupt servicing. When the HC11 timer becomes identical to the time set in step 3 of task #2, the OC1 interrupt will automatically output the four bits defined in the same step. This assures exact activation of the BINH signals independent of other interrupts.
2.2.6 The Fire Signal Table
The original EERUF fire schedule [2] is tailored for a sonar system consisting of 12 sonars, and each sonar is fired once in every 100 ms interval. The difference between two consecutive sonar echoes must be smaller than 1 ms to be accepted as a valid reading. These fire signals are generated by task #2 according to the EERUF schedule. For an efficient software implementation of task #2, the EERUF time schedule is stored in a look-up table.
The remaining part of this section develops the look-up table for the first HC11 slave, which uses the schedule for the first eight sonars.
Table V: EERUF firing schedule
Sonar 1 2 3 4 5 6 7 8 9 10 11 12
Tfire,a [ms] 24 49 74 99 24 49 74 99 24 49 74 99
Tfire,b [ms] 18 37 56 75 20 39 58 77 22 41 60 79
For the second HC11 slave, the schedule for sonars 9-12 and 1-4 is currently implemented for actual sonars 9-16. The selection of repeating the EERUF schedule for sonars 1-4 is arbitrary. If physical sonars 13-16 will be implemented at all, they will likely be facing backward and thus not interfere with the other, forward-facing sonars.
20
The sonar fire signal has to be held high as long as the sensor should be listening to an echo. For maximum flexibility, the fire signal is held high for longer than 58 ms which, theoretically, allows the sonars to detect an obstacle up to at least 10 m. In practice, the electronic environment is too noisy for the sonars to detect obstacles reliably at this distance. However, choosing a large look-ahead gives us maximum flexibility. The PC software can easily reduce the look-ahead, but it can not extend it. For more flexibility during the HC11 software design process, we will start out with an even larger look-ahead of 72.6 ms.
As each of the eight sonars fires once in 125 ms, we would expect to need 16 interrupts in the same time interval, eight for asserting the fire signals and eight for deasserting them. However, during every other period, two sonars are activated and deactivated together as shown in the upper part of Table VI. This reduces the number of interrupts to 12 in a time interval of 125 ms.
To generate these time-critical fire signals, the HC11 uses its timer interrupt OC4. The HC11 timer is prescaled by a factor of 16 to give it a 8 µs resolution. The timer has to interrupt the HC11 whenever a fire signal has to change its state. After each interrupt, a new interrupt time has to be set for the next change. Therefore, what matters is the difference ∆ in 8 µs steps between consecutive time events. After ordering the fire signal events, we get the information shown in Table VII. Now, we can reduce the number of events even further by combining some of the stop events with others. When we built our first fire signal schedule, we were using a look-ahead of 72.6 ms which is much longer than the required look-ahead of 58 ms. Therefore, we can combine a stop event with another one that occurs not earlier than 14.6 ms. This allows us to reduce the number of events in a time interval of 200 ms to only 13 as shown in Table VIII. This table also contains the data for the generation of the BINH signals. The data of the last five columns is stored in the form of look-up lists in the HC11 memory.
The data for the second HC11 slave is shown in Table IX:
21
Table VII: Ordered fire signals
Event [0.1 ms]
Event [8 µµs]
∆∆ [8 µµs]
Fire Stop
240 3000 3125 1, 5
490 6125 3125 2, 6
740 9250 2825 3, 7
966 12075 300 1, 5
990 12375 2375 4, 8
1180 14750 250 1
1200 15000 200 5
1216 15200 1925 2, 6
1370 17125 250 2
1390 17375 950 6
1466 18325 1175 3, 7
1560 19500 250 3
1580 19750 1700 7
1716 21450 425 4, 8
1750 21875 250 4
1770 22125 1700 8
1906 23825 250 1
1926 24075 2125 5
2096 26200 250 2
2116 26450 1550 6
2240 28000 575 1, 5
2286 28575 250 3
2306 28825 2125 7
2476 30950 250 4
2496 31200 8
Table VI: Fire signals
Event [0.1 ms]
Fire Stop
240 1, 5
966 1, 5
490 2, 6
1216 2, 6
740 3, 7
1466 3, 7
990 4, 8
1716 4, 8
1180 1
1200 5
1906 1
1926 5
1370 2
1390 6
2096 2
2116 6
1560 3
1580 7
2286 3
2306 7
1750 4
1770 8
2476 4
2496 8
2240 1, 5
22
Table VIII: Look-up table for the first HC11 slave
Event
[0.1 ms]
Event
[8 µµs]
∆∆
[8 µµs]
Fire Stop ∆∆BINH Byte BINH
240 3000 3125 1, 5 3, 4, 7, 8 BINH 0000|0000
490 6125 3125 2, 6 BINH 0101|0000
740 9250 3125 3, 7 BINH 1010|0000
990 12375 2375 4, 8 1, 5 BINH 1111|0000
1180 14750 250 1 BINH 1100|0000
1200 15000 2125 5 2,6 BINH 0000|0000
1370 17125 250 2 BINH 0001|0000
1390 17375 2125 6 3,7 BINH 0101|0000
1560 19500 250 3 BINH 0110|0000
1580 19750 2125 7 4,8 BINH 1010|0000
1750 21875 250 4 BINH 1011|0000
1770 22125 2500 8 BINH 1111|0000
1970 24625 3375 1, 2, 5, 6 0 0000|0000
2240 28000 1, 5 BINH 0000|0000
Table IX: Look-up table for the second HC11 slave
Event
[0.1 ms]
Event
[8 µµs]
∆∆
[8 µµs]
Fire Stop ∆∆BINH Byte BINH
240 3000 3125 9,13 11,12,15,16 BINH 0000|0000
490 6125 3125 10,14 BINH 0101|0000
740 9250 3125 11,15 BINH 1010|0000
990 12375 2375 12,16 9,13 BINH 1111|0000
1180 14750 500 13 BINH 0011|0000
1220 15250 1875 9 10,14 BINH 0000|0000
1370 17125 500 14 BINH 0100|0000
1410 17625 1875 10 11,15 BINH 0101|0000
1560 19500 500 15 BINH 1001|0000
1600 20000 1875 11 12,16 BINH 1010|0000
1750 21875 500 16 BINH 1110|0000
1790 22375 2875 12 BINH 1111|0000
2020 25250 2750 9,10,13,14 0 0000|0000
2240 28000 9,13 BINH 0000|0000
23
3 THE PC SOFTWARE LIBRARY
In order to facilitate integration of the MCIB in the end-users project, we are providing a library of “C” functions designed to run on the IBM-PC compatible on-board computer, to which the MCIB is linked via the parallel port. This section lists the available functions.
3.1 Constants
3.1.1 Limits
The following constants define the maximum number of sonars, counters, A/D converters and PWM channels provided by the MCIB:
MAX_SONARS maximum number of sonars supported by MCIB MAX_COUNTERS maximum number of counters supported by MCIB MAX_ADCS maximum number of A/D converters supported by MCIB MAX_PWMCS maximum number of PWM channels supported by MCIB
3.1.2 Return Codes
Most of the library functions return an error code while the actual result is passed back through a parameter.
INVALID_PARAM if an invalid (e. g. out of range) parameter was passed NO_DATA if no data could be read from the FIFO DATA_ERR if the data in a sonar package was inconsistent DATA_OK if the function call was successful NO_ECHO if no echo was received by a sonar sensor LOW_DISTANCE if the measured distance was smaller than the minimum distance CROSSTALK if sonar data had to be rejected, because of crosstalk
3.1.3 Parameters
There are several other constants used as function parameters; since they are specific to the functions, they will be explained in the context of the function descriptions.
24
3.1.4 Communication Timing
Since robotic applications are always time-critical, we want the communication between the PC and the MCIB to be as fast as possible. In the ideal case we would be switching the control signals on the PC’s parallel port at a rate close to the CPU’s clock speed, but due to signal run-time and the lower clock speed of the MCIB we need to introduce a delay in switching signals on the parallel port. In order to avoid the use of a commercial timer library, which would additionally have to be purchased by the user, we decided on implementing these delays by simple “for”-loops. This method depends on the PC’s clock speed, of course, which means that the number of loop cycles has to be adjusted to the used computer to keep the delay times constant. This can easily be done by changing the value of the following constants defined in the ‘MCI.cpp’ source file; the values given are used on our system which is controlled by a 166 MHz Pentium PC.
TIMEOUT timeout for waiting on MCIB to respond (1000) RESET_DELAY delay to hold reset signals (10000) SIGNAL_DELAY delay to hold signals (100) (to compensate for run-time through long cables)
The ‘RESET_DELAY’ is not time-critical, because the function shouldn’t be called inside the robot’s control loop - we chose a pretty high value in the first place. The ‘TIMEOUT’ for the communication with the “Master” HC11 is not that critical, either, because the PC should never have to wait for the MCIB during normal operation. It’s used to compensate for delays occurring when the “Master” HC11 is servicing an interrupt call. The ‘SIGNAL_DELAY’ is very important, though, because it’s value determines the length of impulses between switching signals on the parallel port. In order to achieve fast communication you want this value to be as small as possible, but large enough to guarantee reliable data transmissions – unfortunately, this requires some testing with different values for ‘SIGNAL_DELAY’. For a faster machine you want this value to be higher, for a slower machine you can decrease it. It’s a good idea to start with a large value and then decrease it until the transmissions show errors
25
3.2 Data Structures
There is only one data structure defined in the MCI library:
typedef struct tagSonarReading { byte bSonar mm mmDistance } tSonarReading
This data structure is used when calling the functions ‘MCIReadSonar’ and ‘MCIGetSonarReading’ (see below); on return it contains the sonar number (‘bSonar’) and measured distance in millimeters (‘mmDistance’).
3.3 Interface Functions
These are the “public” functions of the MCIB library allowing access to the entire functionality of the MCIB.
bool MCIInit( int far *fpiBIOS_LPT )
Initializes the Multi Controller Interface – has to be called before any other function can be called. Since the printer port’s data lines are usually configured as outputs and the MCIB is also able to send data back to the PC it could happen that the output drivers work against each other on power-up. To avoid this on reset all devices on the MCIB are switched to input mode until the “Master” HC11 recognizes a specific handshaking on one of the control lines. This handshaking is performed by the initialization function. On calling the function the used parallel port needs to be specified by one of the pre-defined constants:
LPT1 LPT2 LPT3
The function uses the corresponding BIOS entry to determine the actual port address. If there was an error initializing the system the function prints an error message to the screen and returns ‘BL_FALSE’.
26
void MCIExit( void )
Resets the MCIB and has to be called at the end of the program.
float MCIGetVersion ( void )
Returns the version number of the MCIB’s firmware if it is connected, otherwise 0.0.
void MCIResetDevice( byte bDevice )
Resets a single device on the MCIB which can be specified by using one of the following constants defined in the MCIB library:
DEV_HC11 for all HC11‘s DEV_CNTS for the counters DEV_FIFO for the FIFO
short MCISetPWM( byte bChannel, float fPulseWidth, bool blReverse )
Sets pulse width and direction for the selected PWM channel [0..MAX_PMWCS]. The direction can be specified by passing one of the following constants defined in the MCIB library:
PWM_FORWARD PWM_REVERSE
Although the PWM signal is generated using the hardware timers and compare registers of the “Master” HC11 an interrupt routine is necessary to update the compare registers. Executing this interrupt routine takes some time (approx. 50 µs), which limits the maximum duty cycle. With a base period time of 200 µs the maximum duty cycle is 75%. Although the theoretical range for the pulse width parameter is [0.0..100.0] the actual duty cycle is limited to 75%.
short MCIReadADC( byte bChannel, byte &bValue )
Reads the value from the selected A/D converter where the channel number (‘bChannel’) is [0..MAX_ADCS]. All “read” functions return an error code (see Return Codes) and the actual result in the corresponding parameter (‘bValue’).
27
short MCIReadCounter( byte bCounter, word &wValue )
Reads the current value from the selected counter where the counter number (‘bCounter’) is [0..MAX_COUNTERS].
short MCIReadSonar( tSonarReading &sr, word wDeltaDistTblIdx = 0U )
Fires a single sonar and returns the measured distance in ‘sr’. The sonar number [0..MAX_SONARS] has to be specified in ‘sr.bSonar’ before the function is called (see also ‘MCIGetSonarReading’).
void MCIStartEERUF( byte bSchedule )
Starts execution of the EERUF algorithm on the MCIB using one of the EERUF schedule explained in Appendix A. (‘bCounter’) is [EERUF_1..EERUF_n], where constants EERUF_1 through EERUF_n are defined in the MCIB library. Data packages containing the range information have to be read from the FIFO, continuously, using the ‘MCIGetSonarReading’ function.
Note: in order to switch between different EERUF schedules do not call ‘MCIStopEERUF’ first, just call ‘MCIStartEERUF’ again.
void MCIStopEERUF( void )
Stops execution of the EERUF algorithm on the MCIB.
short MCIGetSonarReading( tSonarReading &sr, word wDeltaDistTblIdx = 0U)
Reads a sonar package from the FIFO.
Note: the delta distance for crosstalk rejection depends on the circumstances the sonar sensor is used under, e.g. the direction the sonar is facing at (front or side), the speed the robot is travelling at (front facing sonars), the kind of surfaces around the sensor, etc. With a mobile robot these circumstances change more or less quickly which means that the delta distance for the different sensors has to be adjusted dynamically. This is done by using a number of tables containing delta distances specific to every sensor where a particular table is chosen dependent on the speed of the robot ('wDeltaDistTblIdx'). The number of tables used depends on the application (maximum speed of the robot) and the calling
28
function has to make sure that only valid table indices are passed to the 'MCIGetSonarReading' function, because 'MCIGetSonarReading' does NOT check the index for reasons of efficiency.
3.4 Internal functions
These functions usually do not need to be called by the user; they are low-level functions called by the “public” interface functions.
void MCISendCommand( byte bCommand, byte bParameter, bool blDisable )
Sends a command to the “Master” HC11 (for command codes see ‘MCI.h’ file).
short MCIReceiveByte( byte &bData )
Receives a byte from the “Master” HC11.
short MCIReadFIFO( byte &bData )
Reads the next byte from the FIFO - if a byte could be read from the FIFO, it is returned in ‘bData’.
void MCISelectDevice( byte bDevice )
Selects a device (“Master” HC11, FIFO or counter) to read from or write data to.
Note: the output of the address decoder has to be enabled (disabled) using the ‘MCIEnableDevice’ function to actually access the device.
void MCIUnlock( void )
Performs “secret handshaking” with the “Master” HC11 on the MCIB to make sure that the MCIB’s devices put data on the parallel port only when we are talking to it.
29
void MCISetExtControlBit( byte bControlBit, bool blActiveLow, bool blActive )
Manipulates the specified bit in the MCIB’s extended control register (for bit codes see ‘MCI.h’ file).
void MCISetExtControlReg( byte bValue )
Sets the value of the MCIB’s extended control register.
void MCISetControlBit( byte bControlBit, bool blActiveLow, bool blActive )
Manipulates the specified (-> ONE) bit in the parallel port’s control register (for bit codes see ‘MCI.h’ file).
30
APPENDIX A: EERUF SCHEDULES
The MCIB implements the UM’s patented EERUF method. EERUF fires the ultrasonic sensors according to preprogrammed “schedules.” UM has pre-programmed five different schedules in the MCIB firmware. Function MCIStartEERUF( byte bSchedule ) is used to select one of these predefined schedules.
The timing and firing sequence defined in each EERUF schedule are optimized for a certain number of sonars and possible environmental conditions. Table A1 below lists the characteristics of each of the preprogrammed schedules. The firing rate indicates the amount of time during which each sonar is fired once.
Table A1: EERUF schedules and their properties
Constant (defined in
MCIB library)
# of sonars on robot
Firing rate [ms]
Comment
EERUF_1 12 100 The original schedule from the EERUF paper
(ftp://ftp.eecs.umich.edu/people/johannb/paper32.pdf)
EERUF_2 12 200 A slower version of the original schedule from the EERUF paper. Will produce fewer rejections in high-crosstalk environments.
EERUF_3 10 100 The EERUF schedule used on the “GuideCane” where 10 sonars were used
EERUF_4 16 110 Optimized schedule for 16 sonar.
EERUF_5 16 90 Two banks of 8 sonars with identical, simultaneous firing one bank for each slave HC11. This is not pure EERUF but it will work fine if the chance of crosstalk between the two bans is minimal (e.g., if one bank is arranged in a semi-circle in the front, the other bank in the rear.
31
APPENDIX B – INSTALLATION
B1. Parallel Port Cable
First you have to make a cable to connect the MCIB to the PC’s parallel port. You need a 25-pin male SUBD connector, a 26-pin (!) female connector and a 25-pin ribbon cable with a maximum length of 2 m, but try to keep the cable as short as possible.
B.2 Power Supply
The sonar boards hooked up to the MCIB can be powered at a different voltage (+6 V) than the digital electronics (+5 V), but the standard Polaroid boards work at +5 V, as well. So you can either use the same +5 V power supply for both the electronics and the sonar boards or use separate power supplies. The power supply driving the sonar boards should have a constant current rating of at least 3 A.
B.3 Sensors
In order to connect the various sensors to the MCIB you need to equip them with connectors fitting the ones on the board – see Appendix C for pinouts.
B.4 Software
To verify that the board is working properly you can either use the provided binary test file (see Appendix D) or compile and link the sources yourself using one of the Borland project files. If you want to use a different compiler you will need to set up a project yourself.
B.5 Initial Power-up
To test the board it has to be connected to the power supply and the computer using the parallel port cable prepared in step B.1 above. The PC has to be booted in DOS mode (not a Windows DOS box!). Before turning on power make sure the jumper JP3 is closed. When run, the test program first checks the BIOS, if the configured parallel port is available (the test program uses LPT1 which should be available on every PC). If the port is valid, the secret handshaking (see also explanation of ‘MCIInit’ function) with the MCIB is performed – the yellow on-line LED on the board lights up, otherwise the board is either not connected to the computer or not powered up. The version number of the MCIB’s firmware is read and displayed on the screen in the last step of the initialization.
32
APPENDIX C: CONNECTOR PINOUT
APPENDIX D – TEST PROGRAM
Besides the MCIB itself, the MCI library, and the User’s Manual, the MCIB kit also includes a test program, which allows the user to verify that the board is working properly.
D.1 Source Code The installation floppy disk contains two project files for Borland C++ V3.1 (‘Test.prj’) and
V4.5 (‘Test.ide’); the source tree includes the following files:
• ‘Test.cpp’: main module of test program; look at this file for examples how to call the various functions in the MCI library
• ‘MCI.h/cpp’: the header file and source code of the MCI library
• ‘AuxFcts.h/cpp’: a module providing some useful auxiliary functions
• ‘BasicDef.h/cpp’: definitions of basic data types, data structures, macros, etc.
• ‘egavga.obj’: the Borland graphics library If all the source files are saved in the same directory as the project file, you can simply open the
project file, compile the sources and run the program. Note: Since Windows does not allow direct access to the PC’s communication ports and also
interferes with the computer’s timers, you have to run any application using the MCIB and the MCI library under DOS (not in a Windows DOS box!). Also, the MCIB needs to be initialized before any changes to the PC’s timing system are made (by a timer library, for example), because the initialization of the board requires exact timing.
Figure A1: MCIB Vers. 3.1 connector pinout
33
When using the MCI library with your own project just integrate the source files ‘MCI.cpp’, ‘AuxFcts.cpp’ and ‘BasicDef.cpp’ in the source tree and include the header file ‘MCI.h’ in all modules calling MCI functions.
D.2 Binary File
For your convenience the CD also includes an already compiled and linked binary version of the test program. This program uses very conservative timing (see Section 3.1.4 Communication Timing) in order to be compatible with a wider range of computers with regards to clock speed – it was tested on machines working at 166 MHz through 450 MHz.
D.3 Functionality
The test program allows verification of every function of the MCIB:
• EERUF execution
• single sonar firing
• PWM signal generation
• A/D conversion
• encoder reading
However, there is no graphical display, all values read from the board are displayed numerically. Execution of the various EERUF schedules is started by pressing the function keys F1 through Fn (see Appendix A for available schedules); execution of any EERUF schedule is stopped by pressing SPACE. Single sonar sensors can be “fired” by pressing the keys 0 through 9 and A through F (hexadecimal counting), M fires all sensors; pressing the key K before allows for one or all sensors to be fired continuously. The A/D converters and counters are read constantly. The keys CRSR_UP and CRSR_DOWN are used to set the pulse width in increments of 10% for the channel chosen with the CRSR_LEFT and CRSR_RIGHT keys.
34
4 BIBLIOGRAPHY
[1]6 Borenstein, J. and Feng, L., “Measurement and Correction of Systematic Odometry Errors in Mobile Robots.” IEEE Transactions on Robotics and Automation, December 1996, pp. 869-880.
[2] Borenstein, J. and Koren, Y., “Error Eliminating Rapid Ultrasonic Firing for Mobile Robot Obstacle Avoidance.” IEEE Transactions on Robotics and Automation, February 1995, Vol. 11, No. 1, pp. 132-138.
[3] Borenstein, J. and Koren, Y., “Histogramic In-Motion Mapping for Mobile Robot Obstacle Avoidance.” IEEE Transactions on Robotics and Automation, August 1991, pp. 535-539.
[4] Borenstein, J. and Koren, Y., “Real-time Obstacle Avoidance for Fast Mobile Robots.” IEEE Transactions on Systems, Man, and Cybernetics, Vol. 19, No. 5, Sept./Oct/ 1989, pp. 1179-1187.
[5] Borenstein, J. and Koren, Y., “The Vector Field Histogram - Fast Obstacle Avoidance for Mobile Robots.” IEEE Journal of Robotics and Automation, June 1991, Vol. 7, No. 3, pp. 278-288.
[6] Borenstein, J. and Ulrich, I., “The GuideCane - A Computerized Travel Aid for the Active Guidance of Blind Pedestrians.” IEEE Conference on Robotics and Automation, Albuquerque, April 1997, pp. 1283-1288.
[7] Borenstein, J., Everett, H.R. and Feng, L., “Navigating Mobile Robots.” A. K. Peters, Ltd., Wellesley, MA, ISBN 1-56881-058-X, Publication Date: February 1996..
[8] Brabyn, J. A., “New Developments in Mobility and Orientation Aids for the Blind.” IEEE Transactions on Biomedical Engineering, 1982, Vol. BME-29, No. 4, pp. 285-289.
[9] Crowley, J. and Reignier, P., “Asynchronous Control of Rotation and Translation for a Robot Vehicle.” Robotics and Autonomous Systems, 1992, Vol. 10, pp. 243-251.
[10] Elfes, A., “Using occupancy grids for mobile robot perception and navigation.” Computer Magazine, June 1989, pp. 46-57.
[11] Feng, L., Borenstein, J. and Wehe, D., “A Completely Wireless Development System for Mobile Robots.” ISRAM Conference, Montpellier, France, May 1996, pp. 277-282.
[12] Klarer, P.R., “Simple 2-D Navigation for Wheeled Vehicles.” Sandia Report SAND88-0540, Sandia National Laboratories, Albuquerque, April 1988.
[13] Koren, Y., and Borenstein, J., “Analysis of Control Methods for Mobile Robot Obstacle Avoidance.” IEEE International Workshop on Intelligent Motion Control, Istanbul, Turkey, August 1990, pp. 457-462.
[14] Koren, Y., and Borenstein, J., “Potential Field Methods and Their Inherent Limitations for Mobile Robot Navigation.” IEEE International Conference on Robotics and Automation, Sacramento, California, April 1991, pp. 1398-1404.
6 All Borenstein papers can be downloaded from
http://www-personal.engin.umich.edu/~johannb/mypapers.htm
35
[15] KVH Industries, C100 Compass Engine Product Literature, 110 Enterprise Center, Middletown, RI 02840, 401-847-3327.
[16] Moravec, H.P., “Sensor fusion in certainty grids for mobile robots”, AI Magazine, Summer 1988, pp. 61-74.
[17] Motorola, M68HC11 Reference Manual, 1991. [18] PC/104 Consortium, “PC/104 Specification Version 2.3”, June 1996. [19] Polaroid, "Ultrasonic Ranging System", Product Literature, Polaroid Corporation, 784
Memorial Drive, Cambridge, MA 02139, (617) 386 3964, 1991. [20] Simmons, R., “The Curvature-Velocity Method for Local Obstacle Avoidance.”
International Conference on Robotics and Automation, Minneapolis, MN, April 1996. [21] Thorpe, C.E., “Vision and Navigation - The Carnegie Mellon Navlab.” Kluwer Academic
Publishers, Norwell, MA, 1990. [22] TriTech, "Voice Storage Controller TR83100CF." Product Literature, TriTech
Microelectronics International Inc., 1400 McCandless Drive, Milpitas, CA 95035-8800, (408) 894 1900, 1996.
[23] Wolfensberger, M. and Wright, D., “Synthesis of reflexive algorithms with intelligence for effective robot path planning in unknown environments.” Proceeding of the 8th International Conference on Mobile Robots, 1993, pp. 770-780.