I finally bit the bullet and stopped playing with "slider knob software" for my robot doggie project.

Up until now I’ve been using a simplified version of the provided Joinmax s/w that just allows you to built up scripts of servo controls. From the neat vids the company has on its website and other places, you can do a lot with just that. I haven’t looked for any ".rb" script files via Google, but it seems there are scripts to make the doggy walk, beg, and stand on its head (yes, literally!).

But I’m more interested in having s/w do all the hard work for me. At one time — when the powers-that-be entrusted the filling of young minds with useful info to me — I used to say "If you understand X then you can write a program to do X. And the obvious corollary".

So the question became — do I understand how a doggy walks?

I dusted off a few old planners written in Prolog, fixed up a few obvious bugs, and set to work.

If you recall the "programming with a planner"  process, briefly outlined here-abouts (and here’s a nice intro to the whole area), the first step it to make a model of the world. The second is to introduce a set of operators to be used in making plans, and then have a start state and goal the planner is to find a sequence of operations to reach.

Planners come in various guises — "non-linear" and "disjunctive" as 2 examples — but let’s KISS.

My world model was simply a square platform with 4 x 3 df legs at each corner. Various simplifying assumptions were made about the servos in the joints, and the alignment of all limbs and servos was presumed to be absolutely accurate. (This assumption was obviously going to lead to problems when we started to operate the robo-doggy in real time).

The set of operators were all pretty obvious — lift leg (i.e. the lateral motion at the shoulder), rotate shoulder, bend knee. I also threw in a couple of dual operators that allowed 2 servos on "related" legs to move at the same time. E.g. bend knee on 2 diagonally-opposed legs.

Gravity was set at "1" unit, and since I wasn’t too interested in handling the kinematics at this point, I assumed all operations were given sufficiently long to complete that the final, resting, position of the doggy was all that was important. 

The start state had the virtual robo doggy simply standing up straight. How it got into that position was a problem-solving task for another day.

The goal state was the doggy standing up straight, but moved foward by any positive amount.

The planner started to whirrr on a 6 GHz Duo. After about 30 minutes I went to bed.

In the morning it had come up with about 100 sequences that allegedly achieved the goal.

At this stage the plans looked just like Prolog lists — i.e. "[shoulder(0,10),knee(0,10),shoulder(1,-10),...]", etc.

But Prolog is a bit of a master at symbolic procesing, so it took about 5 minutes to have a program turn the list of operators into C code.

Some low-level C code had to be written by hand, of course. In the case of the Joinmax doggy the ultimate command is simply a sequence of 3 bytes sent out on a 9600 baud serial line.

I even managed to make the code do a bit of scheduling. While nowhere near the kind of thing you do with Gantt charts, the "mini-compiler" spotted instances where servo A might be able to move at the same time as B and then sent out both commands and put a "wait" (i.e. a usleep in C/Linux terms) after the pair of commands.  This can get complicated because some of the operators are, themselves, parallel commands that operator 2 servos at once.

The first couple of runs with the first generated program (I’ve been through only 4 or the 100 of them so far) were disappointing. The doggy just seemed to thrash around, shuffling its feet in random order, and not making any visible progress in the foward direction.

After a bit of inspection, and with some suspicions in the back of my mind from the outset, I found one of the basic problems. The legs on the robot were mis-aligned.

As I mentioned some time back, this kit bothered to issue left feet and right feet (i.e. facing the opposite way), but has 4 shoulders all the same. So one pair of legs points forward and the other pair point backward when the shoulder servos are all at "0" (and have been carefully aligned during construction).

Another little problem that I was a bit surprised I hadn’t spotted before – the  controls for 1 pair of motors were in the opposite sense of all the others. Maybe I have the connections internally around the wrong way — the 16 control points on the microcontroller were labelled with each joint they were supposed to serve; maybe I got it wrong.

But I kinda suspect this is something you were meant to handle yourself, and the controller actually doesn’t do anything special to handle the mirror-imaging problem of the servo orientation.  It certainly does nothing to handle the limited motion of the neck or tail servos. You can easily bust a servo if you don’t limit the positions, there.

Basic problems sorted out (i.e. by unscrewing legs and putting a bit of a bias on their orientation), doggy started to painfully drag itself forward. It was making progress, but at the expense of an awful lot of wasted energy due to friction.

There was  another problem — occassionally the dog over-balanced backward and sat down on its bum, and the servos didn’t seem to be powerful enough to make it get up.

This is the kind of thing motion planning is meant to overcome, of course. You sometime have to go in a non-obvious way to get to the goal you can’t reach directly because you’re not strong enough.

I also looked at the relevant plan, and spotted an assumption that maybe wasn’t true. The plan was essentially leaning forward and then trying to move each foot. But due to the compliance in the joints some feet were a lot easier to lift and move than others.

I hacked the plan to fix this — all that was needed was to comment out a couple of operations and allow gravity to do compensating work.

Net result — doggy now scampers across the floor at a fairly high rate of knots. Initially the "waits" inserted by my s/w were hard-wired at 100 ms. This turned out to be WAY too long and 20 ms or more was sufficient. (Less than 20 ms and robo-doggy just does a very high-speed foot-shuffle because many servos don’t have enough time to move to the commanded positions).

There still seems to be a problem with doggy turning in a large left-handed circle, but I presume this is due to one or more servos on the lhs being "weaker" than those on the right.

The maker of the Vigor servos I’m using says variation between servos can be +-10% in both torque and positioning angle.

So I’m going to have to make a little low-level tweek in the C code to take that into account. It won’t be as good as having real feedback about the direction (although I’m talking to Inex and they have a neat "compass module" that may come in handy , but scuttling in a more-or-less straight line will have to do for now.

I’d really like to post some videos. But (as I mentioned) the camera I ended up getting to replace one that’s been doing sentry duty at the front door for several years — well, it turned out not to be compatible with Linux. They said "various Logitech QuickCams" were supported; but just not the one I bought.

I’ll either have to get a wintoxbox-powered laptop or get a new camera. (I now have a list of the actual cameras supported in the o/s drivers).

So no pix until at least next wk.

But he is just soooo cute.

Here are a few company pix, anyway:

Roll over 

Hand stand

Gymnastics