Subject:
|
Re: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 3 Feb 2003 18:19:10 GMT
|
Original-From:
|
Kyle McDonald <Kyle.McDonald@*stopspammers*Sun.COM>
|
Viewed:
|
734 times
|
| |
|
|
PeterBalch wrote:
> Kyle
>
>
> > a compromise
> > computer would connect to a 'bus' or communications interace
> > (which could be a simple as the 2 wires we use today, and which
> > possibly could carry both power and data.)
>
>
> CAN bus? I2C bus? But that would require a third wire for power. They could
> be connected with miniature stereo jacks.
While did take some EE courses in college I don't claim to have enough
background in that area to comment on which bus could be used. I made
that statement mainly based on my suspicion that something like DCC
could be made to work. 2 Wires would be cool since the wiring LEGO
uses today could be reused. But if 3 or 4 or 6 wires were needed, that
wouldn't be the end of the world.
>
> > blocks with motor , motor controller, an RPM/Rotation/Torque Sensor
> > a compass, or a sonar, or even a
>
>
> Sure.
>
>
> > camera could directly interface to the computer block,
>
>
> Hmmm. I don't see how. The data rates for pictures are too high and would
> swamp the bus. And the real problem with a images is what to do with them.
> I guess if you had an intelligent camera like the CMUCAM then the output is
> just a few bytes per second.
I was thinking more of a camera that is a computer itself. This would
be like the 'optional' multiple computers on the bus idea I barely
mentioned in the beginning. I would expect this camera to do have a
program downloaded to it that would tell it what to look for, and all
it would really need to signal on the bus would be that is saw movement
in quadrant 3,4 or that is reconized a shape. Not the actual image itself.
I know I'm going out on a limb here. I'm letting my imagination run, and
then trying to see what can be done and what can't. This is probably one
of the tougher things to actually do.
>
> > The downside, (and
> > maybe what stopped LEGO from doing something like this) is
> > the programming.
>
>
> Why is it different from programming the RCX? Except whenever you buy a new
> block, you also get a mini CD (or do a download) which contains the
> driver/interface for that block, an icon for the drag-and-drop programming
> language, etc.
What I thought was harder, was that the PC programming software wouldn't
easily be able to tell How many motors you have (it knows you only have 3
on the RCX) or how many sensors. Figuring that out, or having it know what
type of sensor sensor #3 is might be solveable.
What I think is tricky (not for real programmers, but for providing an
easy user interface for kids to use to do programming) is dealing with
which touch sensor is which. Lets say I add one in my robotic hand that
already had 4. Did I wire it up on the end of the bus? in the middle?
When I go to update my program how does the programming environment
help me locate the one I added so that I update the code correctly?
Debugging embedded software isn't easy, even in the current RCX. While
I think the added flexibility from this type of design would be great,
I also think it is a potential source of frustration for the kids who
don't have a strong programming background. This I think it's a huge
challenge for the Programming environment developers to try to ease
that frustration.
One solution may be to actually provide a 'debugger' that allows you
to step through the program on the RCX through the IR tower. Another
may be an RCX simulator that can run your program on the PC. Who knows.
>
> > each motor has to
> > have it's own address hard coded
>
>
> Each block has a unique (in the universe) ID - such as the Dallas ID chips.
> When the cpu is turned on it queries who's there (I think both CAN and I2C
> can do that). When the PC starts a dowload, it checks that the hardware is
> as expected and if it's in doubt asks which motor you meant when you said
> "the left hand tracks".
Yes something like ethernet MAC addresses. That would be useful and would
minimize what I described above. Without some type of marking on the outside
of the motor though (maybe LEDs that the software could light up?) it'd be
hard to make sure you and the PC environment are talking about the same
motor/sensor without having to enter long numbers.
>
> > very similiar to the DCC
> > system used in model trains.
>
>
> I suspect that the DCC system can send power and data because it only uses
> low bit rates.
As I said I'm no electrical engineer. I don't know what the bit rate
is, but I'm not sure a whole lot of data needs to be sent. To me it
really seemed that some sort of RCX like computer giveing power and
direction commands to a motor was very similiar to what a DCC system
sends to the decoders in trains.
Querying a register on a motor or sensor decoder wouldn't take that
long I would think, but it may be limited in how often you could do
it, and that may not work.
I was really thinking more along the lines that someone could look
at DCC and design something new and similiar that met the needs of
a new RCX, not that DCC itself should be used the way it is.
-Kyle
--
_
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc. |||||
Enterprise Server Products Kyle.McDonald@Sun.COM
1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o) fax: (781) 442-1542
-------------------------------ooO(_)Ooo-------------------------------
|
|
Message has 1 Reply:
 | | Re: RCX & RIS, a fading glory?
|
| I think an ability to retain as much "Lego" infrastructure as possible is to be desired. Mixing and matching alien non Lego wires and connectors starts to depart the basic simplicity of polarity independence and Lego mechical compatibility which I (...) (22 years ago, 3-Feb-03, to lugnet.robotics)
|
Message is in Reply To:
| | Re: RCX & RIS, a fading glory?
|
| Kyle (...) Very true. (...) CAN bus? I2C bus? But that would require a third wire for power. They could be connected with miniature stereo jacks. (...) Sure. (...) Hmmm. I don't see how. The data rates for pictures are too high and would swamp the (...) (22 years ago, 1-Feb-03, 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
|
|
|
|
