Opinions wanted: LabView-based controller?

[Dave Flowerday]

Originally Posted by Danny Diaz

how many hits a particular search term reveals on an engine has VERY LITTLE to do with what this thread initially looked like what it was attempting to do.

Mike Martus asked what the industry was using, since he said he measures cirriculums based on what industry is doing. I think that's a legitmate question in this context and so I attempted to find some reasonably-unbiased data to answer the question rather than just stating that "I don't think a large percentage of the software industry uses Labview."

Anyway, I just want to clarify one thing and then I'll try not to post in this thread much more. I think Labview would be a great addition to FRC as an option. I'm sure some would love to use it and would get a lot out of it. What I asked in this thread, however, is what would the community think of a controller that required the use of Labview. It is this idea that I am not in favor of.

[seanwitte]

If a package like LabVIEW would enable more teams to have quality robots then it would be a great addition to the organization. This is only my opinion, but outside of embedded systems there isn't much need for C programmers. Job postings almost always include C/C++ even though you're far more likely to use .NET or Java. My personal feelings are that a single board computer with a data aquisition interface would be the best solution. At least then you would be able to work in the OS and development environment of your choice.

[Qbranch]

After reading many of the replies here, I think that there are really two angles that people have on this subject:

1) People who are non-programmers like the idea of a graphical programming environment.

And,

2) People who are programmers hate the idea of a graphical programming environment.

Since it seems that these two 'parties' can't be good bedfellows... I guess the solution is to remain with a controller that offers both graphical and textual programming options.

NI is beginning to realize this as well... as time goes on NI is allowing more and more of their hardware and software to be programmed through C/VB/etc... case in point... LabWindows/CVI can usually be used on NI hardware and software anywhere LabVIEW can go... there are still places where only LabVIEW can be used to write code but those places are decreasing.

Really where I see a ton of potential is in the awesome hardware NI has to offer.... it would be awesome to have an NI compact vision system on your robot! Just think... tracking at up to 100 frames per second! Not to mention full color processing and multi-object tracking... wow.... to have that for autonomous... could have found ringers in autonomous this year!

Wow i really hope we get some discounts from NI this year... imagine the possibilities!

-q

[Alan Anderson]

Originally Posted by Mike Martus

Question? Is Industry - wide scale using Lab view for their development and also are universities using Lab View for teaching programming in their curriculum?

LabView is indeed widely used, in both schools and industry. However, what I see it used for is almost entirely instrument control and data acquisition. What most of us would consider applicable to robot programming -- algorithmic transformation of inputs to outputs, tracking state, sequencing of actions, responding to feedback -- is much less common.

Where I work we use a National Instruments product called TestStand, so there is actually a lot of opportunity for that sort of programming here, but I find it a whole lot easier to use the non-graphical LabWindows/CVI for anything more complicated than a single function. "Non-programmers" naturally have the opposite opinion, but what they produce is often not easily maintainable. The LabView expert in our group does create wonderful tools and applications, though even he has trouble when they get complicated.

In the context of teaching programming, the only use of LabView I've heard of is specifically teaching LabView. For learning to program in general, a traditional procedural language like C or Java is still the rule.

[Jimmy Cao]

Personally, I have no objections to using Labview, except for the fact that I do not know how to use it...

I do know it is very powerful, and that people who know how to use it can do very complicated things, with relative ease.

If the new system uses LabView, I think I'll like it.

[Mr.G]

I have been programming assembly line test machines for 12 years and have used many languages and hardware: C, PLC, Flowchart, BASIC, and LabVIEW. I have also been programming FIRST robots for 6 years.

Here are my opinions:

Pros:
LabVIEW integrates with other programming software nicely. I.E, you can integrate C routines into a LabVIEW routine, so you can reuse code. It also comunicates with almost anything.

LabVIEW has hands down the best hardware that I have used in all areas. Reliability, Support, Integration, and at a pretty good cost.

LabVIEW is the easiest to teach if you have no experience like students do. Also, being a visual program I think it will appeal to the students more.

I think the current C program is overwhelming for the students the way it currently is laid out. All the extra programming that is in the current FRC code for interface to the field can be put into a single sub IV. Out of sight and out of mind. A’ man.

Students can take a piece of LabVIEW code and prototype it all by itself in a simple fashion, get it working on the pc, and then integrate it in to the main code with little help. Not having to know the whole code.

