Exploring Vision Options

As part of the Pokey refit for the next Firefighting contest, better flame detection is a must. Imaging seems the most reliable solution.  The NXTcam was probably a large part of Physignathus' victory in the first Fort Collins Robot Firefighting Contest.  The CMUcam is popular as well.  But both are too expensive for me.

Cheap Camera Options
Pokey is supposed to be a budget/DIY robot.  A couple weeks ago, I was considering a DIY vision system built around a cheap, poorly documented CMOS camera, but gave it up as too ambitious.

Three remaining options best fit within budget and complexity constraints. Parallax has a 1d vision sensor (picture at right from http://www.parallax.com/) that captures a line at a time. By scanning across an area, one can reconstruct the complete image.  Cost is considerably less than a 2d sensor at around $50 (and already I have spare servos).

One question arises: do I need to add an encoder like the one available from Acroname or this one from Zero One Mechatronics or make my own? Is a single servo step a small enough angle to reconstruct a complete image or is gear reduction needed for smaller steps?

AVRcam picture at http://www.jrobot.net/

The second option is to buy a $100 AVRcam kit which is simply a matter of assembling and then using.  No reinventing the wheel, but not a lot of learning about computer vision, either.  It may be worth the cost to save time.  The vision system is totally open source, so future tinkering is entirely possible.

The third option is to use a black and white Game Boy camera.  I've got one on order (Scratch that) One just arrived from eBay! There are several articles floating around about using this sensor. One in particular discusses interfaces to an AVR and external ADC. The camera can remain fixed on the robot and the robot can crudely scan the room as it is moving.  However, implementation will be time consuming and complex.

Vision Processing Power
Video takes a lot of memory and processor speed.  The Game Boy camera is based on a Mitsubishi M64282FP CMOS image sensor that, much like a human retina, has built in edge detection which is an amazing feature that offloads some intense image processing.  It's only a 16KP -- that's right kilo-pixel -- camera: 128x123 pixels.

Even so, a maximum 30fps frame rate still puts a lot of demand on a mere MCU.  The sensor is a serial device, outputting an analog value one pixel at a time.  Maximum frame rate requires a 500KSPS (thousand samples per second) which is far beyond what most AVRs can provide with their built-in ADCs.

How much is really needed?  For now, at least, simply taking a couple of still pictures might be enough to detect the candle flame, with a low frame rate to point the robot at the flame and drive to it accurately.  So maybe 10fps is enough.  Or less?

If one is to process just two entire frames in memory, one needs around 32K of RAM. There's probably little reason to process more than this yet.  And maybe I can come up with some memory-saving tricks, like doing feature detection on the fly without storing the entire image.

Which MCU?
So what processor to use?  Again, think low budget.  Otherwise I should just get a CMUcam and be done with it.  The ATmega8515, ATmega32, 64, and 128 can be hooked to as much as 64K of external SRAM. The AVR32 chips support 32K and 64K of internal ram. Sticking with AVR would save time. No new development environment, no new language. They're cheap, very few components to get one going, and no new serial programmer hardware to buy.

An external ADC could sample much faster than the AVR.  I've got a couple of candidate ADCs I want to look at, one serial, one parallel. I'm leaning towards parallel as I think it'll be simpler to interface from a timing standpoint.

I've never looked at PIC processors before but there may be a couple of options there. For example, the PIC32XX3XX/4XX family runs at 80MHz, has up to 32K RAM and 1000kHz ADC sample rate.  But, it would have the disadvantage of a new chip, new IDE, new flavor of C, etc.  And I'd need to get a big TQFP breakout board.

Another option is to use a Parallax Propeller which runs at 80MHz, has 32K RAM and a little research suggests it may support fast ADC rates at lower resolutions (EDIT: the Propeller doesn't include an on-board ADC hardware peripheral, however it is possible to do 1-bit sigma-delta conversion). And it has parallel processing. It comes in a through-hole version as well as TQFP but requires several support components, particularly a serial EEPROM and a special usb-to-serial programmer. The unusual chip and its entirely new language would be very unfamiliar territory. Figure $40 ($23 as of Nov 15, 2011) for a Schmartboard development board, and try to hack one of my two usb-to-serial programmers for use with the Propeller. But, it runs about 160MIPS and does true, deterministic, real time parallel processing with 8 cores. That's a powerful argument.

Software
I'm not quite sure what the heck to do about software so more learning and experimenting is required there. This is one of those time vs money trade-offs -- with more investment I would save myself all the time of building circuits and software.  But I wouldn't learn as much, either.

At any rate, the current plan is to prototype some algorithms on a PC or Mac using simulated candle images: pictures of a candle in various situations, re-sized to 128x123 pixels to see how feasible this really is.  More on that in a later article.

Mind Mapping Pokey's Refit

I've got my head in a lot of different places at once right now, thinking about Pokey's refit for the next firefighting competition.

One tool I like for keeping a bunch of related thoughts straight is Freemind, a mindmapping tool that is, as you might guess, free. It's also cross-platform (Mac OS X, Windows, Linux, or really any OS that supports Java).

The interface is quick to use because it supports simple keyboard shortcuts for every operation. Once you learn those shortcuts, you can add your thoughts quickly (sort of a mind dump I guess...)

Here's an export of my mind map so far for Pokey:

National Robotics Week

The first annual National Robotics Week is April 10-18, 2010.

The purpose of National Robotics Week is to:

• Celebrate the US as a leader in robotics technology development
• Educate the public about how robotics technology impacts society, both now and in the future
• Advocate for increased funding for robotics technology research and development
• Inspire students of all ages to pursue careers in robotics and other Science, Technology, Engineering, and Math-related fields

Why is robotics important?

• Robotics technology is a growing industry which creates high-tech jobs in the US
• Robotics technologies are helping to improve healthcare, national defense, homeland security, energy, manufacturing, logistics, transportation, agriculture, education, consumer goods, and many other sectors
• Robotics provides an exciting, hands-on way for students to learn Science, Technology, Engineering, and Math

Celebrate National Robotics Week by attending an event in your area or host your own event!

Pokey V2.0

There's talk of another local robotic firefighting competition some time in May or June!

Pokey's defeat in 2008 has nagged at me for the last couple years so time permitting Pokey and I are going to take another crack at it.

Pokey needs a refit and redesign. Here are some of the topic areas I'll be covering in the near future --

-- but first, what won't change?

No Dead Reckoning

You may recall that Pokey does not use dead reckoning. I want to continue with that design philosophy. Pokey relied on wall following and "events" to navigate -- the appearance/disappearance, while moving, of walls and floor markers.

Smooth Speed

Pokey was always intended to be a fast robot. His name comes from the fact that I had to slow him down before the original competition to increase navigation reliability.  I don't want to slow him down further. If anything, I'm hoping to speed up the little fella. Also, Pokey was built to move smoothly and fluidly through the maze and I don't want to change that, either.

Budget

Pokey was intended to be somewhat low buck, with cheap, minimalist solutions preferred over fancier, more expensive ones where possible. I may have to admit defeat in a few areas and throw some more money at the problem, but I still want to come in under the cost of a Lego NXT when all is said and done.

Despite the things that won't change, clearly some changes are needed for Pokey to complete his mission and these things will be the subject of upcoming articles.

Navigation Problems

Thinking it through, most of the navigation problems boil down to poor wall following and failing to execute precise turns.

The wall following system was marginal. It could usually maintain a correct alignment but failed to correct even moderate misalignment. A single wall distance sensor was inadequate given short maze walls and a fast robot. A pair of wall distance sensors on each side should solve several problems at once.

While executing consistent, constant radius turns wasn't too tough, reliably turning to a precise heading was. The trigger to terminate the turn was the distance of the wall that the robot was turning to.  It just didn't work.

I suspect using either a rate gyro or wheel encoders -- just for turning, not dead reckoning! -- would provide more precise heading changes and fluid movement. If I can actually pull it off, be assured you'll hear about it here...

Some robots had success aligning to the regulation door threshold floor stripe. This approach alters the flow of robotic movement as it enters the room, but maybe I can live with it if the gyro and encoder options don't pan out.

Flame Detection Problems

Pokey failed to detect a flame the one time he encountered the candle in the contest.  I ran out of time to really dial in the calibration and software. The sensor itself works ok at closer ranges, poorly at long range.  It's big and heavy, limiting fire suppression system options and making Pokey less nimble.

Picture from superdroidrobots.com of Hamamatsu UVtron

Affording (or justifying the cost of) a UVtron or Eltec Pyroelectric flame sensor -- or a CMUcam or NXTcam vision sensor -- is tough. The AVRcam is more affordable and, apparently, just as capable as these other two vision systems. Or sticking with some form of IR detection is still a possibility.

I'm currently exploring some cheap DIY camera/video options. I really think that's the best way to go since the last contest winner was using an NXTcam and very easily and reliably detected the candle. Not to mention, I could reuse this type of sensor for many other purposes. More on vision in future articles.

Telemetry

One of the biggest difficulties was that Pokey didn't collect data for later analysis. I never quite knew what the robot was doing from moment to moment. I'm working on using bluetooth-based communication for telemetry reporting and logging. More on this in an upcoming series of articles.

Collision Avoidance

Finally, it'd be nice if the robot could priority override all other functions to prevent head-on wall collisions...

Of course the biggest challenge is time... but at least I don't have to start totally from scratch.

Heathkit and Robots

So I fixed up my Heathkit IO-12 oscilloscope and the Heathkit RG-8 frequency generator is next on the to-fix list.  I'm also still working on building the oscilloscope calibrator; it's based on a Heathkit design.

Heathkit sold robot kits, too, as you may know.  I remember in college every time I passed the ground floor ECE Building labs, looking in the big windows, being greatly envious of the guys in the lab on the first floor of the ECE Building who got to play with the HERO 1 (as above left).

I guess some of that envy shows in my goofy sketch of Edward Isaac Bot's head, what with the integrated hex programming keypad.  I think it's safe to say that feature would be ditched in a modern verison...

Apparently a Heathkit HE-Robot 2000 is available these days, a rebadged PC-Bot 914 from White Box Robotics. (The picture below is from Retro Thing; presumably they got the pic from the Heathkit site or a news article or something).