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