AusRobotics

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.

After some algebra corrections, the basic 1-d filter for my cheap accellerometers is yielding reasonable results.

The platform is my old AX-11 tankbot  running an mc6811 "brick" running Interactive C (IC).

The accellerometor is an old 2-axis Memsic device giving a 1 mg error over a 2g range.

It can operate in I2C or PWM mode, and I've selected the latter. The value for accel is obtained by the ratio of the "up" time of the pulse, vs the period, multiplied by a fudge factor. The sign, of course, is unknown as far as the sensor is concerned. But we *do* know which direction the motor is *supposed* to be driving the robot, so there's another fudge there. :)

Hi guys, great to see all of the activity on the site over the last couple of weeks. It looks like some cool projects are in the pipeline!

This is just a quick heads up to let everyone know what is going down/up/around the place:

Ausrobotics v2

Still going... You can view it here for testing purposes. I am planning on using phpbb3 for the forums which should be a lot nicer than drupal's built in stuff. It doesn't work nicely in IE5.5 or 6.0 at the moment........... If those browsers would just die that would be great. 

Blog posts in moderation

I noticed a couple of posts in moderation and have pushed them to the front page. If your posts don't go straight to the front (they should be default now) then please leave a comment somewhere and I'll sort it out asap.

After a few weeks of twiddling, I've finally managed to get (i) a 2.6.2x linux kernel, and (ii) a root filesystem with native gcc, going on my 2 AVR32 systems.

One board is the "original" NGW100 with 2 ethernet connectors, a usb device, an sd card, and a few other bits out of edge connectors.

The other -- more problematic -- board is the "Grasshopper" from in-circuit.de.

It turned out most of the s/w available through the Grasshopper forum (embedded-projects.net) or via other misc sites was  pretty rotten. Mostly because it was based on a very buggy gcc 4.0.4 that tended to (a) core dump or get compiler errors such as "unreconised instruction" (gcc-speak for "I have not been configured for this hardware properly!"), or generate code that did core dumps for no reason (maybe bad instruction binary).

Anyway, that now seems behind me.

The 2 boards will form part of a multiprocessor I'm building for an outdoor/indoor "big bot".

Among the (many) things I'm playing with, I managed to finally get some pix from an old CMUcam2 look-alike I'd bought some time back.

The device was relatively cheap -- around 150 usd from INEX Global  in Thailand -- and has some well-publicised abilities, incl blob following and colour stats gathering.

It was intended as an "aiming camera" for a more professional model, so getting an actual image out of it wasn't the real important thing. It was supposed to simply follow the blob at the centre of the f-of-v, taking the big camera along for the ride on a pan head.

I've prev showed the simple "out of the box" blob following ability, incl the ability for the cam to drive a single servo in the direction of the blob-to-be-followed.

But after reading through the INEX leaflet, I discovered this somewhat-hacked version of the CMU cam could be controlled by the java CMUcam2GUI.

I finally got off my bum and took some vid of the 2 RC trucks I'm about to covert into robot bases for one of my paying assignments.

While converting RC trucks to robots is pretty common, it's usual to take a $us300++ nitro model and do the chopping. Or -- if possible -- find a complete chassis kit for such a beast.

But being a bit on the cheap side, I found these 2 70 usd 1:4 scale trucks in my Googlings, and couldn't resist getting samples to see what they amounted to.

The larger beast is a H2 hummer. I had to import this from Shankers, since no-one else seemed to have any available. If you look around, you'll find a $200 usd model of the same thing with MP3 player installed; I want for this "warts and all" model that basically is just a big truck. :)

The other model is a Ford with working pimped-out sound system in the tray. I like to keep that switched off -- it's lound.

While both models performed pretty much as claimed by the makers, it turned out the hummer is the poor cousin of the pair. The radio controls only allow full-speed fwd/back, and the steering is only +- 10 deg. All in all, a bit hard to control.

Well, I didn't manage to get the site finished or progress my bot anywhere but I did manage to relax so all in all I would count this as a successful long weekend.

This is what I should have been making of course... Next time!

There is up-coming news of some pretty neat and very cheap big robot bases.  Hacking is involved! :)

The pic is an "urban" robot I'll be working on, on and off, for the next few m. It's supposed to be a prototype "working stiff" and the brief involves moving around outdoors, and moving around indoors but normally in dangerous conditions.

The attached vid is of the MAARs robot that got cashiered from the US military forces in Iraq after it moved its weapon in the direction of friendly forces. The manual for the bot claims it comes programmable with no-fire zones to prevent accidents, but there seems to be an unexpected and disconcerting element of free will to it all.