Curiosity on why most teams choose LabView
 

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. :D

~DtD

Re: Curiosity on why most teams choose LabView
 

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 :)

Re: Curiosity on why most teams choose LabView
 

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.

Re: Curiosity on why most teams choose LabView
 

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.

Re: Curiosity on why most teams choose LabView
 

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.

Re: Curiosity on why most teams choose LabView
 

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

Re: Curiosity on why most teams choose LabView
 

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.

Re: Curiosity on why most teams choose LabView
 

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

Re: Curiosity on why most teams choose LabView
 

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.

Re: Curiosity on why most teams choose LabView
 

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

Re: Curiosity on why most teams choose LabView
 

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

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.

Re: Curiosity on why most teams choose LabView
 

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

Re: Curiosity on why most teams choose LabView
 

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!

Re: Curiosity on why most teams choose LabView
 

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.

Re: Curiosity on why most teams choose LabView
 

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).

Re: Curiosity on why most teams choose LabView
 

Ni hardware, ni software, good fit.
wendy holladay
team 1912

Re: Curiosity on why most teams choose LabView
 

Our team uses Windriver primarily because our team has many students who are programmers. Programmers use programming languages. Labview is written in a programming language. I suspect that it was written in c/c++. If an individual desires to become a developer of products that use micro controllers they must know a programming language. If an individual desires to write desktop software they must learn a programming language. Having said that Labview is a great tool for people who are not programmers or have little knowledge of programming but need to create software that runs on a specific platform and need to do it fast. Gregs example highlights this. I personally enjoy the flexability that programming languages provide. They are universal allowing developers to write software for a variety of processor platforms. Although that the result may be the same, in some cases, whether you are using Labview or c/c++, to argue that one is better than the other is pointless because they are not the same thing.

Re: Curiosity on why most teams choose LabView
 

The other programmer and I who have been around began coding on the IFI controller in C. Last year, with much persuasion on my part, we decided to try LabView.

I was perfectly okay with it, but the other programmer despised it for a number of reasons.

