During my long experience at Pal Robotics developing humanoid robots, I learned just how much a good simulator can help speed up the development and maintenance processes of robot building. To my surprise, however, I recently discovered that lots of robotics companies don’t use a simulator for this purpose. In this post I’ll share with you the key reasons why you should be using a simulator for your robot development.

1. Test ideas prior to building

Simulations are the best place to start when developing a new robot. By using a simulator to develop your robot, you can quickly identify whether your idea is feasible, with little expense. You can also easily test and discover which are the physical constraints that your robot must face in order to accomplish its goal.

Simulators allow you to easily and quickly test of many different ideas for the same robotic problem, and then decide which one to build based on actual data.

2. Parallelise development

Once your robot has been defined and tested in the simulator, you can start its physical construction. The good thing with simulators is that they allow you to keep doing tests even if your robot is not built yet.

In other words, while your mechanical or electrical departments are building the actual robot, your software department can start developing software and testing it on the simulated robot. Current simulators are closer to reality, so you can develop your software for the simulated robot, make sure it works there, and then transfer the software to the real robot once it has been constructed. Chances are that your software will work with the real robot with only minor mods.

You do not have to wait for your robot to be built before developing its software.

3. Test in different environments

Your robot software could have many bugs that only appear once you take it outside your lab. By using a simulator, you can test your robot in many different environments.

4. Debug in simulation

Your robot software should be debugged first in the simulator. In fact, you should never allow a software engineer to test software on the real robot if the software does not work on the simulator. It won’t work!

Not only does debugging in the simulator save you a lot of time (since testing and correcting basic errors on the real robot is very time consuming), but it also prevents your untested software from breaking your robot!

5. Develop modifications and improvements

With your simulation in place, you can think about modifications for your robot and test them. What is the next feature that your clients are requesting? You can easily test if whether new features are possible, to what extent, and what it would require you to modify and add. Just use the simulation to see if they are possible or not.

6. Functionality testing suite

Once your robot is built and the software is working properly inside it, you will have to maintain it. Correcting bugs, adding new features, adapting to changes in the frameworks you use … all this requires that you update the software that is already running on your robot.

Chances are that some of these changes will crash some of the functionality that already works in the robot. To prevent minimize the damage, you must create a suite of functionality tests.

Functionality tests are tests that execute on a simulation of your robot and check whether the robot is still able to function in the simulation as expected. You can perform these tests at night. The suite must download the latests code from your repository, compile it, and execute it on the simulated robot.

For each functionality, the robot must be placed on a specific situation in the simulation that allows you to test that functionality. A reward function must check whether the robot was able to accomplish the functionality or not. In the case that it cannot, the suit should send an email to the person in charge of that functionality, in order to make that person aware of the functionality crash.

7. Make your robot popular

Whether your company targets a mainstream audience, or a specialized one, you will want your robot to be used. By creating and freely providing a simulation of your robot, you are giving your audience a chance to experiment and find uses for your robot without being tied to an expensive purchase. You can also allow to people publish tools and ideas for your robot on the Internet, which further extends your reach.

Conclusion

Simulators are a powerful tool for robotics companies that can speed up the development process and prevent costly errors.

In a nutshell, follow these steps next time you are doing a robot development:

1. Do some drawings and design the robot you want to build based on the task you are trying to solve.
2. Implement those designs in the simulator and perform some tests.
3. Modify the robot based on the simulator results.
4. Start building the real robot. At the same time use the simulator to develop its software.
5. Test your software on the real robot. If errors are found, use the simulator to correct them and retest. Only use the real robot once errors are corrected.
6. If customers require mods or improvements, use the simulator to test whether they are (theoretically) possible.
7. Once your robot is built (including software), build a functionality test suite that executes functionality tests over the simulation every night to prevent changes in the software from shutting down the robot’s functions.
8. Finally, provide for free a model of your robot (including controllers) and help users to use it!

The Robot Race to Hawaii is a robotics contest where participants program a humanoid Nao robot to run a 10-meter race in the shortest time possible. The whole competition is run in a Webots simulation inside The Construct hosting platform. Participants need only a computer equipped with web browser to participate, and are not required to download any applications. There is no cost to enter.

The competition is simple, making it a good entry point and hands-on exercise for newcomers to robotics. The Construct provides the simulated environment with the robot already in it, as well as a sample controller that participants have the option to use as a starting point for building the walking controller. Because the challenge is hosted in The Construct and stored in the cloud, contestants participate via their web browser and do not need to worry about downloading and installing software.

Teachers, you can use this contest as an assignment for your students, as participants can expect to learn:

