Truckbot -- Mission #3

[Originally written Fri, 08/08/2008@3:15am; took until 28th for me to get around to processing the vid — kym]



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

Mission 3.2 met with another problem that saw much the same result. After driving up-hill along my driveway, turning left at the gate, and moving to the nearest corner, truckbot decided something didn't smell right about it's inertial positioning, and executed a return-to-base. Which it actually managed to perform accurately by simply backtracking on its course -- it didn't rely on the it-assumed-faulty position estimating. (The GPS positioning data wasn't much help in soothing truckbot's estimated location problems since the entire mission track was not much longer than the Trimble board's location error).

During the 60 mins or so all this took I managed to record images from the on-board IR camera. However, even the 200 mw TX attached to the camera didn't seem to reliably connect to the purpose-built AP I'd attached to the top of a pole PoE-style.

Beside learning a few things about internal status monitoring (is is worth it, or should you just accomplish the mission regardless of how well the bot thinks it's doing? :), I did finally managed to decode the vid the AP was stashing on a DVR. I'd always wondered how to decode those .VOB files -- now I think I know.

In the 60 mins of vid, there is -- however -- only a few 1000 monochrome frames that actually show anything recognisable. (Shots of local streetlights against a night sky are not counted in the definition of "recognisable").

I have the converted MPEG4 on a laptop, and will try to fish around in it to get some sample shots.

The DVR footage also seemed to catch a bit of experimenting with using the IR cam as a cat-spotter. (I've had trouble with neighbourhood cats sneaking into my kitchen at night and stealing my kitten's foot -- as well as beating it up). I'll add a bit of that to the YouTube item, too.

I'll attach the YT ref tomorrow, when the fishing & uploading are done.

---

Update: After now looking at the (final) YouTube vid -- it now seems almost unintelligible. The final YouTube upload has massaged the B&W images a bit and now massive pixelation problems largely obscure what images that managed to make it over the wifi.

Humanoid -- walking

Just a short note to maybe gather together some of the rambling commentry I've made about my "movement" projects over the past year.

I've tinkered up a simple physics sim that allows me to animate robots in VR that are designed and/or assembled from a parts library and/or controlled by other parts of my s/w.

Here's one example -- animation of a "standard" hobby robot that can be built in "real" reality using the Robotis Bioloid Comprehensive kit.

In this example, a linear planner written in Prolog -- augmented with a few "axioms" about zero motion balancing -- attempts to shift both feet of the robot forward without falling over.

It manages to come up with a method very similar to the s/w that comes with the Biolod kit.

The planner's idea of (e.g.) counter-movement of the robot's arms to maintain balance falls out of a "meta axiom" in the higher levels of planner having to do memoising solutions -- "if you've solved a problem, maybe a mirror image plan will solve the associated mirror image problem". (This artifact is seen elsewhere in the various quadbot sims).

Elsewhere on my YouTube page there is a "turn right" clip showing the planner solving the problem of turning the robot 45 deg to the right.

These 2 clips should NOT be confused with some of the other "humanoid" animations on my YouTube page.

As another part of the s/w development effort, I also used an AVR8 simulator to actually run the extant Robotis s/w in the same VR. I thought it'd be a good test of the physics sim if s/w that was known to work in the "real world" produced idential results in the VR.

Unfortunately, some of the "shortcut physics" ("A biped robot must have at least one foot on the ground at all times" and "A foot is on the ground if it touches the ground in at least 3 places") in the sim caused the Robotis s/w to fail badly -- usually in spectacular and hard-to-understand ways.

Think of some of the funny results it as "magic" in a VR context. :)

---

Just as an afterthought, here's pretty much the same vid up-loaded to VIMEO. While vimeo has it's design flaws, the video processing seems much cleaner than the final result produced by my perhaps-flawed animations uploaded to Youtube.


Humanoid -- walking from russell horsell on Vimeo.

A New Start

Not to sound like a Starwars title, I'm starting this "independent" blog away from problems that sometimes (or, with a view to the future, may) happen at my robot blog-de-jour at AUSROBOTICS.COM.

It's been a couple of years since I've managed a blog at (what is now blogger.com) and it looks like it'll take a couple of posts to get the feel of things again after battling with drupal.