newbie question - why not VB or C#?

[tjleech]

My son would like to explore more programming with his NXT outside of the NXT-G that comes with it.

I've done some poking around this site and others and see much talk about NXC, Lejos, RobotC, etc but I see very little about using VB or C#. I can understand if one has none of these, the advantage to selecting one that is free is a great, but I already have VS and know this editor and VB/C#.

Is there a tutorial around that can explain how we can get started programming the NXT with VS? I've seen bits and pieces of information around on this but haven't found a comprehensive answer yet.

Also, besides the cost of VS, what, if any, are the downsides of working in VB or C# compare to the others? Why are these other choices better?

Thanks for your patience with my newbie questions.

TL

[sidneys1]

There's a few different libraries for dealing with the NXT via .NET, the most complete of which would probably be mindsqualls. The major downside of these libraries is that it's pretty much limited to bluetooth connections, and you can't actually compile programs to run autonomously. The .NET program has to have a live connection with the robot at all times, and everything from motor commands to sensor readings goes back in forth via bluetooth. Check out the link above to read more on the Mindsqualls library.

Have a nice day,
~Sidneys1

[linusa]

Also, besides the cost of VS, what, if any, are the downsides of working in VB or C# compare to the others? Why are these other choices better?

The problem is that there is no compiler for VB or C# that would produce binaries (or bytecode) which could be executed on the NXT. There is also no firmware / interpreter / virtual machine or something similar, which would interpret the VB / C# code (probably due to the fact that one would need a .net runtime on the NXT, which won't fit into the memory, apart from tons of other problems).

So this is why you can't put "VB / C# on the NXT". But you can still write an application for Windows, running on your computer, which talks to the NXT. In order to do so, download the Mindsqualls framework.

The problems with this approach:
- Limited set of commands
- Bluetooth latency: Only about 15 - 20 commands per second are possible (USB is faster)
- Imprecise motor control: You can't easily tell a motor to "turn 360 degrees", for example (at least not without the use of heavy workarounds).

If those limitations are ok for you (you can actually manage most of them), you have all the advantages of VB / C# and a computer:
- nice screen
- nice editor
- nice debugger
- CPU power
- lots of memory
- .net library
- internet access
- input devices (mouse, joystick, gamepad, etc.)
- more and more and etc.

[tjleech]

Thanks all for the answers. That helps a lot.

[hassenplug]

The problems with this approach:
- Imprecise motor control: You can't easily tell a motor to "turn 360 degrees", for example (at least not without the use of heavy workarounds).

Not sure I agree with this. Pretty much all the commands you can execute directly on the NXT, are available via bluetooth.

If someone wants to learn PC programming, this may be a good way to go about it. But, as other have pointed out, the NXT really can't be programmed directly in VB/C#

Steve

[linusa]

The problems with this approach:
- Imprecise motor control: You can't easily tell a motor to "turn 360 degrees", for example (at least not without the use of heavy workarounds).

Not sure I agree with this. Pretty much all the commands you can execute directly on the NXT, are available via bluetooth.

Well, if you want to put it that way: The problem is then (again) the Bluetooth transmission delay. It's simply too long for an effective controller loop to do its job.

The problems with a lack of motor precision via direct commands (and especially bad problems when using Bluetooth) are well known. You can encounter them in all languages using direct commands, such as Python, Perl, VB / C# / .net, Java (iCommand) with the standard firmware, etc etc.

I personally think this is one of the big disappointments that lead to the small userbase of remote controlled user programs for the NXT. And this is also the feedback we got from our first student project with > 300 students using the RWTH Toolbox 1.0 (which didn't offer a solution to the motor problem at that time).

I've explained the problem here: http://www.mindstorms.rwth-aachen.de/tr ... rmovements

[hassenplug]

I personally think this is one of the big disappointments that lead to the small userbase of remote controlled user programs for the NXT.

Very interesting. I recall when a few of us first got two NXTs, the first thing we did was make remote control vehicles. In all the remote control applications I've made, I don't think I've ever tried telling a motor to "turn 360 degrees". Usually, I'd just say "run at xx speed, unlimited".

However, I suspect the usage in a classroom situation is much different.

Steve

[afanofosc]

Not sure I agree with this. Pretty much all the commands you can execute directly on the NXT, are available via bluetooth.

There are a number of things that can only be done remotely by using the low level IOMapWrite and IOMapRead system commands. If you stick with just direct commands then you are limited to a substantially reduced subset of what you can do when executing code directly on the NXT. And even with IOMapRead and IOMapWrite some things are still impossible. You can't drawn an RIC file on the LCD screen - even the simple versions - via any kind of remote command and you can't do simple drawing operations such as lines and rectangles either. Screen drawing is limited to writing directly to the Normal or Popup 800 byte display buffers in small chunks.

Don't get me wrong, I absolutely love the capabilities that LEGO exposed for remote control via the direct and system commands. But they do impose a number of non-trivial limitations that do not exist when the code is executing directly on the NXT.

John Hansen

[linusa]

Very interesting. I recall when a few of us first got two NXTs, the first thing we did was make remote control vehicles. In all the remote control applications I've made, I don't think I've ever tried telling a motor to "turn 360 degrees". Usually, I'd just say "run at xx speed, unlimited".

However, I suspect the usage in a classroom situation is much different.

Maybe the different experiences are indeed caused by different use caes. I don't know what you're doing with your PC-based remote control programs exactly, i.e. if the PC-program is really the "only thing that controls your robot" (or if you had just some advanced features / support programs running on your PC).

I usually encounter the need for "TachoLimit-based" motor movements very often. Imagine a humanoid robot that needs to perform 1 step (and a specific sequence of motor movements for that), a robot driving a certain distance, a motor opening a gate or, a robot arm turning 90 degrees to the left, etc.

You can of course monitor the TachoCount live via the Bluetooth / USB link and jam in the brake once the TachoLimit is reached, but apart from the big latency you're also wasting "all your packets" to check the motor positon (and insead you might've wanted to check something else, like sensors).

Another example: A robot has to drive right up to a wall, but should stop when somebody claps:
Yes, of course in NXC / NXT-G I just might turn on the motors, and constantly check the US sensor and sound sensor until the wall is close enough or until there was a loud sound. For a PC-based program, the constant US checking would definitely drain the Bluetooth-packet-rate, and the few sound-sensor checks left might miss the clap. Additionally monitoring motor position is a no-go. So what could do in such a case: Measure distance towards the wall (maybe measure 3 times and take the median to filter out invalid measurements), and then set the correct distance (calculated by hardcoded wheel-circumference, i.e. degrees needed per cm driving distance). Once you've done that, you don't have to care about the motors, the US is also not needed right now, and you could use the full Bluetooth bandwidth for sound sensor polling.

So yes, maybe "effective remote-based code design" leads to the need for these precise motor commands, I don't know.

Or maybe we (as in me & and the students) just happen to think of different robot models or build different stuff than you, which is perfectly fine