making and selling robots

[Admin]

This email was posted to the Seattle Robotics group email list, and after speaking with Peter he gave me permission to post his email here.

The jist of the email talks about various issues you would expect to come up as you develop education robots to sell. I figure it can teach a few lessons for any of us planning to make and sell robots in the future . . .

The email,

> Cesar wrote
> Thanx Peter, for that link. I've seen those robots, I
> just didn't know the names. They look like fun robots.

They're advertised in quite a lot of the e-shops. I don't know how many are
being sold though - I only get royalties at the end of each year. I suspect
it's not as many as I would like and certainly not enough to pay for the
development time.

Yes, they _ought_ to be fun robots. I designed them for children, newbies
and people who buy things in "gadget shops" and throw them away after a
month. They have a very simple programming language that (I hope) anyone
can use immediately just by clicking buttons but that allows full use of
the various sensors. They're designed to use very few, very cheap
components and they're produced at very reasonable prices in China.

So they ought to be half the price of any other robot you can buy. Why then
are they so overpriced? I could rant for hours about the iniquities of
retailers.

Am I advertising here? Not really. I'm saying I don't think they're good
value for money. Buy some components and built your own from scratch. Maybe
the same gripe applies to any other robot you can buy.

The only retailer who has understood the philosophy is Rapid who sell
Brainibots for about £6.75 ($13) if you buy an "educational pack" of 20.
They're used by educators who run "introduction to electronics/robotics"
aftenoons and the like. $13 is an excellent price. But you try buying a
Brainibot from any other retailer for less than $45.

Someone is making money but it's not me. And don't get me started on the
bully-boy tactics of the chain stores ...

What I have enjoyed is trying to understand what makes a good small robot
programming language. It's a deceptively difficult problem. You have a
robot with some subset of: two or three motors, antennae, one or two IR
obstacles detectors, one or two light-level sensors, a speaker, a line
follower, a microphone and a time-out timer. The processor has just 128
byes EEPROM to hold the user's program. What's the best programming
language? It sure isn't Basic or C.

My "target" program is something like: head towards light; if you detect an
obstacle, reverse away from it; if, after 1 min, the light is no brighter,
reverse away and spin around looking for the brightest light then start
again. Or: follow the wall on the left until you meet a wall in front; then
turn 90deg right and head towards the light until you hear a loud noise
then stop.

That's the sort of complexity of program that schoolchildren can attempt.
But in 128 bytes of user memory?

What should the instruction word size be? For the Programmable Brainibot, I
chose 4-bits (two instructions per byte but some instructions are 8-bit).
For the other robots, it's 5-bits (three instructions per two bytes).

What control structures should it have? Each robot has turned out different
as my ideas have changed. The Brainibot uses a traditional block-structured
language with If-Then-Else, While, For and Begin-End but no variables. But
I found it was hard to write useful programs in the limited user-memory -
you need too many if-sensor-then blocks. The Picobotz and Quadrabotz have
if/while/for/repeat plus procedures and "Events". Events are like
interrupts. Each Event has a "guard" condition that triggers it. I think
that's how the original Mindstorm "stacks" worked. You need a lot fewer
if-then's because you know that the bot will respond instantly to sensor
input.

The Quadrabotz is the only robot to have variables. It has a traditional
stack-based instruction set compiled from a language close to Basic.
Although that makes the language more "powerful" it takes more instructions
to do anything so you can get less into the 128 bytes. It's those sorts of
trade-offs that make this an interesting problem.

I'm now re-designing the Brainibot (because the CdS cell is not RoHS
compliant; it will have IR obstable sensors not antennae but should still
cost the same). I've got a new language that I'm very pleased with. It has
no traditional control structures: no if, while, for, gosub, variables,
etc. It only has Events and "Behaviours": a Behaviour is a completely
separate program that you can swap to. (As you can imagine, it's inspired
by subsumption.) At first sight, it seems odd to program using only
"interrupts" but it works really well. Even complicated programs are small
- I've not yet used more than 25% of my "user memory" and the robot
responds much more quickly.

