Going Virtual at RoboDev 2008

I just got back from the RoboDevelopment Conference in Santa Clara.  It is clear that the “cool factor” of Robots is definitely a winning strategy in getting our kids involved in science and engineering again – based on the number of conversations I had with teachers, administrators, and students this week.  The energy around FRC, Lego, and all the other educational programs around robotics is incredible. (If you want to get involved, see my previous post).  It’s also amazing to see the number of real business opportunities in industry and the military around robotics and autonomy as well that are helping to drive the need for these future engineers.

I have to give a shout out to Jeanne DIetsch, the CEO of Mobile Robots Inc, who gave one of the keynote presentations for the conference.  In a real display of guts and faith in her company’s technology, she shared the keynote presentation with 3-4 robots that helped her present. It went off pretty well, and her company’s basic robotics platform looks quite impressive.

The other thing that was obvious is that we need to ‘go virtual” again if we are to make a bigger splash in robotics.  I am not talking about Virtual Instruments, but this time, its all about simulation.  It seems that robots are complicated and expensive to build.  Combine that with the fact that you may not know exactly what they are going to do when you send them on their way – you really need a way to write your robotics code so that it will run in a simulator first, before the hardware is actually ready.  This would be yet another example where the software is truly the instrument.  We’ve done some pretty cool integration with Solidworks to co-simulate – definitely more of that kind of work is needed.

What does “support” mean to you?

Technical support has been a key part of our success at NI.  Sure, some of our customers who are gurus and have used our products for many years, have expressed concern about the experience level of some of our front line support engineers.  But the point is, support is important to us – ever since customers started ripping open a PC for the first time or tried to install a Windows driver, we realized we need to be on this support thing. 

However, the word “support” is one of the more overloaded terms out there.  We (NI) and our customers use that term to mean many different things.  Recently, we realized that we don’t really have a documented support policy somewhere that outlines all of these types of “support” and what you should expect.  We are working on that now, and I wanted to get some opinions from the outside world.  So far, I have compiled the following aspects of our business practices that would fall under the term “support”.  Weigh in if I have missed something:

For a given version of LabVIEW (a version is the development environment and all associated modules and toolkits for that particular version release):

• Providing maintenance releases
• Providing patches for specific customer issues on an as-needed basis
• Testing and validating new hardware that comes out after LabVIEW
• Having technical support engineers who answer questions over the phone or through email
• Developing and maintaining technical content specific to this version on ni.com

This list outlines what we do.  What is not clear is FOR HOW LONG?  So the real question we are attempting to answer is to set some guidelines for timeframes for each of these items.  For example, how far into the future should we test new hardware drivers with LabVIEW 8.6?  Is it reasonable for you, as a LabVIEW user, to expect that any new hardware that comes out next year should work with LabVIEW 8.6?  Of course.  What about 3 years from now?  How about 4?  Same thing for maintenance releases – is it reasonable for us to ship a LV 8.6.2 three years from now?  Probably not.  However, we might create a patch for a specific customer who has hit a critical problem with no workaround.

Am I missing anything from this list?

Do you have any comments on timeframes for each of these?

I will be posting our proposal soon, but I thought I would throw this out there now to see if anyone has something else to add.  (Of course, there are related issues to this – like what is the process for upgrading to new versions, and how long will we support specific operating systems – but that’s a different post)

Time to Get Serious (with LabVIEW Software Engineering)

I just finished attending a great NIDays event in the UK – major props to our UK branch for putting on such a professional event.  The day before, we hosted a small group of customers to discuss large-scale test development challenges and issues as part of our Automated Test Customer Advisory Board.  It was also filled with excellent dialog. 

One topic in particular that has come up (again and again and again) has been how to apply software engineering techniques with LabVIEW, in various forms and flavors:

• Large application development with LabVIEW
• Developing in teams with LabVIEW
• Developing in regulated industries (medical, aerospace, etc)
• Using LabVIEW like I used to use C

This is one area where I feel like we have made a lot of progress over the past few years, and I am starting to get frustrated with our inability to educate our users about these tools and techniques – so I am dedicating this blog post to it.  For those of you who have not yet upgraded to LabVIEW 8.0 and its follow-on flavors (8.20, 8.5, and 8.6), we’ve added a number of capabilities:

• Connectivity to Requirements Management tools
• The introduction of a Project workspace in the LabVIEW environment
• LabVIEW libraries
• Better integration with source code control environments
• Graphical DIFF and MERGE capabilities in LabVIEW
• Automated code analyzers
• Lots of techniques and user comments about FDA approval, code validation, testing and deployment, and so on.

The best place to start if you are interested in this is our Large Application Development Portal (or www.ni.com/labview/power) for power programmers.  Take a look and give me some feedback on what we’re missing.  Or you can contact the human lightning rod for this particular topic – Elijah Kerry, one of our LabVIEW Product Managers (elijah.kerry@ni.com).  He has been doing a lot of traveling to NITS events and getting in front of a lot of customers about this topic, and getting rave reviews all around.

This topic falls under the category of “Very important to our users, but not always a source of excitement at NI”.  The notion of disciplined software engineering practices and how you might apply them to LabVIEW programming is something that I hear about all the time – but sometimes I have to admit, this isn’t the kind of topic that people get excited about all the time here.  It tends to be far away from the innovation and technology topics that do excite us.  I am working to change that – or at least fill the gap with the right guideance and support from R&D – so we can better serve you.  Other topics in this category include deployment issues, upgrading, and installers (see the new LabVIEW 8.6 DVD for some improvements there).  I’ll keep the fires burning on these topics – I am sure there are multiple blog posts coming about them.  For now, check out www.ni.com/labview/power and see how it looks.

LabVIEW Can Save Engineering, and the Children (with your help)

By now, you’ve probably read or heard about the crisis of science and engineering education in the United States – our kids are too busy playing video games and surfing the web to get interested in science and engineering in school.   Although it’s refreshing to hear the candidates in the current Presidential election talk about the importance of science and engineering to be a key economic driver to solve the big challenges of the 21^st century – alternative energy sources, healthcare, and infrastructure – these all feel like huge issues that will play out for decades.

Here is something that you can do yourself, right in your own community.  The FIRST robotics organization’s decision to use CompactRIO and LabVIEW as a robotics platform has been well-chronicled.   However, now the teams are getting close to receiving their kit of equipment, and they might be able to benefit from someone who knows LabVIEW already being there as a mentor to get them up and going.  It’s a really cool way to try to get kids turned on to engineering.  You can share your LabVIEW expertise with these teams online, help out with a weekend training session, or help mentor a team – visit www.ni.com/first to learn more.

Both Lego and NI can play an important role in that effort, because kids need to see, touch, and feel the concepts of science and engineering in action to get them tap into their curiosity and get them truly excited.  I remember the first time the light went on for me – unfortunately it was long after the four years of drudgery and theory I slogged through to get my BSEE degree.  On my first week on the job at NI, I very clearly remember hooking up a thermocouple to a DAQ board and writing a program to measure temperature.  It was really cool plotting the data and calculating a bunch of statistics and being able to see the values move as we played around with the sensors.  And then acquiring some higher-speed signals and putting the nyquist theorem and our signal processing classes to work really started to make things click.  Simple, I know – but the point where the physical world of sensors and actuators intersect with the virtual world of computers is when science and engineering come alive. 

My 4^th grade daughter just finished her Robolab session in school – and now we are going to start building robots with Lego Mindstorms and LabVIEW together at home.  She seems genuinely excited to keep playing around with it – lucky for her, she “got it” a lot earlier than I did. 

Visit our website to learn how you might be able to help out a FIRST Robotics team near you this year.