• How to code in Python. The controllers of the robots must be written in Python, which is one of the best languages for introducing someone to programming and especially to robotics. A good place to start learning about python is CodeAcademy.
• How a robotics simulator works. The simulator used for the contest is Webots. Participants must learn how this simulator works in order to understand how all the parts interact together (robot simulation, controller, computer, etc). Fortunately, there are nice tutorials to learn about it here.
• How to build models of objects for robot simulators. Throughout the competition, participants will be asked to create simulated models of simple objects, like a chair, a glass or a blackboard, once per week. This will provide them with deeper knowledge of what a simulation means. The same Webots tutorial linked to above contains information about how to create a model.
• The basics of biped walking. Even if the contest provides a sample controller allowing the robot to walk, participants may be interested in applying more complex techniques for robot walking. Learning about how to make a biped walk can help create faster controllers. You can learn about robot walking here or read many of the scientific papers available in the web.

More complex topics such as writing and compiling C++ controllers, using ROS as a robotics framework, or the programming of more complex robot skills like opening doors or grasping a objects have been deliberately left out of this challenge in order to make it suitable for people with minimal knowledge of robotics. STEM high school students and first year robotics students should find the competition accessible.

Participation is open to anyone, however, so expect some pros to enter.

By the way, did I mention that the winner of the contest will get a trip to Hawaii?!?! Register here: contest.theconstructsim.com

Good luck!

The Construct is a Barcelona based startup created to simplify the simulation of robots. The goal is to allow anybody to simulate complex robots and environments with minimal knowledge, without having to install or maintain anything in their computer and without having to build the simulations from scratch.

With The Construct, users run their robot simulations in the cloud, using a web browser so they don’t need to install, configure or store files on their computer. Any WebGL enabled browser will suffice.

Once logged in, users must select which simulator to run. Currently available simulators include Gazebo, Webots and DRC, and more are in the pipeline. All simulators are fully integrated with ROS (it’s not mandatory to use it though).

Users will also find different versions of the same simulator available. This means that they can run a Gazebo 4.0 with ROS Indigo under Ubuntu 14.04, or a Gazebo 1.9 with ROS Hydro under Ubuntu 12.04. It all depends on their needs.

An interesting feature of The Construct is that it allows sharing of simulations, that is, users can work at the same time on the same simulation, each from their own point of view. This feature opens a lot of simulation possibilities, such as collaboration between workmates, worldwide robotics classes in real time or hosting a competition where all the participants share the same interface and resources.

The Construct running on an iPad2 (Nao robot by Aldebaran on Webots)

Since simulations are created and accessed through a web browser, users can utilize any type of computer or device – a Linux, Windows PC or Mac, a tablet or smartphone.

The Construct running on an iPhone4S (Wam arm by Barret on Gazebo)

As the cloud provides high CPU power, it is possible to simulate really big environments, such as a  city, or very complex robots.

The simulation of a city, which includes the sea and an island.

Users can launch their already existing simulations in The Construct  without a problem. It’s fully compatible with desktop simulators, and allows switching from desktop to cloud and vice versa at anytime without losing features in the simulations.

The Construct was an official tool at the 2015 IEEE-RAS Summer School on Experimental Methodology, Performance Evaluation and Benchmarking in Robotics, and it’s developers are currently working with the University of Pisa and the Center Piaggio to build an off-the-shelf grasping simulation system using a soft robotic hand.

Recently, the company participated in the Robot Launch 2015 startup competition, winning the Reader’s pick award and the Siemens Industrial Award. This later award makes The Construct a Frontier Partner of Siemens.

You can see a demo about how to launch your already created simulations in The Construct by visiting this post.

You can also enrol in The Construct for a free account and start running your simulations in the cloud. Just visit us here.

• LiftDragPlugin: This plugin simulates the forces on an object immersed in a fluid and applies the forces to the object’s links directly. In particular, the phenomena of lift and drag are instrumental to underwater and aerodynamic vehicles. You can learn more about this plugin in its own tutorial.
• BuoyancyPlugin: This plugin simulates buoyancy by generating a force opposing gravity exerted on an object immersed in a fluid. Check out this tutorial to learn more about how to use this plugin.

We have also created other resources that might be useful for your simulations:

• Cessna C-172 model: Control surfaces fully adjustable via plugins.
• Submarine models: A set of basic propeller-based submarines with different buoyancy properties.

In the next Gazebo release, we will also make available two different world files containing simple environments for the Cessna and submarine models.

