Re: Frustration with NXT-G 1.1

In lugnet.robotics, "Doug Wilcox" wrote:

> I was thrilled when my wife presented me with an NXT for
> our anniversary...

Please let your wife know that she has *really* cool tastes in anniversary gifts
:).

> At first glance, it appeared that the NXT-G was
> wonderful...

I still like it quite a bit, but it seems among adults I'm a minority (or an
aberration... I've been called worse). I agree that the bugs in the IDE in
particular can drive you crazy, and it takes me longer to do some things
graphically than I could in a text editor. Like you, if I compare NXT-G to
something like RIS I shudder at the second - NXT-G is a quantum step forward,
but still behind in some ways for power users.
 
> My primary interest was in determining whether it
> would be easier to teach my kids NXT-G or NXC.

That depends. Are you trying to teach your kids how to think in C or a C-like
language, or are you trying to teach them how to acquire new skills? For the
former, I'd suggest RobotC (for a number of reasons, the main downsides being
cost and that it's not open platform). I'd probably be using RobotC myself if it
was available on a Mac (closer to C, and more importantly for me more powerful
and *much* faster than other options based on the stock firmware).

> For example, see this image...

What's happened there is that sequence beams within the multi-state Switch have
become corrupted. The best way I know to fix that is to rip out the block
sequences within each state of the Switch (saving them somewhere else on the
worksheet for later), and then tearing out the corrupted Switch, replacing it
with a new one, and then selecting and dragging the sequences back into the
proper cases of the Switch. I agree, this isn't at all ideal. I'm not sure why
that happens (or why it doesn't seem to happen to me), but it *is* very
annoying.

Note that here I suspect part of the problem is you are trying to use a Switch
when there's little reason. For instance, for each case you need to move the "B"
motor a different distance, correct? It might be far better to calculate (or
even use a simple look-up table) to determine those distance, and then *wire*
the result into the Motor B blocks. This sort of thing (working with the
strengths of NXT-G, instead of forcing on its weaknesses) is one of the things I
must admit I really like - it's a thinking puzzle for me (and for those of you
who think that's not a part of the MINDSTORMS product, consider that we all keep
trying to build industrial and innovative autonomous robots... with a childs toy
:) ).

--
Brian "Wanted: RobotC for OSX" Davis