Im new at this this year and i was wondering what the pros and cons were of the different programming languages we can use. My team is probably going to use RobotC, is this a good one to use?
RobotC is great! I don’t recommend NXT-G though as it is limited and I can only imagine the size of the program for an entire FTC robot. As for LabVIEW, I have no comment, great tool, can be confusing to new programmers though and might take a while to become at a level where you can easily program the full code for your robot.
Robot C:
Pros:
Advanced Firmware!
Faster
Uses less memory
Floating point math
Just more math functions in general
Simple little things that NXT-G can’t do (i.e. wait for a random amount of time)
Some great debugging tools
Simple interface
Good ol’ C
Here’s a few other “Pros” for ROBOTC.
The elapsed time from when you move a joystick or push a button on the PC Game controller until a motor speed or servo position is changed is much faster. ROBOTC has an optimized Bluetooth messaging mode that is about 50% faster than NXT-G. And ROBOTC messaging to the HiTechnic motor controller is about twice as fast. The cumulative effect is tens of milliseconds faster. Your robot will be more responsive to game controller movements.
Many sample programs specifically focussed on FTC robotcs and game operation.
A PC “dashboard” that gives you continuously refreshed views of all the motor speeds and encoder positions, the servo positions and sensor values. You can even change motor speeds and servo positions via dashboard controls. The dashboard display operates simultaneous with your program running and the built-in Controller Station (i.e. Game Controller testing) function.
A Controller Station (CS) “application” built-in to the ROBOTC development environment (IDE) for easy testing of user control game mode. You can use the single ROBOTC IDE for you edit code, compile, download, test cycles; there’s no need to switch between mutually exclusive IDE environment and standalone CS environment.
NOTE: I may be a little biased. I’m involved in ROBOTC development.
As much as I love C, we’re going to use LabVIEW this year.
Why…
Because we’re also using it for FRC.
And why are we using it for FRC?
Because we’re also using it for FTC 
Seriously, NI is destined to become a force in the robotics industry, now that they’ve captured FIRST’s mind and soul.
I see C and C++ as the “programmer’s” language, but LabVIEW as the “Scientist and Engineer’s” language. Since the later is a bigger part of the the pie… I thought it best to bite the bullet and lead the charge.
If using labVIEW encourages more students to become programmers, they can learn C++ in their CS classes
Hey…me and my team is doing FRC this year for the first time. Our fabricators/engineers know how their job works but as a programmer I really don’t know to much on “Robot Programming”. I do VB/html web based programming but do not know much on other types. I am willing to learn how and want to be ready.
So first of all, it seems like either RobotC or lab view are the most popular ones to use. For a programmer like me, which one should I use. I can easily learn in like a month all about it so I just want to know which one is better to use. Please reply.
Hey stealthkill,
I’m sure you have some basics of programming down, so I would suggest that you go through and try to learn RobotC. RobotC is easy to learn and even easier to use. Visit www.ftctraining.com to get started.
After that, I would suggest you expand your knowledge to Labview. Labview may be difficult, I think it would be beneficial for you to create a strong base in RobotC before you go testing Labview.
So are we, and for many of the same reasons.
Please try out our FTC LabView Programming Template, and let the community know about anything you find there that needs fixing, or that could be helpfully changed or added.
Hi Richard…
That’s pretty cool and useful. In many ways it mimics the template that shipped with the FRC LabVIEW beta test. Lots of good comments too.
I’ve been playing with the encoder controls a bit, and your code would be easilly adapted to that to (constant speed vs move motor)
My only trivial suggestion is that instead of inverting the drive signal to one motor, you can set the “Invert” input to “true” for that wheel.
The only reason I mention this is because if you do end up using the encoder based motor drives, the “invert” input is also used by the encoder code, so both motors will count in the same direction, even though one is running in “reverse”.
Phil.
Thanks for the suggestions, Phil. I will pass them along to the team’s software developers.
To avoid further hijacking of this thread, can I ask that further discussion of ways improve the template be moved to the other thread?
What programming language are we going to use this year?
I asked myself the same question at the beginning of the season. Then I took my two programmers to a LabVIEW Users Group meeting a few weeks later and one of the people from Innoventor asked my students if they would be interested in an internship once they had learned LabVIEW. I immediately understood that LabVIEW was the right choice. It is the industry standard and to learn anything else would be a waste of time. So we have jumped headfirst into it and haven’t looked back since.
What industry is that?
I Don’t know. Labview seems a tad bit complex from generic programming. I’m wondering, is there some sort of advantage to Labview compared to RobotC?