A major milestone has now been reached
in the project: All of the custom hardware & firmware
modules have been designed, prototyped and tested. I've just
finished work on the last of these, the Motor Control
Module, which generates high frequency PWM signals for
the two main DC drive motors, and decodes the signals from two
quadrature encoders. The interface with the host mainboard,
as always, is I2C. The functionality of the Motor Control
Module has been scaled back somewhat from what was
originally planned. Originally, the Motor Control Module was
to contain firmware for PID closed-loop control, and for
keeping track of the robot's pose. Now, this functionality
will be a part of the "driver" layer (more on this below)
which runs on the host mainboard.

I've already started
work on the next layer of software, a "driver" that
communicates with the robot's hardware modules. The driver
acts as an abstraction layer, which
represents the hardware to "client" code as a collection of
standard interfaces. I'm writing this driver to fit into the
Player
robot server framework. Such is the magic of Player, that
once the driver has been written, it should be possible to
"plug in" pre-written Player-ready algorithms and code modules
into the robot. They will interact with the Open Automaton
Project hardware via the standard interfaces.

Robothon

Now that all the custom
hardware modules are done, the prototype is about ready for
final assembly. There are a few more holes to drill and
wires to run, but I should be able to get this done over the
next couple of days, so it'll certainly be ready for the
Robothon.

The prototype will be on static display at the
Robothon, and I've prepared a two-sided flyer that I'll be
handing out at the event, which briefly introduces the
project to interested visitors.

Here's a PDF draft of the
flyer: oap.pdf
(feedback is welcome; it's not been printed yet; dafydd at
walters dot net).

The
Big Move

There are just nine more days left before the movers
come to put all my worldly belongings into a 20-foot freight
container, leaving my family and I with just a few
suitcases, my laptop, some books and essential tools, and
of course, the
robot. Then we're off on a leisurely 5-day drive up the
coast to Seattle in a rented SUV, which will be our last
chance to enjoy this country's scenery before we head back
to the UK.

The Head Control Module is now up and
running.
This is a PICmicro-based device for driving up to two RC
servos (for Pan and Tilt) and optionally interfacing with an
Eltec 442-3 pyroelectric passive infrared human body heat
sensor.

The Head Control Module allows a host to limit the
maximum speed of servo movement, facilitating very smooth
pan and tilt motion. This also allows the position of heat
sources to be recorded fairly accurately.

The module uses I2C to interface with a host
controller,
and a command-line utility program (which runs on GNU/Linux)
is available for testing the interface and experimenting
with the module.

There's still some testing to do on the passive
infrared
sensing, but the servo drive functionality is fully tested.

Sourceforge appears to be experiencing some Shell
issues
this morning, and I've not been able to update the tarball on
the downloads
page, so you'll need to either wait a few hours before
downloading the code from there, or use direct anonymous CVS
access (you'll know you've got an up-to-date release if
you have version 1.8 or later of head_control_module.asm).

The hardware/firmware modules still left to complete at
this time are:

Motor Control Module - takes quadrature encoder
signals from two wheels, outputs 20KHz PWM signals for two
motor drivers. Firmware includes two PID control loops (one for
translation, and one for rotation), as well as dead
reckoning by odometry.

Head Control Module - drives two RC servos (PWM)
of the Pan and Tilt Head, and interfaces with the Eltec
442-3 human body heat sensor

At this rate, it looks like I will be
ready
for the
Robothon just in time. However, because I've taken a
bottom-up approach to the project, and there won't be much
time left when I've finished the hardware/firmware modules,
the prototype is not going to be as "smart" as I'd hoped in
time for the Robothon. It'll probably just have some
basic behaviours. I'll be adding the real
smarts after I land back in the UK.

DC to DC Converter Woes

I blew up my Morex DC to DC converter
earlier
in the
week! This is the device that takes the 12V (nominal)
voltage from the lead acid battery, and converts it to all
the different
voltage levels necessary to drive the motherboard and hard
drive. I always had my doubts about that particular DC to
DC converter because of the very limited input voltage range
specification (11.4V - 12.6V). I knew that the battery
voltage could go above the upper limit, so it was just
wishful thinking to hope that this would not be a problem.
This setback has turned out
to be a blessing in disguise because it forced me to look
around for a better DC to DC converter. The one I ended up
choosing as a replacement is the PW-70 from
Mini-Box.com. This can tolerate an input voltage in the
range 10.5V to 15.5V - much better!

Another (obvious in hindsight) lesson I
learned this week: Make
sure that
the wire gauge used for carrying the 12V power rails
around the robot can handle the current draw of the various
modules! While
testing the Power Management Module and Docking Station, I
was quite surprised to see a 0.7V drop between the 12V DC
switched mode power supply inside the Docking Station, and
the input of the DC to DC converter on board the robot.
Quite a bit of this voltage drop was just due to wires that
were not thick enough. The docking station coupling also
accounted for some voltage drop. In fact, having already
tried two different approaches to implementing the
docking/charging contacts at the front of the robot (which
mate with the Docking Station) it still seems that I'm going
to have to come up with something better than I have now
(which is using modified decorative brass hinges). I think
this is going to have to wait until after the move, though.

