C or LabVIEW: CompactRIO

[whytheheckme]

Originally Posted by lingomaniac88

Hmm... I'm considering buying an NXT to practice working with LabView between now and next year's season.

Same here.

I see LabView dominating most certainly the rookie teams, as well as the more advanced veteran teams. I think a lot of veteran teams will be at a disadvantage this year, when they just touch LabView for the time in January, while others have been practicing on their NXTs for months. I have a feeling that next year's game will heavily weight a team's ability to use some higher-end sensors, and I think that LabView is really going to help out in this regard.

My 2 cents.
Jacob

[Richard McClellan]

Originally Posted by markulrich

What do you think is the "best" way to have students learn LabVIEW during the offseason? Is there something better than the lego NXT, something more similar to what FIRST will use? Is there a good simulator (built into LabVIEW??) that students could use at home?

The Lego NXT is probably a good option for learning LabVIEW right now. However, I believe that NI is going to try and get the new controllers to the teams prior to kickoff so that they can start learning a little bit early. The last thing they want is for build season to start and have everyone struggle to learn LabVIEW in 6 weeks. Nothing is definite yet, but they said something might be ready at the end of summer/early fall time period.

[Danny Diaz]

Originally Posted by richardmcc2

The Lego NXT is probably a good option for learning LabVIEW right now.

I agree. Anything that will allow a team to become more familiar with LabVIEW will give them a head start, and the NXT is a great platform for doing so.

Originally Posted by richardmcc2

However, I believe that NI is going to try and get the new controllers to the teams prior to kickoff so that they can start learning a little bit early.

That's the plan, inasmuch as I am aware. However, plans are contingent of a lot of things going right and are subject to change - everybody will be apprised of the situation as it draws closer, I promise.

-Danny

[JesseK]

1) What is your team planning to use?
I want to use LabView itself. I hate dealing with pointers. I'd rather work from an algorithmic level than a nit-picky tit-for-tat variable level. However, I'm not the programming mentor so I don't have final say for what the team will use.

2) What do you think will become the new standard?
In 2 years, LabView. Veterans who stuck to their guns in C/C++ will experience shock and awe when they're stomped by algorithms that would have been hard to program in C, namely things that have to do with the vision system.

3) What will most rookie teams pick next year?
No clue. It seems logical that the previous reply about "whichever has more documentation" is the best prediction.

4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
The FIRST rep at the Q&A said there would be specific libraries for use with an FRC bot. These libraries are being developed by WPI. Other than that, no mention was made about a "custom interface" to the CompactRIO. So it's standard labview with a few bells and whistles that tell the RIO what ports map to what pwms, etc (I think).

5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
Let me consult my Magic 8 Ball... :-p

6) Will there be any limitations to using LabVIEW? Will there be any features that are easily accessibly throught LabVIEW but require complex C? What are the main advantages/disadvantages?
Supposedly we can use a laptop and communicate with the driver's station via the laptop. This will allow us to connect ANY USB joystick or device to the laptop and control the bot. This also implies (though it may later be throttled) that the laptop may serve as an offboard processor for other external scripts. So long as the interface exists and the software can communicate back to the Labview API, the limitations are only limited by your teams' minds. The LabView API can do many many things so long as you properly encode a way to receive the external data (e.g. file inputs...but don't count on real-time direct IP protocol communication...).

[random_guy7531]

Originally Posted by markulrich

As a team that hasn't developed a very strong programming base yet, we are considering switching from C/MPLAB to LabVIEW next year. I think that it would be much easier for inexperienced students.

1) What is your team planning to use?
2) What do you think will become the new standard?
3) What will most rookie teams pick next year?
4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
6) Will there be any limitations to using LabVIEW? Will there be any features that are easily accessibly throught LabVIEW but require complex C? What are the main advantages/disadvantages?

Thanks so much, any advice is greatly appreciated.

1) we will most likely (about 95-99% sure) be useing c/C++ considering that the students already know the lanuage from previous years, and the newer students have been shown to learn from them rather well (by osmosis ). As well, c/c++ gives the programmer a finer amount of control over their control system, and also provides a HUGE library of code that has already been developed (just think of all the c++ libraries in existance. Although many wont be applicable (like, say, the directX library), others could be very useful, such as a sockets library for sending datagram packets across the wifi connection to the oi to display sensor info, etc). Also, it is one of the primary languages used by the mentors for their robots.

