Towards Interactive, Incremental Programming of ROS Nodes*  Work in progress  Sorin Adam 1   and Ulrik Pagh Schultz 2  Abstract — Writing software for controlling robots is a com- plex task, usually demanding command of many programming languages and requiring significant experimentation. We believe that a bottom-up development process that complements tradi- tional component- and MDSD-based approaches can facilitate experimentation.   We   propose   the   use   of   an   internal   DSL providing both a tool to interactively create ROS nodes and a behaviour-replacement mechanism to interactively reshape existing ROS nodes by wrapping the external interfaces (the publish/subscribe   topics),   dynamically   controlled   using   the Python command line interface.  I. INTRODUCTION Writing   software   for   controlling   robots   is   a   complex task, usually demanding a good command of one or more programming languages. As robotics is a multidisciplinary field, it is equally important to make accessible the software development for a larger number of roboticists with other expertise then software, as it is to increase the productivity of the software experts. Middleware such as ROS (Robot Operating System) [1] or Orocos [2] are often used to simplify the development tasks, while model-driven software development (MDSD) or domain specific languages (DSLs) are used to increase the productivity [3], [4], [5]. Robotics software requires often significant experimenta- tion, especially in the initial phase of development when debugging of algorithms and tuning of parameters prevail. Even if an overall   software   architecture   described by a metamodel exists, adapting and customizing it for a given robot requires plasticity of the model and tools to reshape it. We believe that a bottom-up development process com- plementing MDSD while facilitating the initial iterations, is more appealing to the experimenter. As is the case with MDSD in general, we shorten the iteration time by using a DSL to generate the boilerplate code, thus providing ways for easy code modification. This enables the roboticist to focus on development by leaving the compliance with the restrictions of the programming environment to the tools. In essence, we propose a DSL supporting a bottom-up, experimental tinkering approach to development. We propose the use of   component wrapping   model to combine the advantages of MDSD with an experimenter- friendly bottom-up approach of constructing the node model. Concretely, we propose to   create   ROS nodes using a more dynamic programming model and change the behaviour of  *This work was supported by the SAFE project  1 Sorin   Adam   is   with   Conpleks   ApS,   Struer,   Denmark  sorin.adam@conpleks.dk  2 Ulrik Pagh Schultz is with University of Southern Denmark, Odense, Denmark   ups@mmmi.sdu.dk  existing ROS nodes by   wrapping   the external interfaces (the publish/subscribe topics) while reshaping them   interactively  using the Python command line interface. This way, existing functionality in a ROS node can be incrementally modified and experimented with, in effect allowing a kind of   wrap- pingnode   to be defined based on the functionality found in a   basenode . We achieve that using a Python-based internal DSL language. The   rest   of   this   paper   is   organised   as   follows:   Sec- tion II discusses practical problems associated with robotics software development and possible solutions, after which Section III presents our main contribution, last Section IV discusses the limitations of our approach as well as the possible extensions of its usage. II. PROBLEM ANALYSIS We now present two concrete cases that motivate the work presented in this paper, followed by reflections on possible solutions.  A. Case 1: Developing ROS nodes for FroboMind  A ROS-based program is composed of nodes communi- cating through topics via a publish/subscribe mechanism 1 . Experimenting requires often a small modification of an existing node. For example, if a new way of handling a message published on a topic is needed, several solutions are possible. If the source code is available, the options to alter the node functionality range from in-place modification of the original code or cloning and changing the code, to usage of extension mechanisms of the node implementation language (e.g., a new C++ subclass if the original node structure permits). When the node source code is unavailable, the alternatives are often limited to re-write the complete node or interpose a new node on the message path and implementing the changes there. The last option is applicable even when the source code is available. From our experience with ROS-based FroboMind framework   [6], whenever the source code is available, the experimental tinkerer will of- ten be tempted to use the clone-and-modify method. This approach introduces code redundancy and complicates the propagation of the original source code updates.  B. Case 2: Experiments in safety restrictions  Enhancing the robot safety using software is a high interest research area for us. In a previous work, we have developed  1 For the moment our work only addresses interaction through publish- subscribe, we plan to extend our approach to also include service calls, but this is left as future work.  arXiv:1412.4714v1 [cs.RO] 15 Dec 2014
a safety-related DLS enforcing a set of safety rules to an existing robot [7]. Our experiments with the safety-related DSL required generation of robot misbehaviour in two dif- ferent scenarios: when using a real robot ( Frobit   [8]) and when experimenting with the simulated iClebo   Kobuki   robot from the ROS distribution. While for the real robot, the fault simulation have been achieved by hardware means, for the simulated Kobuki a ROS node developed in Python has been created. Experimentation often triggered source code changes followed by restarts of the node. An environment where the node could be dynamically modified had the potential to accelerate the experiments. In general, writing software in Python is convenient for small scale development, as it is possible to experiment quickly using the command line interface. With the proper integration, the interactivity promoted by the Python develop- ment environment could further enhance the runtime system interaction of the ROS command line tools.  C. Reflections on components wrapping and object-oriented inheritance  Our ROS experience indicates a need to incrementally and interactively modify or extend the behaviour of exist- ing components by e.g., changing their response to mes- sages, modifying messages, or communicating on new top- ics. Component-oriented programming suggests the use of wrappers [9] or adapters [10] to address these needs. Such approaches are similar to a delegation-based model to in- heritance [11], where an aggregate object receives method calls   and   can   delegate   them   to   a   parent   object.   Unlike inheritance, wrapping implies a significant runtime overhead. The components maintain separate identities, and moreover employ a black-box approach to composition where internal state is not visible, making fine-grained reuse difficult. Mod- ular modification and extension of component behaviours through message interception has nevertheless been demon- strated as a useful programming model using composition filters [12]. We observe that among these component adap- tation techniques only inheritance is widely known and used by programmers, which suggests that presenting component adaptation using an wrapping model will facilitate practical use. Making the adaptation technique dynamic will enable in- teractive experimentation, well-known from object-oriented languages such as, e.g., Self and Smalltalk [11], [13]. III. INCREMENTAL AND INTERACTIVE ROS PROGRAMMING Our work proposes an incremental approach for altering ROS node functionality by using Python’s command line interface as an interactive programming environment. This gives the experimenter a set of tools to work with a running system, especially useful during e.g., the initial phase of algo- rithm development and tuning, or hardware experimentation. As   a   first   step,   we   have   developed   an   internal   DSL implemented   as   a   Python   module.   We   use   the   DSL   to enhance or modify already existing ROS nodes by using component wrapping mechanisms. In the end, the developed  Fig. 1.   ROS node wrapping  node encapsulates both the needed functionality and the node model, paving the way to higher level of MDSD usage in the robotics field by constructing the node model in a bottom- up, interactive approach, matching the way many roboticists develop robots.  A. Concept  Our proposal for changing the functionality of an existing ROS node, applicable whether the source code is available or   not,   is   to   wrap   the   communication   interfaces   of   an existing node, henceforth referred to as the   basenode   , via an interception layer referred to as the   wrappingnode , allowing functionality   to   be   modified   or   replaced.   This   approach is illustrated in Fig. 1 where the   basenode   subscrib- ing to the topics   BT1, BT2, BT3, BT8   and publishing to the topics   BT4, BT5, BT6, BT7 , has the commu- nication interfaces consisting of the topics   BT1,   BT2, BT5, BT6 , wrapped through the   wrappingnode . The  wrappingnode   not only wraps several communication interfaces of the   basenode   via the   WT1, WT2,   WT3, WT9, WT10   topics,   but   also   adds   new   communication interfaces   (   WT4, WT5, WT6, WT7   )and   replaces   one of   the   topics   of   the   basenode   ( BT4 )   with   WT8 .   The blocks   Action1, Action2   and   Action6   implement the functionality changes for the   basenode   topics   BT1, BT4   and   BT6 ,   while   the   blocks   Action3,   Action4  and   Action5   handle the new communication interfaces of the   wrappingnode . Note that wrapping unlike standard object-oriented inheritance, does not address the issue of the identity of the component (the   wrappingnode   does not completely hide the   basenode ), and moreover the state stored in the   basenode   is not implicitly accessible to the  wrappingnode . In the end, by wrapping the   basenode  we preserve parts of its functionality while also being able to extend or modify the original behaviour. The   wrapping   approach   impacts   the   MDSD   develop- ment. If a robot architecture model exists and a new node must be added, node modelling is only required for the  wrappingnode   as the   basenode   is no longer visible as a separate entity in the new model. On the other hand, if a   basenode   model exists and the wrapping approach is applied, the model is altered in an invisible way for the  basenode . Therefore, the resulted   wrappingnode   model
could be seen as a reshaped version of the original one.  B. DSL by Example: Interactive ROS Node Creation  To provide an intuitive overview of the design of our DSL, we illustrate the succession of steps taken to create a new ROS node having the goal to drive the turtle from the ROS tutorials (Tutlesim) running in a circle. The code is presented as it is typed at Python’s command line interface. As the presentation focus is on the DSL language, unimportant implementation details like importing the required libraries, are omitted. First, the code implementing the callback functions imple- menting the behaviour of the node to the subscribed topics have to be typed:  def   showPose(data): print("Pose:   {}".format(data))  Next, we declare the new node name:  nd   =   rosNode("turtle_control_node")  It follows the node structure definition: the subscribe and published topics:  { nd.new.subscribe(topic   =   "/turtle1/pose",   handler   = showPose,   msgType   =   Pose) .publish(topic   =   "/turtle1/cmd_vel",   msgType   =   Twist ) }  We now   create   the defined ROS node. This operation causes the node to start running.  nd.create()  As we wanted to make the Turtle in the Turtlesim to run in a circle, we will publish with 1Hz frequency the appropriate message to the   /turtle1/cmd vel   topic using a timer:  def   onTimer(event): msg   =   Twist() msg.linear.x   =   2.0 msg.angular.z   =   1.8 nd.write("/turtle1/cmd_vel",   msg   ) timer   =   rospy.Timer(rospy.Duration(1),   onTimer)  C. DSL by Example: Kobuki Case Study  The DSL could be used to interactively wrap an existing ROS node from the Python’s command line interface. To exemplify this, we presnt the process of modifying one of the nodes used in the simulation demo example of section II- B. As in the previous example, unimportant implementation details like importing the required libraries, are omitted. The interactive session starts when a   new node  tt   wnode   is   declared,   wrapping   an   existing   basenode  defined in a given package:  wnode   =   rosNode("experimental_move_base") { wnode .baseNode("move_base") .basePackage("move_base") }  Next, the   wnode   structure of the topics being   reused   is declared as a pair of topic name and message type:  { wnode.reuse .publish(   topic   =   "cmd_vel",   type   =   Twist) .publish(   topic   =   "move_base/current_goal", type = PoseStamped) .publish(   topic   =   "move_base/goal",   type   = MoveBaseActionGoal) .subscribe(topic   =   "tf_static",   type   =   TFMessage) .subscribe(topic   =   "move_base_simple/goal", type = PoseStamped) .subscribe(topic   =   "tf",   type   =   TFMessage) }  To   wrap   a   basenode   topic, we relay the data between the  subscribe   and   publish   topics through a function and then we declare the   new   topics:  def   relayVelocity(data): wnode.write(   "mobile_base/commands/velocity", data) { wnode.new .subscribe(   topic   =   "cmd_vel",   handler   =   relayVelocity ,   type   =   Twist) .publish(   topic   =   "mobile_base/commands/velocity", type   =   Twist) }  We now   create   the defined   wnode . This operation causes the node to start running.  wnode.create()  Now, the experimentation phase could begin. We first define a new function for controlling the speed of the robot through a global variable and then we   replace   the initial functionality:  speed   =   4.5 def   controlVelocity(data): global   speed if   data.linear.x   >   0: data.linear.x   =   speed wnode.write(   m o b i l e _ b a s e /commands/ v e l o c i t y   , data ) wnode.new .subscribe(   topic   =   "cmd_vel",   handler   = controlVelocity,   msgType   =   Twist)  From   now   on,   the   speed   of   the   simulated   robot   could be controlled by simply changing the value of the global variable. The example triggers the maximum speed exceeded scenario by forcing the robot to run with 6m/s and exceeding in this way the defined maximum speed of 5m/s:  speed   =   6  D. Implementation  The internal DSL is implemented as a Python library. In order to achieve the syntax form, the language implemen- tation relies on method chaining. For improved readability, we prefer to split the chain into several lines, achieved by placing the code between either parentheses, square or curly brackets. This code nesting makes also possible unrestricted usage of indentation, further improving the code readability. The   rosNode   class   implements   the   basePackage ,  baseNode ,   write   and   create   as well as it contains two instances of the   topicHandler   class ( reuse   and   new ). The information related to the published and subscribed topics is encapsulated in dedicated classes ( publisher  and   subscriber ) instantiated trough the   topicHandler  class and used by the   subscribe   and   publish   methods.
The DSL is flexible. After declaring a new ROS node, the order of the   wrappingnode   components is unimportant. Even more, after creation of the new node, it is possible to further modify it. The changes are dynamic, the node continues to run while topics are added, deleted or modified. Moreover, it is possible to replace on-the-fly any of the handling functions used by the node.  E. Open issues  The   basenode   is launched by the DSL in a separate terminal command window when the   create   method is called. As a result, two ROS nodes (the   basenode   and the  wrappingnode ) along with their internal topics, are visible to ROS commands like   rosnode   list   or   rostopic list . When working with launch files, changes inside them are needed. The modified node has to be removed from the original launch file and has to be created manually using the DSL via the Python’s command line interface. When the experimental work is concluded, the program- mer normally wants to store the results and resume the work later. Also, when working in bigger projects involving several developers, it is desirable to share the source code among the team. None of these functionalities are present in the current version of the DSL, but are left for future work. In our robotics research work, we use the FroboMind framework [6]. As FroboMind does not utilize services, implementing them in the DSL was down-prioritized and left for future work. The direct support for timers is missing in the DSL, while the usage of configuration parameters is limited to the  basenode . However, if timers or configuration parameters for the   wrappingnode   are needed, it is possible to imple- ment them in the normal way used when developing ROS nodes in Python as exemplified in Section III-B. IV. DISCUSSION This section discusses the limitations of the DSL and proposes ways to address them, followed by possible en- hancements of language and extensions to its current usage.  A. Efficiency and its challenges  While the DSL implementation allows creation of a new ROS node from scratch, without the need of any   basenode , the only practical side of it is to minimize the number of lines of code written, and group the ROS-related code in a way easier to understand. This could appeal to beginners, as learning ROS is neither fast nor easy, requiring both comprehension of the ROS concepts and mastering the ROS API. The DSL permits instrumenting an existing ROS node using a black box approach by first launching the node of interest, and then obtaining the information about the pub- lish/subscribe topics together with the details about the mes- sages used through standard ROS commands like   rosnode info   or   rostopic   info . After the   wrappingnode   is created, the experimental phase could start. As the DSL keeps an internal representation of the corre- sponding node model, it is possible to be save it in a format compatible with other MDSD tools like e.g., the external DSL developed for the ROS nodes used in FroboMind [14]. As the current DSL implementation internally relies on the usage of the standard ROS message transport, overhead is generated when the messages between the internal topics are serialized at sending time and deserialized at receiving time. This, of course, adds up delay in the transport of the message and increases the processor load. One solution to the problem would be to use the special ROS message   anyMsg , avoiding in this way the serialization-deserialization overhead. Alter- natively, it could be possible to use nodelets. They are used in ROS to optimize the transport of messages by passing between them pointers to the buffers where the exchanged messages are stored. Optimizing the message transport is left for future work.  B. DSL design enhancements and usage extensions  A first enhancement of the DSL as a tool is to extend it with a code generation part, able to produce Python or C++ code. Leaving the generation of the boilerplate type of code to the tool is appealing to both the inexperienced and the experienced ROS programmers. Moreover, the interactive way of experimenting with the ROS nodes makes possible to immediately experience the effect of any changes in the code as the DSL permits a live reshaping of a running node. The DSL language syntax could be improved by changing the way the   publish   and   subscribe   topics are handled. For example, by using dynamic class attributes, publishing could be declared like:  node.reuse.publish.cmd_vel(Twist)  rather than:  node.reuse.publish(topic="cmd_vel",type=Twist)  The language syntax improvements are left as future work. Another possible usage of the node wrapping concept implemented in our DSL is for safety enhancement purposes. Let’s consider the case of an existing robot requiring to fulfil safety behaviour not originally implemented into it. While it is possible to enforce safety rules by adding dedicated ROS nodes (e.g. by using a safety-related DSL like in   [7]), the final reaction of the robot still depends of the original code, making the safety addition less effective. By developing the presented DSL to cover a safety-related scenario like this one, it will be possible to use the node wrapping for e.g., to safety wrap the actuator nodes and ensure the continuous control of the robot independent of the legacy software. Moreover, the node wrapping makes possible to use software of unknown provenance (SOUP) and ensure that, no matter how the original software reacts, the robot remains safe. Even more, the   wrappingnode   could run on a different platform than the rest of the robot, where e.g. the response time of the node is guaranteed.
R EFERENCES [1]   M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng, “Ros: an open-source robot operating system,” in   ICRA workshop on open source software , no. 3.2, 2009. [2]   H. Bruyninckx, “Open robot control software: the orocos project,” in  IEEE ICRA 2001 Proceedings , vol. 3, 2001, pp. 2523–2528 vol.3. [3]   U.   Schultz,   M.   Bordignon,   and   K.   Stoy,   “Robust   and   reversible execution of self-reconfiguration sequences,”   Robotica , vol. 29, no. 1, pp. 35–57, 2011. [4]   A. Steck, A. Lotz, and C. Schlegel, “Model-driven engineering and run-time model-usage in service robotics,” in   Proceedings of Gen- erative Programming and Component-Based Engineering (GPCE) . ACM, 2011. [5]   L. Gherardi and D. Brugali, “Modeling and reusing robotic software architectures: the hyperflex toolchain,” in   Robotics and Automation (ICRA), 2014 IEEE International Conference on , to appear. [6]   K. Jensen, A. Bøgild, S. Nielsen, M. Christiansen, and R. Jørgensen, “Frobomind, proposing a conceptual architecture for agricultural field robot navigation,” Spain, 2012, paper presented at CIGR 2012. [7]   S. Adam, M. Larsen, K. Jensen, and U. P. Schultz, “Towards rule-based dynamic safety monitoring for mobile robots,” accepted for publication at SIMPAR 2014. [8]   L. B. Larsen, K. S. Olsen, L. Ahrenkiel, and K. Jensen, “Extracurric- ular activities targeted towards increasing the number of engineers working in the field of precision agriculture.” XXXV CIOSTA & CIGR V Conference, Billund, Denmark, July 2013. [9]   E. Gamma, R. Helm, R. Johnson, and J. Vlissides,   Design Patterns - Elements of Reusable Object-Oriented Software .   Addison Wesley, Reading, MA, 1995. [10]   H. D. Hofmann and J. Stynes, “Implementation reuse and inheritance in distributed component systems,” in   Computer Software and Appli- cations Conference, 1998. COMPSAC’98. Proceedings. The Twenty- Second Annual International.   IEEE, 1998. [11]   D. Ungar and R. B. Smith, “Self: The power of simplicity.”   ACM , vol. 22, no. 12, 1987. [12]   L. Bergmans and M. Aksit, “Composing crosscutting concerns using composition filters,”   Communications of the ACM , vol. 44, no. 10, pp. 51–57, 2001. [13]   A. Goldberg and D. Robson,   Smalltalk-80: the language and its implementation .   Addison-Wesley Longman Publishing Co., Inc., 1983. [14]   M. Larsen, S. Adam, U. Schultz, and R. N. Jørgensen, “Towards auto- matic consistency checking of software components in field robotics,” in   RHEA-2014: Second International Conference on Robotics and associated   High-technologies   and   Equipment   for   Agriculture   and forestry , May 2014.