Opinions wanted: LabView-based controller?
 

Many of you probably saw the rumor that was posted in another thread that the new RC was to be an NI device that is programmed using LabView. The poster later recanted that statement, but it brings up an interesting topic.

I know there are already several other threads on the new RC, but I'd like to discuss something more specific in this thread. I am curious about how would you here on CD would feel about an RC that required the use of LabView to program it. I have a strong opinion on this subject myself, but I won't go in to that right now. I would, however, like to know how the rest of the FIRST community would feel about that option (well, at least how the "people-who-post-on-CD" community feels anyway).

Tell us what you think the pros and cons are, tell us why you like or dislike the idea. Tell us if you have first-hand experience with LabView or if you're basing your opinions on second-hand information or just what you think you know about it (it's OK if you don't have experience with it, but I think it's important to note what your opinions are based on).

Anyway, I hope this might generate some interesting conversation.

Re: Opinions wanted: LabView-based controller?
 

My opinion: Bleah. That's a sticking-out-tongue bleah, not a shrugging-shoulders one.

LabView is useful, powerful, and appropriate in some contexts. In my opinion, a project with thousands of programmers creating thousands of individual programs with many shared features is not one of those contexts. Learning the LabView "style" of programming does not carry over well to other development environments (and vice versa).

If FRC were to start providing LabView-based robot control systems, I think the pool of helpful programming mentors would shrink drastically. Even with experienced programmers standing by to help, it's a lot easier to do text-based support on a forum like Chief Delphi than it would be to try to assist someone having problems with a graphical programming language that hides details behind separate layers of views.

(I have programmed using LabView, and I use LabView-developed systems regularly.)

Re: Opinions wanted: LabView-based controller?
 

I have never used LabView for development, however in my opinion a move away from C would be a big mistake. The biggest pro of using C is that it is the one language you will find in almost every technical industry and University engineering program.

Re: Opinions wanted: LabView-based controller?
 

I have experience in LabVIEW... for better or worse. I guess i'll just start out with some pro's cons for the language itself:

Pros: Insane amount of conenctivity options, rapid software prototyping, many built in Signal Processing filters and functions, little learning curve for very basic operations, graphical, great quick easy operator control pannels, easy integration of multiple high complexity sensing systems, C code snippets can be used, LabVIEW vi's can be compiled to ANSI standard dll's, can handle and optimize-compile for multiprocessor/multicore and 64bit processors, can compile to FPGAs, compatible with SolidWorks CosmosMOTION in-pc design mechatronics/programming full simulation system (run your code in a purely virtual full physical simulation environment)

Cons: MEMORY INEFFICIENT (all variables passed by value), LabVIEW code runs at decent speed but isn't the most efficient, code nearly impossible to document, debug difficult, code appears extremely complex, some fundamental features missing (ex, poor array functions), no zoom on editor (it sounds trivial but just try 'writing' code for a while), complex functions have large learning curve, debug sometimes difficult.

Now that's just LabVIEW.... NI hardware is AMAZING! I usually avoid labview but for some functions speed is not a huge issue, and the picture (code) you make isn't way too hard to read, then i sometimes use it favoring speed of development over execution efficiency and algorithmic power.

NI has a gigantic array of hardware... all of which is expensive for FIRST robot type price ranges and probably overkill... but wow... the thought of having a PXI chassis on a robot with an XPe computer card.... whoooo hoo. For those of you who arent familiar, you really should check out NI's hardware products... I've experience with their M-cards (PXI I/O cards), NI-Motion cards (fantastic performance! but $$$$$$), CAN-interface cards, Vision systems (check out VBAI) and others.... all of them have performed with exemplary performance.

So, in my opinion, would it be cool to have a PXI or something of the sort NI hardware based controller? ABSOLUTELY! (provided we got hefty discounts)

Would I like to see LabVIEW show up on a FIRST controller? Not so much... I don't mind if its an option, but I'd still like to be able to write C, even if the C code runs within an NI framework... as long as the C code you can write is not in any way restricted (i.e. can still run arrays and such)

What do you all think....

-q

Planning, Training, and Support Critical
 