2)Personally, although i see labview doing very well among younger or rookie teams, I thinks that c/c++ will the language of choice for the older (>2 years) teams simply on the basis that c/c++ can carry over to much more in the programming world (try programming a windows app in labview). I guess you could look at the c/c++ vs labview in the same way $@#$@#$@# the current c vs easyC decision many teams have. easyC is good for a starting team without a knowledgable programming mentor who needs to get through a season, but for total control over a program, c/c++ is preferred.

3)As I explained above, i think labview will be the choice of most rookie teams. LAbview will enable teams to get off the ground quickly, and they can switch to c/c+ when they feel that they need greater control over their control system.

4)Im really not sure on this one. I think that FIRST will likely provide a standard labview, but with first elements, like the WPI lib, installed with it. Basically, i think it will be a standard version for all intents and purposes, but optomized for first. Then again, im not really sure here, so quoting me would probably be a bad idea.

5)I think that doing so would be a great way to try out the labview side of things before getting the full system. People learn by actually coding (well, dragging in this case), not just by reading or watching a tutorial. The more hands on experience you can get, the more prepared you will be for next season. However, be cautious about what may change between the NXT and cRio. The addition of the OI will change several things, so be prepared for things to not be the exact same as they were with the NXT as they are with the Rio.

6)I dont think that the limitations on labview will be that great. That being said, C/c++'s vast number of already written libraries can give it an advantage (if they are applicable). Think about having an single board computer (like a via motherboard with a small hdd and like 128 mb of ram) running windows xp sitting on your robot which the cRio talks to using its ethernet port. The cRio would communicate all of its sensor data, which the computer would process and return all of the motor/relay commands. THis would give the advantage of allowing more complex calculations, as well as the ability to program in the language of almost anyones choice, as all the cRio would have to do would be to read sensors, send them out in a TCP or UDP packet, and then receive a TCP or UDP packet and assign motor commands. The computer would be doing all of the processing of the actual values, which could be done in c#, java, or vb.net (any language that supports sockets). While i dont know if labview can do this, I think that it would be much more difficult than in c++. One thing labview has going for it that I personally liked was its data filters. Many sensors we have tried in the past have been very noisy, and labview has its own filters incorporated with it that actually make the data readable.

pros/cons:

c++:
pro-lots of flexibility. already developed libraries. known from previous years.
Object orientation (YAY! )

cons- difficult to pick up for a first timer, requires more knowledge of coding and algorithm development

labview:
pros- visual coding allows quick pickup by less experienced students. Allows for more complex control systems by younger teams

cons-less flexible, less applicable in larger context of programming

Hope this helps!

[Greg McKaskle]

I've inserted comments with >>s.

... just think of all the c++ libraries in existance. Although many wont be applicable (like, say, the directX library), others could be very useful, such as a sockets library for sending datagram packets across the wifi connection to the oi to display sensor info, etc). Also, it is one of the primary languages used by the mentors for their robots.

>> Both C and LV have enormous libraries available, but of course these will be subset to those portable enough to run on VxWorks. It isn't windows, and it isn't linux. Also, FIRST may not allow arbitrary wifi traffic, at least not within a competition.

2)Personally, ... (try programming a windows app in labview).

>> Actually, it isn't hard. The OI shown in Atlanta was written in LV, as was the Mindstorms NXT environment. Some things are easier, some harder.

4)
>> It will be standard LV, but with a simplified palette option. Over the last few decades, LV has grown to include tons of functionality, and this is an attempt to filter it to the needs of very bright high school teams. The full set will still be installed and available when desired. Additionally, some of the toolkits for LV will be included, such as vision. Most importantly, the FRC or WPI libraries will be integrated.

5)
>> A good way, but it may be just as valuable to go through some PC examples for LV. LV is cross-platform and the code written for the PC is the quickest to develop, and can later be targeted to the cRIO, NXT, etc. The biggest limit you will find on the NXT is the limited data types and programming palette. The subset of LV that NXT supports is very basic. Cool, but basic.

6)...running windows xp sitting on your robot which the cRio talks to using its ethernet port.

>> One reason XP and an SBC weren't the primary computer is the boot time, size requirements, etc. Also, the latency of going over TCP or UDP is large compared to internal busses, so this data path would need to be used wisely. I'm also not sure if FIRST will consider the multi-computer approach legal.

... While i dont know if labview can do this, I think that it would be much more difficult than in c++.

>> The TCP and UDP stuff in LV is quite nice. The data parsing isn't as nice as in some rapid prototyping languages, but it works fine once you get used to it.

pros/cons:

>> Your list was a pretty good one in my opinion, but I'll list what I've experienced as the major differences between these languages.