As I say, it's a deceptively difficult problem. I've not seen any
literature on it and I haven't found anyone who is working on it. Does
anyone know of anything? If anyone wants to try designing their own
language, just choose an instruction set (what's the optimum mix?) and
start writing programs. How complicated a program can you fit in 128 bytes?

> If I remember right, I saw a walking robot liket that,
> but much larger, made of PVC pipe.

Great. Do you have a link.

Peter

[Admin]

Oh, and the more technical continuation email, describing details:

> What processor are you using now, if you don't mind me being nosy?

For the Picobotz and Quadrabotz, the PIC16F627. I find that it has the
mixture of features that I need and is pretty cheap. I could go to the
PIC16F628 if I needed more code space but that's not been neccessary so
far. I don't need an 8-bit ADC - the 4-bit one in the PIC16F627 is fine for
measuring the motor current in the Quadrabotz. For measuring light-level,
I've found that a linear ADC can't give good resolution over the whole
light range of a typical room; you really need a logarithmic response. So I
use the discharge time of a cap and then do a log/lin conversion.

The original Brainibot uses a 12C508 or 12C509. That was the cheapest chip
available at the time (8-pin flash PICs weren't around). It has the huge
disadvantage of no EEPROM which means that the user's program is held in
RAM and is cleared when the PIC is turned off. Yuk. The new Brainibot uses
a 12F629 which has 128 bytes of EEPROM for the user's program.

Using 8-pin PICs is an enjoyable challenge. The new Brainibot uses just 5
I/O pins to control two light-level sensors, two IR obstacle detectors, a
beeper, serial comms to a PC and the the H-bridges for 2 motors. That's a
lot of multiplexing. It left an extra input pin so I have it as an
"external" input for the customer to add their own sensor.

I've designed robots with bigger chips but never persauded anyone to
produce them. Cost is everything. The new Brainibot's electronics and pcb
cost around £3.50 in 100off. Presumably in China, they'd be half that.

So far, the limit of 1024 instructions hasn't been a problem. The original
Brainibot was a bit of a squeeze but it has both comms from the PC (but not
to it) and a built-in editor so you can "type" your program in via the
antennae. The other robots can only be programmed from a PC so their code
is smaller.

A larger EEPROM would be nice but I don't want the extra cost of an
external chip. With a good interpreted language you can do a fair amount
with 128 bytes.

Comms with a PC can be tricky. To reduce costs, I always use the PIC's
internal oscillator but, in theory, it isn't quite good enough for reliable
comms. RS232 requires the clock to be accurate to about 5%. But a PIC's
internal oscillator can only manage 9%. So I use a system of long and short
pulses: the PC sends $80, $F0 or $FE via RS232 to send "Start", "1" and "0"
bits. Self-clocking codes like that are more tolerant of noise and
clock-frequency mismatches. But maybe it's not necessary. The Picobotz uses
straight RS232 and no-one has ever returned a Picobotz because the comms
doesn't work. Maybe Microchip's worst-case figures are unduly pessimistic.

In future, I might look at using the 16C745 USB PIC. Adding USB is a "big"
expense in terms of the socket, cable, etc. but serial ports are bcoming
more scarce. I'll also have to learn how to do USB comms ports. I don't
want the cost of a separate USB-serial convertor chip, especally as a PIC
can already do it. I've already done USB-keyboard on a 16C745 but
USB-keyboard has the advantage that the drivers are already built into XP.

I don't understand the driver situation for USB comms ports. Is the driver
already in XP? Or do I have to write a PC driver? I think it's built-in:
serial comms, like HID, uses a standard protocol. But, if it's built-in,
why do USB-serial convertors come with a CD? Does XP just need an INF file
to describe the connection? Does anyone here know? Has anyone here done a
USB comms port on a 16C745?

Peter

[Dosbomber]

> If I remember right, I saw a walking robot liket that,
> but much larger, made of PVC pipe.

That's pretty funny, I just built a testbed robot out of PVC tubing recently.  It isn't a walker, more like a box with plenty of room for expansion and retooling with various drive systems, sensor arrays, and accessories.