We are a newer FRC team (Ultimate Ascent was our first season) and we are currently trying to decide what programming language to use for next season, so that we can begin training students. We used LabVIEW last year and had some issues with it, although these were likely due to our being rookies, and are considering changing to C++ or Java. We have access to good resources for all three languages, so mentorship is not a problem. What languages do your teams teams use and why? Pros & cons? Any and all advice or input would be greatly appreciated!
Thanks,
Howell High School FIRST Robotics
The S.C.O.T.S. Bots - Team 4776 “Service, Character, Opportunity, Teamwork, Spirit”
We use LabView because mentors have experience with this language. We are considering Java, because that is what the High School teaches students (the Mentors would have to get up to speed here).
We have found that any language can do anything you might want, but the amount of support offered for FRC teams varies.
We at Innovators Robotics use C++ on grounds of it being “closer to the metal” without the overhead of Java, and because it was what the original programming team in 2010 knew to use. Between C++ and Java, though, if overhead isn’t something you care about, it’s often a wash. Plenty of support from CD and other programmers in both. Arguably easier to get new kids in if using Java, though it’s still not that big of a gap.
I might also recommend RobotPy and the Lua interpretter + WPILib that are floating around CD. The interpretters run as C/C++ modules, therefore being legal to run on the cRIOs, and the ease of writing either of those languages is great (I know both extensively from working on web development projects in Python and working with tons of open source in Lua, and I have to admit they’re in my “top favorite” list for languages). Very fast to write, and very fast to teach newbies. Also not sitting through compile times for your one-liner changes would be a nice sanity item (If I recall RobotPy will auto-reload code when a new version is pushed over the FTP link, meaning you have near-instant response from hitting Save to seeing the outcome).
We use Java, so that is what I would recommend.
The first advantage to Java is that it is the language used in the AP Computer Science course, so if your school offers that some students may have Java experience from the class.
Java tends to be more friendly to beginner programmers because of the garbage collection function of the JVM. If you’re not familiar with it, it automatically reclaims memory used by objects that no longer have any references to them. This abstracts something complicated like memory management so an inexperienced programmer can focus more on the logic than making sure they don’t have any memory leaks. Most FRC applications are probably simple enough that memory leaks aren’t an issue, however.
Another advantage to Java (and I believe C++ as well) is dramatically faster deployment times compared to LabVIEW. I spoke to a member from Code Orange, who uses LabVIEW and he said that their deploy times ranged from 5-10 minutes, and I have heard similar stories from other teams. Here I was complaining about 30-45 seconds for Java
The main disadvantage to Java in FRC is that the cRIO JVM is Java ME, which is based on Java 1.3, so doesn’t have a bunch of new features like generics.
Yes, this is one of the issues we encountered at our first competition. We didn’t leave enough time for the code to deploy (we had made a last-minute update) during our first match, so we had no programming and were dead in the water, so to speak. It was taking us 15-20 minutes to deploy code, although that could’ve been due to our code being written rather inefficiently. (VIs galore!)
Our team has always programmed with Labview in the past. In our opinion it is very straight forward and people have been able to pick it up very quickly. I know that some people have complained about being somewhat limited when it comes to certain applications, but we have been able to do everything that we have wanted to with it. I have also been able to find a lot of support for it, and there are quite a few tutorials floating around online which can help a ton.
We also used to have horrible deploying time until this year. In years past we only used the Classmate as the programming laptop, and as a result deploying would take an eternity. This year we finally got a new laptop and our deploys have been very fast, with the complete code deploying in less than a minute. I think the laptop had an i3 processor with 16 GB of RAM and 2 SSD’s. That may be a little overkill, but that is just what we decided to go with. I know that it isn’t always possible to get a brand new laptop, but you will most likely see a speed increase no matter what language you decide to go with.
There is nothing wrong with trying out other programming languages, but if you do that I would make sure that your programmers know that language very well by the time the season rolls around. It is not fun to have to learn a new language in season as well as getting competition worthy code.
The deploy times of LabVIEW last year were miserable due to bugs in the compile cache. Advanced optimization features and a bit of human error caused deployment to a controller with a running startup app to recompile everything it saw. The bugs have been fixed and the FRC use-case is better understood with the RT development teams. I apologize for the bad experience.
To your questions about languages, my advice would be to try and gain experience in multiple languages. Ideally with a mentor, pick some problems, and code the solution in the trial languages. Debug it with the tools. Modify it a few times, explain how the solution works to someone else. Experiment and learn what works for your team. Then go deeper on one of them. All are good choices.
I would recommend C++. Deploy times are around 1 minute (or less), the environment is easy to set up (albeit you need the LabView disc and two WindRiver ones), and it’s pretty easy to learn (even if you have no programming experience). Unless you have people who know LabView, I wouldn’t recommend it. LabView experts are like truffles; they’re really hard to find, and worth a fortune. C++ and Java programmers are more common (no offence!). The C++ deploy times were my favourite part. We created our entire Autonomous programme in-between matches at the competition this year.
We use java primarily because that’s what our AP comp sci students know. You should pick a language that your programmers know best. Otherwise it doesn’t matter, although C++ and Java deploy times are nice.
Since you have support in all 3 languages I would recommend you use what will help the students in the long run. We used LabVIEW a couple of seasons but have programmed with Java the last 2. We switched mainly because we had a number of students interested in pursuing computer science degrees. Not to say you won’t learn about standard programming methodologies with LabVIEW however being familiar with Java (or C++) and learning about Object Oriented programming will give them a leg up in college.
Our team has been using LabVIEW for the last few years but this summer we have been trying to make the change to C++. Somewhere in the process it rendered one of our team laptops unusable for sometime(I don’t know the details on what it was), i’m not saying don’t use it, but be careful.
Our team is/was in a similar position. Ultimate Ascent was our first season, and we were a LabView shop. I’m not on the programming team, but as I understand it, we stayed away from Java/C++/et al. and close to LabView because LabView seemed simpler and the other languages seemed more daunting and a bit lower-level than we needed.
There’s already a load of better advice above this post, so I’ll keep this short. Whichever language you decide to use, you need to have a mentor with experience in that area. There are forums, IRC channels, etc. that you can go to if you need help, but it’s not the same as having someone with specific experience on-site. Especially with the lower-level and more complex languages like C++.
In short, you really need someone on the team who’s been bitten by everything your programming language can bite you with.
We use Java because that’s what the mentors prefer and because the AP classes use Java.
An FRC Java environment has a couple more benefits too – it’s (low-effort) cross-platform (Linux or Mac users can easily integrate into the team), and a simple Netbeans+plugins IDE setup is 10 min or less depending on your download speed
In my experience with programming FRC robots I have found LabView to be the easiest language to pickup if you have little/no experience. The interactive tutorials and exmaples that teams and NI have posted will allow you to get your robot up and running reliably pretty fast. The one downside is that NI LabView tends to not be as powerful as C++/Java.
To put it in perspective you generally see LabView being used for testing in the Manufacturing industry whereas you will see Java/C++ used more in the Development process for the Engineering/Defense Industry.
Also as a note most high school classes that give college credit (Known as AP classes in MN) will teach students Java. With the knowledge I learned in FRC I was able to take the java AP exam without actually taking the class in high school.
In terms of the direct function of the program, what can you do in C based languages or Java that you can’t do in LabVIEW? I would say LabVIEW is just as “powerful” as any text language, but it takes some knowledge to know what to use LabVIEW for and how to do it in LabVIEW. In FRC, LabVIEW works well for programming for the robot, and can be simple or complicated depending on how you use it.
We used LabView for programming in past years and have enjoyed it. This year we will be switching to C++. I find that LabView is good for creating robot code due to its intuitive nature concerning machinery, but a downside is longer compile times and its contrasting nature to other languages. In the end, though, it is your choice and you may want to ask the mentors what they think you should do, seeing as they all have prior experience.
Some people argue Java or Object-Oriented programming is better to learn. I disagree. I don’t think anyone can truly learn programming by learning only one language/paradigm. A very wise man once said that the most important programming language you learn is your second. When you learn the first language, you learn to design software around the constructs, syntax, and programming practices of that language. When you learn your second (ESPECIALLY if it’s vastly different language paradigm) you learn to apply the design skills much better and choose the best method of implementation for a given project, and it really opens your mind to other potential methods for writing software.
We’ve chosen LabVIEW for various reasons. We prefer the language and diagnostic tools, and feel that they outweigh the downsides that there are. Jim and I both work heavily with C and model-based programming (I do a TON of simulink now), so it all makes sense to us.
All three languages are used heavily in the ‘real world’. While it might be true that LV is less commonly used for production software (it’s used EXTENSIVELY for prototping, one-off test pieces, and research), Simulink and the similar autocoding languages are used heavily for embedded controls stuff.
Whatever you do, don’t restrict your thinking to only one method of writing code. OO is not always the answer. Sometimes it is. Learning two dissimilar languages will teach that.
@Ilovepineapples, all of the defense work I’ve ever done was in C and Simulink (autocoded to C). We just didn’t have the CPU resources to throw away on garbage collection, dynamic memory allocation, and interpreted code. On a related note, automotive safety standards specifically prohibit dynamic memory allocation, heaps, and reuse of memory for different items (aside from the main stack), so Java is ruled out entirely. I haven’t read a military vehicle safety standard, though, maybe they do crazy things.
You are correct. You can accomplish anything in LabView that you can accomplish in C++/Java but it is a completely different way of looking at it. When looking at LabView you almost have to look at it from an EE point of view rather than a CS point of view. Both are valid forms of programming that can do advanced tasks but LabView is wiring boxes to make it drive whereas C++/Java is writing words to make it drive.
For the record I much prefer LabView as a programming language overall but there are some applications I would rather write in C++/Java. For me LabView makes programming a little more creative and fun but that is just my 2 cents.
(If I recall RobotPy will auto-reload code when a new version is pushed over the FTP link, meaning you have near-instant response from hitting Save to seeing the outcome).