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.
What is your team planning to use?
What do you think will become the new standard?
What will most rookie teams pick next year?
Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year’s kickoff?
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.
generally lab view isn’t bad, there really isn’t any thing wrong with it, it makes programming sensors easier. But it feels like i’m programming in photoshop. And when you can type 100 wpm (words per minute), the click and drag feels slow.
1). well we used WPILib this year so there woulnt be a problem with use codeing in C/C++ next year. with that said we are already looking in to how to use labview because we think that we will be able to do alot more with labview than with C/C++ ( well in 6 weeks that is)
2). I think labview will become the new standard
3). rookies will pick what every has the better how too videos, or the best “getting started with _____” documentation. on that I see them using labview
4). no idea on what first will use . . but for specializations sake it will be standard labview with some custom first functions.
5). I think programing any thing for real is better than programing for “fake”. so if you’ve got some NXTs go a head and use labe view to try some things out.
6). I think the only limitations to labview till be the learning curve, and with the exception of maybe some very easy “push button - raise arm” code every thing will be “more difficult” with C/C++
1) What is your team planning to use?
Not sure at this point. I know LabVIEW pretty well, and C very well, but I’m graduating after next year and I don’t really want the C knowledge to die off.
*2) What do you think will become the new standard? *
LabVIEW. It’s a very robust system and it’ll be picked up.
3) What will most rookie teams pick next year?
LabVIEW. There will be a lot of documentation (more than previous) on how to use it. Plug fancy videos and everything. It’s also easier to look at and trace. These things will prevail when it comes to a rookie team choosing.
4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
They already give teams LabVIEW, I’m going to guess it’ll be some addon for it so we can use FIRST functions in it. At least I hope. I don’t want a dumbed down version of LabVIEW =(
5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year’s kickoff? YES. What kind of a question is that? =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?
Can’t say. LabVIEW can seriously do pretty much anything C can. I’ve made really complicated things in LabVIEW because I couldn’t think of an easy way to do it (and it’d have been easy in C), only to find later an easier way, or the function already existed. (I made a function to convert a unsigned to a signed… I still don’t know if such a function exists. When you use LabVIEW functions it truncates the number instead of making it negative, I think).
I will be using C. I will also modify whichever WPILIB’s we use to work the way WE program.
Generally speaking, if you know how to program, any time you add an additional layer of abstraction between you and your robot it is a bad thing. It creates issues (look up the disable to auton switchover that created issues because it went through teleop using an additional layer of abstraction).
In addition, Labview is not a common environment. I understand that it’s used - but C is MUCH more widely used and will serve the students better in the future. I’d rather they have a good grasp of programming so they can actually fix problems they run into later rather than having someone else write them a new labview library that functions.
Both have their uses. As far as I’m concerned, Labview is very nice for data acquisition - because as someone said you can grab your sensor module library and plug it in and read your thermocouple temperature, etc. That’s not something that’s as easy in C. However, it is not for programming complex robotics, no matter how much playing you do with it. Even in industrial applications (we have a large number of test stations in our plant) they use C and underlying ladder logic and rely on Labview for data acquistion. Not control.
What is your team planning to use? I am planning on coding in C++, as it is what I’m most comfortable in. However, our coach may “strongly suggest” us to use LabVIEW… which would be unfortunate… When I’m faced with graphical programming, I just can’t do it. It’s not how I work.
What do you think will become the new standard?
I think, with nothing to base this off, most teams will stick with programming in C/C++, since most already have an established programming team which knows how to do everything in C, and so, there would be little to no advantage of using LabVIEW.
What will most rookie teams pick next year?
I think most will use LabVIEW because, as mentioned before, they have great support and many videos to help out. However, this year, many rookie teams, like mine, chose C over EasyC.
Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
I thought I read somewhere that they ARE doing this, but it was about midnight when I was reading the thread…
We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year’s kickoff?
Yes.
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?
One /dis/advantage: no commenting out a huge block of code that doesn’t work and consequently confuse everyone reading it. See? I need comments! FIRST / National Instruments stated that there will be parity between the libraries for C and those for LabVIEW, so I think that with an equal understanding of LabVIEW and C, there will be no difference in difficulty.
Our team is going to be using C++. The code team is already fluent in C, and we’re going to be able to do some amazing stuff with Object-Oriented Programming.
I have no clue what will be the standard. It will be interesting to see which way teams swing.
I think rookie teams will be using LabView more.
I think some sort of customized interface would be released. This will make things interesting.
Familiarizing yourself with a language or IDE is always good, regardless of the project. That way when you actually start programming the robot, you know what to do and how to approach it.
I personally will always prefer C++ over LabVIEW. While I admit I have no experience with LabVIEW, I like to deal with hard code so I can program line by line, command by command.
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?
What is your team planning to use?
I’ll let the new programmers pick that. We are starting fresh next year, Our programming “staff” graduates this year.
For my money? I think LabView is amazing
What do you think will become the new standard?
I hope it is LabView, but C and C++ has a installed base
What will most rookie teams pick next year?
Great question, not sure. Someone stated it will be whoever has the best “How to…”
I tend to agree
Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
I hope it is a full on dev pakage with specialized libraries. That way I will have all of the tools I am used to
We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year’s kickoff?
Yes and No.
Yes because you will learn the drag and drop method.
No because a Full Dev Package of LabView is SO much cooler, with more capability
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?
Some one once told me that “LabView allows scientists to act like programmers. It makes the easy things hard but it makes the hard things easy”
I have programmed in LabView and in C (and Pascal and Fortran and…ok enough) and I prefer LabView. I don’t even see the difference anymore between C and LV. But I can get up and running fast with LV
I am excited about this. I have always wondered if LabView is a good way to train a programmer.
We will continue to use C, or C++ if OO is really useful for this (think driver control and complex modular end effector systems)
C is the industry standard, and frankly, I think that C will continue, at least with veteran teams, just because things like dealing with packet data and interfacing new systems are easier to handle with a text-based language. All experimentation, and complex robot code will probably be done in C. Debugging, though, is where Labview will begin to dominate, since building GUIs is so much easier, and teams can make really nice dashboards.
Rookie teams will probably use Labview, just because it doesn’t look as intimidating as a C environment with all the functions and brackets, and everything. Things like functions, arguments, parameters, and variable types are all nicely obscured.
Was a new version of LabVIEW created specifically for this competition?
A: NI is creating a custom build of LabVIEW made specifically to meet the needs of the FRC
competition. The graphical programming environment, though, is the same one used by hundreds
of thousands of students and engineers worldwide.
That’s from the FAQs on the WPI FRC Resources site.
YES, NXT would be a great way to prep for LabView (it familiarizes you with wires and stuff like that.) Data flow programming is a slightly different paradigm, and NXT would be good practice.
GUIs are very easy with Labview. I’ve tried Python, C, Java, and VB, and for GUIs related to I/O processing, nothing is easier than LabView. On the other hand, we did have problems with VIs crashing, i.e., CMU2Cam, but hopefully this has been fixed. It just works, and there is amazing documentation if you need it. On the other hand, it will be harder to do a lot of the low-level stuff hard-core embedded systems programmers love to do. Interfacing a custom router, or a PS3 would be a lot harder to code. The capabilities of the C libraries will be easier to modify, and existing C code can be easily ported over, so a lot more code exists. And innovative systems, like the Autoflex 2.0 might take more effort to code.
Personally, I’m planning on having the new programmers on our team write the debuggers and dashboards with LabView, so they learn programming concepts at least, and don’t get overwhelmed by the power and complexity of C. But slowly, we will move them from debuggers and dashboards to real robot code, which we will continue to write in C.
I prefer C++ myself, but I’m going to have to learn labview either way because I’ll pretty much be the only programmer on my team next year ( subteam leader graduating…) I’d like to give the choice to new programmers about which one they want to use, and I’ll be learning both to help them with whichever one they choose. Also, the simplicity of probing and analyzing video data is very tempting… The best option for me at least, is to hope that NI finalizes their compatibility stuff, so that we get to use vis with dlls interchangeably and vice versa instead of choosing one and sticking with it…
ComradeNikolai made a comment about commenting above, and I thought I should comment on it.
Comments should be used for . . . comments. Aside from debugging during development, commented-out code is likely a bad thing. If you find yourself looking at code with large sections commented out, it may be time to consider cleaning up unused, broken, or out-dated code.
One of the structures in LabVIEW is a “diagram disable block” which acts like commenting out code in a text-based language. You can still see the underlying code, but a transparent block is above it and the code will not run.
I think what some people are going to label LabVIEW as is the rookie standard… which really isn’t true at all. LV is powerful; extremely powerful. The ‘flowgraph’ portion of LV is very high level, yet based on modifiable low-level code. Anyone who makes their robot in C will quickly realize how un-needed it is at the level the FRC competition is going to. you only have 6 weeks to program, and lets say the challenge is to autonomously pick out 15 red colored balls from a pile of 150 multicolored balls. Anyone using C programming from scratch will be in the pit because no easy-to-use library really exists for the task at hand. in LV, however, the vision and manipulation libraries are extensive, and the ability to add new libraries further adds to the power.
true, labview’s libraries probably could be ported to work with a standard C compiler, and probably already have.
but isn’t it easier to maintain the code when you can see it all at once, while it is natively written in a followable flowchart form?
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.
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.
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.
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.
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.
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.
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.
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).
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
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…).
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 :P). 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! :P)
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
subteam leader graduating…) I’d like to give the choice to new programmers about which one they want to use, and I’ll be learning both to help them with whichever one they choose. Also, the simplicity of probing and analyzing video data is very tempting… The best option for me at least, is to hope that NI finalizes their compatibility stuff, so that we get to use vis with dlls interchangeably and vice versa instead of choosing one and sticking with it…