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
Reprints
