Our resident expert on all things
robotic is merely an email away.
roboto@servomagazine.com
Tap into the sum of allhumanknowledge and get your questions answered here!
From software algorithms to material selection, Mr. Roboto strives to meet you
where you are — and what more would you expect from a complex service droid?
by
Dennis Clark
This month, I was asked a seemingly simple
question that dovetailed very nicely into a project I’ve
been contemplating for a while. As usual, when such
things happen to me the project balloons out of control
and a major project ensues. That is what happened this
month. What started out simple turned into a monster
with lots of twists and turns and a last minute subtle bug
that turned out to be obvious once I looked carefully at it.
I’ll attempt to work through the entire process here so
that you can avoid the same pitfall!
Q. I want to put a bunch of sonar boards on my
robot so that I can experiment with area mapping.
The problem is that I don’t want to have my
“brain” do all the work of running them. Is there a way to
network my sonar units with sub-processors so that my
main brain can communicate with it to get my readings?
— Sean
A. Of course! It just so happens that I’ve been working
on an outdoors robot that I want to put a bunch of
sonar units on. On top of that, I’ve wanted to create
a network protocol for sensors on my robot that is simple,
fast, and easy to implement no matter what microcontroller
I use. In this article I’ll try to give some insight into my
design process and some of the problems that I ran across
and solved to get to a solution.
THE PROBLEM: How to network
a bunch of sensors easily?
Since I want my network to be cheap and easy to
implement, this means it will need to be serial in nature
to minimize the number of I/O lines needed.
We’ll leave out the networks that require extra
hardware and more powerful microcontrollers like CAN and
Ethernet. I want to create a network that I can implement
by bit-banging I/O lines on any device so I can use cheap,
low pin count micros.
The first hardware transport layer that comes to mind is
asynchronous serial, also known as RS-232. This is certainly
simple to bit-bang, however, because it is asynchronous
(has no system clock) the timing needs to be precise or
other receivers won’t be able to decode it properly. This will
limit the data rate to something slow enough that a little
slop in the timing will still work correctly, but I don’t think
this is what I want. If I’m going to have lots of sensors, I
want to get some speed from the bus.
Synchronous serial will have a clock line and one or
two data lines. We can make the data line bi-directional so
we only need to run two I/O lines to every device. Because
this bus is synchronous, the clock can be any speed and the
speed can drift a little. Synchronous serial buses typically
operate on rising and falling edges of a clock, not the
frequency of the clock. A rising edge is the point where a
digital signal changes from a logic low 0 to a logic high 1
and vice-versa. This will be ideal for our simple network.
There are two commonly used synchronous serial buses
that microcontrollers like: SPI (Serial Peripheral Interface)
and I2C (Inter-IC). I2C is a fairly complex bus architecture
that allows for multiple masters (a master controls the flow
of data on the bus), addressing of individual nodes, bus
arbitration, and priority addressing. It only needs two I/O
lines: a clock and a bi-directional data line. Messages on
the I2C bus are half-duplex which means transmitting and
receiving don’t occur at the same time. This is a pretty
complex standard, so I’m not sure I want to deal with all
of the packet overhead that is needed.
The SPI bus is master/slave which means that the bus
has only one master controller and the rest only respond
when they are talked to. There is no packet formatting; it
just clocks data back and forth. This bus is full-duplex which
means you can receive data at the same time you send it.
The SPI interface, on the other hand, uses four I/O lines: a
clock, a data out, a data in, and a select line. Four I/O lines
are needed for SPI and one of them is a chip select, which
means that I’d need an additional I/O line for each device
on the bus. That isn’t what I want either.
SERVO 06.2009
13
