AusRobotics

BP Australia has set up a nice site where you can remote-control one of several "surveyor" robots they have running around a diarama.

I have an early "version 1" of these things, and a friend has a 2nd gen  blackfin version. But neither behaves like the beasties on the game site.

Oh yes. There's a bit of a queue... :)

See http://www.bpexplorer.com.au/.

Going back (the 2nd day) to edit up something to put on YouTube found my supposed-mpeg files from the truckbot mission were unreadable.

Funny -- I was sure I'd managed to play them on the laptop 24 hrs earlier. But, regardless, they couldn't be played or shoved into a video editor today.

So I had to go back and do it again.

Since the conversion seems to run on almost real time (i.e. 60 mins of video as an .VOB file takes 30-60 mins of time on the Win klaptop to make into an mpeg4 avi), I've only managed to edit together something that was also on the same DVD at the start -- vision from my "catguard" experiments.

So that's what I'm pointing at today.

Basically, the "catguard" (maybe later will mysteriously transform to a "kitchguard" or "houseguard") is meant to look after my kitten. Presently, some of the neighbouring toms have been following it into the house late at night either to steal its food or beat it up or both.

I managed to cook up a simple Bioloid that used IR and light sensors to detect suspicious commings and goings and make a noise and wave an arm if so.

After some last-minute hacking to get my s/w to smoothly integrate 3-point turns plus smooth PID-type turning, the Ford truckbot was sent out Wed night to circle the block.

The mission met with "mixed success". While the turning code worked OK, the bot lost contact with the base AP at a range of only 50 m, so executed an "abort" and shut down on the nearest of the 4 corners on the block.

Like most of my robot s/w, the ultimate controlling is done by some goal-oriented Prolog. And one of the (several) great things about Prolog programming is the ease with which you can hack in a correction to a complex set of instructions. (I.e. "clauses" nearer the top of the source file take precedence over those later in the code; you can also ensure a given "hack" clause causes later alternatives to be simply dropped. This is all pretty much a hacker's dream and a maintance programmer's nightmare :).

So it was only a matter of seconds before the idea of simply "aborting" was short-circuited unless there was REAL trouble (i.e. none of a shortlist of things that could actually be ignored for the night).

A $us150 3" sq mobo featuring TI's OMAP3 has just been announced, and for once you can actually "buy it now".

While not aimed for controller-type applications, the OMAP3 features a 65 nm low-power 600 MHz ARM9 with graphics and DSP co-processors.

The board incl an LCD i/f, SD slot for digital cameras, USB 2 OTG (i.e. host+device), audio in/out, DVI and analog video out.

See: http://beagleboard.org/ .

A few new items have come in over the past week or so, and actually recording one of my "bigbot"'s night missions (i.e. when the roads and footpaths are clear of kibbizters and their pets) is now green-lighted.

Some of the recent devices include a couple of IR-assisted wifi cameras. For 20 usd they aren't TOO bad, bad at least one suffers from the problem of "hum" over the audio circuit.

It seems the PWM used to power the IR lamps manages to make its way over the wifi to the destination at about 3db below (i.e. "not much, really") the actual noises of interest. But the 4Mpx image is nice and sharp, so I can't complain there.

The wifi has a 200 mw transmitter so should be able to go the full 200 m of my block (don't want to be crossing any unofficial dragstrips during the early am's, either).

Both units have a bit of a drain on a 12v supply -- 5-10w each, mostly for the lamps, of course.

So it may have been wiser to just have an IR-sensitive camera and an external (compatible) IR lamp mounted on a tripod, or somthing.

Anyway, I'm set to record mission 3 of the Ford, which is slated for sometime next week.

After a couple of experiments and a few mis-starts, I figure I'm ready to circle the block on full auto. :)

What with all these toy sales on now, I've been doing the rounds of the various supermarkets and looking at large-scale toy cars &ct.

In case you hadn't noticed, and maybe are interested, the following base looks like it could be hacked into a reasonable large-format wheelbot.

Yes, all-plastic construction -- apart from the motor mount and steering linkages.

The motor is a pretty nice (but cheap -- i.e. $20 on ebay kinda thing) 12v with some grunt, at least by the usual hobby robot standards.

