PERSONAL ROBOTICS
with a header and some neater wiring.
Since I will be using an identical
Mega32 board at both the console
side and the robot side, the connections and wiring will be identical.
■ PHOTO 3. EB500 connected
to a STK500 with a Mega32.
For this we will use the
ASCII characters:
EB500 OPERATION
Header: STX (hex 02)
Trailer: ETX (hex 03)
The EB500 has two basic modes
of operation: Command and Data. In
Command mode, the user can issue
various commands to cause certain
actions. In Data mode, the device acts
like a “cordless” RS-232 connection
and all input is passed through.
In Command mode, there are
several commands available, though I
will only be using a small subset of
these, namely “connect” and “get
address.” There are a number of other
interesting commands and capabilities, most notably the ability to have
encryption and trusted devices.
DATA TRANSMISSION
The whole point of the hand-held
console is to have the robot send its set
of variables to the console and then to
let the user change those parameters
and send them back to the robot. The
data being transmitted may consist of
some ASCII characters as part of the
protocol between the two devices, for
example, “respond,” “var,” “ready,” etc.
However, the data being transmitted
also consists of variables and the variables will contain non-ASCII data, such
as a binary 1 or a binary 2 etc., so special accommodations need to be made
for this type of non-ASCII data. We will
also have to delineate a message. That
is, we will need to build each message
into a packet, with a header and a
trailer; in this case, very simple ones.
To this end, we need a simple
packet protocol and a way to ensure
the transmission of binary data. It just
so happens that my robotics buddy,
Ken Tait, uses such a protocol and
with his permission, I am briefly going
to describe a version of it.
Regardless of what the contents of
the messages sent back and forth are,
we are going to wrap them in a header and trailer. This way, we will know
where the beginning of the message is
and where the end of the message is.
When a message comes
into either the bot or the
Console, the first thing we
will do is look for an STX character and
wait for an ETX character. Then we will
know the stuff in the middle is the message. However, as mentioned before,
we need to take into consideration
binary data. Why — you might ask —
since we encapsulate our message with
STX/ETX. Well, we have to consider
what would happen if part of the data
being transmitted is a binary 2 or a
binary 3, since these could be mistaken
for either an STX or an ETX.
To solve this problem, we will
incorporate into our packet construction a search for any of these characters in the data of the message. If we
find one, we will insert a character
before it marking its position and then
follow it with the actual character. For
this mark character, we will use:
et and the message, the next SOH
tells us that the following character
could be an SOH, STX, or ETX, and
should be treated literally. When we
find an SOH, we throw it away and
take the next character as-is. Finally,
moving through the rest of the data
we find the ETX that is not preceded
by an SOH and we then know that is
the end of the message and packet.
So, if we use this simple technique to construct and deconstruct
the packets, we can be assured of
sending both ASCII and binary data
back and forth. Note also, there is no
attempt at error detection or correction and it is assumed that all data will
be received accurately, which I think is
fine for this level of robotics.
Mark: SOH (hex 01)
PROTOCOL
As an illustration, let’s say we have
a message of two bytes each containing the following:
Byte 1:
Byte 2:
hex 03
hex 41
Following the rules above, we
would then construct a packet as
follows, using a ‘|’ to separate each
byte for clarity:
Packetizing and sending data
back and forth is not quite enough.
We now need to develop a
simple protocol we can layer on top of
it and use to identify requests and
responses, as well as a ‘standard’
method for packing the information.
As an example, these are some of the
commands we will need to pass the
variables back and forth:
STX|SOH|0x03|0x41|ETX
• respond — Sent by the console to
the bot when the console first
powers up and after the EB500s
become connected.
As you can see, our packet grew
from a length of two to a length of
five, but we are able to determine the
beginning and the end, as well as not
confuse any binary data with the STX,
ETX, or the SOH since this is also a
reserved character.
When we deconstruct this packet,
we essentially reverse the process. The
STX tells us this is the start of the pack-
• ready — Sent by the bot to the
console to acknowledge it is ready
and running. This is in response to
receipt of “respond.” May be sent
by the console to the bot to
acknowledge it is ready and running.
• send — Sent by the console to the
bot once communication has been
April 2007 13