Cons:
LabVIEW is not very common except in testing equiptment.
Software licensee is expensive. (FIRSTer's get it free though)

Note: Our team has been unable to engage the students completely in programming in the 6 years I have been in it. I think LabVIEW is a good way to go, it is very easy to learn. I think a lot of people that are talking negative about it haven’t programmed in it. I.E. everyone hates change.

LabVIEW is good change for FIRST. I can't see things getting any worse, only better.

[JesseK]

Isn't it also possible to integrate Matlab algorithms into LabView? Aren't they pretty much one in the same? I seem to remember our LabView expert in college take our optical system that we had in Matlab and adapt it to LabView without much pain.

While some programmers have never used Matlab, I'm sure several Electrical/Systems Engineers have. The inability to use vector-based math without crazy lookup tables drove me mad over the summer when attempting to make a feasible, fast and accurate field-oriented mecanum drive algorithm for the RC that matched my pretty Matlab surface graphs.

[Chris Hibner]

Originally Posted by Mike Martus

Question? Is Industry - wide scale using Lab view for their development and also are universities using Lab View for teaching programming in their curriculum?

That's a good question, Mike.

There IS an industry-wide movement to start using rapid prototyping languages in the controls industry. Furthermore, there is an industry-wide movement to move away from hand-generated C coding of signal processing and control algorithms. Here's a little history:

In the VERY old days, a controls engineer would create a block diagram of the control algorithm by hand on paper. The control engineer would perform some basic analyses on the block diagram to determine system stability as well as responses to basic inputs. After this the control engineer would give the paper block diagram to the software engineer who would code it in C. A simulation environment would be created in C to test the control algorithm to determine if it worked like it should.

Since the above took a long time and the control engineer depended on the software engineers to finish a simulation environment, products such as Matlab/Simulink and LabView were developed. Now the control engineer can create the block diagram on the computer and start running simulations immediately. Once again, however, the block diagram must still be given to the software team for coding in C and final testing in a simulation environment.

More recently, products have been developed to "cut out the middle man" (i.e. the software engineer) and automatically generate the C code from the block diagrams. This has the very large benefits of: a) the code should theoretically be 100% bug free, and b) requires virtually zero man-hours to create the code.

In my previous life as a controls engineer, we extensively used Matlab/Simulink/StateFlow (which was much more suited to what we did than LabView). We also extensively used a product called TargetLink which is a 3rd party add-on to Simulink made by a company called dSpace. What TargetLink did was automatically generate production-ready real-time C code from the Simulink block diagrams.

TargetLink works very well, by the way. By the time I left my former job, we had put two generations of product into production using TargetLink to generate all of the control/signal processing algorithm code (not just two products, but two GENERATIONS of products).

Interesting side note: virtually all of the autonomous modes that I have been associated with on teams 308 and 65 have used TargetLink to generate a large portion of the code for the control algorithms.

Keep in mind that this works very well for signal processing and control algorithms. For other things such as certain diagnostics, operating systems, and communications, I think hand coding is still superior.

Sorry this was so long.

[Mr.G]

Originally Posted by Chris Hibner

More recently, products have been developed to "cut out the middle man" (i.e. the software engineer) and automatically generate the C code from the block diagrams. This has the very large benefits of: a) the code should theoretically be 100% bug free, and b) requires virtually zero man-hours to create the code.

Chris, I never tought of it that way and I think LabVIEW does eliminate a lot of C coding and syntax.

Originally Posted by JesseK

Isn't it also possible to integrate Matlab algorithms into LabView? Aren't they pretty much one in the same? I seem to remember our LabView expert in college take our optical system that we had in Matlab and adapt it to LabView without much pain.

In my 12 years I haven't come across anything that you couldn't integrate to or communicate with using LabVIEW.

[EricVanWyk]

Originally Posted by JesseK

Isn't it also possible to integrate Matlab algorithms into LabView? Aren't they pretty much one in the same? I seem to remember our LabView expert in college take our optical system that we had in Matlab and adapt it to LabView without much pain.

While some programmers have never used Matlab, I'm sure several Electrical/Systems Engineers have. The inability to use vector-based math without crazy lookup tables drove me mad over the summer when attempting to make a feasible, fast and accurate field-oriented mecanum drive algorithm for the RC that matched my pretty Matlab surface graphs.

Yes, you can place MATLAB scripts into LabVIEW quite easily. The only part I had difficulty with is making the types line up appropriately. After a small dose of RTFM and casting into baser variable types, everything was just ducky.

[EricS-Team180]

Originally Posted by Chris Hibner

More recently, products have been developed to "cut out the middle man" (i.e. the software engineer) and automatically generate the C code from the block diagrams.

The aerospace industry incorporated "pictures-to-code", starting back in the 1980's. It never truly eliminated the middle-man, since we aero's needed software engineers to develop and maintain the process and keep porting it to new hardware platforms!

Easy-C for FTC and FRC is a pretty decent implementation of the concept. While we use Easy-C for all our FTC teams' programming, we teach C and write customized code at the FRC level.

After trying out LabView 2 years ago, in the pilot project, and after reading through this thread, I have to align myself with those who'd accept LabView as an option for coding the FRC, but - please - not the only option.

Thanks,
Eric

[Zflash]

To those teams that participated in the pilot project. Do you have any suggestions on how someone new to lab view shoud get started or any tips or lessons learned? Other then the material that National Instruments has already put out of course.

Thanks in advance.