Curiosity on why most teams choose LabView

[DtD]

Our team has used C++ on all of our robots ever since with started with Overdrive, and I have always wondered why it seems most teams choose LabView over C++ (Or Java in the case of this year.)

Is it experience? C++ seems daunting? Documentation for C++ isn't as solid? Forced by Mentors?

I personally encourage all my fellow programmers to do C++ because I think it offers real industry experience, is more useful in the future, and you can develop faster with it.

~DtD

[MrForbes]

interesting. Our electronics/programming mentor strongly encouraged the team to use LabView for several reasons...among them that he knows something about it, another that he would like to be able to hire young engineers that know something about it (and he knows that it's used in industry quite a bit). There are other reasons having to do with it's capabilities too, something about virtual instruments or something

[BLAQmx]

If you are using C++ you are writing software that offers real industry experience.

If you are using Java you are writing software that offers real industry experience.

If you are using LabVIEW you are writing software that offers real industry experience.

[cooldude8181]

The reason that my team is using LabView as opposed to C++ is because we feel that is is easier to teach the freshmen in a more visual based programing language.

I see no other advantage to it other than that.

[umangv620]

Originally Posted by cooldude8181

The reason that my team is using LabView as opposed to C++ is because we feel that is is easier to teach the freshmen in a more visual based programing language.

I see no other advantage to it other than that.

I agree. Teaching code to new freshman is challenging, so LabView is easier to use in the long run. Also I remember a few years back, when our robot would not run with the c++ code, and we were up next(this was at a competition), We were saved because we ran LabView code, and that worked perfectly.

Its mostly preference. C++, Java and LabView both provide an enriching learning experience and it will help in the future. It is better to be comfortable with all, but it is not mandatory to use one or the other.

[SuperBK]

We used C++ last year and will probably use it this year as well because we didn't have any experience with Labview, but already knew C++ really well. At a control system seminar before the kickoff last weekend, the presenter asked how many teams used C++. We were the only ones. We did try Labview for a couple of days, just to get some exposure to it.


Brian

[DonRotolo]

LabView is an easier language to learn than C++, particularly for high school kids. Our mentors use LabView in the real world, so their learning curve is almost zero. NI has a lot of support if you just go and look for it. These three factors push us towards LabView, even though C++ would certainly be a viable option for us.

[Bobert]

Labview makes it easy to debut programs. it also has a cleaner, more organized interface.

[gvarndell]

I wondered the same thing last year and started a thread on the subject myself.
In Atlanta last year, I couldn't help but wonder what percentage of the (very many) robots that did nothing during autonomous were LabView robots.
I suspect most.

[Greg McKaskle]

I wondered the same thing last year and started a thread on the subject myself.
In Atlanta last year, I couldn't help but wonder what percentage of the (very many) robots that did nothing during autonomous were LabView robots.
I suspect most.

I can't comment on these statistics, but I doubt that a poor autonomous routine has much to do with the tool. Since the urban challenge autonomous vehicle from Virginia Tech was programmed with a fair amount of LV by five MEs and a geologist and placed third, I really doubt that the tool is the issue.

Perhaps it has more to do with the team experience and capabilities.

Greg McKaskle

[gvarndell]

Originally Posted by Greg McKaskle

I can't comment on these statistics...

Perhaps it has more to do with the team experience and capabilities.

I didn't cite any statistics -- just personal observation and conjecture.

And, while it may appear I blamed LabView for robots having no autonomous capabilities, in fact, I attribute the tendency to choose LabView as being most often motivated by lack of software experience and capability.

I think the inexperienced generally perceive LabView as an easy tool for doing easy stuff -- which I admit it is -- but (I think it is) a fundamentally inadequate tool for doing harder stuff.

I should also point out that 1629's robot did do something useful during autonomous last year and was a LabView robot.

[Greg McKaskle]

Originally Posted by gvarndell

I think the inexperienced generally perceive LabView as an easy tool for doing easy stuff -- which I admit it is -- but (I think it is) a fundamentally inadequate tool for doing harder stuff.

Sorry if it came off as if I was challenging your statement/observation. My post was trying to offer up some possible reasons.

As for LV being fundamentally inadequate, this is one of the reasons I mentioned the DARPA usage. I can't claim that LV is the best programming language at any particular task, but I can point out customer successes.

If you want to dig deeper into the elements you feel are inadequate, I'll participate.

Greg McKaskle

[mswalker]

Our team used LabView last year and probably will this year (we are considering the Java toolkit.) The biggest benefit I saw was the ability to do realtime debugging by sampling the "wires" in Labview to see whether the system was doing what we thought it should. The graphical templates for each of the functions with identified inputs/outputs was also a plus. That helps the learning curve. We thought our autonomous was great. We found Labview capable of doing anything we thought of, partly because we had great help from NI Mentors!

[fritzdejongh]

We chose Labview for our 2009 rookie year after a control system workshop. With Labview, the virtual instruments (controls and indicators) are great, and the debugging is great. These seem to be the "killer apps" for Labview. There didn't seem to be anything comparable for C++. Did we get the wrong impression?

Also, with Labview it's very clear what's going on with parallel processing. You can write C like code blocks if you want for equations. And, you can certainly do hard things with it, for example, camera tracking was available in Labview. I can imagine that for advanced OO programming and AI that Java and C++ are much better, but for FRC I haven't heard of any "killer apps" you especially get with C++, it seems mainly to be a good choice if it's what you already know.

[jmanela]

The real time graphs and charts are invaluable as well. When testing our program, i also use the controls on the front panel, which makes making small adjustments very easy. (You don't have to stop the code, then re-hardcode something in your program and run it again (rinse, wash, and repeat).