Subject:
|
re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 13 Aug 2002 03:39:32 GMT
|
Viewed:
|
764 times
|
| |
|
|
Thanks Stef Mientki for pointing me to this great thread you guys
have going.
People may wish to take a look at the Cricket work I've been doing
the last five years. The Cricket system a modular brain &
sensors & actuators construction kit along the lines of what people
are proposing here. It began as a research project at the MIT
Media Lab in 1996, and is available now as a commercial product,
the Handy Cricket (see http://handyboard.com/cricket/). (You can
order a Handy Cricket today and have it in a few days.)
The starting point for our Cricket work was to get away from the
well-known "put every circuit you can possibly imagine ever needing
into one brick" problem. We had done a series of programmable
bricks (the "Logo Brick" in 1987, the "gray brick" in 1992, the
"Model 100" Brick in 1994, and the "red brick" in 1996) and we
always had arguments like * --
Bill: It needs at least four motor outputs.
Bob: No, two are enough.
Bill: The batteries should be built in.
Bob: Can you add a voice-recorder circuit? I'd really like that.
(* names have been changed to protect the innocent.)
Not only did the arguments take time, but then it took a long time
to design the mega-brick that would make everyone happy.
So our launching point for the Cricket was to separate the brain
from the sensor and actuator circuitry. And more specifically, to
bundle the requisite hardware AND SOFTWARE drivers with each sensor
or actuator device. Then the brain could communicate with any
sensor/actuator, even ones we hadn't thought of yet, because they'd
be having a high level conversation. E.g., the brain could say,
"hey you stepper motor, take a step" without knowing or caring how
the stepper motor went about doing that.
Of course, to implement this, we used a bus system. As people have
explored in this thread, the next questions are:
* how many wires does it have?
* is power carried over the bus?
* what kind of connector is used?
* do you wire devices together or stack them?
* what signal format should be used?
* what kind of protocol? master-slave? multi-master? can sensors
generate interrupts?
We made some initial decisions to get started that have held up
pretty well. Our design philosophy was to build something simple
and get it working, and then only make it more complex if we really
had to. So that led to a system that may be susceptible to the
criticism "not powerful enough." But if you use it, you might be
surprised at how useful it is.
Here's how the Cricket Bus answers the design choices.
The big question first -- protocol. We decided on a strict
single-master, multiple slave system. The Cricket is the master;
there can be only one master on the bus. The master individually
addresses the slaves, asking them one at a time for their values or
telling them one at a time what to do. Slaves cannot talk to each
other. Slaves cannot generate interrupts ("speak if not spoken
to"). If the master needs to know when a slave has changed state,
it must poll.
At first glance, this might seem terribly limiting. But, when
you've got a bunch of devices all tied together, and it actually
works as advertised, it's pretty liberating. You can mix and match
devices at will. Yes, you are limited to a single thread of
control on your one master, but, one thread goes a long way.
Also, you can play tricks to compensate for the lack of sensor
interrupts. For example, suppose you're designing a sound sensor
to tell when it hears a clap. If you design it so the master must
ask "do you hear a clap now?," it obviously won't work. The clap
is so short, it won't be happening when you ask.
So you need the sensor to cache the clap. Then, the master's
protocol with the slave is a question like, "did you hear a clap
since the last time I asked you?" or "how many claps since I last
asked?". Then, if the master is polling, it'll learn of the clap
pretty near to when it happened; or, if it's been a while, it'll
get a clap count, which is probably useful.
Here's the next answer -- what kind of signal format to use. The
usual suspects would be RS-232 or i2c. Both have limitations. As
observed in this thread, RS-232 is slow if you want to be able to
use chips without a built-in UART. It's hard to implement i2c
receiver code, and you can't really be dealing with while doing
purposeful work unless you've also get dedicated hardware.
We wanted to be able to use cheap, bottom of the line PIC chips for
our sensor and actuator devices, so something had to give.
We came up with what I think is a fairly clever solution: our own
async signal format. It looks a lot like fast, 10-usec-per-bit
serial, but with a long, 100-usec "prestart" pulse. The slave
device now has two choices for how to implement its control loop:
a) if it doesn't mind a 200 usec interruption when a bus word comes
in [100 usec prestart + 10 usec x 10 data bits (1 start + 8 data +
1 stop)], it can receive the bus word using an interrupt routine.
The 100 usec prestart pulse is way long enough for the interrupt
routine to take over and get ready to receive the blast of actual
data.
b) or, you can build your program so that interrupts never take
longer than 100 usec to execute, and then receive the bus word in
the main execution flow. If you get interrupted just as the
prestart pulse come in, that's ok, because you'll be back in time
to read in the data word before the prestart pulse ends!
With this solution, we get an effective baud rate of 50k without
any special hardware. Pretty cool!
Next choice, how to connect devices. We went with separate boards
cabled together, rather than stacking. Seemed more flexible.
What kind of connector? We started with 0.1" male header, but that
got annoying, so now we're using Hirose DF3 connectors, available
from Digi-Key. These are small, polarized PCB mount jacks (very
cheap, but robust) that accept crimped wires inserted into a
plastic plug. The extra-cool thing is that Digi-Key will sell you
wires with the connector pin *already crimped*. This is a huge
win; you just insert the crimped wires into the plug, they lock
into place, and you have a ready-to-use connector.
Related to the connector question, we imposed the rule that each
slave board must provide a jack that lets you plug in the next
one. Then the brain only needs one jack. You plug a slave into
it. The slave gives you a jack for the next slave. And so on.
(We actually have the brain two jacks, for good measure.)
Is power carried over the bus? We decided a resounding Yes. Many
sensor devices don't take much power, so they shouldn't need
batteries. The research version of the Cricket done at MIT
provides a 9v power line, so each slave needs its own +5v
regulator. The commercial Handy Cricket includes two power lines,
one regulated and one not, so slaves don't need their own
regulator. Power-hungry actuators, like the servo motor control,
do provide their own source of power.
Then the signals on the bus are: (MIT Cricket) ground, unreg 9v,
bus signal; (Handy Cricket) ground, unreg 6v, reg 5v, bus signal.
About the brain. My close collaborator on the design of the
Cricket system, Brian Silverman, always argued for a pure brain --
that is, a brain that has no motor drivers or sensor inputs of its
own. But we never built one. Our basic brain (the Cricket itself)
still gives you two motors and two sensors. It just seems useful
to have that little bit of capability when you first get started.
It's hard to imagine that we would have thought a 2-in/2-out device
to be adequate. At first, I consoled myself with the observation
that if you didn't want to use a Cricket, you could use a
Programmable Brick! But now with the bus devices that are
available, this doesn't seem like much of a limitation at all.
OK, where are the limitations? Clearly, the biggest is that there
can only be one brain. It's fantastic to be able to add new
peripherals and even new *types* of peripherals just by plugging
them in, but it would be even better to be able to add computation
just as easily.
The speed of the bus actually isn't a problem, because the brain we
are using (the Cricket, that is) is relatively slow. Plus, a lot
of the high speed stuff can be handled locally at the bus device.
So the next generation of the Cricket system may go with i2c (no
need to invent my own multi-master bus when there's one in use that
does all the right things)!
But I'd like to close by noting one property of the Cricket system
that often gets lost in these kinds of conversations.
It's incredibly easy to create a new bus device.
The code to do bus send and bus receive is about 20 lines of PIC
assembly for each [see references at end of this message]. So it's
pretty trivial to get a PIC up and running and talking to the
Cricket. Then you're left with implementing the real work of your
device, which is either hard or easy depending on what you're
doing. But getting the Cricket to talk to it isn't a problem.
So while the Cricket system won't win design awards for raw power,
it might stand to be nominated for usefulness and adaptability!
regards to all,
Fred
references:
Handy Cricket http://handyboard.com/cricket/
MIT Cricket http://lcs.www.media.mit.edu/people/fredm/projects/cricket/
http://cricket.media.mit.edu/
Position paper on the Cricket system
http://www.research.ibm.com/journal/sj/393/part2/martin.html
Build your own bus device http://handyboard.com/cricket/tech/bus.shtml
Buy a Handy Cricket http://gleasonresearch.com/
|
|
Message has 3 Replies:
 | | Re: Brainstorms
|
| (...) Yep - we agree on that goal. (...) I agree that this is a nice goal - but it conflicts with another goal I have - which is to keep the physical dimensions of these devices *tiny*. Lego is a very small scale to build on compared to most robotic (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
| | | RE: Brainstorms
|
| <snipped Fred's excellent Cricket description> (...) Again, I need to go back to my real-world fire alarm experience and say that this makes very good sense. Nobody gives much thought to the alarm systems in their building. They must meet very tough (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
| | | Re: Brainstorms
|
| (...) I will contrast the decisions made by the Cricket team with the decisions made by the RoboBrick team. For reference purposes the RoboBrick home page is at: (URL) reasons for avoid centralized solution] (...) The RoboBrick team also asked (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
