Managed to get a couple orders out to replace the fiasco at RobotShop.CA.

But it now seems another problem is developing with RobotStore.COM. Similar name, similar problem…

Well, not quite. While the Canadians did at least answer emails when they were asking and then demanding old bank statements, RobotStore.COM doesn’t bother to answer emails at all. They’ve had my money for 4 weeks, I got a robo-confirm from their web page in the beginning, giving the address to contact with problems. 3 or 4 emails asking what the hold-up might be and no responses since.

[Update Sep 5: all my  emails to these folks have suddenly been answered by different people  in the past 6-7 hours. Although the order was originally accepted,  I'm now told the items -- a couple of different hex walkers and some other bits -- are all old and/or superceded(!?). Pity -- they seemed the most interesting items on their site! ].  

But ash’s suggestion of tribiotics (answered  by someone at the Uni of Newcastle seems to be bearing fruit. And the various Texans (see attached video) I normally do business with are at least answering, but just waiting for Japan and Korea to get something off small-run production lines.

 I’ve also solved my problem with poor old Robo-11 tankbot. While I’ve been in contact with the makers about getting a couple of chips (they initially offered) their Singapore-based tech support have also stopped answering mails and it seems  I am on my own.

So I got me a chip datasheet and started hacking.

Initially the bot had responded to the Windows-based Interactive C and allowed "firmware downloading" (the mini-O/S needed to run C programs on the mc68hc11e) as well as "library downloads" (seems to be needed as well as the "firmware") and also individual program downloads.

But after the first re-charge of the NiCd’s the firmware apparently was corrupted. Don’t know how — maybe a spike during the recharging?

Regardless, the more I tried to fix the problem, the bigger it got. Intitially the download(s) failed at 30% completed (there’s a little progress bar, of course).

After I’d tried to fix it a few times we were down to 1% before failure. It’s at that time I contacted the maker. (This distributor, of course, was an un-named Canadian company with whom I’d fallen out :{ ).

Tech support had offered to send a couple of 6811’s, and indicated I could ship back the whole controller board at my expense and they might be able to fix it. I’d accepted the offer of the chips and gotten my plastic out in case it was needed.

But since then, nothing.

So — as I said — I ordered up the datasheet and a couple of those really big hammers from the Bunnings "you got a problem" dept. Designed by computers for computers, the old joke goes.

With a bit of fooling around, tricking the download program into thinking a laptop was the Robo-11 and adding in some s/w hacks to find out what was going on, seems the IC compiler monkeys around with the baud rate of the serial line during download. The 6811e would like downloads at some unusual rate (1762 baud?), but will accept 1200 baud provided you send a nice 0xff first so it can get the timing right.

Looking at what the download was doing, it seemed to whip the baudrate around between 9600 to 1200 to 9600 to 1200 for quite a while — even during the times it should just be doing the serial download.

So with a bit more jiggery-pokery I managed to pause the whole process just before the s/w was to send its initial 0xff and make sure the line was in the right state. There was a bit of a delay — maybe the 6811 didn’t like someone else on the wire — but after about 15-20 seconds the progress bar popped up and started to move and — wonder of wonders — passed 30% and, eventually, finished.

Maybe I can do it again, if the need arises.

Elsewhere, robo-doggy has been taught to sit down (easy) and get up again (harder) using the same old planner techniques I’ve described before.

The hang-up this time was the servos on the dog are not powerful enough to lift even the left hand side of the doggy off the ground. How can it possibly stand up?

Even my planner couldn’t sort out a way. But providence came to the rescue when a silly bit of coding saw a position code wrap around from -n to +m (I missed a non-ignorable conversion from int to char). The error caused doggie — under planner control — to stick its leg straight out backwards while laying on the ground. Surprisingly, even though it was sitting on it at the time, the body wobbled, the leg moved and the command succeeded.

The next command drew the leg up under the doggy, and the subsequent "straighten leg" managed to lift doggy off the ground. There’s a bit of mechanical advantage to dragging doggy’s knees along the ground and under its body this way.

A little hacking on the planner-generated C code to capitalise on the error (as well as fix the wrap-around for future use) and doggy was able to sit and stand up.

Little problems I’ve noted with doggy are the sometimes critical positioning needed for servos not to become stuck in the middle of a task. On the Joinmax bot I have, the controller apparently cuts out for unpredictable periods when it detects some kind of overload. After a cut-out, it can take from 10 seconds to serveral minutes to again respond to serial-line input.

If a joint is positioned just a few degrees from where it’s supposed to be — e.g. through typical compliance issues related to plastic joints as well as variations in servo positioning — a task can fail. And, as you probably know, the size of this error can be smaller than just the positioning slosh  of a servo.

The servos I’m using here can even vary by 5-10% from cmd to cmd, as I’ve found out.

So I’ve been tightening joints and trying to align servos between left & right a bit more accurately. But this is only a partial fix. It seems the planner is going to have to know that some plans are impractical if they require high degress of accuracy in positioning. And this is moving from the realm of simple planners to dijunctive planners — where the goal states are no longer single states-of-the-world but sets of states.

Or maybe just a planner that can use fuzzy min/max logic on some values. 

A disjunctive plan is still a sequence of operations, but each operation can take us from a single state to a set of states (i.e. that operator can have an unpredictable outcome indicated by a set of possibilities) or from a set of states to a singleton state (i.e. a given operation merges a number of possibilities into a single "possible world"), and many-to-many. 

For the physics-minded,  the state-of-the-world in disjunctive planning moves away from mapping between states to mapping between superpositions (more like "pure mixtures") of states.

But the plan must still ensure we reach the specified goal and only the goal  (i.e. if the plan ends up in a superposition that merely includes the goal, we’re not there yet — we’re usually looking for a singleton state that is the goal).

I have tools for disjunctive and/or fuzzy planning, but the downside is they don’t run fast.