Calling Out All Programmers

Which route are you guys taking to code the robot? C++, Java or the LabView?

I seem to have to use Java… I wanted to use C++ but my mentor is like “The C++ Libraries Are Too Messy” or something like that… And that the Java code wont be any slower than the C++ because of FPGAs or something

LabVIEW. We like the real-time front panel.

That’s kind of funny actually – since you can literally take C++ code, change the syntax to Java (like capitalization, accessors, etc) and compile it. Likewise, you can take Java code and change the syntax and compile it with WindRiver. I actually found C++ file a lot more elegant than LabView files we tried last year. The biggest difference is real-time execution (C++ is fast – but is it “live” like LabView? – I don’t know). LabView by nature is slower, but it is able to process multiple things at once – a tradeoff?

Anyway, We’re using C++. We have a opensource Github, but latest code’s not pushed yet. Perhaps I’m wrong about it, but I think your mentor’s off the mark when he says “messy libraries”. And also, are you the only programmer? How many others are there? What’s your guy’s consensus on a language preference? A mentor shouldn’t force the students in to anything. (Except maybe administrative functions?)

That’s just how my team rolls…

Thanks,
Keehun
Team 2502

Yea I code in Java and C++, I been using C++ longer and I like it way better than Java, well the mentor said I CAN use C++ but he highly recommends Java for the sake of the cleanness of the libraries and easier setup

edit: Im the only guy going for C++ LOL All the other programmers want Java since they don’t know C++

Edit of Edit: Amen to your sig

I’m taking the C++ route for a few reasons

  • Myself and programming partner already knowing C++
  • It’s in it’s second year with FRC, Java is in it’s beta year for FRC
  • More documentation then Java
  • The library is in fact quite straight-forward

C++ has always been my favourite programming language. And I do believe the Java code is going to be slower than C++ code as you’re running a virtual runtime on the cRio, this is an extra process whereas WindRiver compiles C++ directly the PowerPC Architecture assembly.

I do not agree with your mentor depicting the C++ libraries (especially the WPI library) as too messy. It is in fact quite easy to pick up an extra class of the library and integrate it in your code. For example I hadn’t programmed a Spike relay in C++ before and I ended up accomplishing the feet in five minutes just by taking a quick look at the C++ reference found here, http://www.virtualroadside.com/WPILib/index.html.

LabVIEW is a good choice for a lot of teams, it has more advanced and easy to use debugging tools that supposedly “just work.” It has a large community over at the Texas Instruments website with tons of sample code and even video documentation. The problem I have with LabVIEW for one is that it’s a graphical language. For some this great, for others (like me) I prefer manipulating a robot or computer with syntactical text. LabVIEW also requires lots of screen real estate which some of the ancient computers at our school don’t have, and there’s not as many books out there on LabVIEW that I can reference to new programmers.

Just putting in my two cents :slight_smile:

I had a programmer from another team mistake my C++ code for Java.

Ok, well, if all the other guys want Java, then I say just stick with Java. One of coolest things about FIRST is that it teaches you the benefits of working as a team. For my programming team, majority of the guys know Java, but we chose C++ as a preference for two reasons:

  1. We didn’t want to try a “new” language for the cRio platform
  2. C++ was proven to work and was fast
  3. We all kinda-sorta knew C++
  4. Being a captain, I pushed for C++ after having a bad experience with LabView last year
  5. Our mentor is like a 30 yr veteran in the field of C++ and Systems Networking

After working with it for a couple weeks, I feel C++ was the right choice, but I know that Java or LabView would’ve equally been fine. Maybe not LabView, but that’s only because trying to wrap all the programmer’s mindset around the real-time execution paradigm is difficult. Even the 30-yr C++ veteran mentor (he’s also a huge expert in Java) didn’t know why LabView behaved the way it did – that was the real downer last year. Also, we wanted to diff and git with C++. :slight_smile:


int Java = 10;

void Print(const char] Text)
{
//Not Putting This In...
}

for(int C = 0; C < Java; C ++)
{
if(Java < 100 && > 10)
{
Print("Is this Java Or C Or C++??? Who Knows?");
}
}

