Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 13 Aug 2002 17:18:27 GMT
|
Viewed:
|
540 times
|
| |
|
|
> In lugnet.robotics, Fred G. Martin writes:
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:
http://web.gramlich.net/projects/robobricks/index.html
[snip reasons for avoid centralized solution]
> 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?
The RoboBrick team also asked similar questions.
> 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.
This is the RoboBricks strategy as well. Indeed, our first designs
were too complicated and we simplified over time.
> 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.
The RoboBrick team made the same decision.
> 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.
Agreed. In addition, it simplifies the programming in the
master, since the slaves are dealing the the difficult hard
real time stuff (e.g. getting a servo pulse out every 20mS.)
> 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.
The RoboBrick team ultimately added in an interrupt facility
because there are some things that you can not compensate for.
For example when the bump sensor is triggered, it is real
important for the master to get a command off to the motor
controller to get the robot stopped.
> 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!
The RoboBrick team went with a somewhat different set of design
choices here.
We, too, wanted to use bottom of the line PIC chips to keep
costs down. Since many of the people on the list may not be
familiar with current PIC prices, I'll list a few PIC parts
that we typically use, along with some of their more relevant
features and prices. The prices are from DigiKey in tubes of 25.
Part Pins ROM RAM IO A/D UART I2C Cost (25)
====================================================
'509 8 1K 41 6 0 0 0 $1.01
'505 14 1K 72 12 0 0 0 $1.26
'672 8 2K 128 6 4 0 0 $1.94
'F84 18 1K 68 13 0 0 0 $3.94
'F628 18 2K 224 16 0 1 0 $2.21
'F876 28 8K 368 22 5 1 1 $5.49
Please note that the `F628 and the `F876 are both relatively
new parts that were not available at the beginning of the
RoboBricks project. Not that I2C devices from MicroChip
typically cost 5 to 8 times more than their low end
chips and come in fairly large packages as well. The
price of the 'F84 seems to be going up because Microchip
is trying to nudge its customer base over to the less
expensive and more powerful 'F628 which is basically
pin compatible with the 'F84.
Our conclusion was that we wanted to use standard protocols
so that we could ride Moore's law curve as hardware prices
came down. We ultimately decided to go with standard
8N1 serial protocol initially at 2400 baud. The discussion
about how the RoboBrick team selected 2400 baud is found
in a different message that I will list here:
http://news.lugnet.com/robotics/?n=18650
The problem that ensues is how to allow changes in baud
rate as devices with built in UART's come down in price?
We ultimately decided on a hub and spoke architecture
where the master could talk to each slave individually.
This both solves a bunch of problems and solves a bunch
of them at the same time.
1. Since each slave has dedicated wires running to the
master, we can talk to each slave at the fastest
baud rate they can mutually agree on. Everything
starts at 2400 baud and if the master and the slave
can agree to a faster speed, they can do so. For
example, the `F628 can easily go up to 250k baud.
2. The architecture supports simultaneous communication
with each slave. While we have not used this feature
yet, it goes a long way toward answering the questions
of bandwidth availability.
3. A disadvantage is that the master board has to have
a connector for each slave irrespective of whether
there is a slave plugged into it. Our solution was
to use inexpensive connectors that use relatively
little board space. Our thoughts were that the
master would eventually run out of cycles to talk
to an arbitrary number of slaves, so it was unlikely
that most robot designs would find this to be a
serious limitation. Our master boards have between
8 and 16 ports each. One of our boards, the
PIC876Hub8, was specifically designed so that it
could be easily used as a hub expander to deal with
situations where a robot needs to talk with more
slaves that plug directly into the board.
> Next choice, how to connect devices. We went with separate boards
> cabled together, rather than stacking. Seemed more flexible.
Agreed.
> What kind of connector? We started with 0.1" male header, but that
> got annoying,...
RoboBricks uses 0.1" male headers and they are quite annoying.
Their advantage is that they are quite cheap and will *never*
go out of production. We added a polarizing pin so that people
could not plug them in backward.
> ... 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.
We need to look into the DF3.
> 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.
The RoboBrick team made similar decisions. We did not put
an unregulated power source on the bus. Sometimes we wish
that we did, but some of the devices we have are such power
hogs (i.e. the sonar module) that we have concluded that
they still needed their own power connectors. We have
1) ground, 2) regulated 5v, 3) serial up, and 4) serial down.
> 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.
RoboBricks have gone for the pure brain approach. We are
also processor neutral. We have Basic Stamp 2 master,
a PIC16F876 master, and an OOPIC master. We wanted to be
able to ride the Moore's law curve as new processors came
available. One of these days, we will get a Palm Pilot
master going as well.
> 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.
In RoboBricks, the system can be connected in a hierarchical
fashion. The PIC876Hub10 module is specifically designed
to be usable as both a master and a slave. It uses one
connector to talk to its master and uses the remaining ports
to talk to its slaves. Thus, there is no single master
limitation.
In addition, the PIC876Hub10 can talk both I2C and SPI in
hardware. Thus, there is no real restriction that the
RoboBrick bus be used through out the entire robot.
> 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.
The code for bit banging in a PIC is about 20 lines each for send
and receive. If you use a hardware UART, it is even simpler.
Thus, someone who wishes to develop a new RoboBrick has a range
of implementation choices.
> So while the Cricket system won't win design awards for raw power,
> it might stand to be nominated for usefulness and adaptability!
Thank you for taking the time to explain the Cricket system.
The last time I looked at it, I had not realized that a
bus system had been added.
-Wayne
|
|
Message is in Reply To:
 | | re: Brainstorms
|
| 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 (...) (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
|
|
|
|