C/C++ are expected to have the flexibility to write a complete OS such as unix. They plug into every nook and cranny of the HW, no matter how icky or low-level. You can cast pointers, for good and evil, and build amazingly efficient data structures and algorithms provided you can debug them. Summary: the ultimate in flexibility, but one line of code can contain so many bugs, it boggles the mind. Thus one of the more expensive and time-consuming languages to use for development.

LabVIEW is a higher level language. It puts more emphasis on the problem domain, and less on the syntax or logistics of your program. Because you don't have pointers and the like, it is simultaneously easier to get the code working, and harder to get the same control or efficiency as C. This is the same tradeoff as most other higher order rapid prototyping languages. Graphical is the first element people notice, but the data flow approach is really the more fundamental difference. It makes parallel code so easy that whole new approaches are now feasible, and a C/C++ developer scared of threads may need to reconsider their approach to fully use LV. LV is also good for unit testing and modular development.

Other distinct differences are the debugging tools. LV has some nice ones. C/C++ has some different nice ones. I use and really enjoy using both languages.

[neutrino15]

I wrote to the WPIlib team concerning the features available to both Labview and C/C++. It seems as though they are fully committed to offering an almost identical layer of abstraction in Labview/C/C++. With windriver's supposed debugger, it seems as if the only advantage of using Labview would be the Graphcial programming (which is not that much of an advantage to some people):

LabVIEW has an extensive library of code included with it. We are trying to get all the relevant stuff ported to C/C++ so it will be accessible to both languages. For example, selected parts of the Image Processing library is being ported as we speak. That will give teams access to most of the vision code in either language.

C++ will be well supported with classes for each type of device, sensor, and robot abstraction (like driving). Each of those classes will also be on the LabVIEW palette.

The C/C++ default code will be through the library. Since most of the heavy lifting is being done by hardware, the library provides a pretty thin framework. Most of the complex stuff is around driver station – field - robot communications like support competitions, i.e. autonomous/teleop, enable/disable and Driver Station. So the philosophy is that you write programs “from scratch” for the most part, except that there is a rich set of classes (and functions in C) to handle device support.

Since the source code will be available, you’re free to modify it if you feel that is required. But we’re trying to make the programming interface pretty non-intrusive. The goal is for it to never get in your way from doing what you need to.

Between the Open Sourceness, Windriver Workbench, the chance to learn C++, and the ability to continue using Subversion (our versioning system of choice), It's fair to say we will be using C++.

[adman]

The question you have to ask yourself about the entire shift to the
CRIO Chassis and the NI Software ensemble is...

Do I want to teach my students a langauge that can be used in any
industry at any level ... C, C++

or

Do I want to teach my students a lanaguage that is much easier to
learn up front, can be adapted but will rarely be ported to things
like a mass consumed low cost consumer product... LabView

As with all things in life. Probably both is the correct answer.

[Russ Beavis]

I wouldn't sell NI + LabVIEW short with respect to programming lower-end microcontrollers.

http://www.ni.com/embedded/

The tools might be a bit pricey and still somewhat immature but I can envision a time when > 90% of programmers will be using graphical tools (eg LabVIEW, Simulink, UML, etc) and < 10% of programmers will be doing low-level work in a text-based language.

Anyone still using punch cards and assembly language out there? Those were great tools for their time and are still critical in a number of applications. However, I'm sure that C/C++ is WAY more common now even though assembly language dominated the embedded world until relatively recently.

Will the graphical tools create code that is as efficient as hand-crafted assembly or C? Never. Will continued time-to-market pressure force engineers to find faster ways to develop their code? You bet.

Russ

[Tom Bottiglieri]

Originally Posted by Russ Beavis

I can envision a time when > 90% of programmers will be using graphical tools (eg LabVIEW, Simulink, UML, etc) and < 10% of programmers will be doing low-level work in a text-based language.

I absolutely agree with this statement. Most all safety critical applications already use this approach as code generation can be controlled and qualified.

In these cases the efficiency (execution time) isn't quite as good as something hand crafted and optimized, but with processing power on the cheap and labor costs rising, efficiency in development time seems much more appetizing to me.

[Dave Flowerday]

Originally Posted by Russ Beavis

The tools might be a bit pricey and still somewhat immature but I can envision a time when > 90% of programmers will be using graphical tools (eg LabVIEW, Simulink, UML, etc) and < 10% of programmers will be doing low-level work in a text-based language.