With my self-imposed deadline rapidly approaching for
getting the prototype robot ready in time for the Seattle Robothon,
I feel like I'm running out of time. I've had the flu the
past few days, and in a couple of months (right after the
Robothon, in fact) I'll be moving myself, my family and all
my worldly belongings half-way across the globe to a
different continent, so I'm having to deal with selling the
family cars and all non-240V-compatible electrical goods,
packing boxes, etc.

And here I am building a PC-based mobile
robot. I must be mad!

Well, come hell or high water, I
will be bringing my creation to the Robothon, and it
will be up and running!

Recently, I remember reading how Marvin Minsky was lamenting at the
state of "stupid little robots", and that graduate
students were "wasting 3 years of their lives soldering and
repairing robots, instead of making them smart". Based on
my recent experiences, I have some sympathy for those
graduate students: Before embarking on the Open Automaton
Project, I had visions of getting the prototype robot
platform working quickly, and then spending lots of time
experimenting with A.I. code for stereo vision, facial
recognition, mapping, localization, etc. However, the
reality of having to do lots of drilling, sawing, soldering
and building circuits on veroboard and then debugging them
has made me realize that I'm really not going to get to that
"high-level" software stage until much later than I had
originally hoped. It's surprising how much of this "grunt
work" has to be done, even when using as many off-the-shelf
components as possible.

I've decided that sometime in the next few
months, I'm going to design printed circuit board layouts
for the hardware modules, and then have a small run of them
made so that I can offer them for sale as kits. This way,
people interested in
building their own Open Automaton Project-based robot will
not have to suffer, as I did, building and debugging
veroboard circuits.

Another decision I've made is to split my project plan
into two major phases, based around my
intercontinental move. I've assigned each individual
project task as either pre-move or post-move.

Without going into too much detail here, basically at
the end of the pre-move phase, the prototype robot
will have all of the hardware (with firmware) modules
designed, built, debugged and tested, and some basic
intelligence working via the Pyro
framework. All this, of course, will be done while packing
boxes, and
generally getting ready to move.

