Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 13 Aug 2002 05:55:34 GMT
|
Original-From:
|
Steve Baker <(sjbaker1@airmail)saynotospam(.net)>
|
Reply-To:
|
(sjbaker1@airmail)spamless(.net)
|
Viewed:
|
771 times
|
| |
|
|
Fred G. Martin wrote:
> So our launching point for the Cricket was to separate the brain from
> the sensor and actuator circuitry.
Yep - we agree on that goal.
> 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.
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 systems,
the motors aren't hugely powerful and the mechanical system isn't great
at building large scale, strong structures.
The RCX hardware is really *way* too big for lots of things people would
like to use it for (railroad locomotives for example) - and I tend to find
that it dominates the weight and size of every robot I build.
I'd like the electronics to be orders of magnitude lighter and smaller
if at all possible.
In I2C, most functions (eg sensors, motor controllers) could be shrunk
down into a single 8 or 16 pin chip with no other stuff on the board
*at*all*.
As soon as you put demands of autonomy onto every device, you mandate
that it has either:
* A custom or semi-custom chip. (Which is probably beyond the
realms of the possible here).
...or...
* An I2C CPU, and an I2C EEPROM and the actual peripheral chip.
...or...
* A large CPU chip of the kind we see in RCX with integrated ROM, RAM, etc.
None of those seems like it's going to fit into a 2x4 Lego brick - but a
single dumb I2C peripheral chip would. I think that's a benefit worth
losing some flexibility over.
After all, we can make all the software for all possible devices be
OpenSourced - and the EEPROM's can be reprogrammed from the I2C bus,
and hence from your PC. It would be possible to do something like:
* Build your robot.
* Connect it up to your PC.
* Under PC control, it does a bus scan and figures out what kinds
of chips are in the robot.
* The PC downloads whatever drivers it needs and builds an EEPROM image
that contains all the drivers you'll need.
...this can *appear* to be as flexible as the Cricket method - but it's
considerably cheaper and more compact.
Admittedly we'll consume more bus bandwidth than Cricket because every
little low level event has to be reported back from the peripheral - but
I2C has interrupts and MUCH more bandwidth than Cricket - so this may not
be so big a loss.
I like things to report under interrupt - polling is wasteful and can be
hard to get going if you have something with gazillions of bump sensors or
something.
So, I understand the Cricket's approach - but I think we have slightly
different needs - and can do a better job of meeting them.
> 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.
...unless your microprocessor is itself an I2C device - in which case the
I2C stuff is all in dedicated hardware - so it's cheap and easy.
> 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.
It's hard to imagine anything cheaper than the I2C microprocessor I
mentioned the other day.
> Next choice, how to connect devices.
This seems to be the hardest decision.
> We went with separate boards
> cabled together, rather than stacking. Seemed more flexible.
I agree - also, it's going to be hard to replicate the Lego interconnect
system that works through the studs of the device - and we need studs to
do the interconnect if we want to physically mount onto Lego robots.
> 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.
That's interesting.
> 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.)
Yes - I think we need that too.
> 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.
Also interesting.
> 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.
That's what I'd like to do too. It makes it cheaper and more universal.
With I2C, we aren't restricted to a single 'brain' - and I could see serious
commercial advantages to having the 'ROM' in a separate brick from the
rest of the system. One could make strictly 'toy' systems where all the
behaviour was baked into a ROM that came with the set - then toss that ROM
and replace it with a 'programming environment' for writing your own programs.
Minimising the amount of useless junk you end up with when people 'grow out'
of their toy Lego seems like a good idea.
> It's hard to imagine that we would have thought a 2-in/2-out device to
> be adequate.
...or a 3-in/3-out that we are limited by in the RCX.
> OK, where are the limitations? Clearly, the biggest is that there can
> only be one brain.
It seems that I2C can destroy that limitation.
> 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.
Yes - but I don't see why the modularity cannot be made to happen as you
build your executable - providing the "compiler" and "linker" that run on
the PC are in contact with the robot's "brain" and can automatically determine
the hardware setup as it downloads the executable into the EEPROM.
> 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.
Well, as I explained, I don't think that's such a good decision for a Lego
environment. We'd have dumber peripherals - and hence consume more bandwidth.
With multiple CPU's we can have as much CPU power as we want...so, again, having
more bandwidth would be useful.
> 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)!
So can we talk about collaboration? I just want to see this idea happen - I'm
not interested in earning money at doing it.
> So while the Cricket system won't win design awards for raw power, it
> might stand to be nominated for usefulness and adaptability!
It seems that the basic idea is very similar to what I'd like to see - but
I think that there exists the technology to do 'faster', 'smaller', 'cheaper'
and do a better job (by far) than either the RCX or any likely Lego-manufactured
alternatives.
There seems to be broad agreement that the kinds of things we're talking about
is exactly what Lego Robotics people want (and the RailRoad people will want
it too once they see what it could mean to them). If Lego-Inc are not going
to do it - then someone needs to step into the void.
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net
|
|
Message has 1 Reply:
 | | Re: Brainstorms
|
| (...) There are many more options available than the three you list above. Note that there are far more microcontrollers in small packages with UART's than there are ones that have built in I2C. The UART only ones cost way less too. Many of the (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
