Subject:
|
Re: RCX & RIS, a fading glory?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 Feb 2003 19:27:15 GMT
|
Original-From:
|
Kyle McDonald <kyle.mcdonald@SAYNOTOSPAMsun.com>
|
Viewed:
|
448 times
|
| |
|
|
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-------------------------------
|
|
Message is in Reply To:
 | | Re: RCX & RIS, a fading glory?
|
| Kyle (...) 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. (...) The cpu "brick" (...) (21 years ago, 4-Feb-03, to lugnet.robotics)
|
8 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
