A man's reach should exceed his grasp, else what's a heaven for?

The Byron quote is probably great advice for aviators, but not so good for Lego Mindstorms builders. My job is quite variable: occasionally I have time to set aside, then suddenly I'll find there's no time for anything except eating and sleeping. Even when I was at school and college it was like this, so it must be even harder for the generations that have followed.

This is why regular readers will have noticed that two proejcts, Sugar and Turin, have been relegated from the front page - I just have to accept that I'm never going to finish them. For the record, washing my linen in public, here's as far as I got with the write-ups.

• Sugar was better engineered than QuAD, but shorter lived. I think I may be getting better: I'm certainly using fewer and fewer pieces!
• Turin is based on a concept someone else pointed out to me. It's very much work in progress.

Instead, I've decided to revisit the Ria concept in the light of ideas from Joe Nagata's book and from designing a model railway concept I based on Ria. First, though, I need to take a step back. QuAD and Ria were "successful" projects by my standards. Sugar and Turin "failed" Why?

Partly, it has to do with the length of development time I had. Turin was a neat concept, but by the time I'd solved the problem of getting it to plant both yellow and black blocks, I'd simply run out of my slack work period. Working and travelling dominated my time. I collaborated on a line following program because I could program on my laptop on the train, but it's not possible to take the entire kit into work and use it at lunchtimes, so in terms of construction my reach had exceeded my grasp.

The other half, though, is the problem of co-ordinating a grab with forward and backward motion. Ria worked well because it used the light sensor for positioning. Block sorting problems really need a light sensor to differentiate between various colours. I tried to make a monorail that stopped when it ran over a peg (some real automatic monorails do this, allowing an operator to stick a peg in the track when they want the wagon to tip) but again, the construction problems exceeded the time available.

Sugar's touch sensor, however, was fine for the 'is there a ball there?' test - just as good as the light sensor on QuAD, in fact. So, why not do the standard AI software developer's trick. I can't solve the block-sorting problem on a monobeam, so let's constrain it to be a problem I can solve. Arrange a light sensor to detect several stopping points for a monobeam, use a touch sensor to detect whether there's a block present, and if so, take a dependent action. It's an operating idea I had for a model railway some time ago - I just haven't got anywhere near finishing that yet.

I can use that to model the action of a lime-kiln, for example. For every load in from 'a' (chalk), go fetch two loads in from 'b' (coke). When no more loads in 'a', fetch loads from 'c' (processed lime). Now move all loads from 'd' (waste) to the dump. Begin again. Hardware development involves rebuilding Ria using the lessons I've learned and adding a simple scoop that will load a block onto the back or sweep it off. I just need one motor for that, and it doesn't need much co-ordination.

The programming will be the hard part. And that's what I can do while I'm travelling. First, as with the line follower, make it work efficiently. Then the hard part - trying to reduce the overall number of trips. If you think that's easy, think again.