I'd much prefer to stick with text based programming for the same reasons already mentioned by others. I can see some benefits to the Labview environment and done right it can work.

However, getting it "done right" can be tricky. My FIRST Labview experiences have not made a good impression. This applies to both trying to get the Camera code working a couple of years ago and trying to do a data acquisition project last year. I'll admit to not doing much of the tutorials, but a lot of my concerns really aren't covered in the ones I did try.

1. Installation instructions have been poor or missing, even with correct instructions it takes a long time to install. We usually have four classroom computers plus at least two mentor or loaner laptops.
2. Sample applications have been buggy and cumbersome. (Think version 1 of CMUCam application)
3. The environment likes to start up device drivers for devices when you start the system. I still get occassional error messages from some LV process while shutting down my laptop.
4. LabView also likes to go out to the network when you start it. When I'm programming for FIRST, I hardly ever have a network connection. I think I eventually figured out how to turn this off.
5. LabView (or at least the applications I've tried) seem to require a lot nicer laptop than the hand-me-down school laptops we've used.

I'm sure we can work with it, but as I've said elsewhere, the sooner we know what we're working with the better. This would be a major change, not just a rehashing the current code. Labview based development will call for an entire new set of training resources. The demo at Kettering made it look more promising than I would have thought, but the details are key to making it work.

Re: Opinions wanted: LabView-based controller?
 

For those of you who don't know me, I am a LabVIEW developer working for National Instruments on the LabVIEW Floor. Admittedly I do not develop features in the Core of LabVIEW, I am the owner/maintainer/developer of our x86-based RTOS used in LabVIEW Real-Time. Now that this has been said, I'll be frank with my own personal experiences - I use LabVIEW for several of my "personal" projects as well as in-house projects.

Learning LabVIEW from a C and Pascal based background was definitely not the most pleasant experience; I was a Co-Op student at GTRI and my boss threw LabVIEW and some IMAQ hardware on my desk and said, "Use this to track people walking under a camera." In a couple weeks I learned enough LabVIEW code and its syntax to do pretty much anything I wanted, but the hardest part about learning LabVIEW was getting out of the C mindset. I pulled my hair out trying to figure out how to lay down the code blocks in the correct format, tried to figure out what styles of structured programming work for different scenarios, and until I learned to use the tools that were in front of me built into the language I had a difficult time. It's no hidden secret - just like any other language, Dataflow languages like LabVIEW have a completely different "style" of programming and until you've been programming in it for a couple weeks it's going to be somewhat painful to transition.

I would declare myself an expert C programmer, and a proficient LabVIEW programmer. I can do things in LabVIEW in a couple clicks of a mouse that would take me an hour to do in a language such as C. On the flip-side I can perform some specific programming tasks in C in a few minutes that takes me an hour to do in LabVIEW. I can read a C program for an hour and understand everything about it, but I might spend twice as long on a piece of LabVIEW code and still not know all the nuances about it. Reading this you might say, "Well, then, the choice is clear - C is the better environment." I say you can make no such statement - it's impossible to make a qualified comparison between the two languages. And once you are experienced enough to think you can make a comparison, then you will realize there's this thing called LabVIEW Real-Time, and your assumptions about memory, diagrams, and performance just get thrown out the window!

LabVIEW Real-Time, which is what we use on our PXI, cFP, cRIO, and CVS hardware is optimized for the embedded space; what I mean here are targets with very little memory and slow processors. Of course, now that we've got LabVIEW Real-Time SMP we can handle multicore devices and do things that other RTOS systems can only drool at. Would you like to have an entirely dedicated core for a PID loop? Yeah, we can do that. Would you like to have native parallelism (native threading model)? Yeah, done. Would you like to be able to interact with your hardware on a low-level or high-level basis? Yeah, we've been doing it for years.

However, we are definitely in the same boat as C, JAVA, or other "traditional" languages - we're only as powerful as the guy writing the code. Just because you have a .c file or a .VI shouldn't cause you to think any differently about the quality of the engine being used to compile it or to run it. I say this because a lot of people had problems with the CMUCam application that was written and provided to teams. That code was written by a FIRST supporter and volunteer who had an extremely good piece of hardware in his hands when he wrote that code. However, he didn't account for the garbage that is sold really cheap these days, and didn't put in the required error detection and correction code that was eventually needed. Plus who would have guessed at the wide range of hardware issues that eventually came into play when dealing with the CMUCam? There's a whole forum on the problems people have had with that hardware when interfacing with LabVIEW, and several more forums on problems with interfacing with C!

Customers who use LabVIEW love LabVIEW for its inherent parallelism - its ability to natively be multi-threaded. That's a powerful tool, but one that you STILL have to understand what you're doing before you do it, even in C. Race conditions, synchronization, scheduling - all things you still have to deal with, even in LabVIEW.

For good or for bad, it's easy to find things you don't like about LabVIEW. It's also easy to find powerful things about LabVIEW that just cannot be done in languages other than LabVIEW. I could talk for hours on the benefits of LabVIEW, specifically relating to FIRST Robotics, and I can even give you some reasons why LabVIEW might not be the right language for FIRST. But unless you hear them all it's near impossible to make the determination that needs to be made eventually, which is the question you're asking - Should LabVIEW be a language that teams use to program their robots?

-Danny

Re: Planning, Training, and Support Critical
 

Sorry to hear this.

Yup. There's a lot of code and we support more hardware than anything else you've ever installed on your computer. It's the nature of the beast.

Please refer to my previous post.

Because Windows is, well, Windows, there are a lot of services we have to install in order to be able to support the plug-and-play nature of some of our devices.

Never heard of this. There is no reason LabVIEW needs to go to the network, it does not call home unless you ask it to during the initial licensing phase. It does create sockets and interact with the networking stack in your computer for its own internal processing (so your Windows Firewall may bark), but there's no reason for it to go to the internet or scan a network.

For running LabVIEW applications on the laptop, yeah, you're right. But you would never use straight-up LabVIEW on an embedded target, you'd use one of our flavors of LabVIEW Real-Time.

I think everyone is on edge waiting to see what's coming down the line. :cool:

-Danny

Re: Opinions wanted: LabView-based controller?
 

You seem to be in a position to answer the question with an informed opinion. Why not go ahead and do so?

Re: Planning, Training, and Support Critical
 

Personally I'll bet it's more like "It's the nature of the design decisions that were made." I've seen and worked on very complicated software, and I refuse to accept that software which is big and complicated by definition must be buggy.

On the other hand, if it is true that big, complicated things like LabView are inherently buggy then I'd cite that as a good reason not to use it.

Re: Planning, Training, and Support Critical
 

I'm sorry, you must be mistaken. My 2 statements you quoted were not in any way related. In your quote, you quoted two of my replies. In the first reply I was referring to the "taking a lot of time to install" when I spoke of the nature of the beast. In my second reply (about the buggy software) I was referring to my longer post where I spoke about the problems with the application in question. After reading both posts I have made to this thread (previous to this one) I'm sure you will realize the misunderstanding.

-Danny

Re: Opinions wanted: LabView-based controller?
 

While a LabVIEW-based controller would run fine, there are teams out there programming on a 350MHz laptop with a 6GB hard drive with 128MB of RAM. Try installing, let alone running, LabVIEW on that. :ahh: And LabVIEW does NOT need to install any service on my machine (a good program does not rely on them), or start anything up at startup, yet it was trying to start at least 3 processes (which I promptly disabled) at startup.

I also find that documentation on LabVIEW is extremely sparse. For C, there are *tons* of tutorials. Not so for LabVIEW. Mostly because it is so expensive.

At least before today, the MCC18 compiler could be run on any system, even Linux, through WINE. I'm 99.99% sure LabVIEW won't so as well in an emulator. What about alternate OS programmers?

I'm tired of proprietary software. I'd like to see IFI or whoever designs the new controller to *completely* open-source the whole thing. Schematics, master code, compiler, IDE, etc. That would be really nice.

If LabVIEW was quite a bit less beefy, then maybe I might go for it. However, I think that many programmers would be disabled by LabVIEW--it wouldn't install on their systems, or would crash. It's fine for industries that can afford new computers, but we are not such an industry.

It's not that I'm trying to put down LabVIEW; I believe it has applications in other areas (signal processing and simulation are two areas that come to mind) but I don't see it as suitable for FIRST.

Maybe I'm just biased by all of the nice open-source projects I've seen, but that's my 2 cents on this topic.

JBot

Re: Opinions wanted: LabView-based controller?
 

That is right. I don't remember how long it specifically takes to install LabView but there a significant amount of other programs that you install in a full installation. I also don't remember needing instructions though.
Labview can be run on all systems. In fact it would be a step up from running an emulator. It stems from the fact that LabView was originally designed on a Mac.
The problem is that you would be severely limiting your options with such a constraint. There are very little microcontrollers that have open source compilers. I'm all for using LabView if I can be shown it's a good choice for this application. I'm certainly convinced that it's an excellent choice for experimentation and data collection. I can collect data from many different instruments with a minimal amount of effort.

Re: Opinions wanted: LabView-based controller?
 

Umm...FIRST shipped the WINDOWS version of LabVIEW. AFAIK the other OS versions have to be ordered separately and are separate licenses. Those licenses are not cheap.

I am fairly convinced it is not a good choice for the reasons I outlined in the post you responded to.

It would be fun to experiment, but when all is said and done, I am much happier coding in C.

JBot

Re: Opinions wanted: LabView-based controller?
 

Yeah, you're right, if you walked to your local sales office and tried to pick up a copy of LabVIEW it'd cost you several thousand dollars. However, National Instruments feels FIRST teams shouldn't pay a penny for LabVIEW, and so far that's how we've handled that situation. Teams who want a copy of LabVIEW for Linux or for the Mac merely have to ask for the specific operating system version. We had a thread over in the National Instruments LabVIEW topic in the Technical section where some had asked for the Linux and/or Mac version, and we told 'em where to send the e-mail requests; everyone who asked got their copies, some even got upgrades when the upgrades came out... :)

