Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

From toys to mobile home appliances, there has been a proliferation of simple robotic vehicles— and they all rely on some form of a processor. Some use 8-bit microcontrollers, while others use custom silicon or combinations of discrete components. With today’s technology, you can use a single off-theshelf semiconductor device to create a complete autonomous robotic vehicle (ARV) controller, regardless of vehicle size. This article will show how to build such a controller with an FPGA hosting a soft processor.

We’ll begin with a simple tracked ARV with an FPGA, a serial configuration device, two H-bridge motor drivers, an analog-to-digital converter (ADC), a three-axis accelerometer, a dc-dc power converter, expansion/sensor connectors, and miscellaneous support components.

Configured to be a complete system-on-a-chip (SoC), the FPGA is the key to the whole picture. Within the SoC construct is a 32-bit soft-core processor, RAM/ROM, two serial communication blocks, and two motor-control blocks. This SoC is implemented in the smallest Cyclone III FPGA, a 5000-logic element EP3C5 device that has enough room to add other functions as required (Fig. 1).

Most FPGAs, like the Cyclone III, are SRAM-based. Thus, they require a source of configuration data. Our example uses an Altera serial configuration device, which exposes some other possibilities that will be discussed later.

ARV ARCHITECTURAL FOUNDATION
The SoC’s central core is a 32-bit Nios II soft-core processor. It can be easily expanded or enhanced as required by the design function, owing to its FPGAbased implementation (Fig. 2).

Processor selection usually has many factors, such as the amount of processing required, memory needed/available, code space, routing space within the selected FPGA, and final system cost. Our initial project is based on the Nios II/e, which makes it possible to use the lowestdensity Cyclone III FPGA and a small package size.

Memory is crucial. In this type of embedded design, it can be used both internally and externally. The internal function allows for a smaller board footprint and reduced cost, though the choice of FPGA limits the amount of internal RAM/ROM. External memory can be virtually any density and datapath width.

For a robotic system, the developer will need to put some constraints on the overall design due to power availability. External memory is available in two major types, SRAM and DRAM, which come in myriad densities and package styles.

Four major factors will affect the selection: minimum density required versus availability; power constraints, as ARVs have a limited power availability; access and processor speed; and number of I/O pins available from the FPGA to interface with the memory and I/O. Other constraints include packaging, cost, and prebuilt interface IP for the FPGA.

The Cyclone III FPGA has a versatile I/O grouping capable of different voltage levels or multifunction interfaces (PCI, differential signaling). Available intellectual property (IP) includes a broad range of communications, memory, and legacy modules.

Processor code storage, normally a flash-memory device, depends completely on the functions of the ARV and if the designer is going to use a real-time operating system (RTOS). For small ARVs, utilizing the configuration device to store code eliminates the need for a storage component from the system and reduces the power requirement. The FPGA pins are dedicated in the Cyclone III—hence, no extra pins and possibly lower overall cost.

Two different flash interface styles are available for designers who can’t fit their code into the configuration device or aren’t comfortable with that scheme: serial and parallel. The density of the part, as well as board space, will drive the decision or direction taken. Density issues for both styles become a “wash” because they have similar densities.

The interface to the physical part is the clinching entity. (This analysis is based on a 16-bit datapath.) The parallel component could use approximately 44 I/O pins. The same density in the serial version will use roughly six I/O pins. (Serial flash is x8.) The FPGA interface to the component IP must accommodate conversion to a x16 format.

Pin count, which impacts physical component size, again plays a factor. If you’re using an OS, there has to be a driver for the available interface. Otherwise, you’ll wind up building your own.

MOTOR CONTROL
Motor drive and control are essential for the ARV’s motion and control. The simplest motor control contains a driver, which handles current loading, and a single I/O pin. The pin is basically turned on or off (go or stop), but this scheme leaves much to be desired when it comes to the ARV’s overall motion performance.

The next step up is to use a pulse-width modulator (PWM), easily implemented in an FPGA, to control speed. Speed control allows for slowing to a stop or accelerating to a fixed speed (like an automobile). In the case of ARVs that don’t have automobile-style steering or those with tracks, the method of turning is called “skid steering.”

