Subject:
|
Re: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 Feb 2003 21:39:15 GMT
|
Original-From:
|
PeterBalch <peterbalch@compuserve.STOPSPAMcom>
|
Viewed:
|
541 times
|
| |
|
|
Steve
You're really putting me on the spot aren't you? OK ...
> > mapping table in PC
> makes it very hard to share software.
Before a download begins, the PC checks whether the named motors exist in
the model. If they don't, it offers you the chance to set up a new alias
table (which is probably local to that program - you wouldn't want to mess
up your own alias table in order to try out someone else's code).
> It would also make it impossible for LEGO Inc to ship
> pre-programmed software (like the Scout or MicroScout)
Well I wasn't considering this to be used with the Scout. This is
specifically an expandable system.
But for pre-programmed Mindstorms software, the initial setup "Welcome"
process is already quite lengthy. There will be an extra stage in which you
are prompted "Now plug in one of your motors. Put a letter A on the side"
and the alias table is set up with standard names that match the names in
the pre-programmed software.
> physical, reusable
> labels that you stick on the motors so you can easily *see* which is
which.
Yes, like the sticky letters and numbers you (used to?) get with blank
video cassettes.
> a friendly name inside the device itself
> it remembers that in some tiny flash memory.
But, once again, sharing code is difficult. I don't want to mess up my
motor names in order to try out your code. Having the alias on the PC means
I can set up a temporary table which is local to your program.
> put a small rotory switch onto each device
Expensive.
> > you have to have a location-aware system.
> You could still *OPTIONALLY* have support for human-friendly names...
> cute graphical thing
> LEGO ... just have clear building instructions
> each device can electrically 'buffer' the signal before passing it
> on to the next device in the chain, you don't get signal degradation.
I don't believe that degradation would be a problem. Even TTL-level "RS232"
works well over tens of metres.
> I think a position-based scheme wins hands-down.
I think the cost is higher. The connectors need to be more complex -
because you have a separate "in" and "out" rather than a common bus. And
you'd need "Y" connections. The chip needs more I/O pins and more complex
software: it needs to pass on packets that aren't addressed to it (and
add/subtract 1 from the address). The chip must be able to receive and pass
on packets at any time whereas with a well-designed common bus, the chip
might be allowed simply not to answer if it's busy servicing its
peripheral.
I don't see that the advantages are all that great compared with the costs.
> You'd need one 'standard' command to say ...
> ... Address 0 : What are you?
Yes, I've done exactly that protocol but I was using a decent big PIC chip.
I know I couldn't do it with a tiny $1 PIC and also use the PIC to run
ultrasonic sonar. But I reckon I could get a tiny PIC to do sonar and
respond to a common bus (simply by refusing to answer if I'm waiting for
the sonar echo).
> If there are multiple program bricks
> then they are each executed one after the other - so we'll never
> run out of space for programs again...you can just add more
> This allows you to expand your
> robot with an arbitary number of computer 'brains'...each with
> their own program and their own devices and a high speed
> communications path between them.
Yes. That's a very attractive idea. (And it works with either kind of comms
hardware, of course.)
> IR or Radio ... communication between robots would be just the same as
> communications between parts of the same robot.
You'd have parts of the network - both nodes and "wires" - that operate at
very different speeds. I suspect that a network that operates with packet
forwarding would run at the speed of its slowest component.
> Now all we need is someone to build it and sell it to us!
> ...which is the gigantic fly in the ointment.
> :-(
Just send me the money and I'll start today
:-)
Peter
|
|
Message has 2 Replies:
 | | Re: RCX & RIS, a fading glory?
|
| (...) It's not just a matter of distance - it's a matter of the electrical load on the output of a single device. TTL-type devices have a suprisingly low limit on the number of inputs they can drive. With a 'bus' type device, that would limit you to (...) (21 years ago, 7-Feb-03, to lugnet.robotics)
| | | Re: RCX & RIS, a fading glory?
|
| (...) This is sounding a lot like the DCC system used in model train layouts. You're looking at fitting a DCC-like controller into a programmable brick, with each device having a programmable address? ROSCO (21 years ago, 7-Feb-03, to lugnet.robotics)
|
17 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
