Java vs Labview

[s5511]

My team is thinking about switching our robot code from Labview to Java. For the past two seasons, we have used Labview, and we have found it very appealing because of its ease of use. So far, we have used the navX gyro, encoders, limit switches, and PID control for our shooter and drivetrain. Another reason we have enjoyed using Labview over past seasons is that is very easy to learn and allows programmers to quickly modify and make changes to code. Over the summer, we want to experiment with vision processing and motion profiling. I should also mention that we have a small programming team, only 2-3 members.

What are the major advantages of using Java over Labview?
Does it take longer to program the same robot in Java than it would take within Labview?

[Spillertb]

I have never used Labview so this is probably kinda biased. But being the only programmer (yes the only one) on our team I think java works perfectly.

I use command based, and it has worked perfectly for me. I am quite experienced with java though so it may have been easier for me, but its not to heard to learn. We have NavX MXP on the roborio, and it is super easy to use once you add the right plugins, we also use limit switches easily. I haven't personally used pid or encoders just because we haven't ever had to. The main advantage for me is that I know the code absolutely inside out, so if the driver all of a sudden screams at me from half way across the pits to add in a button that would make it spin around in circles for 19 seconds or some other random thing, I could add that in under a few minutes, command based also helps with this. I tried to add vision processing this year, but it totally didn't work for different reasons, though it isn't that hard to do. We also used mecanum wheels this year fyi.

Heres the github of my code: https://github.com/FRC-5752/FRC-5752-2016

[Hitchhiker 42]

I'll offer a biased point of view from the LabVIEW side. From what I have done, implementing vision is easy in LabVIEW. In addition to that, I would suggest staying with LV because of how simple it is to understand. It is easy to find mistakes and fix them, and just as easy to add extra controls, etc. as in java.

The main argument for LV is that it is capable of doing what C++ and Java are, but in a more easy-to-understand and new-to-programming-teachable way. Think about new members.

Our programming team on 4557 also consists of 2-3 members.

[rich2202]

We use C++, but are thinking of switching to Java for the following reasons:

1) AP Computer Science is Java based. Some kids will come in with Java knowledge. I am sure there are great things about Labview. But, if you don't have to teach the students the basics, you are that much ahead.

2) Mentors don't know Labview. It is easier to get a Mentor involved (and productively supervising the students) if they don't have to learn something new.

[s5511]

Yes, 2 of our students have taken APCS.

I was also wondering if there is anything that is significantly easier to program in Java, or that Labview cannot accomplish functionality wise.

[DubstepLion1]

I don't know if LabView can achieve this, but this year we used Java to call a script on the roboRIO via command line to initialize mjpg-streamer to stream the cam to the Driver Station.

There are other reasons to use Java, too. I would argue better support with WPILIB being open sourced and the ability to use outside libraries which can aid in easier implementations for vision or motion profiling,

[Hitchhiker 42]

Originally Posted by DubstepLion1

I don't know if LabView can achieve this, but this year we used Java to call a script on the roboRIO via command line to initialize mjpg-streamer to stream the cam to the Driver Station.

Labview most certainly can stream the camera to the dashboard. In fact, our drivers relied on it heavily this year.

Originally Posted by rich2202

2) Mentors don't know Labview. It is easier to get a Mentor involved (and productively supervising the students) if they don't have to learn something new.

I would certainly argue with that. Our team's programming mentor knew LabVIEW prior to joining our team.

[Monochron]

For what its worth, we would definitely help you guys with the switch to Java if thats what yo u decide to do. We have been using Java for a couple of years now and really like it. Our programming team would be glad to head across the street and hold some sessions with your programming guys. Or you could come to the programming sessions we hold in the Fall.

It would also give me an excuse to get a better look at your robot

[414cnewq]

Java will give you a faster compile than LabView (20 s as compared to 1 min). Command Based programing allows more distribution among programmers, and even when its just a single programmer, RobotBuilder simplifies things. There is no registration code for Eclipse as there is for LabView, so at home set up is easier for sans-cd computers.

[Bell-Inequaliy]

It really depends on your taste. Java is object oriented and LabVIEW is data-flow paradigm.