I'm sure you're not the only one, primarily because that's "what you're most familiar with." I recently had a very "rich" discussion with a group of 7th graders who wanted to program their LEGO Mindstorms robots with Java, and their primary rationale was because "it's what everyone programs in nowadays." So I asked them how rich their library set was, how quickly they could get a program up and running, how easy it was to debug, how extensive it was, and questions like this to try to get them thinking about the things that would be important to consider. Their immediate reaction was one of, "but I KNOW Java, I have used it FOREVER, I don't want to learn a new language!" Those are all good reasons for a 7th grader to stick with when programming a LEGO Mindstorms robot, but is it the best one for an engineering competition such as FRC? I dunno, I'm still on the fence.

-Danny

Re: Planning, Training, and Support Critical
 

Danny, thanks for your replies, It's nice to have your expertise here.

That may be true, but these services should be inactive unless I'm using LabView and should shut down without errors when windows does.

That might very well be what I saw.

Ultimately, the main message that I was trying to convey in my earlier post is that we'll need adequate time, samples, and resources to successfully use whatever controller we go to next. I appreciate the effort that went into the Labview samples we've seen (CMUCam and others) I just remember having a student become more frustrated than inspired trying to get things to work.

I think the LabView RT system has real promise as a controller. I'd rather have a less bulky and complex system to program with, but I am intrigued by the possibilities of the hardware and software.