This year was the first year we have truly had new members interested in programming. Though the mentors and I pushed for labview, we decided to leave it up to a vote of the new programming team. For whatever reason, they decided to go with C++ (I attribute some of this to the fact that two of the members are currently in our school's Computer Science class, which teaches in java, and thus provides text-based experience).

The idea behind the mentors' and my thinking was that LabView would be easier to teach, easier for them to grasp onto quickly, and more comfortable as many of them use it in their workplace (Medtronic). Luckily one mentor has experience with C++, and the other programmer and I have our previous experience work off of.

Still not sure why the decision to use C++ was made, and we will have to see how it turns out.

Re: Curiosity on why most teams choose LabView
 

That begs the question why Java was not selected if that's what the students are learning!

Re: Curiosity on why most teams choose LabView
 

Just FYI, LabVIEW is a programming language.

Re: Curiosity on why most teams choose LabView
 

Our team had been programming in C on the IFI controllers. We seriously considered continuing in C/C++ in 2009, but eventually decided to go with LabView.

We only had one Mentor with much experience in C/C++ and a couple who knew just a smattering. No students with any experience.

None of us had any experience in LabView, yet we decided to choose it because of it's building-block approach and visual clarity. We felt it would be easier to get students involved in the process.

Some of our students from a FLL background had used the NXT software, so they liked it.

We struggled at first, but eventually made progress and were happy with the results. We found a local resource who coached us on LabView and Ben Zimmers videos were extremely helpful.

Our schools don't teach any real programming courses, so there was no knowledge base in either C/C++ or Java. Our local university uses Java in their Computer Science program, but we have no resources there.

This year, we are so comfortable with LabView, we are continuing to use it and look forward to using it again.


...and yes, we had an autonomous mode - several of them - last year.

Re: Curiosity on why most teams choose LabView
 

Yes, Labview is a programming language by any standard. You have inputs and outputs, can implement general algorithms and data structures, etc. It's great for state machines, for example.

For the curious (see thread title) one reason we chose Labview is that we did believe it would provide general programming experience relevant to any programming language. Isn't this more important for children than cultivating specialized skills in a particular language?

Re: Curiosity on why most teams choose LabView
 

I respectfully disagree.

Re: Curiosity on why most teams choose LabView
 

Ok, by your definition wouldn't Excel would be considered a programming language?

Yes, if by "any programming language" you mean Labview

This is exactly my point.

Re: Curiosity on why most teams choose LabView
 

Not sure I agree with this statement: Excel is backend driven by VBA (Visual Basic for Applications), which IS a programming language. Excel is just a fancy frontend for it.

Re: Curiosity on why most teams choose LabView
 

Yes, I agree, that was the point of my post.

Re: Curiosity on why most teams choose LabView
 

LabVIEW is written both in C/C++ and LabVIEW. LabVIEW can also target and program a variety of micro controllers including ARM and ADI Blackfin. It can be used the write software for Mac, Linux, and PC.

Are .NET and Cocoa not programming languages by this definition?

But, we should all probably quick hijacking this thread... Back to the original question - I think LabVIEW is a good choice because it can lower the barrier for entry for computer programming without preventing teams from writing powerful software. LabVIEW is also a great icebreaker for those who find the syntax of text base programming difficult, but still want to learn the basic computer science concepts that are shared across all programming languages.

While working tech support last year I told many teams that were successful with LabVIEW to experiment with C++ in the off season. You can only benefit by challenging yourself and learning as many languages as possible to prepare for college and your career.

Re: Curiosity on why most teams choose LabView
 

I find that programming in Labview provides experience relevant for programming in general, including in C++ and Java, and listed some reasons why above. This was one reason to choose it for our team. (I would find Excel to be more special-purpose). I don't think you need to choose C++ or Java to learn programming.

Mainly, Labview seemed to have some major advantages for the FRC competition, as discussed above. No one has responded whether C++ or Java has similar capabilities. If they do, and us rookies had found out about it, more of us might have chosen differently.

Re: Curiosity on why most teams choose LabView
 

Okay, if you want to get pedantic about it, LabVIEW is a programming environment. The programming language is actually named G.

Re: Curiosity on why most teams choose LabView
 

We are going to use Labview this year because it's the easiest to use by those with little experience in programming. Please don't clutter the posts with trivial arguments.

Re: Curiosity on why most teams choose LabView
 

LabVIEW is easier to learn when you have no programming experience whatsoever- it's more visual and intuitive to use. We have a relatively high turn-over rate with our programmers, and we switched from MPLab and c coding to LabVIEW to facilitate passing on knowledge and teaching rookies.

Re: Curiosity on why most teams choose LabView
 

Considering that the most usefull thing that you could do in auto last year was "drive straight for 5 seconds" and that anything beyond that was gravy, points to the fact that the teams that "had no auto" were probably dealing with more challenging issues than which language to use.

The fact that their robots moved at all in teleop is a good indication that whatever language they used was sufficient for them.

I was a died-in-the-wool C++ programmer untill I learned LabVIEW for Lunacy back in 2008. I wasn't looking forward to it, but I made the switch for two reasons...

1) The language was being used in FTC and FRC, so a programmer I trained in one, was usefull in the other.

2) It seemed that LabVIEW would be more usefull to a wider range of Engineers/Scientists, than say C++ which would be best for a computer science student.

If you're programming an air traffic control simulator, you're not going to use labview, but how many engineers do that sort of programming?

I'm dissapointed that last years, (and maybe this years) FRC game didn't provide more reward for great auto modes, but I didn't see the teams that wanted to use labVIEW to do cool programming being limited by their choice.

Case in point... our FTC robot has a good range of auto modes that we'll be running in Atlanta later this year (for the second time).

I also really like the graphical debugging capabilities of LabVIEW, and I'm not sure I'd like to go back to text based debugging.

Phil.

Re: Curiosity on why most teams choose LabView
 

1075 has always coded our robots in C/C++ (well, since 2004 anyway). I personally use LabVIEW for work, and I have a very love/hate relationship with it. It makes some difficult programming tasks very simple, but makes some simple tasks rather complex, and the whole tendency to create spaghetti really bugs me.

Re: Curiosity on why most teams choose LabView
 

In the interest of keeping things educational and inspirational, I'll continue the hijack just a bit longer to give a response to what makes something a programming language.

A programming language is a mathematical definition that distinguishes valid and invalid user programs, and defines the result of carrying out a sequence of instructions in a user program.

Normally tools such as compilers and runtime environment ,or interpreters are built so that a computer processor can behave according to the language constructs.

As an example, C is a language. gcc is a compiler tool for turning user text sequences into processor specific implementations of the user's C code.

Similarly, G is a graphical language, LabVIEW is a collection of tools for writing VI code or for compiling to a processor specific implementation.

