What software program/language is best for roboRio? [Archive]

newbieQs

30-07-2015, 12:15

Thad House

30-07-2015, 12:26

I've been out of the game for some time but interested in helping my community start a team. One of the first aspects I was looking to brush myself up on was the "brain," for the robot. I noticed here on this link https://wpilib.screenstepslive.com/s/4485/m/13503/l/144981-2015-frc-software-component-overview that LabView was suggested. It has been awhile since I have used this program and I was about to delve into tutorials and videos for it but wanted to know what the community would suggest is the "best," program or language to utilize.

Thanks

FIRST considers LabVIEW the best because it is the language officially supported by NI, who makes the RoboRIO. Many teams use LabVIEW, and at most events you will find many teams that know it and can help you.

If you don't have a lot of programming experience, either with the students or the mentors, I would recommend it as well. Teaching LV is fairly easy, and its easy to get a robot up and going.

A lot of the more advanced teams use either C++ or Java because it does allow for easier multi user development, code reviews, and they run faster then LabVIEW (Although with the RoboRIO this is much less of a problem then it used to be). However, if you are just starting, I would recommend LabVIEW just because of the support you will be able to get.

Ari423

30-07-2015, 12:33

My team has always used LabVIEW and is very happy with it. I also know how to program in Java (not robot programming, but still) but I actually prefer using LabVIEW.

If you learned to program with a traditional text-based language, the transition to block-based may be difficult and you may consider Java or C++ (or one of the other options). If you don't have much programming experience, LabVIEW is great for both beginners and experts, and it isn't very hard to learn.

Some people complain that there isn't much support for it at regional events, as many teams are switching over to Java or C++, but this has never been a problem for me in my 3rd year as head programmer.

All things considered, once you are proficient in any language the limiting factor is the programmer, not the langage.

Pault

30-07-2015, 12:57

I personally prefer Java over LabVIEW. I have been on 2 teams that recently switched between the two (one team from Java to LabVIEW, one team from LabVIEW to Java), and the students on both overwhelmingly prefered Java.

In general, there are more teams that use LabVIEW. But from what I have seen, New England has a ton of Java teams, especially among the top teams that you would usually go to for assistance. There is also support at a lot of local events from the crew at WPI that codes the FRC Java/C++ libraries.

The biggest downside is that the initial hurdle of teaching students the basics of Java is a lot tougher than teaching LabVIEW. But once they know the syntax, it is fairly easy to write FRC code (if you are concerned about difficulty, just use RobotBuilder).

I would heavily caution against using LabVIEW if your team has a lot of students with prior coding experience. I don't think I have ever seen someone enjoy going from a text-based object-oriented language to LabVIEW.

Also, C++ is very similar to Java, especially in the context of FRC. Most of what I said above applies to it aswell.

SoftwareBug2.0

30-07-2015, 13:01

Do you have any students or mentors who already know some programming language or would be willing to start learning one before the season starts? If not then you probably want LabVIEW.

Do you have any students or mentors who already know or would be willing to start learning before the season starts C or C++ or assembly or some other language with manual memory management? If so then C++ is an option for you.

If you answered yes to the first question and no to the second question you probably want Java.

Oblarg

30-07-2015, 13:07

I would recommend sticking to a "traditional" text-based language (i.e. C++ or Java) simply because I believe the skills learned are much more easily transferable to other contexts.

Having used the WPI "command based" Java framework for the first time last year, I can safely say that it is reasonably well-documented and very intuitive.

page2067

30-07-2015, 13:17

We have been using Labview since we started. We like the support and have not found it to be at all limiting in what we can do - I think the most common advice is to go with a language that your programming mentor knows best. We know of CT teams that perform well in LV, Java or C++.

Since I see you are in CT - can I ask what commnuity? The Connecticut teams have become increasingly close and have a common interest in helping all of the teams improve their performance level. There are many here that will like to help a new team - feel free to PM if we can be of help with some kitparts, training or other.

connor.worley

30-07-2015, 13:32

LabVIEW - easy to learn, lots of knowledge within FRC, has a niche in automotive / manufacturing industries
Java - easy to learn, works well for AP Computer Science students, very popular in general
C++ - harder to learn, best performance, fairly popular in general, translates well to other robotics applications (microcontrollers)

Katie_UPS

30-07-2015, 13:32

It depends on your team and resources. The difference in speed between C++/java/Labview is going to go unnoticed, because even slow computers are fast.

If your students have programming courses offered that use c++ or Java, then go with that. If you have a mentor (or multiple) that are proficient in one of the languages, then use that one.

If you're starting at ground 0, look at your goals for the team and use that to guide you. If you want your students to get "real world" programming experience, C++ and Java (and other text based languages) are far more common in industry. Learning C++ in high school, I've been told, "is like drinking from a fire hose," but its also one of the harder languages to learn, so its a cool skill for high schooler to have. Java is considered more accessible for a text-based language, is commonly taught in high schools (AP and IB Comp Sci use it), and is one of the first languages students learn in college if they take a computer major (Computer Science, Computer Eng, Software Eng).

I can't really speak for Labview, as I've had minimal experience with it. Its barrier of entry is probably lower and students still learn skills necessary to "think like a programmer."

Ari423

30-07-2015, 13:38

I think the most common advice is to go with a language that your programming mentor knows best. We know of CT teams that perform well in LV, Java or C++.

^^^^^^
I second this. The programmer knowing what he (or she) is doing is much more important than what language they use.

I would recommend standardizing the team to use one language (even if different students have experience with different languages) because otherwise you will need to re-image the RoboRIO every time you want to change languages.

