Older blog entries for dafyddwalters (starting at number 5)

4 Sep 2003 (updated 4 Sep 2003 at 22:13 UTC) »

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.


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.

29 Aug 2003 (updated 29 Aug 2003 at 17:44 UTC) »

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.

31 Jul 2003 (updated 29 Aug 2003 at 20:38 UTC) »

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.

22 Jul 2003 (updated 5 Aug 2003 at 22:44 UTC) »

Open Automaton Project Update:

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!

11 Jul 2003 (updated 30 Jul 2003 at 18:46 UTC) »

I've been quite busy on the Open Automaton Project lately.

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.

Share this page