 | | | | | | |
| |
|
Kyle
> What I thought was harder, was that the PC programming software wouldn't
> easily be able to tell How many motors you have or how many sensors.
Plug-And-Play works well under Windows (at least, it does under XP).
The chip on the sensor or motor can say what it is - an ASCII string that
says 'motor' or 'servo' - and who it is - a unique id like 2908347525.
> 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?
The cpu "brick" uses the id number to address to peripheral - not the
peripheral's position on the bus.
> 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.
You come home from the shop with your brand new motor. You plug it into
your cpu "brick" and plug the cpu into your PC. You select the PC menu
command New Hardware. The PC talks to the cpu, the cpu talks to the bus and
asks everyone whose attached to identify themselves. The PC sees the new
motor and says 'You've got a new "motor". What do you want to call it'. You
take a felt-tip and write on the motor "XYZ" then tell the PC 'It's called
"XYZ"'. From now on, the PC always refers to that motor as XYZ. No-one need
ever see the long id number 2908347525.
It's all straightforward stuff and the sort of thing that comms programmers
do every day.
> 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.
Yes. That is the huge challenge. Lego did a wonderful job with the
Minstorms programming language. It introduces you to real-time embedded
programming in a tremendously gentle way. But then you find it's so
limiting. And runs so slowly.
I think a graphical language is the ideal for beginners and there is no
reason why such a language shouldn't have all the power of a textual
language.
Does anyone have any references to research done on graphical programming
languages for children?
Peter
| | | | | | | | | | | | | | | | |
| |
|
From: PeterBalch
[mailto:PeterBalch@compuserve.com]
> You come home from the shop with your brand new • motor. You plug it into
> your cpu "brick" and plug the cpu into your PC. • You select the PC menu
> command New Hardware. The PC talks to the cpu, • the cpu talks to the bus and
> asks everyone whose attached to identify • themselves. The PC sees the new
> motor and says 'You've got a new "motor". What do • you want to call it'. You
> take a felt-tip and write on the motor "XYZ" then • tell the PC 'It's called
> "XYZ"'. From now on, the PC always refers to that • motor as XYZ. No-one need
> ever see the long id number 2908347525.
This is fine for computer systems that change
infrequently, but for
lego that is intended to change often, it's not
ideal. There is a linkage between the programming
and the specific motors or sensors. If you take
your machine apart and then rebuild it later, the
same devices must be used in the same locations;
switching the original drive motor for an arm
would have serious functionality issues!
> I think a graphical language is the ideal for • beginners and there is no
> reason why such a language shouldn't have all the • power of a textual
> language.
Although a picture is worth a thousand words, I
can change a few of the thousand words to get an
entirely different picture much faster than
drawing a new picture. This is why a textual
programming language has much more power than a
graphical language - you can make changes on any
scale, from instructions to systems. A graphical
language can only be changed at the
pre-manufactured components level.
-Andy
| | | | | | | | | | | | | | | | | | | | |
Subject:
|
RE: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 Feb 2003 17:26:37 GMT
|
Original-From:
|
"Marco Correia" <Marco.Correia@soporcel.pt>
|
Reply-To:
|
<[Marco.Correia@]ihatespam[soporcel.pt]>
|
Viewed:
|
527 times
|
| |
|
Andy,
This won't happen if the Device_ID to Device_Friendly_Name mapping is as
generic as "motor1", "motor2", "light1", "lightsensor1", "irdar1",
"rotationsensor1", "rotationsensor2" and so on...
Then, the *specific* Device_Friendly_Name to Robot_Device_Location mapping
should be done at the source code level (as it is done now, when I say the
the LEFT_ELBOW = OUT_1).
Today, you have to pay attention to which motor/sensor is connected to which
port so everything goes ok with your robot.
With the system we are talking about, you should pay attention to what
devices are where in the robot, and not to what port are connected.
Just by looking at the "friendly name" written by you on the device instead
of looking at the port letter/number.
mc.
-----Original Message-----> Andrew J. Huang
From: PeterBalch
> You come home from the shop with your brand new • motor. You plug it into
> your cpu "brick" and plug the cpu into your PC. • You select the PC menu
> command New Hardware. The PC talks to the cpu, • the cpu talks to the bus and
> asks everyone whose attached to identify • themselves. The PC sees the new
> motor and says 'You've got a new "motor". What do • you want to call it'. You
> take a felt-tip and write on the motor "XYZ" then • tell the PC 'It's called
> "XYZ"'. From now on, the PC always refers to that • motor as XYZ. No-one need
> ever see the long id number 2908347525.
This is fine for computer systems that change
infrequently, but for
lego that is intended to change often, it's not
ideal. There is a linkage between the programming
and the specific motors or sensors. If you take
your machine apart and then rebuild it later, the
same devices must be used in the same locations;
switching the original drive motor for an arm
would have serious functionality issues!
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Marco,
Yes, I agree that logical mappings will help the
problem. But consider this example:
You have motors with the friendly names of
motor1.. motor20
You write a program and specify the
associations:
left arm = motor1,
right=motor2,
etc.
I believe that you can't get around this kind of
association. Each device has to have a unique
friendly name (two devices of the same name cannot
be used in the one system). Each program must
identify the exact device it is to work with,
since it does not know the location.
Now, suppose I say, "Whoa, great robot dude! Can
you send me the program?"
In order for this to work, I need to name my
motors motor1... motor20 (at least in the range in
which the program uses motors). I cannot have
named them, for example moteurUne, moteurDeux, ...
nor motoren1. This is a little vexing, but it can
be done.
It works so far. But I decide to have twins and
I've used up motors motor1..motor5 and I want to
build it on motor6-10. The program linkage will
need to be redone.
Or to take this farther, even, I've built a robot
that builds robots. The factory robot ("Mom")
assembles and programs them. Now we're really
stuck.
This system essentially destroys component
plug-n-play: a motor is not a motor anymore. If
you want to retain the ability to swap components,
you have to have a location-aware system.
Type-aware helps but isn't necessary.
One way to do location aware is to make every bus
brick a network node and source-route packets
between the device and the RCX. Then, you write
your programs based on location. For example you
create a packet that specifies a 10 revolution CCW
rotation and send it:
- down the neck-link,
- out the first right appendage link,
- past the rotator cuff node,
- past the elbow-joint node
- number 1 in the daisy chain
This would then pull/release a pair of tendons
that would un-grasp the thumb.
Note that the human body is NOT built this way.
We're hardwired from the brain to the muscle
fibers. We're sort of plug and play, though it
takes some drugs to make it work.
Just some thoughts.
Andy
-----Original Message-----
From: Marco Correia
[mailto:Marco.Correia@soporcel.pt]
Sent: Tuesday, February 04, 2003 10:27 AM
To: 'lego-robotics'
Subject: RE: RCX & RIS, a fading glory?
Andy,
This won't happen if the Device_ID to
Device_Friendly_Name mapping is as
generic as "motor1", "motor2", "light1",
"lightsensor1", "irdar1",
"rotationsensor1", "rotationsensor2" and so on...
Then, the *specific* Device_Friendly_Name to
Robot_Device_Location mapping
should be done at the source code level (as it is
done now, when I say the
the LEFT_ELBOW = OUT_1).
Today, you have to pay attention to which
motor/sensor is connected to which
port so everything goes ok with your robot.
With the system we are talking about, you should
pay attention to what
devices are where in the robot, and not to what
port are connected.
Just by looking at the "friendly name" written by
you on the device instead
of looking at the port letter/number.
mc.
-----Original Message-----> Andrew J. Huang
From: PeterBalch
> You come home from the shop with your brand new • motor. You plug it into
> your cpu "brick" and plug the cpu into your PC. • You select the PC menu
> command New Hardware. The PC talks to the cpu, • the cpu talks to the bus and
> asks everyone whose attached to identify • themselves. The PC sees the new
> motor and says 'You've got a new "motor". What do • you want to call it'. You
> take a felt-tip and write on the motor "XYZ" then • tell the PC 'It's called
> "XYZ"'. From now on, the PC always refers to that • motor as XYZ. No-one need
> ever see the long id number 2908347525.
This is fine for computer systems that change
infrequently, but for
lego that is intended to change often, it's not
ideal. There is a linkage between the programming
and the specific motors or sensors. If you take
your machine apart and then rebuild it later, the
same devices must be used in the same locations;
switching the original drive motor for an arm
would have serious functionality issues!
--
Did you check the web site first?:
http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | | | | | |
Subject:
|
RE: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 Feb 2003 15:11:32 GMT
|
Original-From:
|
"Marco Correia" <Marco.Correia@soporcel.pt>
|
Reply-To:
|
<marco.correia@soporcel.[NoMoreSpam]pt>
|
Viewed:
|
559 times
|
| |
|
> -----Original Message-----> Andrew J. Huang
> One way to do location aware is to make every bus
> brick a network node and source-route packets
> between the device and the RCX. Then, you write
> your programs based on location. For example you
> create a packet that specifies a 10 revolution CCW
> rotation and send it:
> - down the neck-link,
> - out the first right appendage link,
> - past the rotator cuff node,
> - past the elbow-joint node
> - number 1 in the daisy chain
> This would then pull/release a pair of tendons
> that would un-grasp the thumb.
hmmm... I prefer the method using a High_Level map in the source code or as
a .h file
/////////////////////////////////////////
#IFDEF _TWINROBOTA_
#INCLUDE 'TwinRobotA_devmap.h'
#ENDIF
#IFDEF _TWINROBOTB_
#INCLUDE 'TwinRobotB_devmap.h'
#ENDIF
#IFDEF _TWINROBOTC_
#INCLUDE 'TwinRobotC_devmap.h'
#ENDIF
//ELSE
// compiler will stop with an error like
// "RightHand_Finger1 device unkown !"
//...
OnFor(10,RightHand_Finger1);
OnFor(10,RightHand_Finger2);
OnFor(10,RightHand_Finger4);
//...
//send to rotation sensor+stepper motor
//a "rotate Neck to a 45 degree position"
OnToDegrees(45,NeckServo)
//...
/////////////////////////////////////////
rather than refering to a device with something like:
/////////////////////////////////////////
//...
OnFor(10,'\down the neck-link\out the first right appendage link\past the
rotator cuff node\past the elbow-joint node\number 1 in the daisy chain');
OnFor(10,'\down the neck-link\out the first right appendage link\past the
rotator cuff node\past the elbow-joint node\number 2 in the daisy chain');
OnFor(10,'\down the neck-link\out the first right appendage link\past the
rotator cuff node\past the elbow-joint node\number 4 in the daisy chain');
//...
//send to rotation sensor+stepper motor
//a "rotate Neck to a 45 degree position"
OnToDegrees(45,'\neck base')//...
/////////////////////////////////////////
...even if something like the following could be used:
/////////////////////////////////////////
//...
SetCurrentDeviceNode('\down the neck-link\out the first right appendage
link\past the rotator cuff node\past the elbow-joint node');
OnFor(10,'number 1 in the daisy chain');
OnFor(10,'number 2 in the daisy chain');
OnFor(10,'number 4 in the daisy chain');
//...
//send to rotation sensor+stepper motor
//a "rotate Neck to a 45 degree position"
OnToDegrees(45,'\neck base')//...
//...
/////////////////////////////////////////
mc.
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Marco thought:
> hmmm... I prefer the method using a High_Level • map in the
> source code or as a .h file
From a code writing point of view, defining macros
that identify the motor is much nicer than having
to list out the path to the motor. However, when
you have to replace a dodgy motor on an
individual, you'll have to re-map the motor name
(revise the .h) and then recompile. If you're on
Mars, or at a standalone (no reprogramming)
competition, a recompile and download isn't
convenient.
A route to the motor isn't so bad since it can be
encoded as a macro just the same:
#define RightHand_Finger1 down_neck, \
first_right_appendage, \
past_rotator_cuff, \
past_elbow-joint, \
first_daisy chain
...
do_thumb(degrees) {
packet = create_packet();
setPacketDest(packet, RightHandFinger1);
if (degrees > 0)
packet->command = MOTOR_ON_CCW
else
packet->command = MOTOR_ON_CW
packet->value = degrees*SECS_PER_DEGREE;
sendPacket(packet);
free_packet(packet);
}
This is pretty similar to what you suggested, but
abstracting the operations to a little higher
level.
The main codeline should then look like:
main()
do_thumb(10);
do_forefinger(MAX);
etc.
However, the main point is that you can hide an
arbitrary amount of code ugliness.
Best regards,
Andy
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> Andrew J. Huang:
> From a code writing point of view, defining macros
> that identify the motor is much nicer than having
> to list out the path to the motor. However, when
> you have to replace a dodgy motor on an
> individual, you'll have to re-map the motor name
> (revise the .h) and then recompile. If you're on
> Mars, or at a standalone (no reprogramming)
> competition, a recompile and download isn't
> convenient.
Yes, you're right. :)
The alternative would be to tweak the Device_ID/Friendly_Device_Name table
in real-time, updating the new Device_ID.
Then, the compile-time table with the Friendly_Device_Name/MOC_Specific_Name
would still valid.
> A route to the motor isn't so bad since it can be
> encoded as a macro just the same:
>
> #define RightHand_Finger1 down_neck, \
> first_right_appendage, \
> past_rotator_cuff, \
> past_elbow-joint, \
> first_daisy chain
Seconds after I sent the msg, I thought about this too.
Then, no matter the method used, the source can always use MOC specific
device names, through macros.
hmmm... but aren't we replacing a Device System with a Node System ?
Wouldn't we still need a Node_ID/Friendly_Node_Name map ?
> However, the main point is that you can hide an
> arbitrary amount of code ugliness.
Yes, that is true.
mc.
| | | | | | | | | | | | | | | | | | |
| |
|
PeterBalch wrote:
> Kyle
>
>
> > What I thought was harder, was that the PC programming software wouldn't
> > easily be able to tell How many motors you have or how many sensors.
>
>
> Plug-And-Play works well under Windows (at least, it does under XP).
You mean 'plug and pray' don't you?? ;)
> The chip on the sensor or motor can say what it is - an ASCII string that
> says 'motor' or 'servo' - and who it is - a unique id like 2908347525.
This is one way. Yes.
I never claimed that this was an impossible problem to solve. And
I agree that for you and I who have experience in the computer
programming field (I know I work in that field I don't know about you?)
These solutions are obvious, logical and easy to work with.
My only claim was that it would be tough (not impossible - just not
trivial) for LEGO to be able to modify the current graphical programming
environment to work in such an open ended system without forcing
the kids to learn about things like Unique identifiers, and virtual
device name mappings.
>
> The cpu "brick" uses the id number to address to peripheral - not the
> peripheral's position on the bus.
All I was saying was that both solutions are possible. If you want to
avoid having to think about ID's and mappings, then a possibly simpler
solution might be to assign ID's based on connection order. I was
mainly just pointing out that both solutions (like solutions to almost
any problem) have their trade-offs. Pros, Cons. And I believe that
neither one has an obviously better solution for the basic type of
programming environment that LEGO would like to deliver 'out of the
box'
>
> > 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.
>
> You come home from the shop with your brand new motor. You plug it into
> your cpu "brick" and plug the cpu into your PC. You select the PC menu
> command New Hardware. The PC talks to the cpu, the cpu talks to the bus and
> asks everyone whose attached to identify themselves. The PC sees the new
> motor and says 'You've got a new "motor". What do you want to call it'. You
> take a felt-tip and write on the motor "XYZ" then tell the PC 'It's called
> "XYZ"'. From now on, the PC always refers to that motor as XYZ. No-one need
> ever see the long id number 2908347525.
Ok what if I have 3 new motors?
Maybe 'entering' was the wrong word. Either you have to print the number
on the outside of the motor, and at least read it there and on the
screen to see which one is which, or possibly the software lights one
up (or makes it spin but that can cause problems) at at time and
you name them that way.
One solution is to plug them all in one at a time to name them. That's
not always practical, what if I'm an 8yr old who built a cool robot
and programmed it at home and brought it to my friends house and we
want to reprogram it? I'd hate to have to disassemble it just to be
able to plug each motor (which his PC hasn't seen yet) in one at a
time.
> It's all straightforward stuff and the sort of thing that comms programmers
> do every day.
All the things you describe are fine and easy for people like you and
me that want to use NQC or BrickOS. We're familiar with these concepts.
'comms programmers' are familiar with all this stuff.
8yr olds aren't.
Again, I never claimed that this wasn't something that one of us
as a hobbyist couldn't design or handle. I was trying to discuss the
problems LEGO would have to overcome to feel comfortable marketing
a product like this to children. They'd need to feel that they had
made it simple and unfrustrating enough for the children and beginners
that they were selling it to to even bother trying to make a product
like this.
>
> > 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.
>
>
> Yes. That is the huge challenge. Lego did a wonderful job with the
> Minstorms programming language. It introduces you to real-time embedded
> programming in a tremendously gentle way. But then you find it's so
> limiting. And runs so slowly.
And even with the nice environment they provide it is still very easy
to create race conditions and unreachable code blocks, and still *very*
hard to debug those types of things. But then again Debugging itself
is never easy... (anyone who can make it simple could become rich over
night!)
> I think a graphical language is the ideal for beginners and there is no
> reason why such a language shouldn't have all the power of a textual
> language.
I agree that a graphical language can have the power of a textual one.
I'm not sure that if it did, it would still be as useful to beginners
though. power almost always brings at least some complexity.
> Does anyone have any references to research done on graphical programming
> languages for children?
I don't, no.
-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-------------------------------
| | | | | | |