As to whether this is like what is used in industry, I think the graphical approach is becoming more and more prevalent even where C programming is done. We use UML diagrams for our design documentation and some code generation. We have also looked at other graphical tools as well. Graphical programming has been used for years in factory and lab control applications. Actually, Relay Logic and PLC controls which have been around for decades are actually simple graphical programming environments.

Re: Opinions wanted: LabView-based controller?
 

I would agree with the sentiments already expressed in this thread. As the only programer on a rookie team last year, it was relatively easy to get going with C moving from a Java background. Learning a completely new paradigm in the six weeks would have been nearly impossible. My only experience with LabView was from the camera setup, and I found it quite confusing.

Another thought, what kind of source management system (if that would even be the correct terminology for a graphical environment) works with LabView? Now that our team has grown and we will have multiple programmers (who were recruited for knowing C), we are considering keeping all of the source in a Subversion repository. Would this or something similar be possible using Labview?

Although I don't know enough about LabView to form a valid opinion on its use, I agree that we would need ample time before the build season to prepare for such an extreme change. Last year I attended a WWRF workshop in November or December that help bring me up to speed for programing the robot in C - workshops such as these would be vital for the use of LabView. I also generally favor simpler low level solutions and would be extremely hesitant about moving away from good old C.

Re: Opinions wanted: LabView-based controller?
 

