3. Hardware Control SystemHexotica - The Design and Implementation of a Small Walking Robot
The task of the hardware control system is to act as the interface between the software that determines target leg positions and the motors that drive the legs into position. The hardware control system must be modular, flexible in configuration, and able to be controlled by a wide variety of microprocessors. This criterion ensures that the system can be easily added to or modified. Due to the complexity of the control problem, the hardware control system must also support multiple processors, and provide an interface between them through which they can communicate.
The idea of "modularity" in a design is very popular with roboticists. Many robot designs are described as being inherently modular, when in fact all that is meant by "modular" is that components of the robot are developed separately and can then be plugged into the robot, or removed for repair / redesign. This is not true modularity. An example of a modular hardware system is a desktop PC and its expansion slots. A standard interface is used (PCI, ISA, EISA for example), but this interface does not limit what type of ability the cards that are inserted into the slots will have. You can insert anything from a sound card to a modem to a data acquisition card. These cards simply have to have the ability to communicate with the controller (the computer’s processor, such as a Pentium chip), but their specific function is virtually unlimited.
This type of modularity is used in the hardware control system. The system consists of control modules and expansion modules. Each module is completely interchangeable, and can be removed or added to the system without affecting other modules in the system. Individual hardware devices are developed with a common interface to the system bus. By following this design method, hardware development done on one project is easily re-used in future designs, minimizing development time. Multiple processors can work together and communicate with one another via a high-speed serial network. This section discusses the design of this system in detail.
First, the interface design is discussed. This interface is used to communicate between expansion boards and controller modules. Next, Z-World Engineering’s SmartCore an embedded microcontroller is discussed. This embedded microcontroller acts as a "controller module", and thus must communicate through the interface.
A successful implementation of the system will have the following characteristics:
- Must be modular in design. Modular design means designing components individually, but with a common, robust hardware interface that is capable of communicating with a wide variety of components.
- The hardware interface must be device independent. The same hardware should be accessible by data acquisition cards, embedded controllers such as Motorola’s 68HC11 microprocessor, or newer technologies like C-programmable embedded controllers. The choice in interface design must be based on this requirement.
- Must be scaleable; new modules for the architecture will need to be designed as new technologies are integrated with the robot. The design must be able to accept new modules without affecting the operation of other modules already designed. The size and capabilities of the system must be flexible and expandable.
- EMI (electromagnetic interference) reduction should be part of the design. Because the system will have a flexible final configuration, noise that is acceptable in one module may interfere with another. For that reason, all modules must be designed with noise reduction as an integral consideration.
- Must be fast enough to accomplish typical timing requirements for robotic control
- Should be simple to implement, robust, and flexible
The basic control architecture is shown in Figure 8. It consists of a single controller with multiple expansion cards. A control segment consists of a single controller and all the devices that the controller commands. Figure 8 is an example of a single control segment. In the walking robot project, the SmartCore controller board consists of a 40 pin connector for the actual SmartCore to plug into, a 40-pin connector for the ribbon cable that connects the controller to the motor interface boards, and serial networking hardware. There are only two expansion boards; two motor controller boards for a single leg pair. The sensor array is shown as an example of how additional hardware can be added.
Figure 8 - basic controller architecture
Figure 9 shows a more complex architecture, with multiple control nodes. This architecture is required for cases in which a single controller does not have the bandwidth to satisfy the processing requirements for the entire system. This is the case for the walking robot problem. The kinematic equations and control algorithms for all six legs cannot be implemented on a single controller; it simply doesn’t have the computing capacity.
The multiple control node architecture is characterized by a low bandwidth communication channel between controllers that are each responsible for a high-bandwidth control segment. The individual controllers are considered slave devices. There is a single master responsible for parsing high-level data to and from the individual control nodes. The communication channel between nodes is allowed to be low-bandwidth because the control nodes pass only brief instructions; all low-level functions are handled locally by the individual processors.
A typical node to node communication in the robot might consist of the master sending a slave a high-level command, such as "move foot on leg 1 to position X-Y-Z". The slave control node takes care of specifically how this is achieved, while the master processor is free to do other tasks. When the slave finishes the task, another high-level response is sent back to the master, indicating the foot position has been reached (or an appropriate error message if the objective was not achieved).
Figure 9 - multi-node architecture
The low-bandwidth channel consists of a high-speed TIA/EIA-485 serial network (formerly known as RS-485). Transmission speeds depend on the processor used. With the SmartCore Z2-D that runs at 18 MHz, the top transmission speed is 115,200 baud. The high bandwidth channels consist of the parallel interface described in section 3.4 - Parallel Interface Design. Some design issues related to serial / parallel buses are discussed below.
3.3.1 Serial Interface Design Considerations
Serial hardware interfaces communicate by means of a high-speed serial bus. The serial bus usually consists of two or three physical wires. The main benefit of this hardware interface is the significant reduction in wiring requirements. By reducing the number of communication lines to three, the build cycle is reduced substantially, board wiring density is reduced (an important consideration in PCB layout), and the number of points of failure is reduced. There are a large number of serial devices available, and they are increasingly becoming a standard in hardware development.
There are, however, several disadvantages associated with a serial interface. There are several serial communication protocols in competition in the hardware interface market, and they are not compatible with one another. Choosing a particular type of device means limiting your hardware design to devices that use this particular protocol. This includes the microprocessor. The serial interfaces available on microprocessors vary greatly, and do not always include the necessary protocols. Also, because data is transmitted serially, the time to transmit an 8-bit word is significantly longer than a parallel bus transmission. This transmission time is increased if the communication protocol incorporates error correction. Finally, the processor overhead per read/write cycle is greater for serial transmission than parallel buses, due to the serial nature and error correction of the data transmission.
For these reasons, serial interfaces are appropriate for sending high-level commands with relatively low volume traffic. High level commands contain less information than low-level hardware control commands, and are well suited to the reduced bandwidth of serial transmission channels.
3.3.2 Parallel Interface Design Considerations
The parallel interface uses an address bus to specify the device being accessed, and a data bus to send and receive information. Because it is parallel, the number of wires depends on the size of the data bus, but can generally be assumed to be at least 8. This represents a significant increase in wiring requirements over the serial bus. However, the parallel bus architecture is an extremely mature design, and is a standard for virtually all microprocessors. The processor overhead per read/write cycle is at a minimum, and the data transmission rates are significantly faster than a serial bus. Primarily due to the standard that a parallel bus interface represents, it was chosen for the hardware interface in this project. All of the expansion boards use a parallel bus interface for communicating with the controller cards.
Since the system is intended to be portable and self-contained, microcontrollers are used as the basis of the control system. A huge variety of microcontrollers are available in an extremely competitive market. The interface that the system uses is common to most microcontroller / microprocessor families. The interface and pin-outs are shown in Figure 10.
The address lines are uni-directional signal lines from the controller module to the expansion boards. They select both the board and the specific device on the board that is to have control of the data bus. There are a total of 6 bits for the address bus. This allows the controller to address 26 = 64 individual 8-bit addresses. The 3 least significant bits are used to select a particular device on an expansion board, and the 3 most significant bits are used to select 1 of 8 board ID’s. The bus is TTL compatible.
The data bus is an 8-bit bi-directional path for information flow. Due to the fact that it is bi-directional, the controller types are limited to those with a bi-directional port. The port must be able to change its status from input to output dynamically as a program is executing. The data bus transmits information either from the controller to devices on an expansion board, or from a register on an expansion board to the controller. The bus is TTL compatible.
Figure 10 - parallel interface
3.4.3 Chip Select Lines (/CS1-/CS6)
There are 6 optional chip select lines, for use with controllers that require the use of chip selects. This includes the Z-World Engineering line of C-programmable microcontrollers. The chip selects are implemented because the microprocessor core of these microcontrollers uses the same data bus for both internal and external data transmission. In order to mask internal operations from external data access, the chip select lines are used.
For controllers that do not use chip selects, the designer has two options. Individual boards can be configured not to use a chip select line, or an additional port from the controller can be used to emulate the chip select lines. To make things simpler, chip select lines can even be ignored altogether. In most cases, if a chip select line is not required, the best choice is to avoid emulating them as this will likely require additional clock cycles to process data.
+5V signal for all the components connected to systems ground. Power can either be routed directly through the bus, or through an external connector. There are multiple connections on the 40-pin header for all power and ground signals due to the increased current requirements.
The common ground signal for the majority of the discrete components used in the system. This includes the various logic IC’s, gates, and buffers that form an expansion card. No high-current devices are connected to systems ground, or devices responsible for analog data acquisition.
+12V signal for all the high-current components connected to actuator ground. In general, the +12V signal is not a standard. The specific voltage used depends on the type of system being used. For example, a stepper motor driver expansion board would require a higher voltage power supply.
3.4.7 Actuator Ground (12V_GND)
The ground signal for high-current drivers. The actuator ground signal and the data acquisition ground signal must be joined at the power supply source. They are isolated up to that point so that changes in current from high-current actuators do not result in a voltage drop that may affect data acquisition readings. Generally, digital components are connected to systems ground, while relays, motors, and other high-current devices are connected to actuator ground.
3.5 The SmartCore Microcontroller
The controller chosen for this project is called the SmartCore (shown in Figure 11), and is manufactured and sold by Z-World Engineering. The SmartCore is based on the Zilog Z180 family of microprocessors. The Z-World controller was chosen because of its low cost, immediate availability, and easy upgrade path. The development system includes Dynamic-C, Z-World’s integrated development environment. The Dynamic-C development environment allows code writing in near ANSI-C, as well as in-line assembly code for time critical routines. It also supports real-time interrupts and multi-tasking programming. It runs under Microsoft Windows 3.1, Windows NT, or Windows 95.
Figure 11 - The SmartCore microcontroller board (photo courtesy of Z-World Engineering)
Development is done on an off-board PC. When the program is ready to be run, it is downloaded to the SmartCore via the PC’s serial cable through a serial interface board. The program executes directly from the SmartCore’s onboard RAM, independent of the development PC. When the program is complete, the serial link is removed, and the controller can continue to execute the stored program. The flash RAM version of the SmartCore was purchased. Flash RAM is non-volatile, so even if power to the system is removed the program will remain in memory (for more information related specifically to programming and using the SmartCore, refer to [14] ).
In order to communicate with the rest of the robot, the SmartCore uses an 8-bit data bus and a 6-bit address line connected to the system interface (described in section 3.4 Parallel Interface Design). The method by which this is done is described here.
The data and address lines can be accessed from a 40-pin header on the evaluation board. The pin designation is described in Figure 12. The data and address lines are then connected to the other modules of the robot via a ribbon cable connector. The lines labeled D0-D7 are the data lines, while the lines labeled A0-A5 are the address lines.
Figure 12 - 40 Pin SmartCore Interface (courtesy of Z-World Engineering)
Because there are six bits available on the address line, there are a total of 26=64 addressable devices. They are selected by putting a particular binary word on the address bus. For example, by putting the 6-bit binary word 001101 on the address bus, device number 13 is addressed. The word 111111 corresponds with device number 63, and the word 000000 corresponds with device number 0. Thus, there are 64 available addresses within a 6-bit word. Each of these addresses corresponds to a specific 8-bit device on an expansion board. These hardware devices are either output or input devices; i.e. the software must either give them an 8-bit value to accept, or read an 8-bit value from them. Input devices place an 8-bit word on the data bus when they are selected on the address bus. Output devices accept whatever 8-bit word is currently on the data bus when they are selected on the address bus. Any time a device is not selected by the address bus, it is expected to remain "logically invisible" to the data bus.
The 8-bit input and output devices that communicate on the data bus are generally of two different types. If it is an input device, it is typically a tri-state buffer. If it is an output device, it is generally an 8-bit latch. A tri-state buffer accepts inputs from devices such as sensors, switches, or data registers, and then places this data on the data bus when selected by the address bus. When it is not selected, a tri-state buffer goes into a high-impedance state, which makes it logically invisible to the data bus. This prevents device contention on the data bus. Device contention occurs when more than one device tries to put information on the data bus at the same time, and typically results in hardware failures or unpredictable hardware behaviour.
3.5.1 A Note on Chip Select Lines
The chip select lines are used to enable reading and writing to and from the hardware. The chip select lines are normally left high. Whenever the hardware is accessed, one of the chip select lines goes to a low logic level for the duration of the access period. On the embedded controller, /CS1-/CS6 can be enabled for a total of six chip select lines. Using these lines, 6 groups of 64 addresses can be accessed for a total of 384 addresses with single-level addressing. In order to access devices, you must specify which device you want to access by addressing it.
For more detailed information pertaining to the operation of the SmartCore, please refer to the appropriate resource in the bibliography.
3.6 High Speed Serial Network Hardware
A high-speed serial network is used to allow different processors to communicate with one another. A serial interface has fewer points of failure than a parallel interface, but is much slower since it has to transmit a single bit of data at a time. However, since the network would only be passing high-level commands, it was decided that the throughput would be sufficient. Serial networks are also a very common way to network resources in industrial applications. The type of network implemented is very common in industrial control applications, and has proven its effectiveness over the years.
The protocol used is the TIA/EIA-485 protocol, formerly known as RS-485. The protocol is referred to as a differential bus [1] [9] which means the logic level on the transmission line is determined by the voltage difference between the conductors. This is different from non-differential protocols such as the more common RS-232 [1] which measures logic levels with respect to a ground voltage. The benefit of the differential protocol is that it can operate in extremely noisy environments and over long transmission distances.
The TIA/EIA-485 [9] protocol allows multiple drivers in operation. This makes multi-point (party line) configurations possible. This is important if multiple processors are to pass information back and forth.
Standard TIA/EIA-485 transceiver chips are widely available. They operate from a single 5V supply, and generally use charge pumps to increase the bus common mode range to -7V to +12V. The wide common mode range gives the TIA/EIA-485 standard the ability to operate over a very long cable (up to 4000 feet) without noise interference seriously degrading the signal.
Figure 13 - Typical EIA-485 multidrop application (picture courtesy of National Semiconductor)
One of the suitable transceivers for translating TTL logic level signals to TIA/EIA-485 from a single 5V supply is the DS485 by National Semiconductor, which is pin compatible with the LTC485, MAX485, DS75176, DS3695 devices. The transceiver has enable lines for the driver and receiver stage (see Figure 14).
Figure 14 – DS485 TIA/EIA-485 transceiver (picture courtesy of National Semiconductor)
For multi-driver networks, the driver enable line will have to be switched on when the controller module is talking, and switched back off when listening. Otherwise, multiple drivers on the network will be attempting to drive the logic level on the bus at the same time, which will result in an undeterminable logic level. A protocol to prevent bus contention must be used. The Dynamic-C software libraries include an Opto-22 library for performing master-slave networking, with built-in bus contention prevention.
There are two functions in the library used for switching the driver enable line on and off. It is not documented in the SmartCore function library, so it is mentioned here. The two functions are called on_485() and off_485() (discussed in section 7.2.6 - MSG.LIB). These functions were modified to switch /CS1 on and off before and after sending network data. /CS1 is attached directly from the SmartCore Interface to the driver enable line (see Figure 57 - SmartCore interface board schematic in Appendix C - Schematics).
The successful design of a legged robot depends to a large extent on the leg design chosen. Since all aspects of walking are ultimately governed by the physical limitations of the leg, it is important to select a leg that will allow for a maximum range of motion and that will not impose unnecessary constraints on the walking gait chosen. The first stage of the leg design process therefore consists of a search for an optimal leg design.
copyright information
Back to home
page. Last updated: April 20th,
1997
