Does the use of labview for the run of the mill team provide authentic recognition of the essence of computer science?
The market share of labview is abysmally low; robotic companies such as spacex and rethink robotics don’t
use labview for actual robot control, so why does frc? CS programs teach either python, C, C++, or Java. That in mind, is labview an appropriate language for FRC?
Since when has the “essence of computer science” been the syntax you use?
Yes I believe so. There are certainly better approaches if your goal is to teach computer languages. However, LabVIEW for me was easier to use as a teaching tool since it is specifically designed to “view” inputs and outputs in real time without having to build a graphical interface.
David
Yeah I dont know… I have never seen it used, all of the equipment I have seen is either written in c++ or ladder logic. The only time I saw labview was when this guy who lives like ~2 hours away from from me, was building an EDM machine. We wanted to be able to co-ordinate 3 axis with labview, with no luck. He somehow got a hold my phone number. I ultimately just steered him in the direction of a ramps board. So again, back to c++.
I did hear a rather unpopular theory… Back in the c-rio days, they were very very expensive. Compared to vex first is very hard for small teams to afford, and the c-rio didn’t help. And a rasbery Pi has comparable computing power but costs almost nothing. National instruments wins on multiple fronts. They are selling lots of their expensive products and they are training an army of people to use theirs controllers for free. They will enter the work force and already know how to use their products, as training people is normally expensive. The engineers that result from it will also only know how to use it, thus insist on using it.
It paints a sort of dark image of national instruments. But I honestly think there is some truth to it.
Sorry if that got a little off topic, but thats why I think they use labview.
I can say that I know some engineers at the Air Force Laboratory use it for sensor stuff. It’s definitely used, though more among those working more with hardware and data collection rather than those focused on software alone.
LabVIEW is typically used in industry for test equipment and work where a conventional programming language might not be worth it.
That being said, LabVIEW does have some really good tooling for autonomous programs and the actual dynamics of a robot, as well as other areas. A lot of the VIs in LabVIEW go into good depth in control systems, the transfer function and state space set of VIs spring to mind. I don’t think people give it enough recognition for the amount of work that’s been put into the LabVIEW Robotics toolkit.
The support for FPGAs is also fantastic, but unfortunately that’s mostly locked down in the FRC sense (although you can repurpose your RoboRIO, or use something like the myRIO if you’re interested).
In my personal opinion, I think LabVIEW doesn’t really flourish in competitive robotics, but in terms of working on test equipment, or for autonomous robots, or something to that degree, I find it’s support is actually quite ahead of the ball, if you can afford the premium it comes at, that is.
All being considered, I think LabVIEW has it’s welcome place in the FRC toolset, but as with anything it comes down to a matter of what you’re going to use it for. It’s pretty highly specialized in industry, and maybe that’s the path some students want to go down in the future.
That being said, I still prefer conventional embedded languages like C and C++, but a good programmer should never feel bad about stepping foot in new territory.
Citation Needed. Here’s mine: https://www.linkedin.com/jobs/view/397616509
Different industries use different software, LabView and LabView like programs are very popular in manufacturing plants for example and controlling a line.
I have used LabVIEW professionally, and I believe that for certain tasks it is the best language. That could include some robots being used in FRC.
What I find is that if your code (in First or on the job) primarily reads inputs, maybe processes them, and produces an output, LabVIEW is great. If, on the other hand, there is complex logic, a lot of if-then or switch() statements, it’s a pain in the neck.
Professionally, I found it to be incredibly simple to grab some microphone input, perform an FFT and produce the PSD function with the right filters, and produce a graph of the output, all for doing investigative work, it was fantastic. When I wanted to actually make decisions based on the output of that work, which meant turning on certain actuators, checking the status of inputs and outputs, and generally doing things that required several sentences to describe the logic, it was a pain in the neck.
For some teams, their robot logic consists of “read the joystick and turn the wheels”, and their autonomous programs (if any) are “drive forward 2 seconds and turn 90 degrees”. I can make that work in labview very easily, and without having to teach a student what a subroutine is, or why that should be a local variable instead of a global variable. (Edit) I might add that an awful lot of useful assembly line work consists of “Wait for a signal. Turn on the motor until you get another signal. Repeat several million times.” LabVIEW is pretty good for that.
That being said, my team switched to Java after my first year as a mentor, and no one has regretted it. If you have competent programmers among your team, i.e. taken at least one legitimate programming class, then I think Java is better for most teams.
From this link (Launch Electronics Automation Engineer at SpaceX)
While I have never used or learned LabView myself, LV is used in a number of data collection systems fielded by the Naval Oceanographic Office, including in the acoustics department, where I work. As I see it, the commercial use case for LV is pretty well defined by the name of its owner, National Instruments. LV is a language designed to build “virtual instruments”, and it has a significant number of real-world uses among those whose job it is to measure things. Further, in my experience, electrical engineers seem to find it intuitive.
It also appears to be easier to learn than Java or C for those who have not already been introduced to text-based languages. If you have mentors who are comfortable with LabView, then you are presumably in a location where this skill is of value, so go for it!
Isn’t the ability to adapt to any language the essence of computer science? Given a long enough tape, of course.
Since when is the point of FIRST to teach students pure CS?
Every company will work with a different coding language, environment, platform, whatever that may be. Same goes for cad/cam software, machining brands, the list goes on and on.
Just like any other coding language, Labview helps frc students understand the concepts of robot control systems, and while its UI is different from standard text-based it helps grasp those key concepts that are crucial for CS.
Very few (if any) companies will use code platforms and structure similar to frc, and any new employee will have to adapt to the environment around them. While people have their own thoughts about labview it is used successfully by many teams to accomplish their controls goals (lol rhymes).
Tl;dr: This isnt a hackathon, its a robotics competition and if teams have decided for whatever reasons that a coding language is what works best for them, then I see no problems using it.
Since the same time that good photography is all about the camera. (it’s not)
Labview is a tool, it’s a great tool for certain things. I don’t see why anyone would question it’s place in FRC.
SpaceX is a robot company? News to me.
SpaceX is a rocket company. Slight difference.
Yes, because, as I’m sure you’re aware, the launching of a rocket is done entirely through direct human input and just eyeballing it. Sure, they don’t sit around building robots of all kinds for fun, but I’d challenge you to find any appreciable number of companies that do. A rocket company just builds super specialized robots. Companies that build robots of any sort generally have some sort of target market or task that they’re meant for.
Do you really want to start a debate as to what is or isn’t a robot? 
Well, if you want to go there I’ll call out all of FRC for NOT being a robotics competition. This is actually a debate that’s been had several times, and most folks agree that these aren’t robots. (Neither are the bomb-disposal “robots” for that matter.)
They’re tele-robots–robotic devices that are primarily operated remotely by operators.
Call 'em like the manufacturer does. They’re rockets, built by a rocket company. The fact that they happen to have robotic capabilities doesn’t make them anything other than a rocket. Ditto for aerial drones–wanna call Global Hawk or the MQ-9 a robot? I’m sure Tesla would love a Model S in Autopilot being called a robot–it’s a (partially) self-driving car. And I’m sure your thermostat at home would like being called a robot–after all, it has robotic capabilities as well (it makes decisions, simple ones I dare say, but it still has to decide if it’s time to heat or cool the house).
I mean, we could get into the debate, but remember this: A manufacturer builds what they build, and markets it as what it is. As more and more items get more and more technological, calling everything “robot” will cause all kinds of confusion. So call it what the manufacturer calls it, unless it makes a LOT more sense to call it something else.
Now, I was actually responding to the original post. SpaceX and Rethink Robotics generally wouldn’t be mentioned in the same sentence as being the same sort of company. Fanuc or Genesis, on the other hand, would be. (SpaceX would be mentioned more with ULA or Orbital ATK.)
Well it’s not just syntax. Some basic programming concepts don’t get introduced with labview, while others get introduced spectacularly well. I’ll use this example from NI tutorials.
Here you can see A simple autonomous program. It will drive and turn right for a second, as well as drive and turn left for half a second.
Let’s talk about things it does well first
State Machines - I can clearly see 3 distinct states. When one finishes, it goes to the other. This is a really hard concept for some students to grasp, and I think the example makes it really clear what a state machine is, what’s it’s useful for, and how it works.
Simple - There’s nothing too complex about this code. I can understand what’s happening (for the most part. More on that in the cons). I can see a drive object, I can see the arcadeDrive method being called and what arguments are going to it, and I can see the general flow of the program.
Now the cons
Structure - The first thing I noticed was there’s no ‘line-by-line’ format like there is in text based. In the first block, I see the 50ms delay. Does this happen first? Last? When? There is no concept of order.
State Machine Transition - While Labview shows how state machines work well, the one thing they are missing is the transition phase. One thing I think is important to learn is the concept of keeping track of your states, and then checking which state you’re in, and performing an action based on that state. Labview does make states easier, and I’ll give it props for that, but just something that may be overlooked by students learning
Arguments - There’s no structure to the arguments either. Arguments in Labview are more like keyword arguments in Python. They don’t have to be in any order, since each one has a specific key to go with it. When learning text based languages, it may be hard to grasp this concept of order because previously there was only 1 spot for the argument, and it didn’t matter which one you added, as long as the wires went to the right spot. Just a thought.
Weird style - If I’m “reading” this right, the way the loops work is it’s basically
while True:
blah blah blah
if (i++ >= 10)
break
now, if I saw this in someones code, I might kill them. Anyone can tell you this is a stupid way to write code. But that’s the way labview (or at least this tutorial) does it.
Initialization - That variable i comes out of nowhere. It’s not initialized. That’s just cray cray.
That’s my rant/debate/whatever. I’m sure I missed a few things.
The 50ms delay happens “parallel” to the rest of the structure (put in quotes because there is a bit of optimization done, but for all intents and purposes it is parallel). Inside of a structure, whether it be a loop, case, event or sequential, the structure iteration will not finish until all members are complete.
What’s happening above is that the “Drive - Arcade Drive” VI exits immediately, so in order to keep a well timed loop, each iteration uses the Wait(ms) with 50ms in order to make each iteration, well, 50ms. This keeps going until the loop reaches it’s stop condition, which in this case is 20 iterations (1 second in total) for the first loop
In LabVIEW, order is given by dataflow. If two VIs don’t have a dataflow between them, there should be no reason for them to be run sequentially, so they are run in parallel. The only thing stopping the 3 loops running parallel is the pink dataflow, the reference to the motors. If you do need them to be run sequentially, you can utilize a “sequential” structure.
The example you gave isn’t a great example of a state machine in LabVIEW. A common way to do states is through a case structure with a number (or enum) input. See a quick example below, that handles state transition.
http://puu.sh/wXCAB/0a83f78c33.png
The main reason for this is that data flow is the one and only decider of code progression, and what runs when. On each VI, which you can think of as a conventional function for now, you have the block diagram and the front panel. The block diagram shows the inner workings, while the front panel is where all of your controls (inputs) and indicators (outputs) end up. You can manually edit the controls and observe the indicators in each VI when you run it, which is great, you can use the VI on its own. However, if you want to use the VI inside of another VI (like a function call), you have to “link” the terminals of your VI to its controls and indicators. In essence, the controls are your arguments and indicators your return values.
http://puu.sh/wXCob/e8d6d48f73.png
In the top corner, you can see some colors filling a square. Those are the terminals to the VI. Instead of arguments being based off of name, they’re based off of the position that you put them on the terminals of your VI (i.e. where you wire it to). This makes a whole lot more sense when you think of a VI not as a function, but as a Virtual Instrument, which is what VI actually stands for.
“I” in this case is actually a member of the while loop it sits in. LabVIEW loops will keep a running count of each iteration they do and provide the “I” for you to check. It does not require initialization, because it’s a property of the loop. The stop button is the same in that it belongs to the loop.