Subject:
|
Re: FLL not allowing NQC
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 12 Mar 2005 09:16:49 GMT
|
Viewed:
|
1178 times
|
| |
|
|
Having followed this very active thread with interest, there's several
important points that seem to have been very lightly glossed over.
The content of Robolab is changing and the FLL organizers will almost
certainly have to deal with this issue. There are currently two Robolab
versions. The standard version that has been around "forever". "Ultimate
Robolab" is a second version currently available for free download.
Ultimate Robolab (UR) creates a standalone firmware file from a program
that is then downloaded to the RCX. It is not a byte-code interpreter. I
expect UR programs provide real time performance comparable to BricxOS.
UR programs are written in the Robolab graphical language but with a set
of similar but different graphicals icons so that a program written in
standard Robolab probably requires tweaking to run in UR. I think FLL
will have to address the issue of whether UR programs are allowed in the
competition.
Anyone reading this message (i.e AFOL) is undoubtably in the minority of
Mindstorms users. I'm sure there's at least 10 times as many Robolab
users as there are non-Robolab (NQC, BricxOS, etc) users. Lego has a
strong and active program for Mindstorms / Robolab in the educational
market whereas Mindstorms for the AFOL and consumer market appears
totally stagnant. [I thought this was an interesting point, but only
partially relevent to this thread].
There were many posts on how you could implement any program in any of
the various programming environments. I disagree. There definitely are
differences between the different programming environments that result
in capability differences that could provide a competitive advantage.
Here are a few huge ones:
- It is possible to treat the datalog as one huge array. This is not
supported in standard Robolab. If not already supported in NQC, a few
simple user "#defines" would give basic capability for this.
- UR supports 'float' and 'long' variables.
- Robolab reserves several variables for internal purposes. NQC does
not. Hence with NQC, user programs can define more variables which is
significant
Competitive advantage is not just in the resultant program code, but
also in the speed and quality of the developed code. Again there are
differences.
- Quadruple speed downloading of firmware is available with NQC.
- Arrays are far easier to implement in NQC.
- In general, NQC generates more efficient code than Robolab. Hence user
programs will execute faster.
- Robolab datalogging is more sophisticated. This includes its ability
to sub-divide the datalog into separate smaller datalogs and its full
access to the PC based analysis capabilities of Labview.
- Personally I find it easier to name variables as "leftMotor",
"nErrorValue", etc which is the NQC functionality. Robolab variables
(which they refer to as containers) have pre-assigned names -- "red",
"blue", "user1", "user2", etc.
I haven't seen much comment on John Hansen's recent add to NQC to create
a text file containing LASM commands. It would seem that developing and
testing a program using NQC and then, just before competition, compiling
the LASM text with Mindscript will be "legal". If so, why not simply
allow NQC? [As an aside, Robolab also has an graphical "icon" where a
block of LASM commands can simply be pasted.]
A furthur issue for the FLL organization, is the replacement backwards
compatible firmware. [Which I have authored]. It provides several
competitive advantages such as:
- 10X faster real time performance. With this, programs can implement
more powerful algorithms. As well, faster real time may allow for looser
mechanical tolerances in gear ratios, etc.
- Rotation scanning can be reconfigured to six times faster than the
standard 3 millisecond rate of the standard firmware.
- A true priority scheduler among tasks. Standard firmware only has
round robin scheduler and all tasks are same priority.
Any of the above could be useful in implementing a FLL robot.
- 128 (vs 8) power levels for motors.
- 1-millisecond resolution timers and clock.
The rules may state that only standard firmware can be used in a FLL
robot. But this option may become very blurred if, as is a possiblity,
the 10X firmware is distributed in a Robolab patch/upgrade release. How
do you tell the unsophisticated FLL team and its coach that their entry
has been disqualified because they downloaded a patch from the official
Robolab site?
|
|
Message has 2 Replies:
 | | Re: FLL not allowing NQC
|
| (...) I believe they use the color convention for localization reasons. Robolab is available in 16 (?) different languages. As the code is picture-based, only the environment needs to be localized. Generally speaking, how are text-based languages (...) (20 years ago, 12-Mar-05, to lugnet.robotics)
| | | Re: FLL not allowing NQC
|
| (...) Robolab, in fact, currently delivers a different version of the standard LEGO firmware than what is otherwise publicly available. How, pray tell, is that fair to FLL users who don't use Robolab? Talk about an unfair advantage. (...) I can't (...) (20 years ago, 12-Mar-05, to lugnet.robotics)
|
Message is in Reply To:
| | FLL not allowing NQC
|
| Hi, The ROBOLAB software with training missions and site license (for all computers in one building) -- $235 from LEGO directly, URL: (URL) says it runs on Mac and Windows, and I know one of my students runs it on a Mac. Don't know which OS, but you (...) (20 years ago, 7-Mar-05, to lugnet.robotics)
|
5 Messages in This Thread:
  
- 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