Similarly, JAVA is a language, Squawk JVM is a runtime environment for executing JAVA bytecodes, and NetBeans is a collection of tools that support the JAVA language and allow it to target a specific JVM.

It doesn't actually take much to build a programming language. The math and theory to classify the inherent power of a program running on a processor was done in the '30s. If a language can build a Turing machine, it is capable of solving all computable problems and therefore can write any program, any tool, and is Turing Complete.

Classification of languages is somewhat less well defined. According to http://en.wikipedia.org/wiki/Domain-specific_language Excel and other spreadsheets are usually classified as domain specific. The VBScript which is hosted within Excel is general purpose.

From the computer science perspective, LabVIEW, Java, and C are all general purpose languages, but differ in the paradigms they support.

Other less mathematical definitions you can use to determine the power of a language include ...
Can you write a good game?
Can you write a compiler for your language or another language?
Are people willing to spend their time and money learning and using it?
Can you build a successful FRC robot programmed in that language?

The answer for all three FRC languages to all of these questions is yes.

One of the great things about FRC, IMO, is the exposure to different tools and techniques, different approaches, and different solutions. Opinions are fine and good, but don't let them obscure an opportunity to learn.

Greg McKaskle

Re: Curiosity on why most teams choose LabView
 

What does that have to do with the topic (do you use labview and why)? If you want to fight about what makes a programming language, make another post, please.

Re: Curiosity on why most teams choose LabView
 

I apologize for not reading all 3 pages, but i had to skip some to be able to post this.

Last year I was the only programmer and my mentor had no experience in LabVIEW but we decided to take a chance and use it anyways. I am very glad I got the chance to use it however, we never were able to use it to its full potential, mainly due to time and manpower constraints. we were one of the robots at nationals that didn't do anything in autonomous for the first two matches simply because we couldn't figure it out. We eventually did, but not before I fell prey to death stares from four DANA mentors, three parents, 15 students (and a partridge in a pear tree) because our robot didn't move for two practice matches and the autonomous of the third. Our (more specifically, my) inexperience with the software as it pertains to FRC along with its perceived problems (download speed, learning curve, some other things) led us to change our environment C++ this year, and bring in four new members to the programming team. I felt it would not be the best for me personally, but it is definitely working for the team. Overall I'm glad I got the chance to use LabVIEW for the year, but it just didn't work for the team. I would definitely suggest that teams with programmers who have no experience with coding use LabVIEW. Maybe the team will return to LabVIEW as well next year when it can be seen as more stable by the team.

Re: Curiosity on why most teams choose LabView
 

Ok, I see that you only have three total posts on CD so I will be as gentle as I can. Just to warn you: this post has nothing to do with the thread. Normally I would disengage such converse however I feel that it is important to clear a few things up.

Yes the topic of the thread is "Curiosity on why most teams choose LabView" (not "do you use labview and why" as you posted) First and foremost this is a forum that has been created to help inform individuals and teams about FIRST and robotics in general. Information is shared, discussed, and often times debated. I posted on topic originally. I stated the reasons we as a team use c/c++ vs. Labview. The reasons I stated have become the topic of constructive debate (not an argument) between myself, others, and the boys in blue. While I may not agree with their opinion I do respect it as such. The discussion was not what I consider "off topic" but rather to the heart of it. The reasons people DO NOT choose Labview are just as important as the reasons people DO. Sometimes they are more important, especially to the company that created the software, National Instruments. I suspect my opinion is one that they hear often. I also suspect that they would like to understand it more and educate others who may share my opinion. Since your comment was directed to the people that make Labview I will assume that you are not aware of these things. The world is not always sunshine and gummy bears, people disagree about things. Engineers disgree often. Its how we approach these disagreements that make the difference between argument and constructive debate, productivity and failure. Please consider these things and keep an open mind the next time you decide to become the self appointed thread police.

Re: Curiosity on why most teams choose LabView
 

Our team selected LabView because we had no programming experience and two of our Mentors used it professionally and were able to get us up to speed. Since we were rookies last year when it first came out we jumped on it...

Re: Curiosity on why most teams choose LabView
 

We were a rookie team last year we choose LV beacause it is easy to teach and understand, we looked at Java this year but have decided that we do not have the background and could not find the information needed to teach or program anything in time.

Re: Curiosity on why most teams choose LabView
 

As the de facto programmer for the team i was "strongly encouraged" to use LABView, even though the more technically inclined people on the team have had more experience with Java and RobotC. O.o