Subject:
|
RE: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 Feb 2003 16:03:14 GMT
|
Original-From:
|
"Marco Correia" <Marco.Correia@soporcel.pt>
|
Reply-To:
|
<marco.correia@soporcel%Spamless%.pt>
|
Viewed:
|
757 times
|
| |
|
|
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 =
My_Friendly_Device_Name mapping) and our source code would deal with
Local/Specific/Temporary MOC/Code Device Names (like we usually do with
#DEFINE) having these mappings included in the source code files.
So, there would be 3 levels:
Low) Device_ID: burned on the little devices
Medium) Friendly_Device_Name: Stored on a file on our PC (every pBrick<->PC
session would start a NewDevice? check)
High) MOC_Specific_Device_Name: Stored on the source code.
Example:
(Your mapping table included with your source code)
// DEVICE MAPPING DEFINITIONS - BEGIN
//This MOC specific logical name = My generic (ot not)
friendly_device_name
...
Left_Wheel = Motor1
Right_Wheel = Motor3
Arm_Base = Motor2
Arm_Elbow = Motor10
Hand_Fingers= MicroMotor1
...
// DEVICE MAPPING DEFINITIONS - END
(After receiving your source code and before compiling I'll have to edit it
and make *MY* mappings)
// DEVICE MAPPING DEFINITIONS - BEGIN
//This MOC specific logical name = My generic (ot not)
friendly_device_name
...
Left_Wheel = Motor1996a
Right_Wheel = Motor1996b
Arm_Base = NewMotor1
Arm_Elbow = NewMotor2
Hand_Fingers= MotorPequenito
...
// DEVICE MAPPING DEFINITIONS - END
Only after this, it would be "safe" to compile and run the code.
The compiler could even tell "Unknown Device: MotorPequenito" so you check
the Medium_Level Mapping and make the correction to "LittleMotor".
Ok, what about LEGO programs ?
Well, if Kids/AFOLs understand that they give a name to each device, every
time they connect a new/unknown one to their (PC) system, then they should
understand the need for an "instalation alike" procedure where the LEGO
robot controlling software asks (for each device expected on the robot):
"You should have a device like this, here ?" (pointing to a graphical
representation of the LEGO robot).
"Did you use the "Motor01" ? If not, tell me the name of the device you
used instead:"
This procedure could use default (and sequencial) "friendly" names, given by
a standard LEGO procedure usually run every time a new device was bought and
"presented" to the system. But, if that wasn't the case, give the oportunity
to tell the software the "custom name", 'cause most AFOL would "hack" the
names manually or through freeware third-party "device mapping" software
like we are used to :) ...or simply because there would be some third-party
compatible devices LEGO software would know what default name to give.
What about someone with various PC's ? No problem, you simply:
1) should have a copy (diskette?) with the Medium_Level mappings file and
append or copy it to the new PC(s)
OR
2) go through the "instalation/refresh" procedure again, giving the same
names to each device the PC asks a Friendly_Name for, generating a new
Medium_Level map file.
...just my 2 cents.
mc.
> Steve Baker wrote:
> > 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 is in Reply To:
 | | Re: RCX & RIS, a fading glory?
|
| (...) 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 (...) (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
|
|
|
|