At present it's selling around $400 aud, but on sale it's 199.

I guess someone over-ordered, or summin. ;)

After some careful testing, re-designing, and re-testing around the yard and house, I sent my modified truck "big bot" out on its first mission.

The goal was to go (in a straight line) from initial position -- outside the front gate -- 200 m up the road to an intersection. The problem was specified using GPS co-ords off a website, with a couple of "don't go" areas meant to keep the bot (4" wheels) (a) out of the gutter , and (b) out of people's yards or piling up against fences.

The wheelbot is a much-hacked 1:4 scale RC truck with a couple of nice DC motors, a 3-speed gearbox (although the DC motors now have speed control), stepped steering over +-45 degree (now under control of a cheap servo; previously it was an "all or nothing" type of operation), a bunch of LED headlights, and version 4 (not counting a few version that didn't make it to power-up) of my homebrew IMU.

The platform is controlled by an avr32 "grasshopper" with an attached wifi board, which is connected via a 4-wire serial homebrew to an Orangutan board that supplies the motor control, servo control, and interfaces to the sensors in the IMU -- presently a 3-axis accelerometer, 2 rate gyros, and a recycled GPS board.

OK, I've bitten the bullet and started playing with an avr8 board!

I bought an 8MHz Pololul "Orangutan" (and programmer) some time back, and until now havn't had a decent project to plug it into. But monitoring a few PWM sensors, doing a small amount of filtering and plugging into a USB port may be it.

But with "only"  1K of ram, it may be pushed to be much more than a gateway between one of the avr32 boards and the sensors involved. But it does have 16k of flash, so the s/w can be pretty 'sfisticated.

The basic INS filter I was playing with this past couple wks is only about 8K of 6800 code (i.e. gcc -Os/-O2).

For those interested in such things, the approx 2" sq  board also has 8 10-bit a/d,  a 2-line LCD, a few buttons, a LED, a knob on ad7, a buzzer, and 2 1A motor channels.

It seems like Pololu are moving in the direction of larger robots, so the price has dropped a bit since I bought mine. I noticed a package with an "original Orangutan" plus its controller is now under 70 usd for unit qty.

Found a problem with my algebra in the 2-d navigation box, and reduced the X-Y position error down to about 1/2 m per min when the robot is moving countinuously, and less when it's moving sporadically.

I even managed to mount the components neatly on a bit of plastic!   The whole thing (with room for tiltmeters and GPS) is around 5x5x1 cm. Of course, it's not in a box, yet. :)

There was also some kind of problem with the C library's trig functions, that mean converting from robot polar co-ords to Cartesian world co-ords had a whole lot of noise added every now and then. So I stopped converting and the world is now in polar coords wrt the robot's original position.

But enough of 2-d, I've moved on!

By turning the 2-axis accel on its side (so that Y points up/down and X points along the axis of the tankbot), I now have a 3-d nav board with the world in cylindrical co-ords. Again, the drift is a modest 1/2 m per min in terms of "distance" (i.e. X and Y and about 75 cm per min each).

And so I'm ready to start playing the differential GPS.

I got a cheap old Trimble ACE II from a guy scrapping sat dishes and it was pretty easy to get it going.

After "solving" the problem of dead-reakoning in 1 axis with an accellerometer, I'm now moving to add a compass and the Y-axis to my simple s/w so the tankbot can determine -- roughly -- where it is in 2D.

As for the first part of the exercise, all modules are configured in pwm mode with TTL levels, and are connected to digital inputs of my Handboard-based bot.

The nuts-and-bolts "sample" end of the s/w chain is now a bit more complex -- I have to measure the period and "up" time of 3 inputs. While they could -- of course -- simply be sampled in sequence, I've elected (with an eye to the future) of running a "parallel" bit-bashing method. Something like "read from the parallel port" with no parallel port, kinda thing. :)

The MEMSIC accel is now attached to the front of the tankbot, with the Y axis aligned left/right. Since it's returning "pulse widths", the sign of the Y accel is not immediately apparent. But as for part #1, I'm using the difference between the motor control parameters for left/right to "guess" which direction the Y-accel will be.