Basically, the drive side that’s slowed or stopped is the direction of the turn. The amount of time stopped or slowed will determine the turn amount. The external drive can be a discrete-configured H-bridge (brushed motors) or a single chip with built-in FETs for the current control.

The example ARV contains two motor IP blocks that are configured for basic discrete H-bridge control. The PWM’s output is routed through one of two pins to the bridge. The direction of the motion determines the routed pin. The other pin is set to ground.

Drive safety is a valuable consideration. A simple method for ensuring safety is to monitor the amount of current that flows through the bridge at any given time. On discrete bridges, this can be accomplished by utilizing an ADC and a low ohmic precision resistor.

The interface from the FPGA to the ADC is based on pin-count needs and the ADC’s resolution. Serial peripheral interface (SPI) ADCs, which are becoming more prevalent, offer high data-transfer rates. The ARV in our example uses SPI ADCs.

The processor can, at set intervals of motion, pull the value in and compare it to a set fail parameter. Hopefully, the fail parameter is below the part’s release of the “magic smoke” that makes it function. Most single-chip solutions with integrated FETs have built-in thermal/current safeties that disable the inputs/outputs and set a flag or flags that the user should consider. The user should make these high priorities. Otherwise, the ARV motor controller may become damaged.

Ideally, each motor should also have a speed monitor. This allows the ARV to be moved set distances without intervention from a remote controller. The monitor can be a Hall-effect transducer or a photo-interrupter.

The IP is a simple counter whose clock input is from the transducer or photointerrupter. A second clocking source is used for sample size. This becomes a designer preference, but the bigger the counter, the more resources consumed.

A 500-ms sample will keep most designs in a 32-bit counter, which in this case matches the internal Nios-II data bus. The second source clock latches the counter data into read registers for the processor access and resets the counter to zero.

With a tracked ARV, the designer calculates that for every revolution of the drive sprocket, the track moves “x” inches, or in large equipment, feet. With this constant, the processor can calculate how far it moves forward or backward.

For example, constant “x” = 4inches/ Rev, Distance = x * # of revolutions, 40in = 4in/rev * 10revs. This is simplistic, but adequate for many applications. The speed counter can also inform the processor of slippage or a track jam, which is indicated by an increase in bridge current.

Continue on page 2

GUIDANCE SYSTEM
Guidance, which is a key element in virtually every system, is one of the more complex and physically large sections of an ARV. In very small ARVs or toys, guidance systems are usually a luxury due to space and cost constraints.

The introduction of microelectromechancial systems (MEMS) allowed for smaller units to have full guidance systems at a lighter weight, less power, and a lower cost. MEMS can be connected directly to the FPGA.

The two guidance items under consideration here are the accelerometer and the gyro. The accelerometer offers an analog or digital interface; one, two, or three axes; and different “g” ratings. As a result, a digital SPI accelerometer should be used to reduce the amount of components. This will also lower the chance of noise in the analog lines leading to the ADC. The xand y-axis are useful for determining tilt up/down or tilt left/right. The z-axis indicates the rate and direction the ARV is rotating.

Adding the gyro simplifies some work and also removes potential guesswork. The first gyro to add is the z-axis. This single axis is very handy in determining how long to slow or stop a track for turning. The gyro will indicate how many degrees it has been shifted from the initial reference point.

This information is invaluable if the ARV is to move from point A to point B, barring a straight line. Adding the x-axis and y-axis allows the processor to “paint” a mental picture of the actual position in reference to the earth’s surface. For those who want it all, some MEMS modules include threeaxis accelerometers and a three-axis gyro.

SENSORS AND COMMUNICATIONS
Sensors are the only way that robots can see the world. Most sensors used in the development of our ARVs are SPI/I2C or analog. We again need an ADC for the go-between on the analog sensor and the FPGA.

If you want to minimize I/O pins, I2C is useful because it requires only two I/O pins. Yet its maximum transfer rate is 3.4 MHz. SPI, on the other hand, needs a few more I/O pins—but it can transfer at up to 12.5 MHz.

