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.
Reprints
