What do you use to program your robot?

[ThunderMa14]

We have been using LabView for a while now, and one of our mentors wants us to switch over to Java.

Some other people are agreeing with him, but the team my friend was on had a lot of problems with Java.

So my questions are:
What do you use? (C++, Java, Labview, Other)
How well does it work? (Rate 1-10 please :D )
Has your team experienced problems with your programming language?

[Azores]

Java
7.5/10
I was the only programmer this year, so it's hard to say if the team had difficulties :P. My only issues with the FRC Java libraries were some odd definitions of methods that were either just vague or actually gave slightly incorrect information in a few cases, which obviously lead to code not doing what I wanted, and made troubleshooting impossible until I found out the method I was calling didn't do what I thought it did :rolleyes:

[Andrew Schreiber]

397 used C++. 2337 used Labview.

397 had some issues with Windriver.

2337 had to deal with the crazy long deploy times of Labview.

Personally, my choice is C++ because I am more familiar with it.

I have no experience with Java.

[mwtidd]

I'm curious, what kind of issues did your friend have with Java?

Or even better, do you have his code?

Once you figure our the basics of the java code it becomes pretty easy to do stuff pretty fast

i.e. at competition we added a winch which needed to run in one direction before it ran in another

the coding of the winch and the programmatic lock took a few minutes.

[JABot67]

There have been multiple threads on this topic, but oh well.

Team 67 uses both C++ and LabVIEW. Our programming team was so big this year (10 members) that we decided to split up into C++ and LabVIEW teams. The idea was that both teams would program the robot to work in the same way, and at the end of the build season, we would decide which one was better. When I was told I was to be the senior LabVIEW programmer for the HOT Team, I was sure we were going to end up using C++, because I had no experience with LabVIEW and our head C++ programmer is very good.

But 6 weeks later, after I had taught myself LabVIEW and learned to love it, the team decided that both programming environments were completely functional and worked at exactly the same level. We decided to use LabVIEW at one district event and C++ at the other, and then use whichever one worked better for the State Championship and Atlanta. We used LabVIEW at Kettering, winning the event. The one time that our robot scored 3 balls in auton from the far zone (qf1-2) was the greatest, most exciting moment of my robotics career.

We used C++ at the Detroit District, where we worked all Friday trying to get the robot to hang. Our arm potentiometer malfunctioned Friday afternoon, and that caused a bug in our C++ code where we weren't able to kick. We played one match without kicking at all, and then switched to LabVIEW for 3 matches while our C++ programmers figured out the problem. If it weren't for our ability to use two completely different programs to run our robot, we would not have seeded #1 at Detroit, and perhaps wouldn't have won.

For the State Championship, we had no idea which program to use. In fact, the decision was made at around 10:00 on Thursday that we would use LabVIEW for States and C++ at Atlanta.

One interesting thing is that the HOTBOT is completely student-programmed this year. Us students had to fend for ourselves after two really great mentors, Dave Doerr (C++) and Bob VanHam (LabVIEW) left the team this year. Our programming mentors, Dave Verbrugge and Theresa Prior, told us at the beginning of the season that the would not able to help us program in the pits. (Dave is MCing at every competition we are going to!)

Has any other team tried to use more than 1 programming environment?

[ThunderMa14]

I'm curious, what kind of issues did your friend have with Java?

Or even better, do you have his code?

Once you figure our the basics of the java code it becomes pretty easy to do stuff pretty fast

i.e. at competition we added a winch which needed to run in one direction before it ran in another

the coding of the winch and the programmatic lock took a few minutes.


It was a local scrimmage in suffield, and they could not get their robot running. It was a problem with either their script or their robot just not working with the code, but they did not compete all day.

[apalrd]

We like LabVIEW because we like the debugging and real-time front panel tools. We use global variables to store large amounts of calibration data, and editing in real-time is really nice, especially with the large download times.

I would give it a 6.7 out of 10, for two reasons:

Builds take almost three minutes. This in itself is almost all of the problem.

The WPI library for LabVIEW is not pre-compiled, so it must be re-compiled every time it is built. It re-builds the WPI library every time it is used, causing almost all of the long build times. Also, the WPI library itself isn't the most efficient thing in the world, and some parts of it (Compressor especially) are quite inefficient, and when trying to debug and use camera tracking this can be a killer. We eventually decided that the cRio is not powerful enough to track the target all the time, something we prefer to do.

As some positives to LabVIEW, we can edit the PID gains and setpoints in real time from a global variable file, so we don't actually have to download that much. We also wrote a visual autonomous system, mirroring one that I used several years ago for LEGO, so it's really easy to write new modes and such. We also utilize several threads, and LabVIEW makes that really easy.

[Dkt01]

1756 used Labview for the first time this year. We had a quick learning experience, which was helped greatly by a mentor who uses Labview at work. Otherwise, our lead programming mentor would have likely gone back to C++. I like Labview because it is easy to understand and change, but it takes a long, long, long time to build and deploy. This is frustrating when the mechanical guys are waiting to play with the robot for the first, or thirty-sixth time of the day.
I would recommend Labview, but if a team is more familiar with C++ or Java, why not play to your strengths.

