Subject:
|
Re: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 Feb 2003 14:51:41 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmailSPAMCAKE.net>
|
Viewed:
|
816 times
|
| |
|
|
PeterBalch wrote:
> I think that's the way database programmers do it. The same database
> program can be applied to different databases by changing the alias table.
Yes - exactly. With this approach it's inevitable that you'll need either:
1) Some mapping between a horribly unfriendly unique ID and a friendly name.
...or...
2) A way of storing a friendly name inside the device itself (eg by
connecting the devices one at a time to your PC and downloading the
name into the device.
If it was (1) then where would the mapping table be stored? The computer
in the Lego needs to know it - so it has to go with the program somehow.
That makes the program unique to that system and makes it very hard to
share software. It would also make it impossible for LEGO Inc to ship
pre-programmed software (like the Scout or MicroScout) with the system
because no two systems would have the same set of motors.
Method (2) eliminates that problem - you tell the motor "You are Left-Wheel"
and it remembers that in some tiny flash memory. The Lego computer can
now to a test on startup to find which motor has which name. In effect,
the mapping between unfriendly number and the name is now stored in the
device - not in the program.
That way, I can give you my program - and tell you to give your motors
names like "Left Elbow" in order for it to work...and it'll all work out
OK.
However, that means that for LEGO Inc to ship a model with pre-programmed
software, they'd also have to pre-label the motors "Left Wheel" and "Right Wheel"
and put little stickers on them to say which is which. That's not impossible
but I bet it would sound most unattractive to them.
In either (1) or (2) you need a user-friendly way to label your motors and
sensors both in software/hardware terms - and in terms of physical, reusable
labels that you stick on the motors so you can easily *see* which is which.
A third option would be to put a small rotory switch onto each device
that allowed you to set the device's address. If the switch had 16
positions, that would allow you to connect up to 16 devices together.
That's still an annoying arbitary limit though - and I'd like to
avoid that. However, any bus-based system will inevitably have limits
because you cannot 'fan out' electical signals indefinitely.
> > you have to have a location-aware system.
>
>
> That too has problems. In my Giraffe robot, how do I connect the motors?
> The "LeftHip", "LeftKnee", "LeftAnkle" motors are all daisy-chained
> together in that order. But then I decide to add a tail. I don't want to
> change the program I've written so far so I'm forced to add the "Tail"
> motor after the "LeftAnkle" motor and run a wire all the way back up the
> leg. I can't just add "Tail" to the wire near the "Hip".
We have a location-aware system right now. If you change the location of
your motors, it's sometimes necessary to re-route the wires - and thus
change the locations of the connections on the RCX - thus requiring you
to change your software. It's actually even worse than that because
the plugs are reversable - and that can require a software change in
extreme circumstances.
However, you are right that it would be worse with dozens of motors
and sensors all on one gigantic daisy-chain.
You could still *OPTIONALLY* have support for human-friendly names...
just as with schemes (1) and (2) above. The motors are now numbered
according to their positions rather than when they were manufactured - but
there can still be a mapping table from number to name - and your program
can still refer to them by name.
My programs for RCX already do that:
#define LEFT_MOTOR OUT_A
#define RIGHT_MOTOR OUT_B
#define LAMP OUT_C
#define OnFwdLeft OnFwd(LEFT_MOTOR)
#define OnFwdRight OnRev(RIGHT_MOTOR) /* Right motor connected backwards */
...and so on...
But you could take that out of the program and into the 'compiler'
on the PC. So there could be some cute graphical thing that let
you drag motors and sensors and {whatever} around on your PC and
connect them with lines to indicate where the wires connect in the
real model - then give each one a human-readable name. That
table could then be given to the compiler which would allow your
program to use the human-readable names.
That would fit fairly naturally into the Lego graphical programming
environment - and would probably be completely unnecessary for NQC
users who would know how to use #define mechanisms.
LEGO could still provide pre-built ROM programs - but just have
clear building instructions that show the left motor being connected
to the computer brick and the right motor connected to the left motor.
If you connect up the wires wrong - the model doesn't work - but that's
no different from RCX and Scout.
Another advantage of a position-based 'daisy-chain' system is that
you need never be limited on the number of devices you have. Since
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 think a position-based scheme wins hands-down.
I imagine a stereo-jack type of interface - with a socket on
one side of each device and a protruding pin on the other. Wires
would have a male jack on one end and a female socket on the other.
Using stereo jacks would provide for power, ground and signal wires.
The protocol could be something very simple - a packet containing
an 'address' followed by a 'length' and then some kind of 'command'.
Each device could be set up to obey the command only if the address
is zero - and to subtract one from the address and pass it on to
the next device otherwise.
You'd need one 'standard' command to say "What kind of device are you?"
that all devices would be required to understand - then the remainder
can be specific to one kind of device.
Whenever you started a program running, the 'computer' brick would
go out and ask
Address 0 : What are you?
Address 1 : What are you?
Address 2 : What are you?
Address 3 : What are you?
...until it makes a request and doesn't get an answer back within
(say) 1/10th second.
Now it knows which devices are which.
If one of those is a LEGO 'Program Brick', it could fetch
the program from the brick and execute it. Such bricks could
either have one fixed program loaded into them at the factory
(for a Scout/Microscout-like toy) or be programmable from your
PC (for an RCX-like set). 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
Program bricks.
If one of those devices is another 'Computer Brick' then it could
set up the necessary parameters to communicate with it when the
user's program starts running. 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.
IR or Radio 'Communications bricks' would simply pass on the
same protocol to the other end of the link...so your PC would
appear as just another "Computer brick" on the daisy-chain...
and communication between robots would be just the same as
communications between parts of the same robot. Cooperative
tasks between robots should be a snap to implement.
You could even have just 'dumb' devices like motors on the
end of a communications link - so one robot could detach
part of itself to drive off and do a task.
Thus, a PC could drive motors directly - robots could communicate
with one-another, etc, etc.
No limits on numbers of motors, sensors...except for the largest
number in the 'address' part of a message. That could be a 16 bit
number - allowing up to 65,536 motors, sensors, computers, displays,
cameras, PC's...or whatever. Enough for *any* AFOL ?
Now all we need is someone to build it and sell it to us!
...which is the gigantic fly in the ointment.
:-(
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
|
|
Message has 1 Reply:
 | | RE: RCX & RIS, a fading glory?
|
| I think it'll be easier to edit the source code where the mapping is done and modify it to MY_FRIENDLY_DEVICE_NAMES So, the pBrick would deal with Device_ID's, my PC would deal with Friendly_Device_Names (through a file with current Device_ID = (...) (22 years ago, 5-Feb-03, to lugnet.robotics)
|
Message is in Reply To:
| | RE: RCX & RIS, a fading glory?
|
| Andy (...) That's a very good point that I hadn't considered. But it's easily solved. The whole PC knows id 23948756 as "Motor1". But within a particular program, you're allowed (but not forced) to use aliases. So within your program you say for (...) (22 years ago, 5-Feb-03, to lugnet.robotics)
|
3 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