I mentored robot programming during the pbasic days, including writing state machines with students to handle autonomous operation. It was a breath of fresh air to switch to a C based system, polluted by the requirements of an 8 bit micro-controller as it is, and have the opportunity to teach students to program the robot controller in C. In doing this the students learn something that is applicable to their future college experience.

I can't say that I have spent a lot of time with Labview, but I was not very impressed with the use of labview to do initial work with the CMU camera. We ended up tossing these activities to develop variations of the camera software Kevin Watson provided. I don't see the value in students learning a proprietary programming system that they may never see again.

I have the strong opinion that a conventional C environment should be offered for any future robot controller, and I am not referring here to snippets of C code to be buried in some larger graphical programming environment. It would be great to have a controller along the lines of what Labview runs on, but it is clear that we will not be able to afford to buy these controllers looking at the prices for them. Being able to have controllers to use in development efforts outside of the actual robot is important and the EDU contoller provided by IFI went along way to satisfying this need at cheap prices.

To be blunt, I resonate with Alan here, highly skilled and dedicated programming mentors will drop out of the FIRST FRC program if they are forced to move away from a C programming environment. If this is where FIRST is headed with its new controller, for whatever reason it is headed in this direction, it needs to consider the error of its ways. I would suggest, instead, that a more rational ANSI C programming environment, with a suitable debugger interface be offered. It is perfectly okay to offer something in addition to that, but failing to offer a conventional C environment would be an error. One could add to this a Java environment, or any other additional environment like easy C, etc, even LabView, but these things sould be in addition to and not intending to supplant a conventional C environment.


Eugene

Re: Opinions wanted: LabView-based controller?
 

My comments are as a NON programmer, just a teacher of a shop class.....

Easy C has been our savior the last two years. It has done all we asked and it was done by a student........

With no programming engineers (like many teams) and no programming classes in our school district (like many teams) I fear that a choice to move to a platform that is not as easy as Easy C and not to have the choice to do C if we have the expertise on our team will be a major misteak(sp :)) for FIRST.

In education I measure the curriculum worth by a comparing of "What is Industry using" standard.

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

If not them I say it would be a very poor choice to move to this.... my non programmer opinion.

Re: Opinions wanted: LabView-based controller?
 

Funny you should say that. I am going on 5 years as a mentor with LASA Robotics (FRC418) and we've graduated on average 10 team members each season, with most of them being spread into the wind to different engineering institutions. The result is always the same. Here's a snippet from an e-mail I received TODAY from a team member that went to the Illinois Institute of Technology -
This isn't by accident. CalTech has a "National Instruments" laboratory. The University of Colorado at Boulder uses LabVIEW in its labs. The University of Texas uses LabVIEW extensively in its EE programs. Virginia Tech uses LabVIEW Real-Time in its Robotics labs and as the foundation of the programming software in their humanoid robots. If I were in the Academic group I could go on for hours telling you about the Universities and Institutions around the world that are using LabVIEW.

When I watch the Discovery Channel, and they show the researchers working with their equipment, I have a hard time NOT seeing a National Instruments PXI or cRIO system as the controller for their experiments. The readout screens they put up on the TV are LabVIEW screens. At NASA and JPL they use LabVIEW quite extensively. CERN is a big customer of National Instruments hardware, it's being used in their SuperCollider project. Lockheed Martin uses LabVIEW Real-Time in a lot of their test and measurement systems. In Germany the Max Planck Institute for Plasma Physics uses LabVIEW Real-Time to control the flow of plasma in several of their advanced experiments. You should watch the NI-Week 2007 keynotes that are archived on the NI website, it's really eye-opening.