In LabVIEW, data is generated by predefined functions based on the inputs of the function, or by pulling data from some other input. This data is sent along data paths and operated on by other functions. The data is then either stored or sent out. The advantages of this is that it is a simple graphical programming interface, and that data processing is easy. The disadvantage is that routines and objects are more difficult to handle in state machines, e.x building a complex autonomous from simpler behaviors is more difficult than in Java.

In Java, data is either given by the programmer as a type or is pulled from some other input. This data is treated as an object, and is therefore defaultly stored as an object. Retrieving and handling this data is more difficult as a method is typically require to get or give data. Building routines and simple behavior to create complex behavior is easier in Java, at least in my opinion and having used both languages. It is a text based program as well, which means your data flow can be a bit harder to track.

I suggest you read more about each type of language as I have highly simplified the two paradigms and only overviewed them. Having used both languages independently and alongside each other, I can say I personally prefer Java and I assure you if you know what you are doing it does not take much longer to program a robot in Java, and it is easier to collaborate and set up multiple development environments in Java than in LabVIEW.

[Pault]

Having used both, my experience is that LABVIEW makes it a lot easier to write functional robot code. However, as your code gets more advanced and complex, it becomes a lot harder to keep your code from becoming spaghetti. Java is much more suited to larger projects.

Overall, based on what you said about your programming team, I think you could go either way. Java is going to require a big commitment in the offseason, but can be a worthwhile investment because it makes it easier for your team to grow. However, it is certainly possible to do motion profiling in LabVIEW, it is just harder to code it well.

YMMV. Another huge factor that I have seen come in to play is that people who already know object-oriented, text based programming are much more resistant to LabVIEW.

EDIT: I should also mention that this is a heavy simplification of your decision, and there are a lot more factors that can come in to play.

[Greg McKaskle]

The FIRST offseason is a great place to learn new tools and to learn how to better use familiar tools.

If you think you have time. I'd suggest you take your robot that should be pretty stable, and reprogram it from scratch -- as a group or in small groups. I think you'll find that it goes smoother the second time, no matter what language you use, and you can identify some of the info that makes this possible. This is also a great time to delegate some stuff and let new students learn the ropes.

Use this as a time to learn Java and the framework. You may also find it useful when you find something confusing or new to look back at LV and look for it there.

If you really like the command-based programming, you can also look at using the new LV command & control framework.

If you are familiar with both, then when next year's game rolls around, you will be well prepared to use either language. You will also be able to help that many more teams or students if they have issues.

Greg McKaskle

[Greg McKaskle]

Oh. Forgot to add that to invoke a command,you use the System Exec node. This is in fact how the Java and C++ apps are launched -- from LV using system exec.

So if you wanna launch another process, that is all it takes. But of course communicating to it is another matter, which is why it is much more common to simply have a parallel loop in LV that does the other thing instead of parallel processes doing it. There are cases for another process, but for LV FRC, I'd generally go for another loop.

Greg McKaskle

[techhelpbb]

This is not a dig against LabView but:
There is no LabView at my financial institution.

You walk out of high school knowing Java/Python with some practice you could write software worth huge sums of money to support your future.

You walk out of high school knowing C++ as an embedded engineer or OS contributor you are in good shape. If you easily exchange that knowledge for C# you broaden your future more on the .NET bandwagon.

I can certainly see the value in LabView for engineering and automation professionally and everywhere I have used it was for that purpose.

So teach what you will, LabView can run your robot for FRC, but as far as I am concerned LabView is not positioned to be a core skillset for most people in the market. Now that I have my own robots: I fully intend to increasingly improve my LabView skills to make me a better CSA and Mentor. It may be a FIRST thing but you guys are the lot I am in with so it is a good investment.

FRC11 uses Java and from that experience, even before Mount Olive High School seriously taught programming as they do now, we sent students places after graduation with those skills as part of their toolbox.

[MrRoboSteve]

The most important factor in selecting the language used by your team is the language your mentor knows.

You can build an effective, winning robot program in any of the three supported languages. If you have great mentor support, you can even use Python.

I personally would find Labview skill a plus when interviewing CSci grads. It provides a different experience than the curly brace languages that everyone learns.