Sensors are crucial to the front units, indicating “something in the way,” “edge of the world,” and “don’t hit my head.” These statements refer to objects in the path, a sudden loss of driving surface (like a large hole, edge of a staircase, or a cliff), and low-hanging objects the ARV can’t get under without damage.

Communications with the ARV always make things more interesting and add flexibility. Most wireless modules use a standard UART for processor communications. By creating a low-impact protocol, data can be passed between the operator and the ARV. This allows speed, direction, and even limits for the sensors to be updated. Research data can also be returned from sensor packages through the communications link.

ASSEMBLE COMPONENTS INTO A WORKABLE WHOLE
Now it’s time to put all of the sections together into one FPGA and a working system. The initial project contains a Nios II/e processor, 8 kbytes of internal RAM, two SPI bus modules, two motor modules with speed counters, two interrupt lines (for the accelerometer), and the ability to add other I/O and sensors. The project uses the smallest-density Cyclone III part available in the smallest quad flat pack (QFP) (Fig. 3).

The previous examples discuss simple ARVs, but the robotics real world isn’t as simplistic. Our current FPGA controls an eight-wheel-drive ARV that can utilize different “payload” function options. The unit uses four 32-bit Nios II processors, which handle the following overall functions:

Main processor: Final decision, overall path motion, real-world communications, and payload interface

Guidance processor: Continuous data gathering from the inertial measurement unit (accelerometers and gyro), GPS module, and filtering/navigation algorithms

Sensor processor: This device is constantly communicating with sensor arrays that watch the world around the ARV, as well as special sensors (i.e., methane monitor, oxygen monitor); it includes data sent back from the intelligent light detecting and ranging (lidar) units

Motor processor: This section controls the drive units (not limited to electric motors) and is used for hydraulic systems; in the electric system, it controls each motor’s RPM and monitors the motor’s current (again for current overload from a stalled motor); the hydraulic system is more simplistic in the control function of the valve (proportional actuation in both directions) and line pressure

Each processor has its own ROM area for boot/application code and scratch RAM for the main processor. A 1-kbyte mailbox system divided into four sections handles interprocessor communication. This allows the main processor to “leave messages or information” for the other processors or to retrieve needed data for decision-making.

With the mailbox comes a basic arbiter. Each processor will have to check with the arbiter prior to attempting to communicate with the mailbox RAM. Because this whole configuration is being constructed from the ground up, a very basic communications protocol needs to be instituted. The highest priority would be to ensure no one “hogs” the interconnection bus. That’s followed by the construct of the mailbox and the location of the values (Table 1).

CONVENTIONAL APPROACHES
The overall FPGA-based SoC lends a design edge to time-to-market, potential materials cost, and test/debugging time. Because this is a reconfigurable single-chip solution, multiple design paths can be taken simultaneously.

Also, schematic capture and PCB design can be in the process while the FPGA is being designed. Software for each processor can be flowcharted and even implemented while the other processes are in progress. Board- or system-level simulation can be accomplished with the FPGA, versus having to simulate a multiprocessor environment.

Functions can be simply incorporated into the FPGA, and then the design and any additional software are recompiled. In traditional approaches that rely on discrete microprocessors, additional functions that can’t be implemented with the individual processors force the board to be redesigned, and hence, a new one must be assembled. This is a loss of time and money, as well as potential market shares for the product arena.

Table 2 compares the costs and benefits of an SoC based on a Cyclone III FPGA and Nios II processors with a conventional approach based on four individual processors. (No specific conventional processor is listed. The overall prices are generic.) Functionality between the two approaches will be as close as possible, and PCB area is for only that section of the board.

In this example, we also follow the common practice of leaving 20% to 40% “headroom,” which is used for possible expansion. In the Cyclone III family, some of the physical packages allow for a larger part to be installed on the same PCB footprint. This produces even greater flexibility to gain more logic resources without changing the PCB.

As underscored by Table 2, the Alterabased implementation offers significant benefits in cost, design flexibility, and time-to-market. Opportunities to further refine each of the architectural components at a hardware level to achieve the optimum results for any given application make the FPGA-based SoC a compelling alternative for building robotic vehicles.