FRC Java or Labview?

FIRST General Forum
1

Hello all teams,
My team is getting ready for next year and we are thinking on working with Labview and not with Java as it was until now.
I know that many ask this before but every case is a bit different.

So the team that I am in is exist since 2006 and they always used Java, now, some graduated members are trying to make as use Labview, cause they are not satisfied from the results since the beginning as they say. We never won the local competition, we lost in some of the finals, but most of the times we can’t get to the finals stage. I am the programming team leader next year, this is my call if we switch to Labview completely or only the electronics team will use Labview in order to test all the sensors (which is new too).

As I see it, Labview is for teams that are new or not really good at this part and want to focus on the robot.
So for me it’s like going backwards, but I realy want to hear other opinions.

Thanks in advance :),

Nimrod #2231.

2

I can’t comment really on the specific pros and cons of Labview and Java, but I will say from general experience, I almost always prefer the beast I know to the beast I don’t. This is especially true for FRC because you have so little time to work through the transition. If you start learning Labview, now it will definitely be better, but I can almost guarantee you will have some transition related difficulties during build season. However, the benefits of switching may outweigh this for you. Just something to keep in mind when deciding.

3

Personally, I like that Java deploys much faster than LabVIEW (at least, how long it took back around 2011). This makes it much less stressful to make changes between matches.

4

Is that a bad thing? https://xkcd.com/303/

5

While Labview is a fine language and a number of power house teams use it, it’s normally better to stick with what you know and advance on that instead of trying to relearn your main language. So I have to ask, what makes your alumni believe that programming/JAVA held them back from winning a blue banner?

Also…

Curious how does the electronic team use Java/Labview to test sensors? Can that not be done with a multimeter and an arduino?

6

Hello,

I can almost guarantee the reason why you are not winning has nothing to do with your programming language. More advanced controls can be done in either and I know for sure world championships have been won with robots running on both Java and Labview.

The real question should be what do you and your fellow programmers know better. If they know Java better use java. If you know Labview better use Labview.

I watched a match of yours from this year. To start out I noticed you lacked on autonomous mode. That is probably something the programmers on your team should focus on. From there vision processing would be a good thing to learn. It looked like your team had a mechanically solid robot with a nice shooter but without vision processing, cross heirs, or a flashlight aiming was next to impossible.

Also are you a school based team? If so what language does your school teach. If it is Java I recommend staying with Java for sustainability purposes.

Hope this helps

7

Stick with what you know. Simplify your goals. A robot that can do one thing really well is better than a robot that can do many things fairly well.

Changing your programming language, unless your team knows how to program in LabView better than Java, will only hinder you.

Code is one of the last things to affect how a team performs on the field.

8

I would keep with Java, especially if your school offers a programming course. Many students who already know programming, at least on my team, were turned off by the visual LabView interface.

If you’re not able to accomplish robot goals in Java, switching to LabView may not help. Are your problems with your language or with lack of practice/timing?

9

Well they feel that Java is too complicated and that it will be a waste of time using Java and not Labview in this program.

The electronic team will test the accuracy of the sensors…

Well they dont think that java is a bad language, but they think that we can get the same or even better result in less time.

We have been focusing on the vision part after the competition and made the robot able to aim and shoot automatically, which is not working 100% good but I am sure that we can get better at it.

At school I am learning Java, but after my grade they started teaching c# which is quite the same, but they are not all in the same level (we have two kinds of classes, one is 2 years learning and one is 3 years learning)
And there are also pupils that did not chose to learn C# at school and you need to teach them from the start.

And to make me more clear to all, I am the only one on my team (except from the capten who was on the programming team with me last year and we learned from our team leader) so I need to teach all of the new members java, wpilib and git, which takes alot from me too.

Thanks to all who are commenting I am really trying to use your tips. Thanks!

10

Labview is easier for people who do not know programming to learn. If you find that a lot of members need to learn from the ground up, Labview might be a better choice.
C# is similar to Java in that both are object-oriented text-based languages, and the sytax and logic flow is very similar. If you find that a significant number of incoming members have taken C#, then maybe sticking with Java is for you. If not, Labview is a bit easier to deal with.

How are you testing the accuracy of sensors? What sensors do you use right now?

11

I find the teaching in school quite slow for our requirements. I do think that in the end I teach them from the start.

