Subject:
|
Re: RIS 2.0 Problems
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 6 Mar 2005 19:19:49 GMT
|
Original-From:
|
Steve Baker <sjbaker1@=StopSpam=airmail.net>
|
Viewed:
|
2581 times
|
| |
|
|
Mr S wrote:
> I think that something might be overlooked here? To
> ensure that all contestants are playing on a level
> field, it is necessary to ensure they have the same
> elements for building their competition systems.
Yes. I agree.
> To do
> this, it necessarily requires that development tools
> support a fixed set of functions, calls, and encoding
> so that no team has something the others do not.
Yes - I agree with that too.
The 'fixed set of functions' are the set of byte codes
that the Lego firmware supports. How you put those
together is a matter of what tools you use to design
the robot. NQC does not somehow increase the set of
allowed byte codes or magically cause the Lego firmware
to do things it couldn't do before. It's just another
tool for deciding what byte codes go where and in what
order.
Suppose one team used some specialised software to
pick appropriate gear ratios for a particular motor
in order to arrive at the speed and torque they wanted
at the drive wheels of their robot. Would that be
disallowed?
I don't think so.
Would it be reasonable to make a rule that it's OK to use
a gear train design program *ONLY* it's provided by LEGO?
No!
Should we then ban teams from using LDraw to plan their
designs in advance of actually placing the bricks together?
No!
So long as the actual parts you use in the robot are
unmodified Lego parts, that's OK.
The situation with NQC is EXACTLY the same. You are using
an offline tool to decide how the byte codes inside the
the RCS are arranged. LDraw is just a tool, so is NQC,
so is RIS and Robolab.
> By adding Java or NCQ, the competition judges lose
> control of this and no longer can ensure that the code
> generated could also have been generated by LEGO
> development tools.
Are you saying that there are byte codes that the Lego
firmware provides that NQC uses but which the RIS/Robolab
tools never generate?
I very much doubt that.
> As it happens, there is an independant firmware that
> supports the standard LEGO functions, but has new ones
> of its own, and on top of this works up to 10x faster
> than the LEGO firmware.
I strongly agree that replacing the firmware in the
RCS should be illegal. Especially because that firmware
is not OpenSourced and not included in Mindstorms - and
hence might well become expensive commercial software in
the future.
Replacing the Lego firmware is akin to sawing a brick in
half to make it fit - and it shouldn't be allowed by FLL.
NQC isn't like that because it's guaranteed by the GPL
to remain free forever and it doesn't actually live inside
the robot. Anything you write in NQC could (at least in
principle) have been written with either RIS or Robolab
so there is no unfair advantage in using it.
> So using NQC could give an
> advantage that others do not have, even if you can't
> use it on a Mac.
No - everyone can use NQC if they want to. There are
no restrictions on what firmware you use, what computer
or operating system you use it one, etc, etc. NQC works
just fine with the standard Lego firmware.
How does that give one team an advantage when anyone
who wants to design their code that way is equally
able to do so?
> Have you ever thought to load and run NQC, and take
> its output and load it in the LEGO development
> environment?
I don't think you can do that. But even if you could,
you'd still be excluding Linux and Mac users from FLL.
Allowing *that* as a sneaky back-door way of allowing
NQC programs compete would be even more ridiculous
than the present rule.
> Seems to me that there is some complaining without
> experience of how 'equal' it might make you if you had
> NQC or other development environment.
As it is now, it's 100% not equal because unless you
use Microsoft operating systems (which are *NOTHING*
to do with Lego), you can't compete - period.
If NQC were allowed, then things would be much more
equal than they are now because people (such as my son)
who'd like to compete - but who don't use Windows - would
be on an equal footing with everyone else. (Well, in a
sense, they'd still be a little disadvantaged because
they still wouldn't be able to use RIS/Robolab - but
at least they wouldn't be completely locked out of the
contest as they are now).
> I also have to say that its a grand thing, to hear a
> Mac user moan about their Mac not being able to do
> what a lowly PC does :)
I'm not a Mac user - I'm a Linux user (using a PC).
My Linux box (or indeed a Mac) is more than able to
build perfectly good software for Lego robots. The
only thing it can't do is get around the ridiculous
and arbitary 'RIS/Robolab'-only rule that the FLL
imposes.
Beyond all issues of fairness (IMHO) is the issue of
educational value for the children who compete in FLL:
The FIRST organisation claims to be pushing educational
standards, learning and the development of useful skills
in children. By forcing them to program in an extremely
wierd and unnatural way (RIS and Robolab are VERY strange
programming environments), you are actually limiting what
they learn from this activity.
NQC - because it's 'Not Quite C' is an awesome way to ease
children into programming in C - which is a real, industrial
strength programming language in which the VAST majority
of real programming tasks are carried out. Learning NQC
leads them naturally and directly into skills that are
applicable in 'real' industrial and research applications
both in robotics and other fields.
RIS/Robolab is an educational dead-end. It leads nowhere
and the bad software design habits they engender may actually
have to be 'unlearned' before a child can learn the right
way to build computer programs.
If FIRST/FLL has to have a rule at all, it should be that
*ONLY* NQC programs are allowed into the competition. (Although
that's *not* something I'd personally advocate).
---------------------------- 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
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
Message has 3 Replies:
 | | Re: RIS 2.0 Problems
|
| NQC bears a stronger resemblance to contemporary programming languages than Lego's development tools do, and a person who is already familiar with programming in any real computer programming language will probably be more productive with NQC than (...) (19 years ago, 6-Mar-05, to lugnet.robotics)
| | | Re: RIS 2.0 Problems
|
| (...) I take issue w/this statement on a number of levels. 1st, is the assumption that RIS/Robolab somehow leads to bad programing habits. Back this statement up! While you can certainly show me some shoddy Robolab code, I can counter w/equally poor (...) (19 years ago, 7-Mar-05, to lugnet.robotics)
|
Message is in Reply To:
| | Re: RIS 2.0 Problems
|
| I think that something might be overlooked here? To ensure that all contestants are playing on a level field, it is necessary to ensure they have the same elements for building their competition systems. To do this, it necessarily requires that (...) (19 years ago, 6-Mar-05, to lugnet.robotics)
|
114 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- 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
|
|
|
|
