当Jeff不能为iRobot公司的Create机器人添加蓝牙适配器模块时（因为它使用了相同的运载站连接器做为命令模块），他做了任何优秀设计者应该做的：他建立了属于他自己的模块。在本月的刊物中，他阐述了如何使用一个带有双串行接口的微控制器替换命令模块。
Application Development
When Jeff couldn’t add a Bluetooth adapter module to iRobot’s
Create (because it used the same cargo bay connector as the Command
Module), he did what any good designer would do: he built his own.
This month, he explains how to replace the Command Module with a
two-serial-port microcontroller.
Last month, I introduced you to iRobot ’s Create robotic platform,
which is based on the successful series of cleaning robots. I
discussed the Create ’s complement of sensors and how they can be
accessed using the Open Interface (OI) with the Command Module (CM)
accessory. The CM contains an Atmel microcontroller that you can
program in C or C++ using your PC. The resultant code is downloaded
onto the CM with a USB interface. I demonstrated how you can use
Atmel ’s AVR Studio to write your application in assembly language.
Yup, some of us still like to get our hands deep into the bits and
bytes. I also examined how the USB tether used in downloading could
provide real-time debugging feedback. Obviously,you can ’t have a
robot running around the floor with a long tether. Another
accessory for the Create is the Bluetooth Adapter Module (BAM). The
BAM gives you a wireless link to your PC. The only catch here is
that it uses the same cargo bay connector that the CM requires.
This means you must choose between either wireless communication or
an on-board programmable microcontroller.Something ’s wrong with
this picture.
This month, I will discuss how to replace the CM with a Microchip
Technology PIC microcontroller that has two full serial ports so
the BAM can be used along with the PIC. But first, I want to
explain why I took this approach. If you remove the CM ’s plastic
top, you will find an Atmel ATmega168 microcontroller. This flash
memory microcontroller has a UART that ’s used for two functions:
sending OI commands to and receiving data from the Create through
the cargo bay connector and programming the microcontroller through
a USB port. The paths to and from the UART are multiplexed
externally and controlled by the microcontroller. I looked for a
way to cleanly interrupt the data to the serial-to-USB chip (FT232)
so I could replace the USB port with an alternative cargo bay
connector (onto which the BAM could be connected). However, this
could not be accomplished without wrecking the CM. I decided to
prototype the idea. But when I started thinking about how I might
use this, I realized that at some point my application would surely
exceed the flash memory available, no matter the size.
At that point, I sat down and thought about the features that
interested me most. I came up with three items: limitless computing
power, expandability,and wireless connectivity. It looked like even
with successful surgery, I would accomplish only the wireless
feature I was looking for by using the CM. My ideal design would
not depend on the CM for program storage and execution, but merely
use the CM as a way to expand the capabilities of the Create (i.e.,
providing additional sensor capability via SPI, I
2C, or other interfaces—something the Create’s analog and digital
I/O was not capable of). In reality, I needed two UARTs. With the
BAM on one port and the Create on the other port, the
microcontroller could pass OI commands from one UART to the other.
Additional commands (OI extensions) could be created for any sensor
handled by the microcontroller.The microcontroller would play
traffic cop and choose to keep an OIE command, but pass through all
original OI commands.
BIG PICTUREI assumed my future application would require a lot of computing
power, not to mention a potentially large database. Therefore, I
would write and execute it on a PC. The BAM wireless interface
feeds the Create platform with commands and receives sensor data.
Although the Create is autonomous, it does not have to carry around
its brain. I can write and run an application from my recliner
outfitted with the appropriate beverage.
The Create has a built-in application for finding its charging dock
and replenishing its power pack, so it should never be found dead
somewhere. The application can monitor battery capacity and send
the Create home, when necessary.
Because I was redefining the CM, there was no particular reason to
stay with the ATmega168. Not that there is anything wrong with it
if you want to stick with an Atmel part. I chose a Microchip
Technology dsPIC30F4012, a part that I hadn’t used before. It
operates on 5 V, comes in a DIP-40 package, has two hardware UARTs,
and executes at close to 30 MIPs.
dsPICWhile the flash memory microcontroller has an internal 7.37-MHz RC
oscillator that has been trimmed to 2%, I added an external crystal
to give spot-on data rate generation. The (4×/8×/16×) PLL can give
the source frequency a real boost, putting it far above the speeds
that I’ve become used to. Refer to Figure 1 to see how the dual
UARTs are used. All communication signals are TTL-level
(uninverted). Between the microcontroller, the Create, and the BAM,
no RS-232 level shifting is necessary. I added connections for the
ICD2 emulator so execution can be easily debugged. Although it has
not been implemented, both SPI and I2C interfaces have been
included for whatever sensors I might add (i.e., compass and
ultrasonic ranger).
Figure 1—This circuit serves two purposes. One, it passes commands from the
Bluetooth Adapter Module (BAM) to the Create by filtering all
communications through a Microchip Technology dsPIC30F4011. Two, it
provides a framework for adding external sensors, such as a compass
or ultrasonic ranger, to the system and accessing them with Open
Interface Extension (OIE) commands.
The SPI and I
2C interfaces share some of the same signals with the in-circuit
programmer (ICP), so I implemented some buffering that should
enable these to coexist. The SPI and I2C clocks have separate
enables so the bus can be reconfigured and appropriately enabled,
when necessary. The ICP needs control to program the part. One
aspect of programming is the ability to reroute some signals to and
from alternate pins. I chose to use alternate pins for the
in-circuit debugger (ICD). By using alternate pins for debugging,
the I
2C and SPI lines
are free to operate normally.
The microcontroller ’s basic function is two-fold: to handle the
serial traffic between the BAM (UART2)and the Create (UART1) and to
interface with any sensors added to the system. The microcontroller
(I call it Me) and each UART (Create and BAM) will have two ring
buffers associated with them —one for TX and one for RX —for a
total of six.Both of the UART ’s RX buffers are automatically
filled by RX interrupt routines when data is received. Anything
placed in either UART ’s TX buffer is automatically transmitted by
TX interrupt routines.
Any data coming from the Create (in the UART1RX buffer), as well as
any data coming from the microcontroller (in the MeRX buffer), must
be melded together into the BAM (the UART2TX buffer). Most OI data
does not have any kind of wrapper;therefore, I had to interleave
data from the microcontroller into a response from the Create.
To keep the Create ’s data packets as a single entity, I needed to
know how many bytes to expect. For most commands, this is a fixed
number of data bytes. When a command byte comes from BAM, its value
is used as an offset into a look-up table. Each potential command
(128 – 255) has two entries: the number of data bytes that follow
the command and the number of data bytes returned in response to
the command. The microcontroller uses the second entry
ResponseLength to keep data from the Create in one piece (or
packet). Figure 2 depicts how the upstream responses flow.
Figure 2—The PassDataUP flowchart shows how responses from the Create and Me
(dsP) are sent to the BAM TX buffer without being intermingled.
The first table entry DataLength helps the microcontroller know how
many data bytes to expect after a command. This keeps the
communication in-sync and unmingled. There are, however, a few
commands that can have a variable number of data bytes following
the command. These exceptions are treated a bit differently. When
an exception is encountered, the DataLength (from the table)
indicates where a length byte can be found—usually, it’s the next
byte following a command. When the byte is transferred, it is also
reloaded into DataLength. Thus, DataLength is corrected on the fly,
enabling the correct number of data bytes to be transferred. Figure
3 shows the flow of the downstream command and data.
Figure 3—The PassDataDown flowchart shows how a command and any associated
data is routed either to the Create—if it’s an OI command—or to Me
(dsP)—if it’s an OIE command.
Extended OI commands can be developed, which when received from the
BAM, will be redirected to the microcontroller where the
appropriate function will be executed to control or gather new
sensor data and reply, if necessary. While no commands have been
written at this point, the OI leaves plenty of room, as it uses
only command bytes 128 to 158.
BAMElement Direct manufactures a number of accessories for iRobot
products, including the Roomba and the Create. That’s right. If you
own a Roomba sweeper, you can take control of its internal
microcontroller and experiment a bit with some of Element Direct’s
offerings (
www.elementdirect.com). The BAM gives the Create a roaming radius of up to 100 m, which
is plenty for most buildings. Element Direct also offers a
Bluetooth dongle, the other end of a Bluetooth connection. I
already have a few of these hanging around. I can use a USB
Bluetooth dongle on a PC or laptop. Any application that has access
to a serial port can take advantage of this connection.
Using the RealTerm terminal emulator, I connected to the BAM and
sent and received OI commands. Although I couldn’t request and
analyze commands and responses fast enough, I used RealTerm to
check the connection and test its range. For application
programming, I used one of my favorite programs, Liberty BASIC.
This let me program in BASIC and enabled me to get off to a running
start.
Photo 1—I built the Create Commander circuit to the same dimensions as the
CM. It fits on the cargo bay connector and provides I/O expansion
and Bluetooth wireless connectivity.
The BAM was used as a serial link. Photo 1 shows my prototyped
circuit plugged onto the Create’s cargo bay connector with BAM
going along for the ride. Like all Bluetooth devices, it first must
be linked to the host before it can be used. To do this, make sure
it’s powered and allow the host to search for (discover) Bluetooth
devices. Next, select BAM, which will have the name Element Serial.
Pair the devices using passcode 0000. When you refresh its
services, you should see a Serial Port Profile (SPP). Check this
service to enable it. (Don’t forget to make note of the COMport#.
You need to use the port number to communicate with the Bluetooth
wireless link from the application program in Liberty Basic.) When
I plug the Bluetooth dongle in one of the two USB ports located on
the front of my desktop PC, the service is available at COM21 on
one USB port and COM23 on the other. This is a far cry from the
COM1-4 that we all used years ago with just hardware serial ports!
LB APPBefore getting into any application, there are a few routines that
will aid in simplifying any future code. All of the Create’s
constants are defined so the description names can be used instead
of trying to remember values, such as right bumper sensor
(BumpRight)=bit1 or the radius value to drive straight
(RadStraight)=32768. I’ve been refining a COM select routine for
some time now. This routine attempts to open each COM port (from
COM1 to COMmax) and look for a comm error. Ports with errors are
flagged as unavailable. Then a pop-up window displays all of the
COM ports as radio buttons with the COM ports flagged as
unavailable disabled. You can choose any of the enabled ports.
(This is where you must select the service port that you made note
of earlier.) Assuming that you’ve chosen the proper port, you now
have a wireless connection between this application and the BAM,
the PIC interface, and the Create.
To support the present OI commands, there are four routines that
will be used in all applications: writing to the serial COM port,
reading from the serial COM port, interpreting each command, and
interpreting each response. The simplest OI command is a
single-byte command like CmdStart. To send OI CmdStart using LB do
a ‘gosub [CmdStart]’. This routine simply sets d = 128 and does a
‘gosub [WriteData]’ and then returns. It has no response.
A more complicated command like CmdDrive must not only send the
command byte (d = 137), but also 16-bit velocity and 16-bit radius
values (as byte values with the MSB first). Not only does the
velocity value need to be broken down into two high- and low-byte
components, but it is a signed value that uses direction to
determine whether the value should be positive (forward) or
negative (backward). The radius value is also a signed value. In
this case, the 16-bit values are predefined as RadCW, RadCCW, and
RadStraight. It has no response.
At some point, we need feedback to determine when to stop, either
because we’ve driven far enough, bumped into something, or are
about to topple down the stairs. CmdSensors would be appropriate.
This command requires one additional byte beyond the command byte
(d = 142). We need to ask for a sensor response using a Packet ID.
The sensor Distance (PacketID = 19) would appropriately respond
with a 16-bit signed number indicating the distance traveled
(forward or backward) since the last request. You will need to keep
a running tally of the total distance traveled to determine if it’s
time to stop or not. If you remember from last month, the sensor
command is also capable of returning the status of groups of
sensors. Packet IDs 0–6 return the status of multiple sensors.
Every sensor will return at least 1 byte, with some sensors
returning 2 bytes, as in the aforementioned distance sensor.
Responses are handled by the command routine that makes the
request. Any routine that expects a response does a gosub
[GetPacket] to handle single- and multiple-byte responses. The
[GetPacket] routine routes Packet IDs of 7–42 to the appropriate
[SaveSensorData] routines that capture the response data using
gosub [ReadData] and then saves it into the local variable, which
the application will use. With Packet IDs of 0–6, the [GetPacket]
routine uses for-next loops to capture the response data from
multiple sensors in the proper order.
APP WITHIN THE APPAlthough all of these routines are certainly part of the
application as a whole, the real app is in having the Create follow
some commands. My future application’s task will be to go exploring
and try to map what it thinks is out there. This sounds easy
enough, but remember that right now all we have is the ability to
bump an object (and respond) and to dead-reckon position (where the
error between your position and where you think you are grows
larger the farther you move). If you have experience in mapping or
terrain learning, I would like to hear from you.
I went for something simple. I backed the robot out of its charging
base a short distance, turned it around, and started exploring with
the cover demo. While the Create explored, I continually monitored
the battery and prepared to change to the cover and dock demo, if
the battery’s charge fell to 50%, so it would return it to the
charging base.
Listing 1 is the mini app (within the application) to command this
behavior. Up to this point, I haven’t mentioned a couple of the
routines in Listing 1. The [Move] and [Turn] routines are where the
robot’s intelligence begins to take shape. These are variations
using the CmdDrive command. Notice the setup prior to these
commands: Distance (for move) and Angle (for turn). These provide
limits to the movement. CmdDrive can actually do both at the same
time (i.e., it can combine forward or backward movement while
turning at some radius). To simplify dead-reckoning calculations,
turns will be made in two steps, rotating in place and moving in a
straight line. These routines do more than just determine when the
robot has reached its destination. They also check sensors for
additional (and potentially dangerous) input. These can include
bumper contact, cliff sensors, excessive wheel currents, button
pushes, battery status, and digital/analog inputs. Each sensor
input might have a routine associated with it that would be
executed, if necessary. For instance, if there is contact with the
bumper, you should provide a routine to back away from the
collision and try a different route.
VIRTUAL DASHBOARDDebugging feedback was one of the topics covered in the first part
of this series. With the wireless link and control coming from the
Liberty BASIC application running on the PC, the issue of tethering
and access to the Create’s sensor data is no longer an issue. The
BAM eliminates the need for a tether, and because all variables are
local, it is easy to display anything.
Photo 2—This is the dashboard. It is a real-time display of many sensor
values.
Photo 2 shows the dashboard I used with this application. I added
some computed items that show the Create’s dead-reckoning X-Y
position in relation to the charging base. This provides an
indication of dead reckoning, and you get to see how it relates to
the Create’s actual position over time. The Power items monitor
power consumption. The Sensors checkboxes show when a sensor
changes states. For debugging purposes, I use a separate debugging
window in which I can print the receipt of sensor data as received.
This window can also hold any computational information that would
help with the application program’s debugging process. Liberty
BASIC has its own debugging resource, which is a useful feature.
RDSMicrosoft Robotics Developer Studio (RDS) 2008 is a Windows-based
environment for hobbyists, academics, and commercial developers for
creating robotics applications with a variety of hardware
platforms. It includes a lightweight, RESTstyle, service-oriented
runtime. In addition, it has a set of visual authoring and
simulation tools, as well as tutorials and sample code, to help you
get started. I mention this because the Create is one of the
presently supported robotic platforms.
The idea behind RDS is to enable developers and manufacturers to
come together. Your robot can use any manufacturer’s device. With
RDS, you can model and simulate things before handing your
application over to your robot. If I get enough reader interest in
the RDS, I’ll devote a future column to it.
MAPPING?As I previously mentioned, I am looking forward to experimenting
with a mapping application. While our ultimate input sensor is our
eyes, our other senses certainly add to the way we perceive the
world. I am amazed by how those without the gift of sight use their
other senses to fill in what most of us would consider a huge void.
It’s obvious that the absence of this ultimate input isn’t a
showstopper.
So, this is really about learning. Is there a limit to what a robot
can learn? Is learning based on its sensing abilities? I believe
that if robots are to become more useful to us, they must be
capable of learning. Otherwise, we won’t put up with them. That’s
why robotics has yet to live up to its hype. We seem to be
constantly pushing for more, bigger, faster solutions. Maybe we
need to step back and look at it from a more simplistic point of
view.
Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for
Circuit Cellar since 1988. His background includes product design
and manufacturing. You can reach him at
jeff.bachiochi@ imaginethatnow.com or at
www.imaginethatnow.com.
RESOURCEiRobot, “iRobot Create Open Interface Specification,” 2006,
www.irobot.com/filelibrary/pdfs/hrd/create/Create%20Open%20Interface_v2.pdf.
SOURCESATmega168 Microcontroller
Atmel Corp. |
www.atmel.comCreate Mobile programmable robot
iRobot |
www.irobot.comdsPIC30F4011 DSC
Microchip Technology, Inc. |
www.microchip.comRobotics Developer Studio
Microsoft Corp. |
http://msdn.microsoft.com/en-us/robotics/default.aspxRealTerm Terminal emulation software
RealTerm |
http://realterm.sourceforge.netLiberty BASIC
Shoptalk Systems |
www.libertybasic.com
;){kind=link}