Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 13 Aug 2002 19:31:24 GMT
|
Viewed:
|
690 times
|
| |
|
|
In lugnet.robotics, sjbaker1@airmail.net writes:
> 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.
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 RoboBrick modules can be done with a single 8-pin DIP,
which trivially fits in a 2x4 Lego Brick. Most of our modules
could be reengineered to use surface mount technology and fit
easily within the 2x4 Lego Brick form factor.
The reason why I do not use surface mount is because it conflicts
with my goal of having boards that can be assembled by mere
human beings without a microscope. Different people have different
goals.
> 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.
You'll need some sort of adaptor, since the PC tends not to
run its I2C (if it has one) out to connectors on the pins.
> * Under PC control, it does a bus scan and figures out what kinds
> of chips are in the robot.
I'll believe it when I see it. You might want to get some
I2C serial EEPROM spec. sheets and try and figure out how to
distinguish the various EEPROM's from one another. Many of
them live at the same I2C addresses and have totally different
I2C command sets. Have fun.
> * 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.
You should price your chips before you make that statement.
The Cricket (and RoboBrick) design is using bottom of the line
MicroChip chips that typically cost $1 each. It is up to you to
find a vendor that will sell your I2C microcontroller chip that
cheaply. Your solution *may* be compact, but it is unlikely to
be cheaper.
> 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.
Have you priced th 87C751 microcontroller? I went to findchips.com
and could only find one vendor that was willing to give a stock
price. It was Allied and they quoted $6.48 (US). Oh, yeah, Allied
didn't have any in stock. Are their follow on chips? Perhaps,
but it is up to *you* to find them.
[snip connector discussion]
> 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.
If you want to take advantage of Moore's law, you should be header
towards smarter peripherals, not dumber ones.
> 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.
Agreed. And several people have. On this list we have covered
Cricket, RoboBricks, and the JCX stuff. You might also want to
check out the BrainStem work being done by AcroName. The
BrainStem uses I2C.
-Wayne
|
|
Message is in Reply To:
 | | 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)
|
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
