Recent blog entries for dafyddwalters

I recently purchased a Roomba (commercial floor-cleaning robot) from iRobot to take some of the load of doing domestic chores, and so far I'm really impressed with how well this thing does using a fairly simple array of sensors and behaviour-based software. It does a great job of vacuuming the carpet, seemingly covering every square inch before declaring the task complete with its R2D2-like beeps.

I'm particularly impressed with how well the Roomba docks with its charging station. This really puts the charging arrangement on my OAP prototype to shame. To be honest, I've never been satisfied with the performance of the three brass hinges (which act as contacts), each in front of a microswitch. I can see that this part of the OAP design is going to have to be torn up and done again.

OAP Update

Scott Crawford has been doing some work on a custom base design for the OAP robot. You can see the progress he's making on the OAP Community Wiki. As a "mechanically challenged" person, I won't be attempting to build his design myself (I shall stick to the Zagros Robotics ready-made base), but for those that don't mind bending metal, Scott's base design certainly looks the part.

On the software side, I'm experimenting with some ideas from a book called Probabalistic Robotics. The basic idea is that nothing is certain in the robot's view - everything from the robot's pose to its model of the world around it is stored in random variables. So for example, its position is represented as a probability density function covering all possibilities, and although there may be times when the robot makes a working assumption that its true pose is at the highest "peak" in this density function in order to carry out a task, it always continuously updates the position probabilities from new sensor data, allowing its assumed position to be corrected. The end result is (theoretically) more robustness in the face of uncertainty in an unstructured environment. I'm interested in this from the standpoint of the Open Automaton Project because the project is targeting the home environment, which is highly unstructured, of course.

18 Jan 2005 (updated 18 Jan 2005 at 09:48 UTC) »

The Open Automaton Project community wiki site is really starting to take shape now. In particular, the Printed Circuit Boards page, Circuit Component List and the Complete Bill of Materials are very comprehensive now, thanks to the tireless efforts of Scott Crawford (you can see Scrott's droid here).

New Wiki for Open Automaton Project

I've recently launched a new Wiki web site for the OAP community. The URL is http://www.openautomaton.org. The new web site is open to anyone interested in the Open Automaton Project who wishes to contribute material that may be of interest to the OAP community.

Material that's already been posted includes:

  • A comprehensive bill of materials, including price estimates
  • Profiles of some of the most active community members, and their OAP-based mobile robots
  • Printed circuit board layouts for the custom modules

"Beingist" Pub Managment?

I had an interesting experience at our Linux User's Group (LUG) meeting a couple of nights ago. It was the first time our LUG had tried out this new venue, and since the turnout was expected to be good, it seemed like a good opportunity for me to bring along my Linux-powered robot, the OAP prototype, for other Linux enthusiasts to see.

The robot was actually quite well received, both by my fellow LUGers, as well as by the ordinary folks in the pub. Most of them just stared in curiosity and amusement as the robot roamed around the pub autonomously, but a couple of people were genuinely interested and wanted to know more.

Unfortunately, one individual who was not amused was the pub manager, who asked me to switch the robot off. I thought he was being rather unfair; the robot was not bothering anybody (it didn't so much as touch a single object or person as it moved around the pub). Perhaps the manager thought it was drunk as it swayed from side to side? I don't think so. I think he discriminated against OAP because it's a robot and not a person. Anyway, as I didn't want to get banned from the pub (and hence future LUG meetings at that venue) myself, I just dutifully switch the robot off and put it away for the rest of the night.

Later, I was thinking about the social implications of what had happened in terms of a future when mobile robots will be a bigger part of our everyday lives. What if the OAP prototype was an "assistance bot" for an elderly person in the pub? I think that perhaps we're going to need to invent a new term that describes discrimination against beings of a different type to humans    :-J

Perhaps some day we'll see signs up at pub entrances saying "No dogs except guide dogs, and no robots except assistance bots".

29 Oct 2004 (updated 29 Oct 2004 at 18:58 UTC) »

Inspiration!

I've been inspired by a recent interview I read with Linus Torvalds to get back to spending more time on the Open Automaton Project (OAP).

In the interview, Linus was asked what advice he had for people undertaking large open source projects (he should certainly know). I won't quote his entire response (read the interview if you want to see it), but basically his advice can be summed up thus: Don't bite off more than you can chew. Here are a couple of the best quotes from his answer:

  • start small, and think about the details
  • if it doesn't solve some fairly immediate need, it's almost certainly over-designed

I realize that I've reached a point with the Open Automaton Project where it would be very easy for me to think "too big", and spend the next two years on some fanciful grand design for the software architecture. But I know that if I were to go in that direction, the project might never be finished.

Instead I'm going to tackle a few specific tasks that will make OAP immediately useful.

The first, most pressing task, is to write a simple Player driver for the robot that fits in with Player's existing interfaces. Any OAP functionality that can't be made to fit the Player interfaces will simply be left out of the driver initially. For a while I've been thinking about complicated strategies for trying to shoehorn OAP's capabilities into the Player interfaces, but I now believe that approach was wrong. Player provides a pretty comprehensive set of interfaces for general purpose mobile robotics, but some of OAP's capabilities currently just don't fit the Player model. For example, one of the ultrasonic distance sensors is mounted on the pan & tilt head, and three of them are pointed at an angle towards the floor in front of the robot, and these things cannot be easily modelled in Player. Also, the pan & tilt head-mounted passive infrared human body-heat sensor cannot be easily modelled in Player either.

By getting a Player driver up and running (even without all of OAP's sensors integrated), this will allow the robot to be immediately useful by leveraging some of the Player-compatible applications and algorithms that have already been developed.

Printed circuit boards

I'd like to take this opportunity to publicly thank Scott Crawford for the contributions he has made to the Open Automaton Project in the past year. He has contributed two-sided printed circuit board layouts for the hardware modules, which I am currently integrating into the official project code in readiness for the next official OAP release. His work will certainly lower the bar for folks interested in building their own OAP-based robot.

A home at last!

I've been settled in my new home for nearly three months now. It was exactly a year ago when I stepped back on British soil after living in California for nearly five years prior to that. It has taken three attempts to buy a house here (the sellers unilaterally withdrew from the sale on the first two attempts). After all the chaos of house hunting, abortive house purchases, and finally moving in, which involved organising the transport of our belongings from LA (where they had been in storage since we moved from the States), only now, one year later, do I finally feel that life is back to normal.

Now that there is a semblance of normality in my life, I will be getting back to doing the things I enjoy, which includes robotics of course, so expect to see more from Mr. Davbot soon.

8 Nov 2003 (updated 8 Nov 2003 at 16:16 UTC) »

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.

28 Oct 2003 (updated 26 Oct 2004 at 20:00 UTC) »

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.

14 Oct 2003 (updated 14 Oct 2003 at 20:50 UTC) »

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.

8 Oct 2003 (updated 8 Oct 2003 at 14:53 UTC) »

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.

2 Oct 2003 (updated 2 Oct 2003 at 16:55 UTC) »

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

7 older entries...

X
Share this page