New to NXT - compatibility question

[mightor]

I submitted ten puns to a joke contest, hoping that at least one of them would win, but no pun in ten did.

[mattallen37]

[HaWe]

I submitted ten puns to a joke contest, hoping that at least one of them would win, but no pun in ten did.

sure, it was a joke contest.
Don't give up! Try it again to a pun contest!

[spillerrec]

The RIS sets used studded technic parts, and the NXT sets use studless technic parts. Both types of beams play nicely together, and all gears, pins, axles, bushings etc. are identical (i.e. they are compatible, not necessarily to say that the NXT sets includes the same parts or quantities as the RIS sets).

While they can be used together, in practice the compatibility isn't that great. Studded Technics works with even numbers, studless Techincs works with uneven numbers. (So it is uncommon to see them freely mixed together, unless people want to use System parts for styling.) The difference causes some subtle issues with a lot of parts.
Gears: The old gears where made to use with the studded beams. Notice that studded beams have an extra 0.5 space at the end, compared to studless beams. The old gears uses that extra space, the newer gears does not. This is usually not a problem, but if you want to place two gears in a 90 deg angle, the beams wouldn't match up if use studless beams and "studded" gears (or the other way around). You can fix this by using half-width brushes, but it is not optimal as it is weaker and more space consuming. It is just a matter of choosing the right gear for the job though.
Axles: If you have a lot of axles from studded sets, you should have good amount of axles with length of: 4, 6 and 8. However studless building mostly requires uneven lengths like 3, 5 and 7. So while they are completely compatible, you will simply rarely end up using a lot of the 4, 6 and 8 length axles in studless building and you might find yourself lacking sufficient amounts of 5 and 7.
Other:Some special parts have been replaced with versions that match better with studless building, for example the differential (RIS 2.0) which have changed from a width of 4 to 3. It is perfectly usable, though you would usually need a width of 5 and the old style gears. (I still find the old one superior for heavy duty stuff though.) The turntable included in UBS (Ultimate Builders Set) is studded, which is a real pain to work with in a studless construction, because of the even width and slightly awkward position of the holes. (The little bit of pneumatics in UBS is also studded, but they are quite similar to the studless versions so there shouldn't be any issues.)

To sum up (or tl:dr):

• You will usually want to stick to either studless or studded building when constructing something. While it is possible to mix, there is rarely much gain with it and it can easily complicate matters if you are not careful.
• While many parts do not contain studs, they where designed to be used together with studded parts and in a few cases this can make them less useful together with studless building.
• If you only do studless building, there is a fair amount of parts you will end up not using, either because it is not useful or because there are better alternatives. (With that said, most parts are useful and if you not have enough of a certain part, you can use the "less preferable" alternatives in most cases.)

I would recommend NXC too, but since you seem to have a good grip on programming I will point out that there are quite a few different text-based languages for NXT out there. If you fancy some particular language, there might be NXT version out there. This forum is probably the place if you want help on NXC though.

Also since you already know programming fairly well you will probably want to focus on learning how to build. There are some books out there, but there are also plenty of free building instructions available on the internet. Try these:
Lots of building and programming instructions: http://www.nxtprograms.com/index2.html
A few models by the guys from the old official Mindstorms forum (including me): http://ricquin.net/lego/instructions/
Bonus models by MDPs and JMDPs: http://mindstorms.lego.com/en-us/suppor ... l%201.aspx

As far as I know it is not possible to program the RCX on 64-bit systems because of driver incomparability, but if you have the time I would recommend you to try building some of the models from UBS nevertheless. They might be studded but they are great models anyway, I especially liked the disc shooter and plotter. (The software should be able run if I remember correctly, but you might have to mess with the comparability settings.)

[dougwalton]

Fantastic information - I appreciate it - thanks!

BTW, a few minutes ago, I ran across RobotC for NXT. Other than cost, how does it compare to NXC with the BricxCC IDE?

Cheers,
Doug

[mattallen37]

I use both NXC and ROBOTC, so here's what I have to say, based only on my own personal opinion.

ROBOTC:

• debugging is more advanced.
• FW VM runs code significantly faster (I think I remember hearing it's about twice the speed).
• Is considered an "official" NXT programming language, so it's within the rules to use for "official" competitions such as FLL.
• Is slightly more limited, as far as how much of the resources are available to the user.
• IDE is extremely glitchy, and not very fun to use.
• Supports BlueTooth as a master and single slave (two NXTs total).

NXC with BCC:

• FW is totally backwards compatible, so you can program in either NXT-G or NXC without changing the FW.
• IDE seems to run almost perfectly.
• All un-used resources are available to the user.
• No SW limit as to the amount of variables, arrays, data structures etc.
• No pointer support (at this time, there isn't pointer support in ROBOTC either).
• Supports BlueTooth as a master and three slaves (four NXTs total).
• Decent file system support (for reading and writing files).
• NXC and the BCC IDE are open-source, so anyone can contribute to make it better.

Both systems have pros and cons about the LCD, and the API. Displaying in NXC seems much less limited than ROBOTC.

NXT <> PC BlueTooth is terrible at best, regardless of programming language/IDE.

There are probably a million other big differences that I'm forgetting about. Once you get the NXT, give NXC a try. If you feel like you could benefit more from ROBOTC, then you can try the 30-day free trial to see what you think of it.

[dougwalton]

Copy that, Matt. Again, thanks for the great info. NXC first - will do. Ideally I'd find something that supported C#, but for now C will be just fine, and I have no urge to dive back into pointer silliness anytime soon.

Cheers,
Doug

[hassenplug]

This may be useful...

http://www.teamhassenplug.org/NXT/NXTSoftware.html

Sorry, but I haven't updated it in a couple years. On the other hand, there haven't been significant changes in the offerings.

A couple adjustments to Matt's comments:
Robot C
- is many times faster than NXC.
- The Bluetooth is totally different, and is more point-to-point than master/slave (still, only two nodes).
- You have more control of the bluetooth communications, in case you want to talk to something other than an NXT
(like http://www.teamhassenplug.org/robots/GreenMonster/)
- IDE is windows-only
- Compiler built into IDE
- NOT legal in FLL, but is legal in FTC (the next level higher)

NXC
- "Backwards compatible firmware" meaning most other programming environments use the same firmware as NXC
- programs can be compiled without IDE
- also not legal in FLL. But, this won't matter to most people.

As a programmer who uses Visual Studio, I found both IDEs to be a bit "funky".

My suggestion:
If you just want to make your robots do stuff, NXC is fine.
If you want to do cool programming (less about robots, more about programming) on your NXT, go for Robot C

Steve

[dougwalton]

Thanks, Steve. For now (for me), it's all about programming some robots and learning about all that. C sounds fine. I get enough C# programming at my day job to satisfy any needs I might have to just program stuff.

FWIW, the most fun I ever had with software development was a project I was on about 15 years ago that involved an extremely complicated, automated blood testing machine. The complexity blew my mind. Probably 10-12 hardware engineers, maybe 7 software developers, numerous CNC guys. All kinds of crazy-but-precise hardware stuff going on both synchronously and in parallel - test tube racks with robot arms pulling them from racks, scanning barcodes, and then putting them onto a circuitous movement path through the system, spinning centrifuges, liquid pipetting, UV light readings, chemistry analysis, supply and waste fluids management, exception handling, etc. etc., all in the space of about the size of a compact car. I got to write higher level C++ code that performed tasks on the device - like "unload the entire device" and "reset the entire device". This involved lots of carefully coordinated concurrency between all of the various operating mechanicals on the device so that the device could be cleared in, say, 5 minutes instead of 90 minutes.

It was easily the most fun I've ever had with software in my career. I would start my program, and the entire machine would go into a controlled frenzy as 15 different things would be performed in parallel, and as they finished, other things would start up, and so on. So the idea of making software control physical robots again sounds like huge fun. I have no idea where this might take me.

[h-g-t]

You should have built it in LEGO .........