A couple more splices; a couple more kits
A couple more kits arrived today. Apart from a feverish 30-40 mins of unpacking and trying to get the simpler one going out-of-the-box, they haven’t been evaluated yet.
One is a Talrik Jr Pro from Mekatronix (about $225 USD, and probably not recommended unless you’re in the ground between naive and a-little-bit-crazy).
The other is the simplest kit from Microbric I could find — the i-bot. This is the one I tried to get slapped together in 30 mins but failed.
Apart from that I’ve been experimenting more with the behaviour splicing, just to illustrate how it can be used.
4-wheeled robot. Take the description of a 2-wheeled robot and double it. You get a pretty reasonable (in my case) MBasic program for a 4w bot. E.g. 2w bumper-bot becomes 4w bumper bot.
Needed some tweeking to get the turning to work properly. No mechanical diff, so a couple of the motors needed to free-wheel at some time rather than drive at the same rate as the other motors.
"flip bot". I took the description of a 2-w bumpbot and added the condition it had to work upside-down as well. This is an example of meta-planning — where the compiler has to do some of the planning as well as the compiled program doing planning at runtime.
The solution the compiler found was to add a slide switch for the human to use.
I also noted the slide could be replaced with a line-follower to make the flip-bot work automatically; when inverted the line-flollower can only see "black" and causes the wheels to go the opposite way from when it can see "white" (i.e. the usual activity mat colour). In automatic mode you can add a few blocks and obstacles to the world and if the robot tries to climb and accidentally flips onto its back it just continues wandering in the original direction because it’s changed its sense of what is "clockwise" and "anticlockwise" when it comes to driving the wheel motors.
And, finally, a sumo-bot. The easiest way to describe this to my compiler was a bump-bot that executes a "scoop" whenever it detects a bump.
The hardware comes in an extension kit to the basic "Viper" from Microbric. It as a 3-port connection to the microprocessor — 2 of them "bumpers" and 1 a serial input to a medium-sized (but rather slow) servo.
A bump-bot normally detects a bump on its left and then backs up and twists right and then goes forward again.
The kind of sumobot I’m describing here does the same but FIRST twists sharply left, charges forward, and flips its scoop down and up. I.e. sumobot == bumpbot + scoop.
Anyway, 10 secs of descriptive programming, 1 sec of compiling, and about 20 sec of serial downloading and the sumobot program — about 200 lines of generated MBasic — was off and away and doing more-or-less what was expected of it.
Here’s a (belated) pix of Mr Sumo searching for a victim:

Hey Kym
Your compiler sounds really interesting. Is it already running as you described above?
How do you specify new conditions for the compiler to take into consideration? Are you using some sort of natural language processing?
It’s not really in a fit form for general use; it has to be targetted to the particular h/w, world semantics, and low-level actions (e.g. type out lines of MBasic).
It’s more akin to about a dozen small tools that can be daisy-chained once you have the targeting setup.
But I’ll give some intro to the syntax and setup on my blog today (no kits arrived so I have time
.
I hope to post the sources to a more usable system and some examples over the next few weeks.