I’m interested in programming our robot in C++ this year, but neither I nor anyone on the team has any experience with it. What are the best resources I could use to learn C++ coming from a background in LabVIEW?
(I know bits and pieces of ActionScript 2.0 and HTML as well, but not much.)
Your question implies that having a background in LabVIEW makes a difference. It doesn’t. Graphical vs. text, procedural vs. dataflow, inherently single-threaded vs. inherently parallel…you will basically have to forget everything about LabVIEW anyway, so don’t worry about how C++ relates to it.
Go to the recent “C++ Noob” thread for advice on learning C++. But if you know LabVIEW and nobody on the team knows C++, why switch?
If the C++ is robot related, then hopefully the common terminology, common parameterization, and common structure of the libraries will help a bit. There was an intentional decision to offer much of WPILib in source, and to show alternate language implementations to assist in cross-language communications and to hopefully assist in learning a subsequent language using WPILib and robotics as a common element.
I’d suggest opening examples that perform similar tasks and looking for similarities. Use reference books and/or tutorials to learn the stuff you don’t know. As you make it through those examples, work your way to the starter code, vision code, etc. As Alan stated, these are very different languages, so don’t expect it to be easy, but if you can learn both, you have your head wrapped around far more than the typical SW student.
Cause C++ is used more often than LabView in the “real world”. Do not argue, it is true, no one uses LabView to make video games, video games are a huge business, so I can infer that.
I digress, start small, literaly “hello world” then a small input out put program, then try making functions, then transition into classes and inheritence and polymorphism. Then you can try friend classes, structs and other stuff. Pointers too, those are important. I suggest not to focus on robotics programming, because chances are you rarely make a lot of classes and only will use the ones already in the library. One thing to keep in mind, it takes small steps, I learned the hard way and tried using classes before I learned some of the more basic stuff and gotten messed up.
I myself didn’t know a line of code when I started and I can tell you from experience that FIRST makes it very easy to learn C++ in a painless way! Here are a few helpful links that can get you started!
The link above will take you to the FIRST guide to C++. It is very useful and gives you the idea of what you can do to pretty much make anything work! This guide covers drive functions, basics of working the camera, and lots of other goodiness!
This link will give you the library of the functions you will need to use. So, the first link tells you how and this link elaborates!
If you are interested in learning C++ outside of the FIRST applications, take a look at the link above. It explains the ins and outs of the language and is very popular among beginners ( at least I like it).
If you have any questions, feel free to pm me! GOOD LUCK!
Ps. Take a look at the Windriver software! It has sample codes that you can use as a base for your robot code. Check out the “Simple Template”!
Sure you can argue with that. More people program things that aren’t video games than things that are video games. Controls engineering and similar fields use Labview all the time.
(I do have to question how you fell you can speak with authority on the manner having never worked a job using CS, ever…)
I feel it’s worth noting that my school issue laptop came with Labview pre-installed, but not a C++ IDE.
Oh woww you guys (davidthefat and Chris is me) XD I think they will soon come out with a book “Labviewers are from Mars, C++'ers are from Venus” based on the passionate programmers of FIRST :ahh:
LOL True that, I have not worked a day as a CS. Yea I am aware that control engineering use it all the time, thats why I brought up gaming industry, so my argument is still valid
So, by selecting some arbitrary subset of the real world based on your perceptions rather than facts you are making “valid arguments”.
I also assume you neglected to remember that one of the largest growing sectors in gaming is the online market (Farmville…) as well as the rapidly growing mobile market (iPhone). Additionally, most of the Microsoft provided tools for creating games use C# and the Dot Net framework.
Additionally, the engines for most games might be written in C++ but they more then often involve at least a portion written in python or lua as a scripting language.
So, yes, I am going to argue.
As for learning C++. If you know LabView and have no compelling reason for switching I would suggest staying with LabView and slowly learn C++ by taking your old robot and reprogramming it in C++ in the offseason.
First, I agree with Andrew. Basing such a statistic off of simply the video game industry is simply foolish.
Second, you’re actually fairly correct, though your justification is wrong. LabVIEW is more often used in specialized areas where you don’t need as much power (ie. data structures and some other widely used programming features), whereas C++, or more correctly, C-based languages (including C# and Java), is used more often in the business world.
Though that’s not to say that non-C-based languages aren’t used. If you work mainly with AI, you’re probably more likely to use a functional language; though once again, it is not the only choice.
And even then, if you work more with the web, you could be using PHP, ASP (possibly with .NET), or even Python.
I guess the point I’m trying to get across is that there is no specific “real world” programming language. It depends on what area of the software world that you work in. Each language has different strengths, as well as its own weaknesses; therefore, bickering about languages shouldn’t even come into the equation.
However, I must applaud dotbran and his team for entering into the often more difficult world of C++, because it is definitely one of the more oft-used languages than LabVIEW.
While slightly unrelated since it was Java, I’d like to mention that I had to program our robot as a mentor due to lack of interest from students (which I’m hopefully fixing this season). I didn’t find this out until Kick-Off. So I got started by reading Java By week 3, I believe, we had a robot that ran using the joysticks, and at shipping, we had a gamepad setup to run through a simple loop for our pneumatic kicker. Sure, we needed professional eyes to fix a small issue with the loop, but the majority of the code worked.
Did we have autonomous? Nope, not really, though I did try. Was the code efficient or purdy to look at? Definitely not, but it worked. Was it elaborate, try to cook you breakfast, could it run Crysis? Not really.
I forgot what my original point was when I started typing up this post. >_<
Glad to find this thread. Our team has a little panic attack going on: our lead programmer graduated last year, and this year’s programmer may or may not be on the team after all. There’s really no-one else who knows how to program, with the exception of our mentor who says ‘You really don’t want me to program’, and me, who loves to tool around with programming but really knows nothing…
We have a load of new [not all freshmen] students this year, and several of them have expressed interest in learning to program [C++ probably]. We’re making plans for a winter-break intensive study-programming course, but need to find a teacher/really good tutorial…
And then, now that our lead programmer may not be on the team, we obviously need one person who really knows what they’re doing. It’s looking like I may be stepping up to the plate on that [our school is sadly lacking in programmers].
So! I’ve done a bit with C++, trying to teach myself on my own, but I haven’t usually gotten very far due to lack of time. And I know almost nothing about programming for an FRC robot: just the sample programs in C++ books. Is it possible to learn C++ well enough over the few weeks of winter break [plus build season] to be able to do reasonably well?
I know all y’all lifelong programmers are going to say it takes years to get really good at a text-based language…
Another thing that came up was LabVIEW. Apparently it’s a lot easier to learn that quickly, than C++ or Java. * I would personally rather learn C++ for several reasons, but I also really want to make sure we have people besides me [a senior] who know how to program for next year, and perhaps LabVIEW would be a better option for them?
On the other hand, there are a lot of other local FRC teams and they all program in C++ or Java, so finding help would be easier with either of those.
Just to add another data point to your consideration. If you ever want to use source control to manage your code, LabView, being a graphical programming language and saved as a binary file, is very difficult to work with using source control because you cannot do a “diff” between two versions of the code as easy as the text-based language. Although I heard somebody said there may be a graphical diff tool from NI, I did not find any hint of that anywhere. But of course, I didn’t look very hard since we do not use LabView.
NXT G is a close variant of LabVIEW. The rbt file is a VI with a custom extension. If you know NXT G and want to try LV, there are lots of new editor elements, but the language is closely related, just skinned for a younger audience.
As for source code control. Professional shops use it with LV, and the tool to diff text will of course not work well on LV VIs or on Photoshop files, pngs, or any other binary files. For that, you need a diff utility with knowledge of the content storage. The tool is in the Source Code Control menu item along with configuration for when to invoke SCC actions.
My input for learning any language is to take a guess at what work a well for you, and get started. If you get stuck, switch to one of the other methods. The methods most often used are …
Read a book on the topic.
Take a class on the topic.
Open sample programs, or examples that perform something you are familiar with, and read them looking for the things you understand and the things you do not. Ask or investigate the things you do not. Then move on to other samples.
At some point you need to start writing or modifying code to see what happens.
Lessee… Though I don’t have a whole lot of practical experience regarding this, I’ll put in my 2 cents.
I’ve been using LV a lot more recently, and it is my opinion that it is very good for rapid development of tools for data display, but not as good for actual program logic. Though that’s not to say that you can’t have a good bit of program logic in a labview program, it is definitely not one of its stronger points.
For C++, there are some more factors. Do you simply want to be able to put together a program that works, or do you want more reusable code that can easily be adapted to different situations that can come up? For the first option, you don’t necessarily need a lot of skill, but if you want the second option (without horribly messing things up), you probably want more than just a few months’ experience. I have been working on personal projects using C++ for about 2 years now, and I’m only just starting to really get the hang of what’s required for the 2nd choice.
So, in conclusion, if you want an easy-to-learn way to program, that you can put together fairly quickly, go with LV. If you want a flexible, robust way to program - which is used in many practical areas - C++ is, for the most part, the better choice.
I think anyone reading the rest of your post should keep in mind that first bit of context.
LabVIEW is tremendously capable of what you call “program logic”. It’s not even hard to do it. It’s simply a different kind of programming from what things like C and Java are designed for. If you’re used to procedural programming, LabVIEW will seem difficult until you recognize the “right” way to do things in a dataflow programming language, and then it will become easy.
By the way, LabVIEW too is “a flexible, robust way to program - which is used in many practical areas”. Those practical areas just tend not to be the kind of programming one encounters in high school, with NXT G and LabVIEW for FRC beginning to change that.
OK, you have a good point. However, when designing robot logic, a more procedural method makes more sense in most cases than a dataflow approach, but insofar as I have seen, LV is simply not as capable with procedural approaches.
Procedural programming obviously makes more sense to you. It does make a lot of sense to anyone who learned to program using a procedural language like C or Java or even BASIC. But dataflow programming makes at least as much sense to people who know it. I’d even say that a dataflow approach makes more sense than a more procedural method to people with a background in PLC programming or in circuit design.
but insofar as I have seen, LV is simply not as capable with procedural approaches.
You merely haven’t seen far enough yet. Give it time.
LabVIEW provides two trivially easy ways to do strict procedural programming (error chaining and Sequence Structure frames), with Case and loop structures able to act just like their procedural counterparts. A moderately experienced programmer can implement a procedural algorithm directly in LabVIEW.
It takes a bit more experience to get to the point of being able to build simple frameworks to combine the best qualities of both the dataflow and the procedure-oriented viewpoints. I think a year of FRC robot programming might be just about enough time to get that experience.