What is LabVIEW

[Danny Diaz]

Originally Posted by Jeff Pahl

The most important thing to understand is that LabVIEW is a programming language, just like C, or Visual Basic, or Java. The big differences are that it is a graphical language, where the programmer creates applications by connecting graphical icons, similar to creating a spreadsheet, and then by defining various properties for the icons.

Really close. Deep down, the most important thing to understand is that LabVIEW is a dataflow language; instead of focusing on the control path of the source code, like in C, VB, or Java, you focus more on the way data flows through the program. In LabVIEW, data trumps control code - nothing happens until the appropriate data is available. In C, Java, etc... multithreaded applications suffer because race conditions occur because data isn't available in time - LabVIEW is inherently multithreaded, but since data is the driving element then race conditions because of data are eliminated (with proper use).

Originally Posted by KenWittlief

Labview is normally used to automate electronic test equipment.

Yes. It is also used to test military equipment (things that go BOOM), control factory operations, develop systems to help quadriplegics walk, develop better artificial hearts, determine what makes the best fuel cell, help reduce the vibration felt within an automobile (and also to lower emissions and improve fuel utilization!), test the XBox360 controllers, and much more. LabVIEW not only satisfies the test vector of Measurement and Automation, but it also satisfies the control and design vectors as well.

Originally Posted by Andrew Schuetze

Is the DAQ and LabView going to be used more for external data collection so that one has physical data of how the robot performed so that analysis and verification of predicted robot performance under load conditions can be made?

No, the 6009 does not have the ability to store data on-board; to do so you would need something a bit beyond the capabilities of the NI USB-6009 DAQ device. In order to do everything the 6009 is capable of doing on its own you would really need something with an on-board processor. The DAQ device should be looked at very much like a steroid-infused IFI controller that instead of controlling via a program you upload to it you control it via the USB interface with a PC or LabVIEW-capable device. The DAQ device, in conjunction with LabVIEW, gives you the ability to analyze sensors, tweak PID control loops, simulate sensors, and perform advanced analysis and control tasks not currently supported by available tools (among a myriad of others). With what you learn with the DAQ device, as Don put it, you will be able to more intelligently tweak/control your robot through conventional means for competition.

Originally Posted by Don Rotolo

It gets even better, because during development you can use sensors that aren't 'legal' (or, for weight, might not be used in competition) to measure and characterize every aspect of the machine's operation, allowing optimization.

EXACTLY! For other examples, strain gauges can help prevent structural integrity or really nasty torsion problems, current sensors (and other sensors) can help determine how much power your motors are pulling so you can design a drive train or arm mechanism that won't smoke your motors and give you maximum efficiency, and you can even develop a testing environment within LabVIEW to allow you to unit test your autonomous robot software without the need for a completed physical robot!

There are a lot of uses for this that haven't even been considered yet!

-Danny

[Andrew Schuetze]

Originally Posted by texasdiaz

SNIP
The DAQ device should be looked at very much like a steroid-infused IFI controller that instead of controlling via a program you upload to it you control it via the USB interface with a PC or LabVIEW-capable device. The DAQ device, in conjunction with LabVIEW, gives you the ability to analyze sensors, tweak PID control loops, simulate sensors, and perform advanced analysis and control tasks not currently supported by available tools (among a myriad of others). With what you learn with the DAQ device, as Don put it, you will be able to more intelligently tweak/control your robot through conventional means for competition.

EXACTLY! For other examples, strain gauges can help prevent structural integrity or really nasty torsion problems, current sensors (and other sensors) can help determine how much power your motors are pulling so you can design a drive train or arm mechanism that won't smoke your motors and give you maximum efficiency, and you can even develop a testing environment within LabVIEW to allow you to unit test your autonomous robot software without the need for a completed physical robot!
-Danny

Wow lot's of good discussion here The testing and development of code has always been hindered by the progress of the robot build team. This sounds great. Can you provide a bit more insight into how the DAQ device is going to interface with the RC? Your comments almost suggest that the DAQ can be used to replace the IFI controller during development. My sense is that the DAQ is external to that but I am foggy on how one will watch the code while observing data flow. Maybe the point is that one really wants to just watch the data flow. My fingers are itching to get a hold of this device and plug it into last year's robot.

[Danny Diaz]

