Subject:
|
Re: FLL not allowing NQC; Mindscript is allowed
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 10 Mar 2005 20:03:05 GMT
|
Viewed:
|
3381 times
|
| |
|
|
In lugnet.robotics, John Hansen wrote:
> I've coached an FLL team twice (2002, 2003). In both cases we failed miserably
> because we were all completely clueless when it came to mechanical design. We
> couldn't figure out how to design a robot that could manipulate the necessary
> objects while being structurally sound and fast enough to complete multiple
> tasks within the five minute time limit. I could help teach the kids how to
> program the thing (using RIS) if we could ever get a design together that didn't
> suffer from a fatal mechanical design flaw. Even with all the examples out on
> the internet that the kids and I looked at we still couldn't get it right.
>
> No one will ever be able to convince me that FLL doesn't reward mechanics over
> programming. Being able to clean dust off the solar collector, trigger the ball
> launch, deliver the housing modules in a specific physical arrangement, and
> climbing into the crater (etc...) are all objectives which require mechanical
> ability and the programming aspects of these tasks are generally a much smaller
> part of the puzzle.
Of course you won't be successful if you're inept (not saying you are inept) at
any aspect of robot building, be it mechanical design, programming, or
(especially) mission planning. But I still say that a fairly simple robot with
some good programming will usually defeat robots that are more sophisticated
mechanically, but have weak programming. And I base this observation on
mentoring more than a dozen teams and judging at over 20 tournaments during the
last 5 years.
And if it really bothers you that NQC isn't allowed in FLL, get involved again,
as a volunteer. I'm sure that the FLL organization in your state would be
ecstatic to have a volunteer with your credentials. Bitching here may make you
feel better, but it won't do any good. FLL is small enough that it is very easy
to make your voice heard.
>
> > And one final comment. I don't understand engineers complaining that FLL places
> > restrictions on supported programming languages, operating system choices,
> > computing platform and sensor availability. Don't we have to put up with that
> > every day? How much more real-world and educational can you get?
>
> Restrictions without good reasons should not be real-world. I don't stand for
> that where I work.
That final comment was meant as a good natured jab, but since you feel compelled
to comment, I will respond.
There is nothing "real-world" about FLL. You use plastic toys to build little
robots that perform silly missions in a completely controlled environment. It
is a simulation of doing robotics. A simulation that can be run with 20 to 30
other teams in a school gymnasium on a Saturday morning. If the restrictions in
place are artificial, well then they dovetail in nicely with artificial nature
of the missions.
> The FLL restriction regarding which language can be used is
> not based on a good reason. My guess is that the vast majority of volunteer
> judges at FLL competitions have rarely seen MindScript or LASM directly. They
> may be very familiar with the RIS GUI and know every Robolab icon at a glance
> but most probably have a very limited familiarity (at best) with MindScript or
> LASM. But those languages are perfectly legal to use solely because they are
> official LEGO languages.
That's not completely correct. RIS is allowed because it is the language
supplied with the commercial product. ROBOLAB is allowed because LEGO loves it
and it is the language offering in their education products. They love it so
much that I'm a little suprised they allow RIS. FLL was thinking of disallowing
LASM and MindScript (I think I remember hearing this, but not certain), but
since these are the meta-languages that the other products are based on it would
have been a very arbitrary judgment.
> If the rule said you can't use MindScript or LASM because we can't afford the
> cost of training judges in both the GUI-based tools and the underlying
> text-based language then their rule might actually make some sense. But even
> then the rule would be based on a seriously flawed view of judging the technical
> merit of a program. As I mentioned previously, the technical merit of a program
> should only be judged via a team-led review of the algorithm and design of the
> software and not a line-by-line examination of the source code.
There is no cost of training judges. Judges training, as well as the team
training is done by volunteers. And program judging is not a line-by-line
examination of the source code. Teams present their programs by describing it's
function. "The robot does this, then the robot does that, and if this thing
happens then it does this other thing". Sometimes I see teams that present
formalized design documentation. They get awarded pretty good points. The
source code review is mostly to see how they structure their programs, and what
language features are being used. It also provided a small opportunity for more
education. "See how you keep repeating this same group of statements? Wouldn't
it be useful if you could somehow encapsulate that function into a component
that you could reuse throughout your program? Have your heard of events?
Events might be useful here in your program where you're watching for one of
these two things to happen."
If FLL were to
> do this sort of judging correctly then their judges would not need to be highly
> trained in every supported language. They would simply need to be someone who
> understands the programming concepts common to every programming language. The
> FLL team members would provide the language-specific knowledge to explain and
> present their software in a language-generic manner. And if FLL were to allow
> NQC in their competitions I would wager that they would find a substantial
> increase in adult volunteers as team coaches and as judges at competitions. The
> available pool of interested and experienced people is simply much larger with
> NQC included than it is with it excluded.
I rather doubt the volunteer pool would change all that much. You appear to be
under the false assumption that AFOL's show an interest in FLL. Sadly it is my
experience that this is not the case. Volunteers and coaches are most likely to
be teachers and parents, with a good mix of engineers thrown into the mix. That
there is an untapped pool of NQC loving AFOL talent just waiting for a rule
change is crazy. You don't volunteer for FLL because you like LEGO and
Mindstorms. You volunteer because you like kids.
Dean Hystad
|
|
Message has 1 Reply:
 | | Re: FLL not allowing NQC; Mindscript is allowed
|
| (...) Explain to me how good programming compensates for a robot that can't travel straight or that has no mechanical means for completing the mission objectives? If by good programming you mean that the program checks sensors to adjust the (...) (20 years ago, 10-Mar-05, to lugnet.robotics)
|
Message is in Reply To:
| | Re: FLL not allowing NQC; Mindscript is allowed
|
| (...) Because any language that targets the standard LEGO firmware on an RCX brick can not result in any competitive advantage while the other examples you cite clearly would lead to an unlevel playing field. LEGO already provides a language choice (...) (20 years ago, 10-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
|
|
|
|
