Opinions wanted: LabView-based controller?

[Mark Pierce]

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

Originally Posted by Danny Diaz

... there are a lot of services we have to install ...

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

Originally Posted by Danny Diaz

... It does create sockets and interact with the networking stack in your computer for its own internal processing (so your Windows Firewall may bark).

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.

[eugenebrooks]

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

[Mike Martus]

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.

[JBotAlan]

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?

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

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

[Danny Diaz]

From what I gather, LabVIEW is actually being used in prototyping.

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.

Originally Posted by JBotAlan

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

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

[EricH]

Originally Posted by Danny Diaz

Then there's the FIRST LEGO League effect. How many students have programmed in RoboLab?

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

[Gdeaver]

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.

[Danny Diaz]

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

[ebarker]

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.

[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

[Dave Flowerday]

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?

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.

[eugenebrooks]

Originally Posted by Dave Flowerday

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

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

[Danny Diaz]

Originally Posted by Dave Flowerday

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.

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

[jgannon]

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. If you'd like to talk about the technical merits (or not) of LabVIEW in the FIRST program, I'd love to have an open discussion with you.

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.