Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 9 Aug 2002 00:30:20 GMT
|
Original-From:
|
Steve Baker <sjbaker1@/stopspammers/airmail.net>
|
Reply-To:
|
sjbaker1@airmail.net!spamcake!
|
Viewed:
|
763 times
|
| |
|
|
John Barnes wrote:
> The subject of this post is intended as an invitation to anyone who would
> like to contribute their ideas, wants, wishes, desires for a new direction
> for managing a microcomputer controlled Lego creation. As far as I see it
> there are only two real candidate architectures, modular and monolithic. I
> regard the RCX as a monolithic structure in the sense that is the entire
> core entity into which you plug motors and sensors. A modular approach, in
> this context, would split that monolithic central "thing" into a number of
> constituent entities, like power source, CPU, memory, sound making devices,
> displays etc etc.
It's more than that.
Lego is all about having no arbitary limits on what you can build. If you
have enough bricks, you can build arbitarily complex things.
However, RCX is horribly limited - and it's limits are obvious and easily
reached. Three motors, three sensors, one communications path, finite
battery power.
It's not *so* much that the RCX itself needs to be modular - it's that the
interfaces to the world need to be open-ended. A first step would be an
addressable I/O bus. Some way to daisy-chain together motors and sensors
to some insanely high limit and then send a message to "Motor number Six"
saying "Forwards, Speed 4".
One could design a custom bus to do this - but something off-the-shelf would
make more sense.
The most common bus like that is I2C - there are dozens and dozens of small,
low power devices that work with I2C. You can find RAM chips with just 8
pins that are smaller than a penny. There are lots of cool I2C peripherals
that could comfortably fit inside a 2x4 brick or a motor housing.
Once you go that way for motors, sensors and cute gadgets like voice synthesisers
and DTMF phone diallers, it comes naturally to make the LCD control panel work
the same way and to have ROM, RAM and CPU separated out into separate chips.
It would take a little software ingenuity to make this work 'elegantly' (eg,
how are motors going to get their addresses? What happens if there are TWO
ROM chips plugged in? What if there are two CPU's?) - but as a software
engineer who'se worked with similar embedded microcontrollers, I don't regard
this as a big problem.
It would be easy to write a ROM 'chip' that would emulate the RCX and another
that would behave in pre-programmed ways like a Scout. If it emulated
the RCX then the existing Lego PC software and all the 3rd party stuff that
uses Lego bytecode should "just work" without change.
I2C is used for things like TV remotes - so there are IR transmitter and
reciever chips.
Lego could make some *REALLY* cool toys with this technology. There are
things like sound synths, voice synths and phone diallers/modems in I2C. They
could have things where your robot can be held up to the phone and made
to send messages to some other kid's Lego robot...have it log into
the www.lego.com web site and download interesting new 'behaviours',
music, stories read out by the voice synth.
> Modular?
>
> How do you connect them? By wires? By plugging modules together?
That's the part that Lego Inc are good at. It would be cool to have bricks
that you just plugged together in stacks - but some other scheme with
additional wires would work too.
The Lego wires are clever because they can be plugged in 'backwards' and
'sideways' and still work - but I think that idea would have to be dropped
for this because we'd want to carry both power and the I2C signals down
the same cable...so more than 2 conductors would be needed. However, a
'keyed' version of that which would only connect one way round would be
fine by me.
> What sort of granularity is required? All semi-intelligent? One master with
> loads of dumb I/O slaves?
Certainly dumb I/O slaves - programming multiple computers is harder than
just one...however, it would be nice if you could have multiple computer
bricks plugged onto the same bus. It might be that you'd actually use a
computer chip inside your motors and sensors - but if so, I'd make it run
off it's own local ROM so it's not obvious that it's a computer.
> How do you supply power to all the modules? Independently? Along the common
> data communication interface (via the wires or plugging scheme mentioned above)?
Ideally, you'd want to use the same bundle of wires to do both power and I2C,
but you'd run into the problem that sooner or later you'd be unable to run
everything off one battery pack - or the wires would start to get hot from
all the current they'd be carrying.
I'm not sure how you deal with that - probably just have the battery pack be
smart enough to shut down if it's in danger of being overloaded - and provide
a special bus interface brick that would allow you to have multiple battery packs - each
running just a small group of devices - but yet allow the I2C bus to cross between
the groups via a 'bus interface brick'.
It might be possible to transmit the I2C data stream by modulating the power
signal and get down to a two wire interface - but Lego wires still allow you
to plug it in 'backwards' and reverse the polarity of the connection...so that
might not be a good idea.
Separating the battery pack out as a separate component would be nice for the
Lego train enthusiasts too - now you can power truly *tiny* computer setups from
the rails. Not having to lug the batteries, the LCD display and all the other
junk around in your railroad car would be a big benefit.
Making the wiring 'kid friendly' *AND* 'abuse-survivable' is certainly the hard
part of this.
The neatest thing would be to have something like the BlueTooth interface - then
you could just apply power using standard Lego wires - and let short range
radio waves do all the data comms. However, the price of that would be **HUGE**
and you wouldn't get it to fit into a 2x4 brick.
> How does your software deal with the variable topology possible? Do modules
> somehow use some kind of dynamic address assignment(how does your software
> know which motor controller is which?)? Do modules have preset addresses or
> IDs (do you really like those fiddly little DIP switches?)? Or do you have
> some kind of initialization process to give them an ID they store internally
> in EEPROM (in which case they all look the same, and you have to try and
> remember what ID you programmed into each one to be able to talk to it again?)?
Well, if it's a daisy-chain bus then the most obvious way is to have them
numbered in order from the CPU. To keep things relatively cheap, I don't
think tiny switches would be a good idea - especially since you'd be imposing
a "modularity limit" if you only had a 0..15 address range or something.
Removing modularity limits is important IMHO.
> etc ... etc ... etc
Yes - exactly! *LOTS* of 'etc...etc' !!
The biggest drawback in what I suggest is that motors and sensors would need
a modicum of intelligence in them - and THAT means that existing motors and
sensors wouldn't work with the new system.
You could probably make another brick that had an I2C interface on the top
and a regular set of Lego wire studs on the bottom that would drive existing
Lego motors and read existing sensors.
> Monolithic?
>
> Do you want a bigger RCX? How big - 6 motors/12 sensors?
No.
That doesn't make sense because you either have to provide this monsterous
contraption with every silly little kiddy toy - very expensive and quite
wasteful - or you create dumbed-down things like the god-awful MicroScout
that people have to throw away when they want to build something big.
If you build one of these monsters, where do you stop? Some people *still* want
more than 6 motors.
You could argue that the RCX is already too complex - otherwise why would
Lego have to make all these crappier systems. There must be tens of thousands
of RCX's out there that have never been connected to more than two motors and
two sensors. It's very wasteful to provide all those connectors when they aren't
needed.
My modular approach allows them to sell systems with:
1xCPU
1xROM
2xMOTORS
1xBatteryBox
...with the ROM preprogrammed to do something crappy for kids.
Yet, when you buy 10 of those and add a RAM, an IR interface and the ROM with the RCX-like
functionality in it, you suddenly have an uber-RCX with more intelligence, motors, etc than
you could ever need!
This would also be good for Lego - people who only have one RCX will be most unlikely
to buy more than one extra motor and a couple of extra sensors...but if the system
was infinitely expandable - and with cool stuff like voice synthesisers - their
sales don't stop at the first system you buy.
> Please let your imagination wander and contribute your thoughts. Just
> remember to keep practicality in the back of your mind when blue-skying
> this. I may well decide to build a sample or two of what comes out of this,
> assuming something does. So it needs to be able to be done with existing
> commonplace technology.
I've considered the same - I2C chips are cheap and tiny, if the interconnect
problem could be solved robustly, there are definite possibilities here.
----------------------------- 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 is in Reply To:
 | | Brainstorms
|
| Ok. I've seen a similar ebb and flow of ideas for modularization in this newsgroup before. The difference, is that now, most people who are reading this a probably well familiar with the RCX, Mindstorms, etc etc. The subject of this post is intended (...) (22 years ago, 8-Aug-02, to lugnet.robotics)
|
53 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