And one thing I forgot to say is that they are not investing enough in the trainings and everyone it is a bit different in their understanding.

12

Is there anyone involved in the team or that you interact with face to face that knows Labview? At least with Java there is one teacher on the team (and more in your school). If I understand your situation correctly, there would be no one involved in your team that can teach others Labview. Especially if English is not your first language, learning a new programming language off of the internet is not easy, even if it is graphical. You may actually find it easier to teach your team Java than Labview, even if the language is harder.

13

The alumnus knows Labview , he is using it for the last 3 years or so and I have no problem learning programming language from the internet. Done it in c# and java.

14

Generally I’d say that going with Java is optimal if your team feels they have a basic understanding of programming in general. The main pros for me is:

  1. it makes it a lot easier to exploit version control since it’s text based (you can see what was added/removed on a commit-by-commit basis)
  2. WPILib encourages a clean design pattern with its command callback structure.
    But that’s subjective. Some people will likely disagree.

Honestly our team had many students who struggled with learning LabVIEW. This was especially true for those who had already had some exposure to other C-like languages. LabVIEW’s wiring and VIs can become a bit difficult to decipher when the code becomes complex. LabVIEW does make UI design pretty easy, though, and it integrates very well with the Driver Station. Of course, you can use LabVIEW for the driver UI and Java for the robot.

Regarding improving performance, I don’t believe moving from Java to LabVIEW is likely to accomplish this unless your Java code is designed in a very inefficient way or your programmers are having enormous difficulty grasping how to use it.

Programming is sometimes (often?) asked to make up the difference for shortcomings from design and/or implementation. Changing languages won’t fix that. Good game strategy, well thought out robot design, proper fabrication and assembly, appropriate use of sensors, and a good UX can mean huge strides forward for robot performance. Only the appropriate use of sensors and good UX is within the realm of programming. It is not language dependent at all.

15

Disclaimer- my experiences with LabVIEW are not exactly up to date, as we switched to using C++ a few years ago.

There is, in my opinion, one truly great thing about LabVIEW, and that is the level of support it is given not only by FIRST but also by National Instruments, where no similar support is offered for Java, C++, and the like.

It is true that it is very easy to get started with LabVIEW, meaning that yes, initially, you will find it more streamlined. However, it is significantly more difficult to use for custom functions or more complex/ advanced functions than the other languages are.

As well, your team will often find the increase in deployment/ compile times to waste time when it is possibly needed most (robot testing at competition/ bag and tag week), which could possibly have the reverse effect of what is intended.

No offense meant, and I will not pretend to know the situation or personalities of you or any members of your team, but to me it sounds like your mentor is making a push for LabVIEW because that is the language he has more experience with and prefers more. This means that yes, for him, it must be a faster solution than Java, so of course he wants to pass that onto the team.
However, you should remember that he isn’t the one writing the code; you guys are, and should use what you think works best and fastest, not anything else.

In addition, Java will prepare more people for likely situations in the workforce, especially because Java is so prolific, and using it can give students very valuable life/ career experience.

Those are just my $0.02 (or $2.00, really, i wrote a lot. Sorry)

16

This is a classic debate on CD.

As many of the others have stated on this thread, you should go with the language that you are most comfortable with and further your efforts in that. But I do want to dispel one notion about Labview as though it is some kind of a regression. From what I have seen, labview in FRC is atleast as powerful as Java is. Yes, it has a low entry point making it very accessible to newer teams and programmers but it also has a very high skill cap. Several veteran teams use it and have had no trouble achieving what any Java or C team has. I would also like to point out that Labview is used in many applications beyond FIRST such as indisutrial automation and testing. While Java is the more popular and more widely used language in the real world, it is also undeniably been on the decline.

That aside, there is no difference in what you can achieve with Labview or Java in FRC and the choice should be based solely off of which your team has the most experience with and is more comfortable with. I see that while you all have used Java thus far, your mentors seem to be proficient in Labview. I know that mentor expertise is the deciding factor for many teams in their choice of language so I urge you to keep your options open.

17

I think that you can be successful with either language,
Our team uses LabVIEW and we keep using it because it was used since our rookie year and we gained experience with it.

I think you should consider the following things in your decision:

**1) How many students on the team have already had a season using Java? **
Experience is something you should maintain and a transition may be a struggle.