I can almost say that if you work for a big company and you don't see LabVIEW somewhere, you're not looking hard enough. If you go to a school and are in an ME, EE, or CmpE program, and you don't see LabVIEW, go back tomorrow and check again. There's no shortage of the need for experienced LabVIEW programmers, but last time I checked more and more schools are dropping C programming for JAVA...

-Danny

Re: Opinions wanted: LabView-based controller?
 

From what I gather, LabVIEW is actually being used in prototyping. I don't know how widespread this is, but it is out there. I do suppose I should force myself to learn it, but I think at this point, C, C++, and the Microsoft .NET languages (C#, VB, and I think there's more but I can't recall them right now) are in the most demand.

At this point I am on the fence. My instincts say no, only because I know C and am comfortable with it. Then again, there are valid points to learning C and there are valid points to learning LabVIEW...

Ugh...I don't know...
JBot

Re: Opinions wanted: LabView-based controller?
 

Not only that, but a LabVIEW prototype is quite different than most other prototypes. Have you ever heard of the Segway-like system developed by Rensselaer Polytechnic Institute? Here's a link to a description of their project.

http://zone.ni.com/devzone/cda/pub/p/id/177

They did the prototyping in LabVIEW, and in no time flat they took the prototype code and ported it to a real-time controller and had a functioning system in less time than it takes most companies to decide whether or not they're going to scrap a prototype or keep working on it.

If you are using a cRIO, the power there is the FPGA involved. You can offload most of your hardware processing to the FPGA, and handle all your "software" work on the controller itself (why should you do stuff like counting events in software when an FPGA can do it in hardware?). Once you have your FPGA running like you want it, the same code you used to program the FPGA can be given to a fabricator to make you a chip. How many CmpE and EE students wish they could use LabVIEW FPGA in class to program an FPGA rather than have to know YET ANOTHER language (VHDL) to do it? <raises hand> Yeah, it's that powerful.

Yep, I can't argue with that. However, not everybody is a programmer. How many people do you have on your team, and what percent of them don't code? The power of LabVIEW is that you don't have to be a programmer to write functional LabVIEW code - by incorporating LabVIEW, you are going to be able to involve the non-CS members of your team more readily. I'm not saying it will be immediate, however, but you're going to be able to empower students who have never touched a text-based language in their lives, and shockingly enough they'll probably write the best code. If you're skeptical, that's exactly how it works in industry. In LabVIEW you don't have to write complicated code to get complex results.

Then there's the FIRST LEGO League effect. How many students have programmed in RoboLab? How many of them will now be able to program in LabVIEW? The results are stunning. Again, watch the NI-Week Keynote videos, especially watch Thursday's video. Then tell me what you think. ;)

-Danny

Re: Opinions wanted: LabView-based controller?
 

Interesting question Mike... I haven't encountered anyone using LabView at work or at our suppliers myself, but that's obviously only a small data point.

Out of curiosity, I went to Monster.com and did some job searching for Chicago. "C" is unfortunately a terrible search term so I searched for 3 things: "c++", "java", and "labview". Java generates 674 hits, C++ generates 294, and LabView generates 5. Take that as you may.

Re: Opinions wanted: LabView-based controller?
 

And "C/C++" gets 1624 hits over this way...

Lets get serious guys, if we want to teach programming in our FIRST activities
a high performance a C environment on a more powerful processor (with a nice
debugger hookup) is the answer. The "higher level" environments are great for
teams without good programming mentors, as noted by posters in this thread.
If FIRST decides, for whatever reason it might, that we should be teaching LabVIEW
(LabVIEW is heavily used and taught for lab use where I work), then one is going
to have to round up a large number of new LabVIEW mentors (not programming
mentors) to do that. This [potential?] decision is neither good, nor bad, it only has
consequences...

Eugene

Re: Opinions wanted: LabView-based controller?
 

I think you forgot the 69 after the 5. When I did my search on Monster I got 569 hits for "LabVIEW". But that's neither here nor there, 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. I'd like to get back to that please... :)

-Danny

Re: Opinions wanted: LabView-based controller?
 