Originally Posted by Andrew Schuetze

Can you provide a bit more insight into how the DAQ device is going to interface with the RC? Your comments almost suggest that the DAQ can be used to replace the IFI controller during development. <snip> Maybe the point is that one really wants to just watch the data flow.

Fortunately for IFI RC lovers everywhere this DAQ device will never replace the RC - it will only be used to enhance the RC during the build/test/development season; OK, you can use it to enhance the RC everywhere except on the competition floor. This aspect of using the DAQ device with the RC is the one that is probably the one I am evangelizing the most, even though there are many many GREAT uses for it (like modeling motor/drive train performance and generating sensor models so that it's possible to build a "virtual robot" before the start of the season and know how the robot will perform, as another example).

In a sense you're right, Andrew. You really do want to watch the data flow coming from the IFI controller, but it's also nice that you can inject data with the DAQ device as well. Let's look at a couple scenarios that lead up to something I think is the best thing since the IFI breaker panel.

Scenario 1: I have written some dead-reckoning autonomous code, and I want to be able to see when the code I have written actually tells the motors to start and stop; I think I've timed the start/stop correctly (based on initial estimates of how fast the robot travels), but I am unsure. There are two ways to do this; one would be with the IFI or LabVIEW Dashboard, and the other would be to monitor the PWM signals themselves with the 6009 DAQ device - of course I want to use the DAQ device since it's the one that will allow me to cut additional wires and write some LabVIEW code (yes, for this example it's overkill but follow with me). Once you've connected the DAQ device to the PWM signal driving the motor (you don't even need the motors here, just the IFI controller) you can write a simple LabVIEW program that will display the PWM signals acquired from the DAQ device to a strip-chart. I can then start my autonomous mode on the IFI controller and see how long the signal is applied to the motors and at what "percentage", and that can help me determine if my code is timing the autonomous properly. I can then tweak my values once the robot is ready, but at least now I have code that I have verified is working properly.

Scenario 2: I've decided that I want to use sensors since all the dead-reckoning business is making my head hurt. I don't really know what kind of signals I'm going to get from a Hall-effect sensor or a gyro since I've never used them before, so before I write a bunch of code I want to find out what sensor values I'll get and log some sample readings. So, I connect the Hall-effect sensor (or the gyro or whatever your sensor of choice happens to be) to the DAQ device (as per the instructions with the sensor), write a simple LabVIEW program to gather its data to a strip-chart, and save the data to a file (so we can reference it later or share). I play with it until I am satisfied I know what the sensor data looks like under various conditions - for the gyro and other sensors, I can even prototype code in seconds to figure out the best algorithm for working with that sensor. Now I have mastered the sensor!

Scenario 3: OK, so now I have replaced the lame dead-reckoning code with some code to use a Hall-effect sensor watching a wheel sprocket but I'm unsure my code will do what I want it to do. Now I roll up my shirt sleeve and get a little down and dirty. I connect the appropriate DAQ inputs to the PWM outputs on the RC, but I also connect the appropriate DAQ outputs to the appropriate analog/digital inputs on the RC. I use LabVIEW in the same manner as I did before to gather motor/PWM data into a strip-chart, but I also tell LabVIEW to generate a signal that mimics my Hall-effect sensor (or other sensors) and to output that signal to the DAQ outputs (I also want to view this data with a strip-chart as it's being output to the RC). I add a little bit of smarts to my LabVIEW code so that it will begin outputting the generated sensor data only when the motor has been turned on, and stop outputting the signal once the motor is turned off. This way I can start up my autonomous code and watch the RC react to the sensor data from the simulated Hall-effect sensors. Does my robot stop after N number of pulses? Yes! I've just unit tested a portion of my autonomous code without having any physical robot hardware attached to the RC! Once I have my robot, the values can be tweaked for optimum performance.

This is just an extremely simple example of what you can do with the NI USB-6009 DAQ device and the IFI RC, but hopefully you are able to extrapolate this use-case to larger projects for your team.

-Danny

[EricS-Team180]

Originally Posted by texasdiaz

This way I can start up my autonomous code and watch the RC react to the sensor data from the simulated Hall-effect sensors. Does my robot stop after N number of pulses? Yes! I've just unit tested a portion of my autonomous code without having any physical robot hardware attached to the RC! Once I have my robot, the values can be tweaked for optimum performance.

Dang! We've given a lot of lip service, over the last few years, to building a "black box" that could simulate sensor inputs, but you've just given us a whole lot more!

Eric

There is a version of Labview called RoboLab written for the Lego RCX brick.
I believe this has always been included as part of the FLL distribution, and can be obtained separately from Dacta for under $50 (I think). Robolab was witten by Tufts University under a NASA Grant. I believe our own Jeff Seaton
(National MC and NASA guy) was responsible for awarding the grant. Any way you can get a good introduction to Labview for very little $$$. I don't think LabView would be suitable for FRC, heck - you guys need to learn C eventually!!!!

If you google "tufts sensors NASA" you should get to the site.

[Mr.G]

LabVIEW is a great program made by a company that stands behind their product. The hardware is also the best in the industry and relatively inexpensive, but the software is not. Both have been around a long while.

It is rumored that Microsoft purchased the Windows name from National Instruments.

I use it every day, and love it.

[Danny Diaz]

Originally Posted by Eagle Master

LabVIEW is a great program made by a company that stands behind their product. The hardware is also the best in the industry and relatively inexpensive, but the software is not.

I hope you mean that the software is not relatively inexpensive, and not not the best in the industry. Our software is definitely not inexpensive, mainly because it's done right. What's the difference between a $20 USB-to-Serial converter and National Instruments $150 USB-to-Serial converter? Ours actually works when it's supposed to. As far as drivers go, I'd say we produce the best in the business, and they're free. As far as LabVIEW, TestSTAND, MeasurementStudio, etc... products are concerned, you'd be hard pressed to find anything better for what they're designed for.

Originally Posted by Eagle Master

It is rumored that Microsoft purchased the Windows name from National Instruments.

LabVIEW was originally designed to run on the Mac because Windows didn't have the graphics engine required to use LabVIEW. If NI had anything to do with the Windows name, this is the first I'm hearing of it...

-Danny

[Danny Diaz]

Originally Posted by Dr.Bot

There is a version of Labview called RoboLab written for the Lego RCX brick.

True and False. RoboLab isn't actually a version of LabVIEW, it's an app built on top of the LabVIEW runtime engine. It uses all of the components of LabVIEW but isn't a specific "version" of LabVIEW. Originally Chris Rogers at Tufts wrote VI's to plug into LabVIEW, and we worked with him to expose the front-end hooks necessary to make it its own "application". However, with that said, each of the last 4 versions of RoboLab (at least, could be more) has used a version of LabVIEW that was specifically tweaked for RoboLab - we took a version of LabVIEW (LabVIEW 7.x for the latest version, RoboLab 2.5.4) and released a dot-release for RoboLab specifically.

Originally Posted by Dr.Bot

Any way you can get a good introduction to Labview for very little $$$. I don't think LabView would be suitable for FRC, heck - you guys need to learn C eventually!!!!

LabVIEW Student Edition costs $89, it's also a cost-effective way to learn LabVIEW. Realize that only the most advanced RoboLab programs will actually use LabVIEW as you would consider it as a real programming language, there are a lot of things you cannot do with LabVIEW when targeting an RCX. I would strongly disagree that LabVIEW wouldn't be suitable for FRC - as a matter of fact, it might be better than traditional C programming. It all depends on whether or not you're more trying to emphasize low-level or high-level programming; more and more colleges are not teaching C or C++ but more Java because they are focusing more on high-level programming. I agree you should learn what's inside the hardware "black box" and how to control it, but when it comes down to it what's important (especially for FIRST) is how to incorporate the usage of the hardware, sensors, and such in a program at a high level. Drowning in the implementation details of a list or an array is a GREAT academic effort but completely unnecessary for a 6-week competition.

-Danny

[Danny Diaz]

Originally Posted by Dr.Bot

There is a version of Labview called RoboLab written for the Lego RCX brick.

I guess I get to finally tell everyone that there are now 2 programs written for 2 different versions of the LEGO Mindstorms family, and both are written on top of LabVIEW - the new LEGO Mindstorms NXT system is more of an environment that uses LabVIEW in a MUCH different way (way better in my opinion) and it introduces graphical programming concepts better for a smoother migration into LabVIEW.

-Danny