In the videos below you can see a teaser of some of the new Gazebo capabilities. We are excited about these contributions but we are also aware of the various missing features that would make such simulations even better. We are looking forward to integrating your contributions into Gazebo in any possible way: Improve the current plugins, integrate Gazebo with other existing tools, or create awesome environments. Don’t be shy and contribute to Gazebo!

https://youtu.be/iMHGnEhOIhs

By Ilia Baranov

Robots are expensive and they usually depend on batteries. What if you want to run an experiment with 100 robots, running for 10 hours? To help answer this question, ROS has built in support for robot simulation in the form of Gazebo. While this works quite well, it is currently unable to simulate physical properties like batteries, temperature, surface roughness. If your robotics research depends on accurate models, you may want to consider looking at MapleSim® 2015 – a high performance physical modeling and simulation tool developed by Maplesoft.

Below we can see a video of the Grizzly RUV taking an open loop control path around a surface. Elements like current and voltage provided by the batteries, surface slipperiness and weight distribution all play a role in where the Grizzly actually ends up. To see what we’re referring to, watch the quick simulation video below:

https://youtu.be/dnhotIAyYBk

The MapleSim model features a 200 Ah lead-acid battery pack with a nominal voltage of 48 V, similar to the Type B battery pack used in the robot, to provide electrical power to move the vehicle on an uneven terrain. The lead acid battery used in the model is part of MapleSim’s Battery Component Library. The physical behaviors of the battery are described by mathematical expressions curve-fitted based on experiment measurements to provide the accurate battery voltage and state of charge during the operations of the robot.

The interaction forces and moments at the tire-terrain contact points are generated based on a 3D tire model. A 3D mathematical expression is used to describe the terrain surface to allow the tire-terrain contact points to be calculated based on the position of the vehicle. This 3D function is also used to generate the STL graphics of the terrain for animation (see Figure 1).

The model also outputs electric motor torques, speeds, and battery state of charge as shown below:

Setting up the simulation involves using the Grizzly RUV MapleSim model, available at the bottom of this post. The graphical representation is easy to understand and also quick to modify.

Maple and MapleSim provide a testing and analysis environment based on the virtual prototypes of the model. A number of analysis can be performed:

• Virtual testing and analysis: an engineer can easily test the operations of the robot for any design in a virtual environment through simulations in MapleSim. Using Maple, different terrain surface conditions and tire force models to fit different test scenarios can be generated. As an example, the plot below shows different battery energy consumption (state of charge) rates under different terrain conditions.

• Battery optimization: the developed MapleSim model can be coupled with Maple’s powerful optimization toolboxes to determine the optimal battery size and optimize the Battery Management System (BMS) to minimize energy consumption, reduce battery temperature, and increase battery service life.
• Motor sizing: the robot is equipped with four electric motors that are independently controlled to provide wheel torques and steering maneuvers. The seamless integration with Maple will allow the motor sizing optimization to be performed based on MapleSim simulations.
• Chassis design and payload distribution: the virtual prototype of the system will allow engineers to easily vary payload locations and distributions and analyze their effects, e.g., roll-over, stability, controllability, etc., on certain tasks.
• Path planning: Using Maple, different terrain surface conditions and tire force models to fit different test scenarios can be generated for path planning.
• Model-based controller design: the MapleSim model will allow the control strategies to be designed and tested for accuracy before being deployed on a real vehicle.
• Localization and mapping: the high-fidelity dynamic model of the robot will allow state estimation algorithms, such as Kalman filter and other Bayesian-based filtering algorithms, to be performed at a high accuracy.
• Optimized code generation: optimized C code can be generated from the MapleSim model for purpose of implementations of control, localization, and path planning strategies.

See here for more information on simulating the Grizzly in MapleSim.

Using computer graphics and motion simulations, on-screen robots can be quite convincing and similar to the real thing, and researchers sometimes use these to conduct studies about how people interact with these robots. Clearly, simulations have limitations when compared to the real thing; for one, people cannot touch simulated robots. But what about for simpler cases where people just converse with the robot or work together on a mental task? Do people interact with these simulated robots the same as they would a real robot? Would people feel empathy for a simulated robot in the same way as they do for real robots?

We conducted a study to investigate this question, according to the following scenario:

1. A person gets to know an intelligent robot’s personality while collaboratively playing Sudoku
2. The robot gets a virus and acts increasingly strange
3. The robot expresses fear of being reset and losing its memory
4. The robot is erased by the researcher and loses its memory (Poor thing!), and re-introduces itself with a new voice.

This is scenario similar to a common movie cliché, where a protagonist has a friend who is harmed by an unpopular third party (in our case, the researcher). Based on background work in this area, we expected that people would feel sorry for the robot, feel empathy, similar to how they would for an animal or a pet. We validated our study design by comparing it to a case where the robot does not get a virus or get reset, and found that indeed people empathized more with the unfortunate robot that loses its memory.

