Subject:
|
Re: How many people signed up for the NXT Developer's Program?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 18 Jan 2006 16:28:37 GMT
|
Viewed:
|
1856 times
|
| |
|
|
In lugnet.robotics, dan miller <danbmil99@yahoo.com> wrote:
> --- Steve Hassenplug <Steve@TeamHassenplug.org> wrote:
>
> > More powerful than what?
>
> Good question... My understanding is that something like LabView, which has
> been used by FLL and others for some time now, is being shipped with NXT.
I'm wondering what it means to be "something like LabView". Robolab is
something like LabView, but it isn't LabView. It is a GUI application written
in G running in the LabView runtime engine. LabView itself (i.e., the editor
and the underlying engine) is not written in G. It is written in C++/C (I
believe). LabView as a development environment has been pretty stable for me,
although I have managed to crash it on occasion.
Do you think that the NXT software will be LabView with special VIs or will it
be (like Robolab) a GUI application written in G? From the one image I saw
linked to in an earlier post the GUI did not look like the LabView front panel
and block diagram editor windows I am familiar with. I'm worried about the
stability and quality of a GUI application written in G and running on the
LabView runtime engine. Didn't it take several revisions over a number of years
to finally get Robolab to the point where it was useable for more than simple
programs? I've used the latest release of Robolab and from my perspective as a
professional software engineer writing commercial applications used around the
world it still seems rather amateurish in its appearance and GUI behavior. And
from what I have read there are still plenty of bugs in Robolab which make
writing advanced programs more difficult than it should be. Is this the future
of the NXT software? I sure hope not.
Can anyone who has had experience running complex GUI applications written in G
comment on the performance, stability, and quality of user interaction in such
programs? Do complex programs written in G suffer from the same sort of flaws
you see in a lot of applications developed using 4GL languages (i.e., bug-prone
and having UI quirks)?
There are a couple of other things that worry me about the NXT software given
what we have been told so far by the various FAQs and press releases. If it is
based on LabView and the G programming language does that mean that types will
be distinguished by color as they are in G? Will a wire connecting an integer
variable to a VI be orange, for instance? I really dislike the way LabView uses
color and wire thickness as the way to tell types. It looked like smooth
technic beams were used as a connection between blocks in that one screenshot I
saw
(http://cache.lego.com/upload/contentTemplating/LEGOAboutUs-ImageLibrary/images/2057/pic99228FEF-67E2-4510-A3A6-2ACBDB337328.jpg).
Maybe they'll use different colors of smooth beams, like bley. :-) A half-wide
liftarm could represent an integer while a full-width beam could represent a
LabView cluster (aka record structure) or an array of clusters. I'm kidding, of
course. Color coded datatypes strike me as a very bad idea. What if I'm
red-green or yellow-blue color blind? Hopefully the NXT software will not
follow LabView and G in this manner.
And the G language used in LabView is what is known as a dataflow language. In
a dataflow language the program execution is not a series of sequential steps as
you would find in a more traditional language like C or Basic. Instead a unit
of code executes once all of its required inputs are satisfied. The standard
LEGO firmware for the RCX and other programmable bricks (and languages which
targetted it, including Robolab) was modelled after the more traditional and
familiar imperative form of programming where you could define multiple tasks
and explicitly start and stop them. Whether the new NXT firmware will be a
souped-up version of the firmware we are familiar with from the RCX or a
completely new beast (possibly modeled after the dataflow language paradigm) is
impossible to say at this point. My preference would be for the former. That
would certainly make the work I'll have to do for NQC and BricxCC simpler.
Hopefully, like Robolab, the NXT software will generate LASM (or maybe
MindScript) and there will be a compiler in a COM automation object like what is
included in the MindStorms SDK which I could use from within BricxCC like I do
today.
The screenshot mentioned above gives me hope that the NXT software is kind of
like the old RIS software with respect to defining multiple tasks. It looks
like maybe the spikey-haired kid has defined two task that run concurrently.
The top line of blocks appear to control motors b and c together with separate
block doing something to motor a. The hourglass microphone block might be a
wait for some sound sensor value. The bottom row looks like an infinite loop
with two blocks that do something to the display and the hour glass block could
be a wait for 1,000 milliseconds or something like that.
John Hansen
|
|
Message is in Reply To:
77 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
