An Event-Driven Embedded Operating System for Miniature Robots
Total Page：16
File Type：pdf, Size：1020Kb
This is a repository copy of OpenSwarm: an event-driven embedded operating system for miniature robots. White Rose Research Online URL for this paper: http://eprints.whiterose.ac.uk/110437/ Version: Accepted Version Proceedings Paper: Trenkwalder, S.M., Lopes, Y.K., Kolling, A. et al. (3 more authors) (2016) OpenSwarm: an event-driven embedded operating system for miniature robots. In: Proceedings of IROS 2016. 2016 IEEE/RSJ International Conference on Intelligent Robots and Systems, 09-14 Oct 2016, Daejeon, Korea. IEEE . ISBN 978-1-5090-3762-9 https://doi.org/10.1109/IROS.2016.7759660 © 2016 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works. Reuse Items deposited in White Rose Research Online are protected by copyright, with all rights reserved unless indicated otherwise. They may be downloaded and/or printed for private study, or other acts as permitted by national copyright laws. The publisher or other rights holders may allow further reproduction and re-use of the full text version. This is indicated by the licence information on the White Rose Research Online record for the item. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request. [email protected] https://eprints.whiterose.ac.uk/ OpenSwarm: An Event-Driven Embedded Operating System for Miniature Robots Stefan M. Trenkwalder1, Yuri Kaszubowski Lopes1, Andreas Kolling1, Anders Lyhne Christensen2, Radu Prodan3 and Roderich Groß1 Abstract— This paper presents OpenSwarm, a lightweight effectively and personal computers could execute multiple easy-to-use open-source operating system. To our knowledge, applications concurrently. As a result, personal computers it is the first operating system designed for and deployed on became easier to use and program, and, hence, they were miniature robots. OpenSwarm operates directly on a robot’s microcontroller. It has a memory footprint of 1 kB RAM used more widely. and 12 kB ROM. OpenSwarm enables a robot to execute The benefits of operating systems have already led to the multiple processes simultaneously. It provides a hybrid kernel development of embedded operating systems in the field of that natively supports preemptive and cooperative schedul- sensor networks [5] and the Internet of Things [6]. Sensor ing, making it suitable for both computationally intensive network motes1 and Internet of Things devices provide and swiftly responsive robotics tasks. OpenSwarm provides hardware abstractions to rapidly develop and test platform- limited resources similar to swarm robots. For instance, the independent code. sensor mote AS-XM1000, a Class 1 constrained device, We show how OpenSwarm can be used to solve a canonical provides 8 kB RAM and 116 kB ROM. Embedded operating problem in swarm robotics—clustering a collection of dispersed systems—such as Contiki [7] and TinyOS [8]—manage objects. We report experiments, conducted with five e-puck these resources and facilitate application development. They mobile robots, that show that an OpenSwarm implementation performs as good as a hardware-near implementation. The are mainly designed to send sensor data to a central base primary goal of OpenSwarm is to make robots with severely unit, which requires them to execute short sequences of constrained hardware more accessible, which may help such instructions. However, robots may also need to execute systems to be deployed in real-world applications. computationally expensive algorithms—for example, image processing. As a result, operating systems for robots have I. INTRODUCTION different requirements. Swarm robotics investigates the emergence of collective This paper introduces OpenSwarm, an open-source, event- behavior through local interactions of simple robots in large driven operating system for miniature robots. It provides groups (swarms) [1]. Due to the large number of robots a novel hybrid kernel that, unlike other kernels for within a swarm, each robot typically has to be inexpensive microcontroller-based systems, natively supports two concur- and is designed to rely on basic operations. As a result, rency models, preemptive and cooperative scheduling. It uses many swarm robots have severely limited on-board resources events as hardware-abstraction to interface components of the and can be categorized as Class 0 or Class 1 constrained system with hardware. OpenSwarm provides mechanisms to devices [2]. For instance, the Kilobot [3] platform is a Class restrict, convert, and manipulate sensor and actuator values 0 constrained device by providing an Atmel ATmega328P for further—higher levels of—abstraction. All this makes with 2 kB RAM and 32 kB ROM. algorithms and code easier to port, maintain, and extend. Due to the limited on-board resources, swarm robotics We compare OpenSwarm to state-of-the-art embedded algorithms are, in general, implemented at a low level operating systems. OpenSwarm’s static and dynamic memory (hardware-near). Consequently, their implementation cannot footprint is analysed. OpenSwarm is then used to solve a be directly ported to other platforms. They are usually canonical problem in swarm robotics on the e-puck miniature onerous to maintain or extend, and are likely to contain mobile robot [9], a Class 1 constrained device. The perform- programming errors [4]. This resembles the beginnings of ance of the OpenSwarm implementation is compared with personal computers, where every machine executed only a that of a hardware-near implementation presented in [10]. single program—such as a word processor or accounting The paper is structured as follows. Section II summarizes software. With the advent of operating systems and concur- existing systems that influenced OpenSwarm. The Open- rency models, complex software could be developed more Swarm architecture is presented in Section III. Section IV details its implementation and its evaluation is presented in 1S.M. Trenkwalder, Y.K. Lopes, A. Kolling, and R. Groß Section V. Section VI concludes the paper. are with the Department of Automatic Control and Systems Engineering, The University of Sheffield, Sheffield, UK, e-mail: {s.trenkwalder, y.kaszubowski, a.kolling, II. RELATED WORK r.gross}@sheffield.ac.uk The need for easy-to-use software environments in ro- 2A.L. Christensen is with the BioMachines Lab, University Institute of Lisbon, (ISCTE-IUL), Lisbon, Portugal, e-mail: [email protected] botics resulted in a variety of middlewares [11]. They are 3R. Prodan is with the Institute of Computer Science, University of Innsbruck, Innsbruck, Austria, e-mail: [email protected] 1A mote is a sensor device inside a sensor network. designed to simplify development, but require an underlying another thread can take over [18]. A thread is only preemp- operating system. One of the most common middlewares is ted by a hardware interrupt which executes certain run-to- ROS [12]. Small units of ROS, which are called ROS nodes, completion handler functions. As a result, Contiki is not a can be executed on small and embedded devices [13], but preemptive operating system according to the definition in need a ROS master and core functions, which are commonly [19]. executed on a central device capable of running Linux. The execution models of LiteOS [20], Mantis OS [21], Consequently, ROS and other robot middlewares are not Nano-RK [22] and NuttX [23]—four embedded operating suitable for scalable swarm robotics applications. systems—are based on preempted threads, which require one Some frameworks—such as ASEBA [14] and JaMOS [15] call stack per thread. This creates a memory and time over- can be seen as interpreters implemented on miniature robots. head compared to cooperative scheduling. LiteOS and Mantis ASEBA is a virtual machine that executes a hardware- OS use a priority-based round-robin scheduler. NuttX uses independent script language. This improves the portability FIFO/priority-based round-robin and sporadic scheduling. and maintainability. However, the performance is limited (on Nano-RK uses rate-harmonized and rate-monotonic schedul- average, one instruction of virtualized code translates to 70 ing, which provides real-time properties. processor instructions [14]). JaMOS is a finite state machine The aforementioned operating systems are mainly de- operating system, which uses an XML-based motion de- signed to support measurements and communication, which scription language (MDL2ε). This provides good reusability results in different system requirements compared to mini- of code. Both systems—ASEBA and JaMOS—only provide ature robots. For instance, motes typically have long inactive predefined sets of functions, which restrict the verity of and short active times. They are designed for low energy con- possible solutions. sumption. On the other hand, a robot might constantly inter- Wireless sensor networks, which work under similar com- act with its environment. Consequently, it cannot be assumed putational constraints as swarm robotics systems, already that the robot has long inactive periods. Interactions—such make use of concepts of operating systems [5]. Operating as locomotion and actuation—usually require a significantly systems