The post-move tasks are to integrate the vision
code (at this point, I'm leaning towards reusing
motters' GPL'd stereo vision
code), fully
developing a framework for "plug in" behaviours and task
programs, and developing some initial behaviour and task
program software modules. After that, I intend to
commercialize some of this work by creating kits for the
circuit modules (I'm not expecting to make a living from
this). All this, of course, will be done while finding a new
job in the
UK (if you're a hiring manager in the South Wales area, my resume
is on-line; I'll be available from November), buying a house
and cars for the family, etc. and generally starting to
build a new life in the UK.

The Open Automaton
Project now has a discussion mailing
list. If you'd like to hear about project milestones or
anything of interest, or if you'd like to discuss anything
related to the project, please feel free to join the mailing
list.

Of course I will continue to keep posting updates to this
diary, but if you'd like to comment about anything you read,
or you'd like to influence the future direction of the
project, the mailing list provides a suitable channel.

Work on the Open
Automaton
Project the last few days has focused on getting the IIC
bus up and running with the VIA Nehemiah M10000 EPIA M
Mini-ITX motherboard which is at the heart of my prototype
droid.
The I2C bus is the backbone to which many of the
microcontroller-based driver and sensor boards connect. This
arrangement keeps the wire runs around the robot simple
(basically just power and IIC), and keeps most of the
mainboard ports free for other functions.

After a few trials and tribulations, I finally got the
whole thing working really well, so I thought it would be
worth chronicling some of the notable things I found for the
benefit of others who may also be attempting to access I2C
peripherals on their PC-based robot (running GNU/Linux).

I found this
web page a useful source of information. It describes
how to access I2C devices using the /dev interface
from the PC's standpoint. If you're using the same VIA
mainboard as me, then you'll need to
load the drivers i2c-viapro and i2c-dev. For
example, you could add the following lines to a startup
script such as /etc/rc.d/rc.local

modprobe i2c-dev
modprobe i2c-viapro

To check if the devices are loaded, typing
cat /proc/bus/i2c should list the I2C buses on
your system. On my system, there's one entry, called
i2c-0. This device is accessed from your code using
the device name /dev/i2c-0, as described in the web
page I linked to earlier.

I found that on Red Hat Linux 9, everything worked "out
of the box". There were no patches to apply or drivers to
download.

One thing worth noting about the hardware implementation
of the I2C interface on the VIA motherboard, is that it uses
3.3V logic rather than the usual 5V logic. This is no big
deal because all I2C signal lines are open collector anyway.
It just means that any pull-up resistors you use be should
tied to the 3.3V rail
that's conveniently provided on the mainboard I2C connector,
rather than a 5V rail. This last point may actually be moot,
because based on the results of my experimentation, it
appears that the host mainboard has its own on-board pull-up
resistors, and the interface seemed to work perfectly well
without pull-up resistors at the peripheral end.

I'm using PICmicro devices on the I2C bus, configured as
slaves (obviously, the mainboard is the master), and I found
a couple of very useful documents to help me with this.
One is Microchip's Application Note AN734, "Using the
PICmicro SSP for Slave I2C Communication", and the other is
the official SMBus Specification, version 2.0. The second of
these documents describes how the SMBus protocol can be
implemented using I2C, allowing the higher level
i2c_smbus_ functions to be used at the PC end (highly
recommended). I've provided links to PDF versions of both of
these documents at the bottom of the downloads page of the
Open Automaton Project web site.

I've added a hardware block diagram to the project
page of the web site, which gives an idea of the scope of
the project (as much for my own benefit, as any interested
visitors). This puts the project into perspective; there are
seven hardware modules with firmware to develop in all, five
of which are left to design as of today. After that, there's the
Player "driver"
software to be written for the I2C
devices, and initial versions of the behaviour and task
software components based on the Pyro framework
need to be integrated.

To get all this done in time so that I can take the
prototype droid to the Seattle Robothon
this October as planned, seems like a tall order, but
I'm determined to do it.

I've added some pictures to the prototype
page; there aren't many there yet, but I'll add some more
over the next couple of weeks.

Work on the prototype droid continues. I've updated the
web site to include
a 'prototype'
page, detailing some of my design decisions and thought
processes in building the prototype, so I won't clutter
this diary entry with those details.

On the development front, the Input Module, which
is the hardware/firmware component that receives human
input, now fully supports IR remote control, so I can now
point my TV remote at the robot, and when I press buttons on
the remote, the PC motherboard thinks that keys are being
pressed on a keyboard. It occurred to me that this part of
the project by itself may be of interest to some people even
if they're not interested in building a robot. For example,
if you're working on a project to make an MP3 jukebox or
media device out of a PC, you could use my Input Module to
control the device via an TV remote.

I've taken delivery of most of the major hardware
components now. One component I was particularly keen to get
my hands on was the motherboard, a Nehemiah M10000 EPIA M
Mini-ITX 1GHz from VIA. When this arrived, I quickly got it
set up on a bench with the DC-to-DC converter and 13AH
sealed lead acid battery to take some power measurements. I
was pleasantly surprised by what I found: The information
published about the Morex DC-to-DC converter mentions that
the AC adapter normally used to power the DC-to-DC converter
(not used in my project) outputs up to 4.58A, so I
was expecting to see a current draw from my battery in the
order of 4A to
4.5A. However, what I found was that with a 40GB hard drive
and a USB wireless 802.11 adapter plugged into the
motherboard, the current draw from the 12V battery was just
over 3A. This is good news in that it means that the robot
is likely to be able to run for a couple of hours or more
between charges.

While the motherboard was on the bench, I also took the
opportunity to install the operating system (GNU/Linux) and
the driver for the wireless network adapter. I plugged in a
conventional ATX power supply to do this, although in fact,
the operating system went on so smoothly and quickly, I
could have quite honestly done it all on battery power :-)

So far, I'm very impressed with this little motherboard.
It packs a lot of punch in a small, lightweight package, and
has oodles of robot-friendly I/O ports, including
I2C!

I have just placed orders for most of the expensive
off-the-shelf hardware components of the prototype droid,
including the base,
processor board, sensors (vision, ultrasonic, passive
infrared). If you scroll to the bottom of this
page, you can see a list of all the major hardware
components that make up the robot, including how much I
paid and the names of the vendors.

So far, I've developed some of the electronics and
firmware that make up the human-robot interface, and I've
got a breadboard prototype up and running. The input
device on the robot itself is a simple six-button keypad
(up, down, left, right, enter and escape), which allows
rudimentary control such as program/task selection, and
basic human responses to robot prompts (be they spoken or
by text displayed on the LCD screen).

I've been spending quite a bit of time looking at existing
publicly available open-source software projects of
interest to the Open Automaton Project. A couple in
particular are of great interest, and I believe will be an
excellent fit. One is Player/Stage, and the
other is Pyro. At the
moment, my plan is to develop sensor and actuator software
components that comply with the Player specification, and
develop behaviours and high-level task programs using the
Pyro framework.

I certified motters as a
Master
today since I've frequented his web site on numerous
occasions in the past couple of years, and have always been
impressed with the robotics work he's been doing. I'm
particularly impressed with the work he's been doing
recently in the area of robot vision, and since he has very
generously seen fit to publish this work under the terms of
the GNU
General Public License, I will very likely be able to
re-use some of this work in the Open Automaton Project.