Subject:
|
Re: FLL not allowing NQC
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 9 Mar 2005 20:35:42 GMT
|
Viewed:
|
2918 times
|
| |
|
|
John,
I'm involved in FLL up here in Minnesota. For the last couple of years we have
been running a High School FLL pilot program. The high school kids run the same
competition as the younger kids, but they have fewer restrictions. You can have
2 RCX's, but they must be somehow attached to the same robot. You can have any
number of LEGO manufactured sensors. And this year we allowed the teams to use
any programming language they wanted.
I got to judge programming at the state tournament (for high school we don't
have any regional tournaments). I usually judge mechanical design, but I think
the tournament director was having a really hard time finding someone with a
broad enough background to judge programming. Many of the teams consisted of
kids that have grown out of FLL. Most of these teams use ROBOLAB, though a few
tried NQC, and one a full blown C++/BrickOS. The teams without lots of FLL
background split evenly between ROBOLAB and RIS code.
Here are my findings:
According to the competition results, you are best off using ROBOLAB. Second is
a tie between RIS Code and NQC, with C++ coming in last. Do I think this means
that ROBOLAB and RIS are better than C++? Of course not, but given the
limitations of the challenge, all the programming tools are adequate, and
familiarity with a tool is more important than features.
I found the programming in NQC to be no more or less sophisticated than the
ROBOLAB programming. Many of the NQC programs were very simple, and some of the
ROBOLAB programs were very complicated. The more advanced ROBOLAB teams also
knew LASM really well. When ROBOLAB wasn't "working right", reading the LASM
file was the only debugging tool they really had. The most sophisticated
program was done in C++. It had a map of the playing field and a trajectory
planner that told the robot how to get from one location to another, navigating
around obstacles. Unfortunately this sophistication didn't provide any
competative advantage.
Judging a text based program takes longer than judging a graphical language
program. ROBOLAB is easiest to judge. When the program is formated nicely the
patterns jump right out at you. RIS code really isn't a graphical language. It
is a text based language that is assembled using a graphical editor. Too much
information is contained in the text associated with the blocks. The layout of
the blocks only conveys the sequence of the operations. In ROBOLAB, the
graphics show sequence and data flow. And if well designed sub VI's (ROBOLABS
version of subroutines) with descriptive icons are used, the graphics even show
function. Judging the C++ program took much longer than the 20 minutes alotted.
This is in part because of the complexity of the program, but it is also a fault
of the language. There is no one file that I could view that "showed me the
program". You have to study the classes, see how the classes interact to create
an environment, then see how the program uses the environment to complete it's
tasks. Lucky for me I had an open judging slot that allowed a time overrun.
Even then I had to say good bye and good luck long before I wanted.
I'll close by saying that given the structure of the tournaments, I prefer that
LEGO stay with the rule of allowing only RIS and ROBOLAB. There just isnt
enough time to judge programming for less restricted environments. NQC programs
are almost as easy to judge as the graphical languages (maybe even easier than
RIS). Most RIS programs are small, and reside in a single file. But C++ and
Java (and whatever else that comes along where programming consists of
generating a solution environment, then deriving a solution in that environment)
are too hard to judge given the time constraints. I suppose FLL could go to an
"any language as long as you use the firmware" rule, but it seems rather
arbitrary, and how could that be policed?
I supposed FLL could remove the technical judging aspect of the competition, but
I think it is very valuable. It may be only 20 minutes, but that is 20 minutes
where the kids have the undivided attention of 2-3 highly trained professionals
(usually engineers in my experience). I think this interaction is very
important. The kids get a chance to present their ideas, answer questions,
discuss alternatives, and hopefully learn a thing or two. And more importantly,
they are doing this peer to peer instead of adult to child. Pretty heady stuff
for a fourth grader.
OK, so I said I was closing before, but instead I want to close with this rant
(a mild rant because I am a midwesterner of Scandinavian ancestry). If you
don't like the rules, get involved and change them. There is sadly little AFOL
involvement in FLL. I get the feeling the LEGO and FIRST don't really know how
what to do with FLL. They don't have a grand plan, and are eager to embrace the
ideas of others. Active, involved AFOLS could have a much larger impact in FLL
than anywhere else in the LEGO universe.
Dean Hystad
|
|
Message is in Reply To:
 | | Re: FLL not allowing NQC
|
| (...) Done. (URL) NQC executable contained in this zip can now optionally produce LASM-compliant output in its listing file (with the -c switch). I've tested it fairly carefully but it *may* still have a few bugs. So now it is perfectly legal to use (...) (20 years ago, 9-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
|
|
|
|
