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