We did this study twice: once with a real robot, and once with an identical simulated robot: same look, same voice, same actions, and same conversation. We found that people rated their empathy about 10% higher for the real robot than for the simulated one. So, if you are investigating social interactions with your robot, be wary of using simulations – the interaction may not quite be the same as the real thing.

Like any interesting result, our work raises more questions than it answers. Why does this difference exist? Is it as simple as people knowing the difference between real and fake things? Maybe we are used to seeing bad things happen in virtual worlds? Would this difference happen for positive empathy as well? Will this hold for other kinds of robots? What other social interactions are different with simulated robots? Moving forward, our team is continuing to look into these questions!

One final point – looking back, the really hard part of this work was to make a study design that is convincing, believable by the participants, and actually makes people feel sorry for the robot. This was much harder than we expected, and we ended up collaborating with a local artist company, ZenFri Inc.

So – which would you feel more sorry for: a simulated robot, or a real one? If you want to learn more about our process, or any of our results, please check out our paper or visit our project homepage.

Stela H. Seo, Denise Geiskkovitch, Masayuki Nakane, Corey King, James E. Young. “Poor Thing! Would You Feel Sorry for a Simulated Robot? A comparison of empathy toward a physical and a simulated robot,” In proceedings of the 10th ACM/IEEE international conference on Human-Robot Interaction, HRI’2015, Portland, Oregon, USA.

If you liked this article, you may also be interested in:

• Driven by care needs, will it be the booming senior population that spurs wider acceptance of robots?
• Natural language: The de-facto interface convention for social robotics
• Should a care robot bring an alcoholic a drink? It depends on who owns the robot
• Evaluating the effectiveness of robot behaviors in human-robot interactions

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

CloudSim-Ed from OSRF.

During her Gnome Outreach Program for Women internship with OSRF, Ana Marian Pedro worked on CloudSim-Ed a prototype for a massive open online robotics course built with Google CourseBuilder. The course offers simulation tasks and challenges created with CloudSim, Gazebo and ROS.

To enroll in a course, a student must have a Google account and basic CloudSim credentials. CloudSim simulators are controlled from a custom module in CourseBuilder to launch simulation challenges and retrieve the score. When a challenge is launched, the Gazebo simulation world is viewed through a web interface, while an IPython notebook provides the means to interact with the simulated robot using ROS commands.

This project intends to provide students with a means to learn robotics using open source software. For schools with limited robotics laboratory space and equipment, the simulated worlds and environments give students a chance to experiment with minimal setup time and effort. This will hopefully reduce the time used in software troubleshooting when dealing with actual robot hardware.

References:
http://www.ros.org
http://www.gazebosim.org
http://cloudsim.io
https://code.google.com/p/course-builder/

Repositories:
https://bitbucket.org/ammpedro/cloudsim-ed-actuation
https://bitbucket.org/ammpedro/cloudsim-ed-web
https://sunlit-vortex-449.appspot.com/course

If you liked this article, you may also be interested in:

• ROS 101: Intro to the Robot Operating System
• Up and flying with the AR.Drone and ROS: Getting started
• Taking your first steps in robotics with the Thymio II
• Discovering social robotics with the Aisoy1
• Parrot AR.Drone app harnesses crowd power to fast-track vision learning in robotic spacecraft

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

In the previous ROS 101 post, we showed how easy it is to get ROS going inside a virtual machine, publish topics and subscribe to them. If you haven’t had a chance to check the out all the previous ROS 101 tutorials, you may want to do so before we go on. In this post, we’re going to drive a Husky in a virtual environment, and examine how ROS passes topics around.

An updated version of the Learn_ROS disk is available here:

https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS-disk1.vmdk
https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS.ovf

Login (username): user
Password: learn

If you just downloaded the updated version above, please skip the next section. If you have already downloaded it, or are starting from a base install of ROS, please follow the next section.

Updating the Virtual Machine

Open a terminal window (Ctrl + Alt + T), and enter the following:

sudo apt-get update
sudo apt-get install ros-hydro-husky-desktop

Running a virtual Husky

Open a terminal window, and enter:

roslaunch husky_gazebo husky_empty_world.launch

Open another terminal window, and enter:

roslaunch husky_viz view_robot.launch

You should be given two windows, both showing a yellow, rugged robot (the Husky!)

The first window shown is Gazebo. This is where we get a realistic simulation of our robot, including wheel slippage, skidding, and inertia. We can add objects to this simulation, such as the cube above, or even entire maps of real places.

The second window is RViz. This tool allows us to see sensor data from a robot, and give it commands (We’ll talk about how to do this in a future post). RViz is a more simplified simulation in the interest of speed.

We can now command the robot to go forwards. Open a terminal window, and enter:

rostopic pub /husky/cmd_vel geometry_msgs/Twist -r 100 '[0.5,0,0]' '[0,0,0]'

In the above command, we publish to the /husky/cmd_vel topic, of topic type geometry_msgs/Twist, at a rate of 100Hz. The data we publish tells the simulated Husky to go forwards at 0.5m/s, without any rotation. You should see your Husky move forwards. In the gazebo window, you might notice simulated wheel slip, and skidding.

Using rqt_graph

We can also see the structure of how topics are passed around the system. Leave the publishing window running, and open a terminal window. Type in:

rosrun rqt_graph rqt_graph

This command generates a representation of how the nodes and topics running on the current ROS Master are related. You should get something similar to the following:

The highlighted node and arrow show the topic that you are publishing to the simulated Husky. This Husky then goes on to update the gazebo virtual environment, which takes care of movement of the joints (wheels) and the physics of the robot. The rqt_graph command is very handy to use, when you are unsure who is publishing to what in ROS. Once you figure out what topic you are interested in, you can see the content of the topic using rostopic echo.

Using tf

In Ros, tf is a special topic that keeps track of coordinate frames, and how they relate to each other. So, our simulated Husky starts at (0,0,0) in the world coordinate frame. When the Husky moves, it’s own coordinate frame changes. Each wheel has a coordinate frame that tracks how it is rotating, and where it is. Generally, anything on the robot that is not fixed in space, will have a tf describing it. In the rqt_graph section, you can see that the /tf topic is published to and subscribed from by many different nodes.

One intuitive way to see how the tf topic is structured for a robot is to use the view_frames tool provided by ROS. Open a terminal window. Type in:

rosrun tf2_tools view_frames.py

Wait for this to complete, and then type in:

evince frames.pdf

This will bring up the following image.

Here we can see that all four wheel are referenced to the base_link, which is referenced from the base_frootprint. (Toe bone connected to the foot bone, the foot bone….). We also see that the odom topic is driving the reference of the whole robot. This means that if you write to the odom topic (IE, when you publish to the /cmd_vel topic) then the whole robot will move.

Guest talk in the ShanghAI Lectures, 2009-12-17

In this guest lecture, Wenwei Yu from Chiba University, Japan, introduces his approach to assistive technology and talks about (simulation) experiments in human walking and reflexive responses.

The ShanghAI Lectures are a videoconference-based lecture series on Embodied Intelligence, run and organized by Rolf Pfeifer (from 2009 till 2012), Fabio Bonsignorio (since 2013), and me with partners around the world.

https://www.youtube.com/watch?v=FvLVPmBgWUo

The ShanghAI lectures have brought us a treasure trove of guest lectures by experts in robotics. You can find the whole series from 2012 here. Now, we’re bringing you the guest lectures you haven’t yet seen from previous years, starting with the first lectures from 2009 and releasing a new guest lecture every Thursday until all the series are complete. Enjoy!

This simulator can represent the complex pulsation of the heart. It is being developed by a group including members from National Cerebral and Cardiovascular Center and Riken.

Until now, simulating heart pulsation has required huge amounts of computing, done by supercomputers or offline. But this new system makes it possible to visualize heart pulsation on a notebook PC in real time, by applying computer graphics technology.

“Previously, simulation methods were based on mechanics. Our method is completely new because we use technology called shape matching, based on shape constraints. To put it simply, we divide a heart model into 7,000 parts, and make each part contract independently. The main point about this method is that it calculates the shape of the heart overall by minimizing contradictions between the contracted parts.”

“The 3D heart model can be created by extracting regions from a patient’s CT scan. The course of the cardiac muscle fibers has already been designed. The timing of contraction can be specified through this graph. Normally, the atrium contracts first, then the ventricles.”

Because the heart model runs in real time, it’s possible to deform the heart by applying tension, and to observe cross-sections. Additionally, heart attacks can be simulated by stopping the motion and painting a region. This also makes it possible to create virtual heart disease.

“First of all, we’d like to utilize this simulator in clinical practice. Its primary purpose is to help physicians and patients communicate with each other. Another purpose is to help train physicians. We’d also like to use it simply for elementary education.”

The remaining issues that need to be overcome include, reducing the complexity of creating individual patients heart models, as well as finding ways to handle complex patterns such as ventricular fibrillation.