2) How many new students came with no programming experience?
As far as I know it’s much easier to teach LabVIEW to new programmers.

3) Are there any mentors on the team that know Java or LabVIEW already?
Mentor support is always good, if you have a mentor that knows Java you should consider staying.

4) What programming languages does other teams use around you?
Getting support from other teams around you can help solve problems faster, even during build season.

Hope it helped,
בהצלחה :slight_smile:

18

LabVIEW compile times are longer, but not prohibitively so. It only takes a matter of seconds to put compiled code on the robot.

LabVIEW seems harder for people who are used to a procedural language like C++ or Java. That’s usually because they are trying to approach it using what they already know. Unfortunately, what they already know is largely inapplicable to dataflow languages and actually gets in the way. If you start out with the idea that you know nothing, you will find LabVIEW much easier to learn and use.

LabVIEW is simple to start out with. It is also very powerful. Its inherent parallel nature makes it easy to do some things which are difficult in other languages.

On the other hand, typical object-oriented features are not as deeply baked in, so common OO constructs aren’t as simple, though again thats mostly an issue for people with a good background in such languages.

19

Both Java and Labview (and C++, of course) have competed at the highest levels. The question is what is right for your team? How many programmers already know each language, how many mentors are comfortable in either language, and how many mentors are willing to learn the other?

We have been a Java team from 2012 to 2016, but we’re looking at only one student who’s done any significant programming being on next year’s team. Our steady programming mentor for the first five years is backing out a bit (maybe more) due to marriage, moving, and a new job that will send him to sea in various places around the world… If our new programming mentor wanted to switch to LV, this is probably the year we’d do it.

Repeating the bottom line - which is better is much more dependent on your internal capabilities than any abstract “betterness” of the program language. The only considerations outside your team should be online support. LV, Java, and C++ all have decent support on CD, but perhaps one or two of these languages has better local/hands-on support from nearby teams.

Play the ball as it lies.

20

I’ve been programming in LabVIEW for 4 years now, and would like to give you some technical details about it. As for Java, I’m actually learning it as I speak, so I can’t be of too much help in that. Sorry.

Pros:

LabVIEW looks more simple for beginners because of the graphical aspect: wires connecting to blocks, drag-and-drop, selecting stuff by drawing a box around them, all of that is more familiar to people with no prior programming experience.
LabVIEW is amazing at running different parts of code in parallel.
There is A LOT of support for LabVIEW on Chief Delphi!
It is an industry-standard programming language.
You can drag-and-drop other teams’ LabVIEW code directly into yours.
LabVIEW has many nice tools to help you when programming. For example, to help with following data transfer inside the code, there is a highlight function that highlights the data flow in ordinal fashion.

Now, LabVIEW does come with quite some quirks and annoyances…

Cons:
LabVIEW and trackpads DO NOT MIX! It basically requires you to have a mouse.
LabVIEW’s version of vision processing has a bunch of lag (about a half a second).
The LabVIEW application has no tab interface; in other words, if you have 5 VI’s open at the same time, you will have a messy conglomerate of 5 windows on your screen that you will have to switch between.
LabVIEW looks like a nightmare for those who have prior programming experience in a text-based language with its wires going everywhere, random blocks and boxes, etc.
Merging two VI’s in LabVIEW is literally THE WORST! A VI-merging application is included in the FRC LabVIEW Suite, but it takes at least 30 minutes just to merge average LabVIEW code, and it may not even do it just the way you want it to, either.
It takes LabVIEW quite some time to deploy code to the robot. I had a weird issue in which the code would not deploy correctly, and in the end, would display a connection issue, so I would have to almost always deploy the code twice or even thrice.
Once you begin making more advanced programs, LabVIEW code becomes more and more complex. For example, my team this year has two cameras on the robot for driver vision, and we wanted to be able to switch between the two camera views at the push of a button. To do that, we had to dig reeeaaaly deep into the existing code infrastructure (roughly seven layers of SubVI’s) and change several components. It took several hours of debugging just to make it work!
Debugging in LabVIEW can be time-consuming, mind-boggling, and overly complicated overall.

Once again, I’m sorry that I can’t be of too much help when it comes to Java (yet…). If you have any questions, I will reply as soon as I can. Hope this helps!