Monochron

30-07-2015, 13:45

I think asking yourself two questions will solve this for you.

Q's:

What programming skills do your students or mentors already have.
What are you priorities for the team going to be?

A's:

If you have students or mentors who are familiar or proficient in one of the languages I recommend going with that language (unless it interferes with question 2). If you do not have any students or mentors with experience, then I would recommend LabView (unless it interferes with question 2). The breadth of support and slightly easier learning curve of LabView make it a great starting point to quickly build a successful robot. Also, LabView is used often in industry, especially in robotics. While your students won't really be familiar with a written language, knowing LabView is still a valuable skill.
If your top priority is building strong computer scientists then one of the written languages will likely give them a broader set of skills (imo). The concepts learned in C++ or Java are applicable to many sets of written programming languages. If your top priority is building a competetive team quickly then LabView may be better due to it's somewhat easier learning curve and the breadth of support that you can find. If your top priority is building the most sophisticated robot you possibly can then I think one of the written languages is going to be more useful (check and see what other top teams are using).

Knufire

30-07-2015, 13:58

If your top priority is building the most sophisticated robot you possibly can then I think one of the written languages is going to be more useful (check and see what other top teams are using).
[/LIST]

I don't have any data, but from what I see the top teams tend towards Java, then C++, then Labview. There are "top teams" proficient in each of those languages however; it really comes down to what the students and mentors are most familiar with.

thatprogrammer

30-07-2015, 14:04

If your mentor already knows Labview, use that. In any other case I would recommend java. Learning Java will teach kids how a text language works, which should allow them to learn many other languages without difficulty. Also: They should be able to view many of the top team's code and learn from it. (254, 1114, and 971 all used text languages)

Arhowk

30-07-2015, 14:28

A lot of teams are starting to move to interpreted languages (Python, JavaScript, etc) because the new roboRIO has the processing power to handle them. Interpreted languages have numerous benefits, such as no deploy time and the ability to grab code from the roboRIO. If you have a mentor that is able to handle the nuance of doing such than I'd recommend it.

However, if you have no one able to handle an interpreted language than I'd stay with Java or LabView since you will be able to receive support from your friendly neighborhood CSA.

Larry Lewis

30-07-2015, 15:12

Ari423

30-07-2015, 15:23

Another possible approach is to give the students the opportunity to use more than one language if you have the mentor and/or experienced students to support that.

For example you could use C++ or Java for the robot and LabVIEW for the operator controls. That way students get exposure to more than one language so they can determine what they are most proficient in.

I don't know much about robot code in Java or C++, but I know for LabVIEW most (if not all) of the input processing is done on the RoboRIO. You can program a fancy dashboard (as I usually do) but I don't know if a LabVIEW dashboard can communicate with a Java or C++ robot. I can definitely say that if you do decide to try both, you should switch them at some point because programming a dashboard in LabVIEW is very different than programming a robot.

TheHolyHades1

30-07-2015, 15:32

One thing that I don't believe has been mentioned is the speed / ease of teaching C++ and Java vs LabVIEW. While my teams haven't had experience in LabVIEW, I can say that FRC Java/C++ is often quite different from "real world" Java/C++, in that generally, a limited subset of the language is used.

I would second the advice about using the language your programming mentor knows best, but I'd also add that if you're planning on teaching students in a standard fashion, similar to a high school / college intro programming course, then the span of preseason isn't usually enough to get it done (at meetings, at least). If you're just teaching FRC specific coding, then with some effort it is certainly possible.

Larry Lewis

30-07-2015, 15:33

I don't know much about robot code in Java or C++, but I know for LabVIEW most (if not all) of the input processing is done on the RoboRIO. You can program a fancy dashboard (as I usually do) but I don't know if a LabVIEW dashboard can communicate with a Java or C++ robot. I can definitely say that if you do decide to try both, you should switch them at some point because programming a dashboard in LabVIEW is very different than programming a robot.

In the past we have done a LabVIEW dashboard while using C++ for the robot code. So that is a possibility for teams if they want to go with that approach.

I agree that programming a dashboard is very different than programming a robot. What I am suggesting is that by programming the robot in one language and the dashboard in another, you can give the same or different students some familiarity to the programming environments of both.

That being said I would introduce the students to both languages you choose prior to build season so that you are not trying to "learn on the job" during build season.

virtuald

30-07-2015, 22:30

Obviously, write the robot in Python (https://github.com/robotpy/robotpy-wpilib), dashboard in HTML5/Javascript (https://github.com/robotpy/pynetworktables2js). :D

SoftwareBug2.0

31-07-2015, 01:31

... Interpreted languages have numerous benefits, such as no deploy time and the ability to grab code from the roboRIO...

I don't mean to hijack the thread but this reminds me: When my team went to a compile/upload cycle outside of Eclipse we got a pretty dramatic speedup. We found that for C++ the waiting didn't need to be more than a couple seconds.

Arhowk

31-07-2015, 12:31

Obviously, write the robot in Python (https://github.com/robotpy/robotpy-wpilib), dashboard in HTML5/Javascript (https://github.com/robotpy/pynetworktables2js). :D

Beat you :D

I don't mean to hijack the thread but this reminds me: When my team went to a compile/upload cycle outside of Eclipse we got a pretty dramatic speedup. We found that for C++ the waiting didn't need to be more than a couple seconds.

I actually modified my eclipse build scripts for Java and was able to get the deploy time down to 20% of what it used to be by removing useless junk (like checking if the robot has a JRE) and performing build-only-as-necessary.

Although it's decently irrelevant to the topic.