This is correct from my perspective, and also the very reason why I think it's most valuable that we're teaching C and low-level stuff to the kids interested in software on our team. When you make the bulk of the code easier to write (as graphical tools are starting to do), it becomes a commodity. For these jobs, you no longer need a software engineer to implement them - anyone with a logical mind has a decent chance at being able to do it. Of course, that means that the 10% of programmers out there who know how to get down and dirty with C and/or assembly coding and debugging become more valuable, and the value of the rest decreases. I think it's important that the kids on our team who show real interest in software be steered towards this 10%.

Learning how to "code" in high level/graphical languages is great, and is a valuable skill for now, but in short time it probably won't be much more important than saying that you know how to write a paper in Microsoft Word. The valuable people will be the ones who know how to find the problem when the high-level language blows up because of a hardware problem, or a device driver or HLL interpreter bug, or whatever. And don't be fooled into thinking that these aren't still an issue. I recently had to spend a good deal of time tracking down a bug in Java that ended up being an issue with the way the JVM handled a hardware timer on the processor, and nothing we could have done from the Java side would have found the problem or been able to fix it.

[chessking132]

This is my second year in FIRST and i have been working on the electrical system the past two years. I have finally grasped all the physical stuff that deal with electronics know i am trying to understand the software side. When i talked to the mentors on the team they gave me a copy of labview and i have just stared using it. I am finding that is essay to pick up and understand and i like looking at the pictures in labview instead of lines of code that you will see in C.

Matthew Simpson
Team 75 driver

[SL8]

I may be biased because it irritates me to have to learn what picture mean in GUI's, but I believe that the argument here goes back to the very core of why we have language. You can only explain so much in flash cards with images, even adaptable ones. We need words for more precision. However, time pressures will most likely lead to the majority using graphics.

[dcbrown]

Originally Posted by Dave Flowerday

This is correct from my perspective, and also the very reason why I think it's most valuable that we're teaching C and low-level stuff to the kids interested in software on our team. When you make the bulk of the code easier to write (as graphical tools are starting to do), it becomes a commodity. For these jobs, you no longer need a software engineer to implement them - anyone with a logical mind has a decent chance at being able to do it. Of course, that means that the 10% of programmers out there who know how to get down and dirty with C and/or assembly coding and debugging become more valuable, and the value of the rest decreases. I think it's important that the kids on our team who show real interest in software be steered towards this 10%.

Agreed (not that it matters). In my view this is the difference between an applications programmer/coder and a systems programmer/engineer.

Although I believe there will be parity between LabView and C programming environments for the FIRST added value in the new platform - specifically in terms of the standard sensor suite included in the KOP. I cannot see how real parity will exist in the 2-3 year short term between the two environments. My reasoning is based upon what the customer base for cRIO has been using - only LabView. So the body of art in terms of VI blocks, knowledge, etc. exist only in LabView within the current customer community. That plus the fact that LabView can be used to model a system and provide the simulation of most of the sensor inputs for testing/simulation makes that environment have benefits that the C environment cannot match from a whole program standpoint in the near term.

I don't even like LabView but my opinion is it would be irresponsible for me to not push LabView as the main programming environment for the robot going forward given the functionality and current art associated with the new platform. I could easily envision that 10-20% of the code would still be in done in C just because it fits better, but that the majority of the software team would be using LabView. So this would reflect the typical 80-90% applications programmers and 10-20% of systems programming mentioned by Dave above.

For me, LabView promotes being a user of black box technology pieces rather than promoting understanding how to be a creator of useful technology. There is nothing wrong with being a technology user, but where's the fun in that?

[mathking]

As a computer science teacher, I am actually strongly leaning toward "encouraging" our programmers to use Lab View, because it is better at forcing them to design good code. It is fairly easy to take a bright kid with any inclination to write workable code. It is quite another thing to design good code. Lab View's module oriented design, with testing of the modules, promotes good design and good practice. And Lab View is not a fluffy tool. It has been around for a long time and can be used for very intricate, high level programming.

I liken this to a debate that occasionally rages among HS and college computer science teachers: Should students start learning to program by learning assembly? My opinion is absolutely not! It teaches most students bad habits. The counter argument is "Would teach someone to drive a race car without teaching them how the engine actually works?" There are two counters to this argument. The first is simple. Sure you want your race car driver to understand how the engine works. But that is not the first thing you teach them. The second is that assembly is not really "how the engine (your computer) works." It is a less abstract interface than C, but still an abstraction.

I will say that I don't know if my opinion would change if my students did not already know some programming languages. On the whole, I don't think that it matters what language you learn first, as long as you learn good practices and skills. In a general sense (not computer science specific) this is actually an area of pedagogical research that is pretty well studied.