Open Automaton Project Update

I've posted some new messages to the oap-develop mailing list about hardware issues that have come to light since building the prototype, a software development roadmap, and a call for help in the project documentation. Rather than clutter this diary entry by repeating the information in those messages, I'll just post a link to the mailing list archive here for those who may be interested:

http://sourceforge.net/mailarchive/forum.ph p?forum_id=35189

An important part of the software development plan is to put together a simulator environment that allows developers to program and test robot behaviours and task programs without needing to have an actual robot. This will open the project up for contributions from those who currently aren't able to build their own droid, or who only have part-time access to one. It also means that those of us who do have a robot will be able to carry on with software development while the robot is on the bench undergoing upgrades or repairs.

The Grand Plan

(... or perhaps just an unrealistic dream, but it's what I'm aiming for anyway ...)

If all the software comes together as planned, I eventually foresee the ability for OAP users from around the world to contribute behaviours and task programs they've created to a central user- community database (I'll probably host this). The robot, if it's on-line, could periodically check the database for any new programs, and alert its owner/operator of any software modules it's discovered. The operator could then use the on-board web application to seamlessly download and install the new modules on to their machine.

Seattle Robotics Society Robothon

The 2003 Robothon was a lot of fun. There were many very interesting robots there, ranging from BEAM insects to soccer playing Aibos. My favourite was David Anderson's balancing robot, nBot. David never ceases to amaze me with what he can do with an 8-bit Motorola microcontroller. There are some cool videos of nBot in action at his web site, balancing graciously on two wheels as it drives effortlessly over rough terrain. I also loved Greg Fredericksen's range of educational Freddy robots designed for teaching robotics concepts to young enthusiasts. Both of them deservedly won Judges awards for their creations.

The Open Automaton Project prototype droid was on display at the event, and I was honoured to receive the Judges' Choice award for my work on the project. I wrote some simple Perl scripts to implement sociable behaviours for the prototype droid in my hotel room, and then I let it autonomously roam around Seattle Center House during the event on the next day. The kids at the event seemed to enjoy chasing it around the arena, and they were tickled pink when the robot spoke to them.

One of the wonderful things about an event like the Robothon is that it brings together many clever robotics enthusiasts, always willing to help each other out and share ideas. A couple of the guys there gave me some great tips on saving power to increase battery life, and I will be making some revisions to the Open Automaton Project circuit schematics accordingly.

The full Robothon results have now been posted at http://www.robothon.org/Robothon2003/results.html.

I've taken a couple of photos of the assembled Open Automaton Project prototype. They're available here and here (click on the photos to see high resolution versions).

A couple of minor issues came to light during the final assembly of the droid, but luckily no showstoppers.

One issue is the weight of the assembled robot. At 30 pounds, it's considerably heavier than I expected it to be, based on the fact that I knew the base weighs 6 pounds, and the battery weighs 9 pounds. I didn't expect the remaining wiring, circuitry etc. to weigh 15 pounds all together. Fortunately, the Rex-12 base seems to be able to drive along just fine with all this weight. The payload specification of this base at the Zagros Robotics web site is a little vague, stating only that the platform will "easily carry over 15lbs of payload at maximum speed". Based on my experience, the base appears to be able to carry 24 pounds on a flat carpet floor at a decent speed. When I get more time, I'll do some experimentation to find out what the true limits are.

Another small problem that came to light after assembling the robot, is that the thickness (and hence, stiffness) of the cables coming out of the head-mounted webcams (5.5mm diameter) means that the puny little hobby servos in the Pan and Tilt head are having to work much harder than they'd like to. I'm considering rewiring these webcams with smaller gauge cables.

This could well be my last diary entry for a while, as I'm going to be franticly packing over the next few days, and then I'll be traveling until the end of the month.

Open Automaton Project

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.

Open Automaton Project Update:

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).

Open Automaton Project Update

The Sonar Array Module is now complete. If you're looking for an inexpensive way of driving up to 16 SRF04 sonar sensors from an I2C host, check it out.

The custom hardware/firmware modules that have been completed to date are:

• Input Module - emulates a PC keyboard, takes input from an IR or RF remote control, or on-board keypad
• RF Remote Module - a handheld radio frequency remote keypad to use with the Input Module
• Power Management Module - controls main battery charging and communicates with docking station by IR
• Docking Station - ground-based charging dock which acts on IR instructions beamed from robot's PMM
• Sonar Array Module - interfaces with up to 16 Devantech SRF04 sonar modules

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.

Open Automaton Project Update

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.

Phew!

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.

To join the discussion mailing list, click here.

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.

Fun with I2C

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.

Open Automaton Project Update:

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.