[kjolana1124]

We're using LabVIEW this year, but I think we're switching to either C or C++ next year. Our programmers are already making modular coding things for next year (I don't know a lot about programming persay, I prefer sleep xD)

[ttldomination]

Team 1261 is using LabView because our head programmer likes the debugging features and everything. And it works well. No complaints on the performance end except for a couple of things. :P

Next year, we're looking at C++. Our head programmer is graduating and our projected head programmer is most familiar with C++.

[AmoryG]

There have been multiple threads on this topic, but oh well.

Team 67 uses both C++ and LabVIEW. Our programming team was so big this year (10 members) that we decided to split up into C++ and LabVIEW teams. The idea was that both teams would program the robot to work in the same way, and at the end of the build season, we would decide which one was better. When I was told I was to be the senior LabVIEW programmer for the HOT Team, I was sure we were going to end up using C++, because I had no experience with LabVIEW and our head C++ programmer is very good.

But 6 weeks later, after I had taught myself LabVIEW and learned to love it, the team decided that both programming environments were completely functional and worked at exactly the same level. We decided to use LabVIEW at one district event and C++ at the other, and then use whichever one worked better for the State Championship and Atlanta. We used LabVIEW at Kettering, winning the event. The one time that our robot scored 3 balls in auton from the far zone (qf1-2) was the greatest, most exciting moment of my robotics career.

We used C++ at the Detroit District, where we worked all Friday trying to get the robot to hang. Our arm potentiometer malfunctioned Friday afternoon, and that caused a bug in our C++ code where we weren't able to kick. We played one match without kicking at all, and then switched to LabVIEW for 3 matches while our C++ programmers figured out the problem. If it weren't for our ability to use two completely different programs to run our robot, we would not have seeded #1 at Detroit, and perhaps wouldn't have won.

For the State Championship, we had no idea which program to use. In fact, the decision was made at around 10:00 on Thursday that we would use LabVIEW for States and C++ at Atlanta.

One interesting thing is that the HOTBOT is completely student-programmed this year. Us students had to fend for ourselves after two really great mentors, Dave Doerr (C++) and Bob VanHam (LabVIEW) left the team this year. Our programming mentors, Dave Verbrugge and Theresa Prior, told us at the beginning of the season that the would not able to help us program in the pits. (Dave is MCing at every competition we are going to!)

Has any other team tried to use more than 1 programming environment?

My team probably would have loved to use two programming languages, but for a different reason. We programmed in C++, but if we could load code from both C++ and Labview at the same time, I think our camera code would have been written in LabView.

[davidthefat]

Did Java this year, doing C++ next year with C for the sub boards

[biojae]

Java this year.

Windriver last, Java this, Labview next (Maybe)

Before I can form an honest opinion of the languages, I have to try them all first.

Next year will complete the trio (unless another language is in the works :ahh:)

But, even if labview isn't used on my team, it will still be used for realtime things like PID tuning. (Did it the hard way this year: upload, doesn't work, change, repeat)

[AmoryG]

Next year will complete the trio (unless another language is in the works :ahh:)

Python! From what I've read/heard from my programming mentor and know about it, I think I would be very happy if we could program in a language like python (probably won't happen).

[Robototes2412]

you can use jython, btw

[lynca]

Once you figure our the basics of the java code it becomes pretty easy to do stuff pretty fast

I agree with this statement. Java is very fast to install , compile and make changes.

Java in FIRST is a natural transistion because most students learn Java in AP classes

[Radical Pi]

We use C++, primarily because both of us are already good in C.

I'd give the language a 9/10, mainly because we didn't run into any language-related issues this year. I dropped a point because of the 4.1 and 4.2 issues in the WPI Libraries (for those of you who don't know, the midseason update to WPILib for C had a few compiler issues). Our other problems weren't really language-specific (bad interactions between the camera and CAN code, OS level I think)

[Al3+]

We use WindRiver C++.

I don't have any problems with it myself, being already familiar with the language. But student turnover is going to be a challenge. C++ isn't exactly easy to teach in 20 hours of off-season meetings, and it doesn't help that there are neither any sort of comp sci classes at school nor a programming mentor on the team.

[davidthefat]

We use WindRiver C++.

I don't have any problems with it myself, being already familiar with the language. But student turnover is going to be a challenge. C++ isn't exactly easy to teach in 20 hours of off-season meetings, and it doesn't help that there are neither any sort of comp sci classes at school nor a programming mentor on the team.

Just hand them all a copy of C++ for Dummies:D But seriously thats what I am considering next year...

[slijin]

I agree with this statement. Java is very fast to install , compile and make changes.

Java in FIRST is a natural transistion because most students learn Java in AP classes

We use Java as well. :)

Though at the Hartford competition this year, robots coded in Java seemed to have the most problems with lag... :mad: