EXERCISES
5.2 A VERY SHORT INTRODUCTION TO ROS
however integrating them into a robot is still a desired goal of the future. This module should consist of NLP, face recognition and emotion recognition. Since human-robot interactions should also tally with known social conventions hence this module should also address roboethics.
10. Many robot teams and robot swarms are interesting avenues and the student will learn about explicit coordination (robot groups) and implicit coordination (robot swarms). Most robot softwares are designed for single robot, and that includes ROS.
The apparent compromise to this approach is that it alienates the wonderful facets of swarming as discussed inChapter 6. There has been prospects to incorporate multiple robots paradigm into ROS using multimaster, and future versions of ROS may have capability to design robot swarms. Autonomous Robots Go Swarming (ARGoS) made by researchers at IRIDIA, Belgium is currently the best software platform option for researching on robot swarms.
ROS easily implements the first six of the above, however it is yet to be employed for social robots or swarm robotics.
161
FIGURE5.4Re-inventingthewheel.Roboticsresearchwasplaguedbylackofauniversallyacceptablehardware/softwareplatformanditwas difficulttoreplicatepublishedresearchandthiswasdetrimentaltorobotics.AdaptedfromCham[65]
computing systems.
3. capabilities: ROS provides a broad collection of libraries that implement useful robot functionality, with a focus on mobility, manipulation, and perception.
4. ecosystem: ROS is supported and improved by a large community, with a strong focus on integration and documentation. The ROS website is a one-stop-shop for finding and learning about the thousands of ROS packages that are available from developers around the world.”
The plumbing part is the asset of ROS, where communicating nodes across a publisher-subscriber system enables versatality in design level, behaviour level, sensor level and control level for the robot, this is broadly accomplished via roscore. One of the most striking features of ROS is that it works more like an operating system than an application, and various command structures and file structures bear similarity to standard bash commands in UNIX. Tools are the OS level aspects of ROS which are a basic set of tool for visualisation, diagnostics and debugging and often mimics sh commandline. Capabilities is the facility to develop customised codes and designs, which is now structured through catkin and is developed on make/cmake file structures.
Ecosystem, other than the ROS website there are variour other forums, mailing lists and annual events which goes on to popularise ROS. It is further to be noted that ROS is not a programming language, it is not a compiler, it is not an IDE and it is not a software library; however all these facilities are supported by ROS in some manner or other. Over the seven years of its existence ROS has become a the single most used software platform in robotics.
Around the new millennium, each robotics research group worked in its own software platform and it was difficult to recreate published results as shown in Figure 5.4. This was detrimental to the future prospects robotics. ROS has nearly solved that problem by benchmarking the software in the robotics domain, and making the software more predominant and universal than the hardware.
Since it’s first release in 2010, over the last seven years ROS has found growing acceptance in the open source community and the user contributed packages has increased at an astounding rate. Other than the ROS website atwww.ros.orgthere are question answer forums atanswers.ros.org, meta blogs atplanet.ros.organd mailing lists to help and support ROS users which helps to fostercommunity participation and crowdsourcing much like large open source projects such as Ubuntu, Python, Apache etc.
ROS provides standard operating system services such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. ROS is currently supported on Ubuntu,
163
An Example In Emergence Of Behaviour
This is an example using the gazebo simulator in ROS. We had met the PR2 robot in the last chapter, here we try to make it perform simple obstacle avoidance using lasers in a box-world like environment made in gazebo.
On running the above code it is noticed that instead of obstacle avoidance the PR2 exhibits an akward box-pushing behaviour.
What is happening here?In this simulation the PR2 has its arms streched. While coding this aspect was not taken into consideration and the algorithm was developed for a point like robot, or at best a circular robot and 0.5 was used as an arbitrary distance to maintain a minimal proximity. For the conditionminimum range≤0.5(∼AB in the figure below), it corresponds to a space at about the elbow of the arms of the PR2 and each time the code checks for an obstacle there, doesn’t find it and itmove forward, since gazebo is a physics simulator, in a box-world this manifests as a box-pushing behaviour. On correcting the code tominimum range≤1.2(∼CD in the figure below) the issue is sorted out.
Box-pushing was never coded in, it emerges as a result of the interaction of the code with the PR2 and the box world.
FIGURE 5.5 ROS Lunar Loggerheadwas released on May 23, 2017 .The tortoise is a reoccuring theme at ROS, all releases and logos have a tortoise reference. It has been suggested that such is due to, the first modern robots are often said to be the two tortoise robots, Elmer and Elyse developed by Walter. Image courtesyhttp://wiki.ros.org/, Creative Commons Attribution 3.0.
TABLE 5.1 ROS Distributions
Name Release
Box Turtle March 2, 2010
C Turtle August 2, 2010
Diamondback March 2, 2011
Electric Emys August 30, 2011 Fuerte Turtle April 23, 2012 Groovy Galapagos December 31, 2012 Hydro Medusa September 4, 2013 Indigo Igloo July 22, 2014
Jade Turtle May 23, 2015
Kinetic Kame May 23, 2016
Lunar Loggerhead May 23, 2017
165
FIGURE 5.6 Differential drive robots.There has been growing interest in making differential drive robots, be it commercial ((a),(b) and (c) from Touretzky [326], reprinted by permission of the publisher Taylor & Francis Ltd,http://www.tandfonline.com)) or hobbyist — (d) Achu Wilson’s Chippu (Image courtesy Achu Wilson) and my own project named Tortue built with ASUS Xtion and a Roomba 560 base in ROS Electric.
experimentation for extending this support for other operating systems as other flavours of Linux, Windows, Mac OS-X, ARM versions for embedded devices etc. is an ongoing effort.
A chit-chat with the STDR developers
Manos, Aris and Chris from Greece tell us about their experience developing the STDR simulator at ROS. This interview took place on 10 Nov 2014.
AB:Tell us about the development of STDR, the motivation and need?
The STDR team:STDR Simulator‘s development process begun in November 2013 from a group of electrical engineers involved in the robotics and specifically members of the P.A.N.D.O.R.A. rescue robotics team from the Aristotle University, Greece.
The motivation behind STDR was to build a low-requirement simulator that‘s easy to install and use, thus providing a good tool to test incipient ideas or develop less advanced projects, as effortless as possible. Our intention was not to provide the most realistic simulator, nor the one with the most functionalities. On the contrary, the overall design is minimal allowing rapid robotic algorithms prototyping. This fact was critical to our approach as many simulators need a considerable amount of time to be installed, configured and setup for an experiment.
The tool that allowed us to implement such automated flexibility is the Robotic Operating System or ROS. Being ROS users for some time now, we pinpointed the fact that there were no ROS-dedicated simulators, meaning that no simulator is actually built in ROS and not just use its interfaces. Thus, we decided to employ ROS tools to create a ROS compliant two dimensional simulator, aiming both at providing easy usage and being a state-of-the-art robotic software.
experiment with specially defined parameter files. On the contrary, in STDR, the robotics developer can immediately execute the simulator, add a robot providing its specification graphically and subscribe to the appropriate ROS topics effortlessly.
FIGURE 5.7 STDR, startup graphics for STDR
AB: Can one make basic algorithms as A?, bug-algorithms, potential fields etc. to work in STDR?
The STDR team:As STDR is a simulator, its job is to simulate robots and their environment. Concerning the environment simulation, the user can provide a simple image file containing the obstacles, the unoccupied space, as well as the unknown areas. On the other hand, via the robot simulation, the robotics developer has access to simulated effectors (wheels) and receptors (sensors like LRFs, Sonars etc). In that sense, the user can perform a SLAM (Simultaneous Localization and Mapping) algorithm or have the map known a priori, and therefore execute on them a wide variety of algorithms such as A?, bug algorithm, potential fields, path planning and navigation modules etc. Of course the developer can benefit from the large amount of ROS packages provided by the scientific community. Since STDR is ROS-based, these packages can be employed with minimal effort.
167
AB:How does STDR handle multiple robot simulations? is there methods to achieve coordination/cooperation or swarming behaviours?
The STDR team:STDR simulator does support multi-robot simulation. The developer has to ability to spawn several robots and send commands to their effectors or receive data from their sensors. Of course he/she is free to implement multi-robot communication controllers via ROS infrastructure (messages / services / actionlib).
However, the multi robot support is a germinal feature, that will be further evolved.
In its current state many robots can be simulated, but lack the capacity to physically detect each other, i.e., robots can navigate through each other and one robots sensors fail to sense another robot.
AB:According to you all what does a person needs to know prior to starting ROS?
C++ or some programming background?
The STDR team: It depends on the application. Some programming background is always useful, when you are developing software but it is not necessary for all applications. ROS has several layers of abstraction, thus writing a simple program does not require understanding implementation and design details of lower (infrastructure) layers. Good knowledge of C++ and/or python is definitely a plus. For someone who is not familiar with C++ concepts it would be an uphill battle to master ROS.
FIGURE 5.8 The STDR team, from the left to right: Manos, Chris and Aris from Aristotle University, Greece
AB:What is the future of STDR?
The STDR team:Our next steps would be towards a more realistic simulation of the environment. In that manner, we aim to add a simple physics engine in order to perform collision checking more realistically. Also, we are thinking of a dynamic environment, where robots can perceive each other as moving obstacles or perceive moving obstacles generally, like a moving door. Since STDR is an open source project, its future would be heavily influenced by communitys interest for new features, bug fixes, etc. We should mention that we have already several contributions from the ROS community and we encourage the potential developers to inform us of any problems or even achievements they had using our simulator.
STDR Simulator is currently an official ROS package and can be downloaded via apt-get. The supported ROS distributions are Hydro and Indigo, thus the supported
ROS in Space - The Robonaut 2 (R2) humanoid torso
The Robonaut-2 is a project which developed the first humanoid robot at the International Space Station (ISS), the humanoid robot runs on ROS. The project is a venture of NASA and General Motor, working at the Johnson Space Center, Houston.
The project aims to develop an automated humanoid torso fitted with 2 dexterous arms which can function as an astronaut in space. The advancement that R2 has achieved over other robots is that it can use the same tools that an astronaut uses, there is no need for specialised tools only meant for use by R2. R2 is an advantage where simple, repetitive, or hazardous tasks are needed to be performed in harsh and unfavourable conditions as space stations and non-terrestrial colonies. R2 was delivered to the ISS aboard the shuttle Discovery on the STS-133 mission with the mission spanning across 2 weeks, 24 February 2011 to 9 March 2011. While still on board the Discovery, testing and basic operation started inside the Destiny module. Once at the ISS, it was deployed on a fixed pedestal. The project achieves real time control using ROS and ORCOS in tandem.R2 is the first humanoid robot in space, it has a height of about 1 meter, weighs 132 kg and is made out of nickel-plated carbon fiber and aluminum. It is equipped with 54 servo motors and has 42 degrees of freedom and needs at 120 volts DC.The torso can be fitted with legs to make it into a full humanoid, deployed on a pedestal or fitted on to a four wheeled rover. NASA’s team used gazebo for R2 simulations, ROS packages which they have released to the opensource community.
FIGURE 5.9 The Robonaut 2uses ROS and is employed at the International Space Station (ISS). Shown here is the robot on the left and its gazebo simulation on the right.
169
A tˆ ete-` a-tˆ ete with Daniel Stonier and Marcus Liebhardt from Yujin Robot, Seoul
Yujin Robot is a Seoul based company which developed the Turtlebot-2 with the Kobuki base. Daniel and Marcus from the company’s innovation team share with us the experience of developing these robots and future prospects. This interview took place on 24 Nov 2014.
FIGURE 5.10 Kobuki base and Turtlebot-2, AB:How did Yujin Robot come into being?
DS & ML:More than 20 years ago Yujin Robot started in automation and is now comprised of several small business groups, not all of them directly related to robotics and has also seen a couple of internal teams successfully spin off their own businesses.
The R&D group entered service robotics more than a decade ago and despite being a relative adventurous proposition at the time, the driving force then, and now has been the CEOs passion for building robots.
FIGURE 5.11 iClebo and iRobi,
AB:What all robots have you developed?
robotics and a healthy economic niche, such a market remains a hard sell.
FIGURE 5.12 The GoCart,
AB:Tell us about the Kobuki? Why this name?
DS & ML:‘Kobuk’ is the Korean word for turtle. Adding the suffixed ‘i’ is typical korean syntax when using such nouns in a sentence, but also gives it a more intimate feeling. The why of its origin for our mobile platform is in part shrouded in time. There was no definitive moment in which we had named our robot, but some things are for certain. For a long time we had a cleaning robot based mobile platform in the lab for experiments that we called Kobukibot. Wed also adopted the ROS fascination with turtles ever since the ROS turtle tutorials first came out (some of us can remember a time even before there were such tutorials at one point there was a tutorial for the most perverse, but fun way to add 1+1 using ros services). Korea is also famous for its Turtle ships, an engineering design we can relate to!
AB:Since the Kobuki and TurtleBot 2 are meant to run with ROS, how do you explain ROS to a young enthusiast? Say a 15 year old who is just about learning some C++
and bits and pieces of Java or Python and wants to own a Kobuki.
DS & ML:Kobuki/TurtleBot is a readymade hardware unit. So working with such a platform is all about problem solving, programming and of course, doing these things on a platform which lets you build interesting applications that come to life in a more vivid way than they can on a PC. ROS itself lets you write programs that can talk to
171
each other and the ROS ecosystem provides you with a lot of software that you can reuse and recycle for your own benefit. I think for a budding young developer, these are awesome concepts that can take them far. It teaches how to break down complexity into small chunks and how to integrate efficiently with existing components. Without these skills, a developer wont be able to scale up what he or she can do, nor accelerate at the same pace as developers around them will be able to do. In todays software world, these concepts are often more important than ones proficiency in a particular language.
FIGURE 5.13 The Kobuki/Turtlebot-2 team,from left to right and top to bottom we have: Hyeong Ju Kim, Jorge Santos Simon, Young Hoon Ju, Nosu Lee, Min Jang, Marcus Liebhardt, Sam Park, Jaeyoung Lee, Daniel Stonier and Joohong Lee
and smart electronics will rule our lives, how do you foresee the future of this industry?
and the impact on society?
DS & ML:There is a definite convergence of technologies happening right now. For the first time in decades, we have explosive growth in multiple sectors of the technology world, and the most interesting thing is, almost all of these sectors impact on what can be done in robotics. Smart phones → embedded computation, good cameras, communicativity outside a wireless LAN. Gaming→3d sensing. The internet explosion post the IE5 stranglehold → cloud computing resources, remote connectivity. As a first step, we are seeing reduced costs and the ability to be able to navigate in semi/unstructured environments, now triggering the emergence of mobile robotics in the service industries (outside cleaning robots). For the first time it feels like the heat is on to get new products to market in these industries. However I dont believe these successes can be solely ascribed to the fact that there is a technology convergence.
History shows that technological leaps often fail to penetrate the market. These leaps have to be either hugely significant, or a need arrives. What we have now is a very real and quickly looming crisis of manpower shortage in various industry sectors in the near future, such as health and elderly care. This is dispelling the conservatism in several industries we have hitherto explored and they are now more keen to take a leap of faith. It is into these emerging service robotics applications Yujin Robot is now venturing with products like GoCart. Rather than trying to sell a service, or provide entertainment, we now look to fulfill the automative needs of the service world.
AB:Tell us more about the GoCart project.
DS & ML: A year ago we started the innovation team with the goal of creating Yujin Robots products of tomorrow. The first result of this endeavour is GoCart our autonomous mealtransport system. GoCart is the first robot of our Gopher Series, which combines Yujin Robots various technologies for indoor transportation, such as our new stereovisionbased dSLAM system. GoCart is our contribution to fight the shortage of skilled caretakers and raising costs in health and elderly care. GoCart will take care of moving meals and other supplies around in a facility, such as hospitals and elderly care facilities. Thereby freeing up caretakers time allowing them to spend more time with the residents and patients. With its affordable price GoCart will reduce the overall operating costs of the facility at the same time. More information about GoCart can be found on the web pagehttp://gocart.yujinrobot.com/and additional technology details in our recent blog posthttp://blog.yujinrobot.com/
2014/11/delivering-ros-in-box.html.