You’re right, hightechburrito, for any serious project, particularly one that will be assembled permanently for a specific purpose, there are much better, simpler, faster solutions, but for me, the hobbyist who doesn’t want to spend hours and hours designing, the OOPIC is hard to beat. The one I’ve got has the B.1.0 firmware (the middle version) - it has the oServoX object and can control a dozen servos and has the Sonar stuff (in fact the bundle I picked up on eBay included a couple of SRF04 sonar modules). I’m thinking about upgrading the chip to the latest version; it seems to be a fairly cheap thing to do.
The walking robot uses a modified alternate tripod gait, i.e.
-Lift & step leg R1 fully forward
<wait a moment>
-Lift & step leg L2 fully forward
<wait a moment>
-Lift & step leg R3 fully forward
<wait a moment>
Pull all legs back half of their travel (pushing the robot forward)
<wait a moment>
-Lift & step leg L1 fully forward
<wait a moment>
-Lift & step leg R2 fully forward
<wait a moment>
-Lift & step leg L3 fully forward
<wait a moment>
Pull all legs back half of their travel (pushing the robot forward)
<wait a moment>
Repeat
So at any one point, no more than one leg is off the ground
The bottom servo raises and lowers the leg in an arc that is near as dammit straight up and down, the top servo tilts the leg forward or back, swiveling the joint where the bottom servo attaches - it isn’t a bad system, all in all - other possibilities I considered include:
Making an up-down assembly, then rotating the whole assembly, servo and all with another servo (rejected due to the complexity of engineering)
Moving the leg back and forth with the bottom servo and up and down with the top one (rejected mainly because this makes it harder to actually mount the servos, possibly including extra hardware, which means more weight).
Most of the instability comes from the simple flexibility of the K’Nex components and the play at the joints.
I’m pretty sure I can overcome some of this by tweaking the gait and stance- initially, I was trying to keep all the legs as near vertical as possible, but I’m staring to see that it might help to keep the front and back ones reaching outwards a bit (most of the instability was dipping and lurching at the ends). However, the weight of the battery pack is a problem - at the moment, all 12 servos (not all of them active at any one time, of course) are powered from just 4 alkaline AAs - it may be that they simply aren’t man enough to supply the current to allow this many servos to develop their proper torque.
I’ll most likely take a short break from the walking machine as I’ve been working on another one at the same time; I put it all together in a couple of hours this evening - here’s (sorry, another crappy photo) what it looks like so far - it’s made from a couple of servos, hacked for continuous rotation, sandwiched between those clear blanks you get at either end of a spindle of CDRs - it seems to work really nicely as a basic turtle - I haven’t added any sensors or adaptive programming yet, but there’s plenty of scope (I might sandwich on a couple more discs as building platforms, the hole through the middle is just perfect for routing all the cables).
I want to make this one kid-friendly for programming (just as a turtle, perhaps with a pen for drawing on the floor) - there won’t be room for a keypad and display on it, so I’m toying with the idea of using an infared remote control - I have a little receiver board that I hacked out of a bit of surplus equipment and I managed to interface it to my controller last night (using an asynchronous buffered serial input) and I’m definitely receiving a stream of digital pulses when I point my TV remote at it. I haven’t worked out how to decode it yet though - I suspect it might not be easy (if possible at all) with the OOPIC without dedicating all of the processor cycles to the task, but until I get myself an LCD display module, it’s hard to monitor exactly what the OOPIC is seeing.