We’re using C++ again this year for the following reasons.

  1. Most of the student programmers know it (the ones that don’t know Java).
  2. I (the programming mentor) know it and work with it professionally.
  3. It offers more control over the execution environment and full access to VxWorks.

Huh? What do you mean by “real-time execution”? You can’t get any more real-time than interrupt driven C/C++.

It is not possible to do multiple things at once on the cRIO in any language without using the FPGA. You can get rather close by using multiple tasks or interrupts, but there is only one core which means only one hardware thread running at a time.

BTW, Java and C++ may be similar on a small part of the syntax level (just like every other curly brace language), but they are far apart semantically or when using any of their features.

Our team is going with C++.

I use C++ because I don’t know how to drag and drop LabView code :P. Also I dislike Java.

Our team is going with Java because we like the overall structure of the program. We didn’t have such a strong foundation in java last year, plus the main programmers this year, myself and my friend, are stronger in Java than C++, so we figured we should try Java, which is working very well for us so far.

I wanted the team to use C++ last year, but due to the lack of time, experience with C++, and impression that labview’s GUI would be much easier, we ended up going with the latter.

It actually took less time to program in C++ then it did in Labview. It took us up until 2 days before the ship date to figure out where all of our issues stemmed from in the GUI. Not to mention it was slow on our set up. For C++ it’s been much more smooth of a ride.

On the first day of the season I got all of my programmers together, taught them the basics, and by end of week one they each had programmed a small portion on the code. By end of week two, they had dived right into the use of sensors, and more intricate styles of programming… end of Week three and now they’re creating their own classes for certain objectives they’ve set for their programming. WPILib, is AMAZING!!! It makes everything so much easier, and with my basic understanding of C and C++ I can explain why things work the way they do, and they can learn more intricate things with delay of coding and confusion.

I. LOVE. C++. <3

-Meezy

C++ for me. I tried Java for a bit on the cRIO from the classmate while our new development computer was being set up. I ran into about 10 errors that were really not errors but the dev environment being jumpy. Haven’t opened netbeans since

Team 1672 will be using C++ as we had hacked up the c++ library last year, and feel that we do not want to have put all that time to waste.

We’ll use LabVIEW but, particullary, I would prefer Java.
However, LabVIEW have all the “visual” things, like the graphs and real-time changings.
P.S.: I hate that blocks.

The only reason I use LabVIEW is because of it’s debugging capabilities. As far as I know, C++/Java still use a terminal window (then again I haven’t been reading up on those). Being able to see anything I want to from my program, in real time, with no extra work is just amazing.

'Course the downer is that it doesn’t work very well with VCS and if you’re a perfectionist (like me) all the little wires must be organized and straight.

-Tanner

LabVIEW can work well with version control systems. You just have to find an adequate set of instructions.

There’s a “broom” tool that straightens up block diagrams. It does a remarkably good job of organizing things.

Spoiler Alert: LV editing tips follow

For the perfectionists out there, I learned to use LV before the auto-routing and the auto tool. I still prefer it that way.

If the little wire bends bother you, try turning off the auto-routing. In that mode wiring will only produce a simple L for each click. There are two orientations to the L depending on whether you first moved horizontal or vertical. If you want to swap for the other, hit the space bar while wiring. Also, you can tack a wire wherever you like to cause it to go through that point. It takes a bit more thought, but but leaves you in control, and I guess I like it that way – though I do like the cleanup tool as well.

A similar tradeoff exists for the auto tool. Using the auto tool, LV will swap out the wiring, movement, and text editing tool depending on mouse position, clicks, and whether the object is selected. If you turn the auto tool off using the preferences, or using shift-right click, you can hit the space bar (provided you aren’t typing text), or tap the tab key to cycle through the common tools. You can also shift-right click to select the uncommon tools. Again, this takes a bit more thought, but leaves you in control.

There are also plenty of key hints you can give LV even if you leave the auto stuff turned on. I believe that holding Ctl and/or Shift key swaps to the alternate auto tool, and hitting the A key while wiring turns auto routing on/off. You may want to check the quick reference card or manual for others.

Greg McKaskle

We were going to use C++ this year, but switched to LabView because it is easier to explain to the freshmen who have no experience and we need to pass along our knowledge in order to keep the team alive.
So far we have not had many problems knock on wood and it’s running smoothly.