I had a chance to check out the NI LabView Robot (Fig. 1) that is part of the National Instrument's Robot Starter Kit (see Hands On A LabVIEW Robot). The robot is programmed using NI's LabView (see LabView 2010 Hits NI Week).
I don't use Labview on a regular basis but I did want to work more with NI's robot. I started by downloading some of the apps found in the NI Developer Zone and the NI LabView Robotics Code Exchange. This also meant upgrading the version of LabView since most developers are using the latest from NI.
My initial attempts to work with the Occupancy Grid VI proved ineffectual. The main reason was that the initial sample navigation system used to drive the wheels did not provide any position information. I was hoping to get simple dead reckoning information but that was not part of the initial example. Trying to add that capability stressed my limited LabView expertise so I started looking for some examples online.
The first thing to try was one of the more advanced, multirobot examples. Unfortunately, it turned out that it employed a camera from above that tracked all the robots. It was a great lab example but not one I could repeat. Another system added a USB camera and a WiFi access point. Unfortunately I didn't have the same camera so I did without. The resulting remote control navigation was fine since I kept the robot where I could see it.
I did learn a few things along the way. LabView has a number of advantages especially when it comes to experimentation and having a link between the robot and PC. I also found the approach on par with some other robotic platforms I have used that are program-centric. These all suffer from a rigid approach that makes reuse at a macro level difficult. Obviously reused of VIs is useful but replacing VIs or using collections of VIs is a bit more challenging.
I am just starting to work with ROS (Robotic Operating System). It has a package system and uses a message-based publish/subscribe system. NI's robotic framework is much different and might benefit from its architecture but melding the two is beyond my expersitse and available time right now.
Another limiting factor is the hardware I could bring to bear. I suspect that most users of this platform will have other National Instrument's hardware on hand. This is where the use of the Single Board RIO (see LabView 2010 and Single Board RIO) shines. It was not too hard to get basic digital and serial I/O working but I had done that with another SBRIO kit I have.
I was able to attach a Belkin access point so I could operate in a wireless fashion but I had to use a separate battery. The robot is on loan so I did not want to modify the power cabling. That would be the first thing I would do with this system because the default configuration requires disconnecting the cable to charge the battery. I actually consider the lack of built-in WiFi a deficiency of the system but only Ethernet is available by default on the SBRIO board.
In closing, LabView has a lot to offer when it comes to robotics but the choice of SBRIO in this case is both advantageous and limiting. There are a number of people posting software on NI's robot site but only some is running on this platform. Adapting applications from others may be easier for those more adept with LabView. I found it challenging. I am hoping to work with this platform some more but I want to check out ROS next. Unfortunately, ROS will not run on this platform so I will be working with another robot. More on that later.