Simple Concurrency for Robotics with the Roboscoop Framework
Andrey Rusakov Jiwon Shin Bertrand Meyer Chair of Software Engineering Department of Computer Science ETH Zurich,¨ Switzerland {andrey.rusakov, jiwon.shin, bertrand.meyer}@inf.ethz.ch
Abstract— Concurrency is inherent to robots, and using enables even novice programmers to program concurrent concurrency in robotics can greatly enhance performance of the robotic software. Current Roboscoop contains behaviors and robotics applications. So far, however, the use of concurrency in tools necessary for the operation of differential drive robots robotics has been limited and cumbersome. This paper presents Roboscoop, a new robotics framework based on Simple Concur- and has been tested on two different robots. rent Object Oriented Programming (SCOOP). SCOOP excludes This paper is organized as follows: After presenting related data races by construction, thereby eliminating a major class of work in Section II, the paper presents the core of Roboscoop concurrent programming errors. Roboscoop utilizes SCOOP’s framework in Section III. Section IV presents an example of concurrency and synchronization mechanisms for coordination using Roboscoop for the task of exploring an unknown area. in robotics applications. We demonstrate Roboscoop’s simplicity by comparing Roboscoop to existing middlewares and evaluate Section V compares Roboscoop against other middlewares Roboscoop’s usability by employing it in education. and also presents an evaluation of Roboscoop in education. The paper concludes with final remarks in Section VI. I.INTRODUCTION Advanced robotic systems are composed of many com- II. RELATED WORK ponents that can operate concurrently. Running these com- In the last decade, many middlewares have been pro- ponents concurrently would enable robots to meet their full posed to ease the development of robotic coordination and potential. Researchers have noticed the value of concurrency control. Some of the more popular middlewares include in robotics three decades ago. Kanayama [1] proposed a Urbi [3], MOOS [4], Microsoft Robotics Developer Stu- simple message passing mechanism to synchronize a robot’s dio [5], ROS [6], and LCM [7]. Two recent surveys [8], [9] multiprocessing units, and Ingemar and Gehani [2] showed provide a comprehensive overview and comparison of mid- how Concurrent C, a general purposed language, can be dlewares. In addition, the related work section of MIRA [10] applied in robotics. Despite the early effort, little progress provides a compact survey of middlewares with the largest has been made in using concurrency in robotics. impact. Here, we highlight how they compare to Roboscoop. Introducing concurrency to robotics poses a great chal- Section V-A presents a more-detailed comparison. lenge. Enabling concurrency in a robotic system requires its Mission Orientated Operating Suite (MOOS) uses software to support concurrent execution. Traditional concur- store/fetch mechanism for message-passing. Robot Operat- rent programming techniques such as standard ”threading li- ing System (ROS) uses a combination of publish/subscribe braries” do not, however, offer any safety guarantees. Hence, and service-based message-passing models. The Lightweight the programmer must write concurrent programs carefully to Communications and Marshalling (LCM) utilizes only a pub- avoid common pitfalls of concurrency such as data races and lish/subscribe message-passing model and additional mar- deadlocks. Consequently, most robotic software make only shalling tools to support low-latency applications. MIRA, elementary use of concurrency or avoid it all together. a recently introduced robotics middleware with a focus on This paper introduces Roboscoop, a new robotics frame- performance, also uses publish/subscribe message-passing work based on Simple Concurrent Object Oriented Program- model and supports multi-threaded accesses through slots. ming (SCOOP). Unlike standard approaches that are complex While all these middlewares concentrate on the inter-process and error-prone and require additional qualifications, SCOOP communication, Roboscoop does coordination and concur- makes concurrency simple and safe. SCOOP is free of data rency on the level of a single application. MOOS, ROS, races by construction. Built on top of SCOOP, Roboscoop en- and LCM applications can be written in general-purpose ables programmers to express robot’s behaviors in a natural languages such as C++ and Java, and their application way without worrying about the program’s safety. In addition support for concurrency is limited to the standard ”threading to SCOOP’s concurrency and synchronization mechanisms, library” approach. On the contrary, Roboscoop provides the Roboscoop provides a library support for robotics, Behavior- language support for concurrency. Signaler-Controller design for coordination of tasks, and ROS SMACH [11] is a ROS-independent Python library infrastructure for integration with external frameworks. We for building hierarchical state machines for specifying mod- demonstrate Roboscoop’s simplicity by comparing it to ex- els of complex robotic behavior. SMACH supports parallel isting middlewares and present Roboscoop in education that execution of state behaviors, but its applicability is limited to scenarios where all possible states and state transitions can • Library (set of primitives and tools be described explicitly. Concurrency in SMACH is bound Roboscoop for their coordination) to the language support, more precisely, to Python threads. • Integration with other robotics frameworks Roboscoop’s concurrency is based on SCOOP that offers • Object-Oriented Structure simpler and safer concurrency than Python threads. SCOOP • Synchronization • Concurrency Microsoft Robotics Developer Studio (MRDS) is a .NET- C/C++ • Calls to external libraries providing based robotics programming environment that uses the Con- communication, navigation, image processing, currency and Coordination Runtime library for parallelism. Externals coordinate transforms, visualization, … Based on .NET, the library manages asynchronous parallel tasks through message-passing. Unlike MRDS that intro- Fig. 1: The Roboscoop framework structure duces work items, Roboscoop does not have to introduce any additional intermediate abstractions for concurrency. In A. SCOOP – Simple Concurrent Object Oriented Program- Roboscoop, concurrency can be reached on the object level. ming Urbi is a software platform for robotics, which along with SCOOP model [15], [16] is an extension of a standard the C++ support brings urbiscript [12] - a parallel event- sequential object-oriented model, Eiffel, and the Design based object-oriented script language. Urbiscript and SCOOP by Contract paradigm [17] to support concurrency. The go in the same direction by providing tools for coordination model provides a higher level of abstraction through object- and concurrency on the language level. Their difference lies orientation and minimizes common concurrency-specific in their complexity. For concurrency, urbiscript introduces mistakes. Programmers using SCOOP can represent, for a set of unmatched additional mechanisms and syntactic instance, various parts of a robot as objects and manipulate extensions to the language while SCOOP introduces only them concurrently without the burden of threads. SCOOP one additional keyword. eliminates data races by construction. In addition to middlewares, some languages have also been Every object in SCOOP is associated with a certain proposed for robotics. Concurrent C [2] provides concur- processor called its handler, for the object’s entire lifetime. rency on top of a general-purpose language and has been Contrary to CPU, SCOOP processor is just an abstract proposed for usage in robotics. SCOOP’s advantage over independent unit of control and is typically implemented as non-object-oriented concurrency languages such as Con- a thread. Only the object’s handler is allowed to execute current C is its ability of reasoning about different robot features, i.e, a set of possible actions, on the object. Each components as programming objects. This results in more object has exactly one handler, but a single processor can modular design and reusable applications. As a general- handle multiple objects. When two objects are handled by purpose language, SCOOP provides more flexibility than different processors, they are called separate to each other. domain-specific languages. For instance, Task Description separate objects can operate concurrently. Language [13], based on the task tree data structure, has nodes that can contain only commands, goals, monitors, Because features of a separate object can only be executed handler or exceptions. SCOOP used in Roboscoop retains its full by its own handler, it may seem that the is not flexibility of a general-purpose language. allowed to execute features on other separate objects. But if client The Roboscoop framework builds on top of the work by in the scope of the current object ( ), there is a need to supplier client Ramanathan et al. [14]. The authors presented a controller call some feature on a separate object ( ), the supplier for hexapod using SCOOP. Roboscoop is an extension of can ask the to execute it on its behalf. Such a call is separate call SCOOP’s concurrent coordination into a full-fledged robotics named a and it can be executed asynchronously. framework. In addition to SCOOP, it provides a library An object can be separate or non-separate. To distinguish support for building up robotic behaviors, Behavior-Signaler- between the two semantics in SCOOP, the separate keyword Controller design for task coordination, and communication is used in object’s type declaration. If the declared object has infrastructure for integration with the external frameworks. a separate type, it indicates that it may reside on a different processor relative to the current object. separate type is also III.ROBOSCOOPFRAMEWORK used for arguments in a feature’s signature to denote the The Roboscoop framework is a set of classes and program- intention of a separate call. ming tools that aims to ease the development of robotics The following example illustrates how SCOOP can co- applications. The framework is composed of three parts – ordinate robotic eyes of a humanoid to look at a moving Roboscoop, SCOOP, and C/C++ externals – as shown in ball. We assume that the robot is equipped with a camera Figure 1. Roboscoop contains a library that provides a set that provides the ball’s location. In the example, left eye , of primitives and tools for coordination of different robotic right eye , ball and the current object are separate objects behaviors. SCOOP is the base language of Roboscoop and and hence have different handlers: gives Roboscoop the power of concurrency and synchroniza- look ( left eye , right eye : separate EYE; ball : separate BALL) tion. C/C++ externals enables Roboscoop users to integrate require ball . is visible existing libraries in robotics. This section describes the three left eye . is ready and right eye . is ready components of Roboscoop in detail. local shields programmers from data races providing an exclusive position : POINT 3D access to the shared resources. do position := ball . position Coordination left eye .move ( position ) right eye .move ( position ) Roboscoop coordinates robotic behaviors through the in- end teraction among behaviors, signalers, and controllers. Be- The above code contains several Eiffel keywords – havior defines tasks a robot performs. Signaler contains require, local, do, and end – and a SCOOP keyword, information about the state of particular subsystems, e.g., separate. The require clause contains the precondition, robots, sensors, actuators, behaviors, etc. Controller controls conditions that must be satisfied before the body of look actuators based on the behavior and the state of sensors. (in do clause) can be executed. In the above example, the The Behavior-Signaler-Controller interaction is crucial to the call will not be executed until ball is visible and both coordination of robotic behaviors in Roboscoop. left eye and right eye are ready to be actuated. To ensure this, SCOOP runtime waits until this condition is True; this 0..* 0..* synchronization mechanism is known as wait conditions. Another synchronization mechanism, named wait by ne- 1..1 1..* cessity, helps the synchronization of execution inside the body of a routine. When the current object requires the 1..* 0..* result of a separate call for further computation, its han- dler automatically waits at the point where the separate Fig. 2: The relationship among behavior, signaler, and con- call returns the result; need for the results necessitates the troller. A behavior is associated with one or more controllers waiting. A similar idea was also recently introduced in other and zero or more signalers. A controller, in turn, is associated modern programming languages including C++ and Java with one or more signalers. with the notion of futures . Unlike C++ and Java, SCOOP does not require programmers to introduce any additional Figure 2 shows the interaction among the three com- constructions or auxiliary objects to support this type of ponents graphically. Behavior handles high-level sophisti- synchronization. In the example, wait by necessity forces the cated robotic tasks. As a single programming unit, behavior execution to wait for the result of ball . position to be stored coordinates multiple simultaneously-operating controllers to in the local variable position before proceeding. Once the perform a particular task. Signaler contains information value is stored in position , calls of the move feature can be about the current state of other components such as sensor executed asynchronously on both left eye and right eye , data or behavior’s state. When a signaler is used in the causing the eyes move simultaneously. precondition of a feature, it enables the feature to synchro- SCOOP’s concurrency mechanism, separate calls, and nize the execution when the desired conditions are satisfied. synchronization mechanisms, wait conditions and wait by Controller implements low-level coordination tasks and is necessity, allows programmers use concurrency to express in charge of controlling actuators based on sensor data and complex robotic behaviors in a natural way, without the pain. state of the algorithm. Coordination in Roboscoop works by behavior objects creating, launching, and orchestrating their B. Roboscoop controller objects when the signalers are in desired states. The core of Roboscoop is the Roboscoop library. Built Section IV presents a concrete example that illustrates the on top of SCOOP, the library uses SCOOP synchroniza- Behavior-Signaler-Controller interaction. tion mechanisms to enable concurrency and coordination in Structure robotic applications. Using the Roboscoop library, program- mers can create various robot behaviors easily and coordinate The Roboscoop library is organized into subclusters – sets these behaviors in a natural way. The Robscoop library of classes. Each subcluster is responsible for one type of achieves concurrency and coordination as follows: functionality. The most important subsclusters are as follows: • SIGNALER: Signaler subcluster contains commonly used Concurrency Signaler classes. Exemplary classes in the subcluster Concurrency in Roboscoop is simple and fine-grained. include STOP SIGNALER that indicates whether or Writing concurrent programs in Roboscoop does not require not some particular task was requested for a stop, programmers to create or manage threads and synchroniza- and ODOMETRY SIGNALER that contains odometry- tion primitives such as mutexes or semaphores. Declar- related information, i.e., position and orientation in ing separate types and applying aforesaid synchronization space and current speed and speed-related features. mechanisms are sufficient to make code concurrent, enabling • BEHAVIOR: Behavior subcluster contains several sim- programmers to concentrate on the robotics issues instead. ple Behaviors for differential drive robots. Exemplary In addition, SCOOP model enables Roboscoop to achieve classes in the subcluster include WANDER BEHAVIOR concurrency on the object level. In turn, programmers can and TANGENT BUG BEHAVIOR, an implementation of create fine-grained concurrent applications. The model also the tangent bug algorithm [18]. avoid obstacles, or stopping. It launches the controllers asynchronously to achieve the desired behavior. class EXPLORATION BEHAVIOR feature ctrl a , ctrl b , ctrl c : separate SIMPLE CONTROLLER
start do launch ( ctrl a , ctrl b , ctrl c ) end
launch (a, b, c: separate SIMPLE CONTROLLER) (a) SmartWalker – the robot for (b) Educational robot Thymio-II do ambient assisted living (AAL) with PrimeSense RGBD sensor a. go straight b. turn to avoid obstacles Fig. 3: Roboscoop demonstrators c.stop on emergency end • CONTROLLER: Controller subcluster contains con- The SIMPLE CONTROLLER class has references to the trollers for the behavior subcluster. Basic controllers objects of the separate types ODOMETRY SIGNALER , such as PID CONTROLLER are collected here. RANGE SIGNALER and ROBOT and use them as ar- • COMMUNICATION: Communication subcluster provides guments for the separate calls. SIMPLE CONTROLLER resources for communication with robots. Classes in this also implements go straight , turn to avoid obstacles , and subcluster send commands to robots and receive neces- stop on emergency features. These features continuously call sary data back. This subcluster also contains functional- go, turn and stop with aforementioned separate arguments. ity for Roboscoop to integrate with external frameworks. Figure 4 shows the object diagram of our example. All ob- • UTILS: Utils subcluster contains useful tools for creating jects are separate and thus can execute calls asynchronously. non-standard behaviors such as non-linear behavior or All three SIMPLE CONTROLLER objects can access the ob- event-based behavior. For instance, the timing tools in jects of ODOMETRY SIGNALER, RANGE SIGNALER, and the subcluster enable delayed and repeated invocation. ROBOT through separate calls. C. Interoperability odom_signaler: ctrl_a: SIMPLE_CONTROLLER ODOMETRY_SIGNALER The underlying Eiffel’s support for C/C++ external calls odom_signaler: ODOMETRY_SIGNALER eases the integration of external libraries and other frame- range_signaler: RANGE_SIGNALER robot: ROBOT works into Roboscoop. Programmers using Roboscoop can use functionality of existing external C/C++ solutions such as image processing libraries without losing the benefits of bvr:EXPLORATION_BEHAVIOR ctrl_b: SIMPLE_CONTROLLER robot: ROBOT Roboscoop’s easy concurrency and coordination; applying ctrl_c: SIMPLE_CONTROLLER odom_signaler: ODOMETRY_SIGNALER ctrl_b: SIMPLE_CONTROLLER range_signaler: RANGE_SIGNALER external calls on a separate object can easily make it parallel. ctrl_a: SIMPLE_CONTROLLER robot: ROBOT Current version of Roboscoop is integrated with ROS and can communicate both ways (publishing and subscribing) ctrl_c: SIMPLE_CONTROLLER with ROS-based applications. Any robot with ROS interface range_signaler: odom_signaler: ODOMETRY_SIGNALER RANGE_SIGNALER can therefore be programmed using Roboscoop. range_signaler: RANGE_SIGNALER The Roboscoop framework has already been used in a real- robot: ROBOT life setup for two different robots (see Figure 3): in ambient Fig. 4: Each object in the diagram is separate. Thick curvy assisted living (AAL) and in education. lines show the borders between SCOOP processors. The be- havior object (on the left) coordinates three controller objects IV. EXAMPLE (in the middle). Each of the controllers uses information from This section demonstrates how to develop robotic appli- the signalers for actuating the robot (on the right). cations with Roboscoop. We assume that our robot is a The go straight feature makes the robot move forward at differential drive robot equipped with forward and ground a constant speed if 1) the robot is not moving, 2) the ground sensors to detect obstacles in the front and distance to the has no hole, and 3) there is no obstacle in front of the robot. ground, respectively. The task is to explore an unknown The three requirements are easily translated into precondition area. To accomplish this task, our robot must go straight in the feature go as shown below: when there is no obstacle in front, turn when there is an go (odom sig: separate ODOMETRY SIGNALER; obstacle, and stop when there is a hole in the ground. We range sig : separate RANGE SIGNALER; robot: separate ROBOT) require implement the task of exploring an unknown area in class not odom sig.is moving −− 1) EXPLORATION BEHAVIOR. not range sig . has ground hole −− 2) The EXPLORATION BEHAVIOR class contains three sep- not range sig . has obstacle −− 3) do arate SIMPLE CONTROLLER objects, each object respon- robot . apply default speed sible for one type of control – going straight, turning to end The turn to avoid obstacles feature makes the robot turn stop (s: separate STOP SIGNALER) if 1) the robot is moving, 2) the ground has no hole, and do s . set stop requested (True) 3) the robot detects an obstacle in front. As before, the end requirements are translated into preconditions naturally: The control feature waits until the robot is ready to be turn (odom sig: separate ODOMETRY SIGNALER; range sig : separate RANGE SIGNALER; robot: separate ROBOT) controlled or stop is requested. If no stop is requested and the require robot is ready, it performs its usual control. Otherwise, if stop odom sig.is moving −− 1) is requested, it stops the robot smoothly. After starting the not range sig . has ground hole −− 2) range sig . has obstacle −− 3) cancellable control, all we need to do to cancel the execution do is to call stop feature with stop signaler as an argument. if range sig . is obstacle left then This approach of stopping an execution can also be used to robot . turn right elseif range sig . is obstacle right then handle other types of interruption such as user-interaction or robot . turn left a timer. end end V. EVALUATION The implementation of the stop feature is also simple and The main features of Roboscoop are its simplicity and natural. The robot must stop if 1) it is moving, and 2) the usability. We demonstrate the framework’s simplicity and ground has a hole. usability by comparing it with other approaches and reporting students’ experience with Roboscoop in educational context. stop (odom sig: separate ODOMETRY SIGNALER; range sig : separate RANGE SIGNALER; robot: separate ROBOT) A. Comparison to other approaches require odom sig.is moving −− 1) We compare SCOOP, Roboscoop’s base language, with range sig . has ground hole −− 2) C++ with boost library [19] and urbiscript [12]. Boost is do robot . stop a popular C++ library with concurrency support and is end extensively used in many robotics middlewares including end ROS. urbiscript is the base language for Urbi, a robotics The code snippets demonstrate how roboscoop ensures a framework with concurrency support. The comparison of close correspondence between the behavioral requirements these languages is on mechanisms or syntactic support for and the SCOOP preconditions. It eases the translation of parallelization and coordination using events. desired behavior into code and simplifies the coordination. First comparison is on parallelization. Let us consider a task of commanding a robot to lift its arm and bending its Canceling approach leg simultaneously. A program that accomplish such a task The EXPLORATION BEHAVIOR can coordinate different can be written in C++ with boost as follows: possible control algorithms for autonomy, but it is sometimes boost :: threada thread , l thread ; necessary to interact with the robot directly. One such a situ- a thread = boost :: thread(&Arm:: lift ,&arm); ation is interruption/cancellation of an ongoing process. The l thread = boost :: thread(&Leg::bend,&leg); STOP SIGNALER class fulfills just the role. Programmers In this example, lift method of the class Arm and bend can easily apply the cooperative cancellation mechanism method of the class Leg will be executed simultaneously, using a separate object of type STOP SIGNALER. each by a separate thread. The problem is that the thread To be interruptible, the controller must be aware of the objects have to be managed manually. To facilitate this issue, state of stop signaler . This can be achieved by using the recently async syntax was announced in C++11. async con- precondition as shown below: structions automatically create and spawn threads allowing stop signaler : separate STOP SIGNALER tasks be executed asynchronously: autoa = std :: async(launch :: async,&Arm:: lift ,&arm); start cancellable control autob = std :: async(launch :: async,&Leg::bend,&leg); do from until stop requested ( stop signaler ) loop Unfortunately, neither C++ cases guarantee that the exe- control ( example signaler , stop signaler ) end cution will not be interrupted by the other threads accessing end the same arm or leg objects. The only way to prevent the data race is by using, for example, mutexes. control (b: separate SOME SIGNALER; s: separate STOP SIGNALER) require urbiscript uses special connectors, ”,” and ”&”, for con- b. is ready or s . is stop requested currency in addition to the standard sequential ”;” connector. do The ”,” connector launches the first statement in background, if (not s . is stop requested ) then robot . execute reactive control and immediately proceeds to executing the next statements. else The ”&” connector is similar to ”,”, but it ”waits” for all the robot . stop smoothly statements to be known to start their concurrent execution. end end The same program of lifting a robotic arm and bending a robotic leg can be written in urbiscript as follows: { In C++, a handler can be subscribed for a particular {arm. lift }, signal (event) using the function connect. After the signal is {leg .bend}, }; emitted, the handler is automatically called. For example, a program that commands a robot to go to the charging station urbiscript’s code is much simpler than C++ one, but the when its battery is low can be written in C++ as follows: above syntax is only valid for behaviors composed only of int main () { special connectors. For instance, dynamically-created jobs signal