ROS for LabVIEW Software
Overview
The Robot Operating System, or ROS, is a protocol that is widely used for programming complex robots, including Rethink Robotics’ Baxter, Willow Garage’s PR2, Clearpath Robotics’ Kingfisher, KUKA’s youBot, and many more. Designed originally at Willow Garage, ROS has five design goals: peer-to-peer, tools-based, multi-lingual, thin, and free and open-source. This means ROS does not run on a central server, thus avoiding slow and unnecessary communi- cation between multiple computers, which are typical of large service robots. Connection between computers, or peers, is communicated through XML-RPC and, because of this, supports several languages including C++, Python, Octave, and LISP.
ROS for LabVIEW Software provides a programming environment with all the benefits of ROS plus the added benefits of LabVIEW: easy to program and easy to debug while maintaining a high upper limit as to what is possible. Graphical programming languages, and specifically LabVIEW, have been shown to feel more natural to users by giving them the ability to program pictorially instead of with a text-based language, thereby decreasing the cognitive load felt by the programmer. In addition, the graphical nature of LabVIEW provides the user with visual and rapid feedback, making it easy for coding and debugging. Users program in LabVIEW by creating Virtual Instruments, or VIs, which LabVIEW is a hierarchical language, allowing users to create VIs and subVIs that can be implemented in different programs.
How it Works
ROS for LabVIEW is a client API for communication with ROS applications that is capable of handling node-to-node transport negotiation and communication using XMLRPC and TCPROS. The ROS for LabVIEW library includes a set of VIs that are capable of establishing a connection with a Master, sending messages to or receiving messages from topics or services, coding or decoding message strings into the proper format, and turning a device, such as a personal computer, into a ROS Master.
ROS for LabVIEW functions at two levels: on a technical low level for those with ROS experience and on a high level for novices and programming ease. The ability to work on these two levels allows experienced programmers flexibility without compromising novice exploration.
In order for ROS to function, a Master must first be started. Depending on the robot or hardware, the Master either starts on boot or can be initialized by running roscore in Linux or ROS MASTER MAIN.vi in LabVIEW. A master in LabVIEW can be targeted to a device, like a myRIO or simply run on the operators computer. Once the master has been started, nodes can register with the Master as publishers, subscribers, service clients, or service hosts. Initial communication negotiation with the Master is done in XMLRPC, and when connection is established between the publisher/subscriber or service host/client, transmission of data is done in TCPROS, a binary ROS protocol. Different message types have their own protocol for how data is sent in TCPROS.
In LabVIEW this process of registering, connecting, and transporting data is implemented in two parts (VI to server and VI to master) and with three different queues (the command queue, the write queue, and the read queue). An example of a LabVIEW VI, Talk.vi, publishing a std msgs/String on the topic /chatter will be used to illustrate ROS execution in LabVIEW.
Communication from the VI to the Master starts a LabVIEW server for the node, /LVROS, requesting a port for /chatter in XMLRPC. If there is no publisher on /LVROS/chatter, an asynchronously running server for this publisher is started. The publisher registers with the master at the node’s IP address and port. The master sends a message to any subscribers on the publisher’s topic alerting them of a new publisher. The subscriber contacts the publisher asking for a connection. At this point, the publisher Talk.vi and subscriber can now communicate data directly via TCPROS. Data is passed to the publisher server from ReadWriteTopicData.vi through the command queue.
Communication also happens between the VI to a LabVIEW server. When Talk.vi is started, a LabVIEW server representing the node, /LVROS, is initialized as described above. At the same time, Talk.vi calls ReadWriteTopicData.vi and adds a string to the write queue, which is then sent to the master via the publisher server created for Talk.vi.
Similar processes are followed for subscribers and service clients.
In order to ease programming and be more accessible to novices, the ROS for LabVIEW palette set contains numerous VIs to enable users. The palette is divided into two different sections: ROS VIs and Device VIs.
The ROS VIs subpalette is made up of building blocks from the ROS library, such as VIs for registering a topic with the Master (ROS Topic Init.vi) or subscribing to a topic (ROS Topic Read.vi). Also included are palettes for ROS primitives, message building and parsing, and a global ROS definition (ROSDefinition.vi). Many common messages are supported, including geometry messages, navigation messages, standard messages, sensor messages, and Baxter core messages. VIs for these messages are divided into builders and parsers for use with publishers or subscribers, respectively.
The ROS VIs subpalette also includes various tools for the ROS Master and debugging. As mentioned earlier, the VI ROS MASTER MAIN.vi allows users to use any device that supports LabVIEW as a ROS Master in addition to ROS supported devices. The Master can be run on the user’s computer or targeted to an NI device, like the myRIO, cRIO, roboRIO. After the Master is started, the user can then use ROS for LabVIEW (or ROS) to communicate with the Master via any other device that supports LabVIEW.
Error Handling
A big goal in developing ROS for LabVIEW was to provide users with an intuitive method for debugging ROS. Currently, a major drawback to ROS is the debugging process. Debugging must be done in two parts: in the programming language, e.g. Python, and in ROS. While this remains true in ROS for LabVIEW, much has been done to improve the transparency of what is being sent back in forth in ROS.
ROS for LabVIEW takes full advantage of the visual debugging LabVIEW allows for. Debugging a ROS VI is no different than debugging any other VI. Running the VI in debugging mode allows the user to see the code execute and also what is being passed back and forth. Custom error codes have been generated for ROS for LabVIEW specific errors in order to better inform users of what is happening.
To debug the ROS side of ROS for LabVIEW, a terminal was created to allow users to see whether or not they are connected to the Master, IP addresses for themselves and the Master, what nodes and topics are running, access individual nodes and topics, queue sizes, close servers, and view HTML files detailing what has been passed back and forth through ROS.
When users click to view the web pages, a window or tab opens up in the user’s default browser. From the node web page, users can see the node port number and IP address, server and client server information, and what topics have been registered or unregistered on the node as well as what has been passed to and back from the Master. Users can also view web pages for the topics to see what was passed back and forth. Information is color coded so that topics with errors show in red, topics without error appear in green, information sent to the Master is in purple. and information replied from the Master is in orange. These web pages increase the visibility of what is happening in the background, allowing users a deeper understanding of how ROS works and increasing their ability to effectively write code.
Examples
In the summer of 2015, the CEEO also employed several undergraduates (names changed) to work on various projects related to ROS for LabVIEW. The undergraduates were at least familiar with LabVIEW but only one was familiar with ROS. Alison and Matt worked on building and programming a mobile robotic arm and Madison and Kevin worked on creating an EV3 ”voodoo robot” to control Baxter. All undergraduates were involved in helping prepare a demo involving ROS for LabVIEW and Baxter for NI Week 2015.
A roboRIO was used to control the servo motors powering the wheels and arms as well as a few of sensors and a joystick was used to move the robot. These two students built the bulk of the robot in a week and spent the following three weeks programming and refining it. Both students had built robots and used LabVIEW before, but neither had used ROS. However, despite not knowing ROS, these students were able to create their own topics, publishers, subscribers, and message types for the two degree-of-freedom arm, the gripper, the wheels, and the sensors. This is significant because it shows that even those with little ROS knowledge are able to publish and subscribe to topics of their own making within a short amount of time. Part of the quick turn-around time in creating this robot is due to the fact that they didn’t have to learn an entirely knew language to use ROS but rather familiarize themselves with a new set of VIs.
Madison worked with Kevin to build and program an EV3 ”voodoo robot” to control Baxter. Madison had some experience with LabVIEW before her internship and had been working with ROS for LabVIEW all summer. Kevin was well versed in LabVIEW and familiar with ROS for LabVIEW. As a side project in the final couple days of their internship, these two students also decided to create an EV3 robot that could control Baxter. The EV3 robot had two arms with two motors each representing a shoulder and elbow joint. Using both ROS for LabVIEW and LabVIEW for LEGO MINDSTORMS, they were able to create a program in which the arms on the EV3 robot could be moved inorder to control Baxter. The program could be run in two with two different methods for position control, one fast but inaccurate and the other slow but accurate. Their work on this EV3 robot showed how rapidly a ROS for LabVIEW program could be created and additionally how easy it is to interface ROS for LabVIEW, ROS robots, and non-ROS robots by exploiting LabVIEW.