I can't swear that this is what Dave was getting at, but it sounds like he was mirroring some of my sentiments. I have never written any Labview, so I can't make any comments as to the language itself. However, I think that a migration to anything that isn't particularly popular in education and in industry is a bad move for FIRST. Though he only provided one data point, what Dave pointed out is that Labview does not appear to be nearly as popular in industry as C or Java. This is a two-fold problem, because it means that teams will have a harder time finding mentors to teach it, and that students won't have as many opportunities to use their learned skills when they graduate. I'd say the same thing about OCaml, Foxpro, or pretty much any other language that isn't BASIC, C, Java, or maybe Python... they definitely have sizable user bases, but not THAT big.

I'm a computer scientist. I trust that I'll be able to pick up Labview pretty quickly should the need arise, so I'm not worried for my team. However, I fear that a move away from "traditional" languages will put teams with minimal programming resources at an even bigger disadvantage.

Re: Opinions wanted: LabView-based controller?
 

You didn't restrict your search to Chicago.
There are 5 hits on labview.
Just to provide the evidence that statistics never lie,
read the first hit. Micro-controller programming in
C/C++ is the primary requirement, labview is the "plus". :)

Eugene

Re: Opinions wanted: LabView-based controller?
 

Or the new language, which is also Labview based? The teams I used to mentor switched from RCX code to the new language in one year, with RoboLab as the stepping stone.

Personally, I could care less about which one is used. I'll take the best tool in the box that I know how to use. (Right now: neither C nor Labview. It's called a professional programmer.;) )

Re: Opinions wanted: Lab View-based controller?
 

In the discussions concerning the new First RC, this is the first time anybody has pointed to a complete hardware, firmware and software commercial platform that could be wrapped up and used as a total competition system.
I started a post - chicken or the egg. Taking about the software with out looking at the hardware to me makes no sense. Someone has to integrate all the pieces into a system we can use. With NI Labveiw and the cRIO this has already been done. The question is can this system take us forward and deal with the future. What if 3 years from now a semiconductor company came to First and said that they will provide to each team a 3-axis accelerometer evaluation board. By the way it's a low voltage xyz buss interface. Could the NI system use this device? Can our current system? Or, What if a automotive supplier offered a intelligent ECM servomotor gear box assembly for a fantastic price and it uses a can interface. Could the NI stuff use it? Can our current controller.
When I was taking CS, I was told FORTRAN was thee language for technical programming and was drilled in it. C was an odd language only for those Unix nuts. I was told there is no job market for C. Learn Fortran and Cobol and you'll have a job. Data flow is a totally different mindset. It will drive competent low level programmers crazy.
My son is a 3rd year ME student and many of his labs are designed around the NI platform. To him, It's just the way it's done.

Re: Opinions wanted: LabView-based controller?
 

I've had several requests for the links to the NI-Week 2007 keynote videos. Here is the link:

http://www.ni.com/niweek/keynote_videos.htm

The Thursday, August 9th video set is really geared towards the majority of the concerns in this discussion.

-Danny

Re: Opinions wanted: LabView-based controller?
 

We are talking several subjects here.

a) what is a good way to educate students about programming?
b) what should a FRC control system look like?
c) what is the value, or best use of Labview?

These answers may, or may NOT have common ground.

20 years ago I ran an engineering group that developed a system for internal use in our company. shortly thereafter Labview 1.0 came out and it had basically the same objectives as our system.

There is a very firm case that can be made for using Labview in certain type of environments. Probably the best case is where you have to lash together a lot of instrumentation, or control components to quickly put together some sort of system. Prior to these types of products a company or agency would literally spend millions of dollars and years integrating these systems together.

Yes, if you get good at Labview, there are plenty of jobs. A good starting point for a motivated student is to redo the CMU app.

Would I like Labview for a robot controller? No, I do not think it is appropriate for use in the FRC community as a robot controller. I'd prefer to see ANSI C for that task.

Something that National might want to think about is helping students focus on a more narrow use of Labview in the form of a contest and provide incentive with an award, much like Autodesk does with the animation and documentation awards.

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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

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

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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! :cool:

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

Re: Opinions wanted: LabView-based controller?
 

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.