In this episode, Audrow Nash speaks to Steve Macenski, who is the Open Source Robotics Engineering Lead at Samsung Research America. Steve leads the Nav2 project, which is an open source robot navigation framework. In this conversation, they talk about the problem and challenges of robot navigation, how Nav2 works at a high level, hybrid planners, and about Steve’s experience working with the Nav2 community.

Episode Links

• Download the episode
• Nav2’s Website
• Steve’s Website
• Steve’s LinkedIn
• Samsung Research’s Website

Podcast info

• Podcast website
• Apple Podcasts
• Spotify
• Podcast RSS feed
• Full episodes
• Clips

Last week I was talking to one lead engineer of a Singapore company which is building a benchmarking system for robot solutions. Having seen my presentation at ROSCON2016 about robot benchmarking, he asked me how I would benchmark solutions that are non-ROS compatible. I said that I wouldn’t dedicate time to benchmark solutions that are not ROS-based. Instead, I suggested I would use the time to polish the ROS-based benchmarking and suggest that vendors adopt that middleware in their products.

Benchmarks are necessary and they need standards

Benchmarks are necessary to improve any field. By having a benchmark, different solutions to a single problem can be compared and hence a direction for improvement can be traced. Currently, robotics lacks such benchmarking system.

I strongly believe that to create a benchmark for robotics we need a standard at the level of programming.

By having a standard at the level of programming, manufacturers can build their own hardware solutions at will, as long as they are programmable with the programming standard. That is the approach taken by devices that can be plugged into a computer. Manufacturers create the product on their own terms, and then provide a Windows driver that allows any computer in the world (that runs Windows) to communicate with the product. Once this computer-to-product communication is made, you can create programs that compare the same type of devices from different manufacturers for performance, quality, noise, whatever your benchmark is trying to compare.

You see? Different types of devices, different types of hardware. But all of them can be compared through the same benchmarking system that relies on the Windows standard.

Software development for robots also needs standards

The need for standards is not only required for comparing solutions but also to speed robotics development. By having a robotics standard, developers can concentrate on building solutions that do not have to be re-implemented whenever the robot hardware changes. Actually, given the middleware structure, developers can disassociate enough from the hardware that they can almost spend 100% of their time in the software realm, while still developing code for robots.

We need the same type of standard for robotics. We need a kind of operating system that allows us to compare different robotics solutions. We need the Windows of the PCs, the Android of the phones, the CAN of the buses…

A few standard proposals and a winner

But you already know that. I’m not the first one to state this. Actually, many people have already tried to create such a standard. Some examples include Player, ROS, YARP, OROCOS, Urbi, MIRA or JdE Robot, to name a few.

Personally, I actually don’t care which standard is used. It could be ROS, it could be YARP, or it could be any other that still has not been created. The only thing I really care about is that we  adopt a standard as soon as possible.

And it looks like the developers have decided. Robotics developers prefer ROS as their common middleware to program robots.

No other middleware for robotics has had such a large adoption. Some data about it:

	ROS	YARP	OROCOS
Number of Google pages:	243.000	37.000	42.000
Number of citations if the paper describing the middleware:	3.638	463	563
Alexa ranking:	14.118	1.505.000	668.293

Note 1: Only showing the current big three players.

Note 2: Very simple comparison. Difficult to compare in other terms since data is not available.

Note 3: Data measured in August 2017. May vary at the time you are reading this. Links provided on the numbers themselves, so you can check yourself.

This is not only the feeling that we, roboticists, have. The numbers also indicate that ROS is becoming the standard for robotics programming.

Why ROS?

The question is then, why has ROS emerged on top of all the other possible contestants. None of them is worst than ROS in terms of features. Actually you can find some feature in all the other middlewares that outperform ROS. If that is so, why or how has ROS achieved the status of becoming the standard ?

A simple answer from my point of view: excellent learning tutorials and debugging tools.

Here there is a video where Leila Takayama, early developer of ROS, explains when she realized that the key for having ROS used worldwide would be to provide tools that simplify the reuse of ROS code. None of the other projects have such a set of clear and structured tutorials. In addition, few of the other middlewares provide debugging tools for their packages. The lack of these two essential aspects is preventing new people from using their middlewares (even if I understand the developers of OROCOS and YARP for not providing it… who wants to write tutorials or build debugging tools… nobody! ? )

Additionally, it is not only about tutorials and debugging tools. ROS creators also provide a good system of managing packages. The result is that developers worldwide could use others packages in a (relatively) easy way. This created an explosion in ROS packages available, providing off-the-shelf almost anything for your brand new ROSified robot.

Now, the impressive rate at which contributions to the ROS ecosystem are made makes it almost unstoppable in terms of growing.

What about companies?

At the beginning, ROS was mostly used by students at Universities. However, as ROS becomes more mature and the number of packages increases, companies are realizing that adopting ROS is also good for them because they will be able to use code developed by others. On top of that, it will be easier for them to hire new engineers who already know the middleware (otherwise they would need to teach the newcomers their own middleware).

As a result, many companies have jumped onto the ROS train, developing from scratch their products to be ROS compatible. Examples include Robotnik, Fetch Robotics, Savioke, Pal Robotics, Yujin Robots, The Construct, Rapyuta Robotics, Erle Robotics, Shadow Robot or Clearpath, to name a few of the sponsors of the next ROSCON ? . Creating their ROS-compatible products, they decreased their development time by several orders of magnitude.

To bring things further, two Spanish companies have revolutionised the standardization of robotics products using ROS middleware: on one side, Robotnik has created the ROS Components shop. A shop where anyone can buy ROS compatible devices, starting from mobile bases to sensors or actuators. On the other side, Erle Robotics (now Acutronic Robotics) is in the process of developing Hardware ROS. The H-ROS is a standardized software and hardware infrastructure to easily create reusable and reconfigurable robot hardware parts. ROS is enabling hardware standarization too, but this time driven by companies, not research! That must mean something…

Finally, it looks like industrial robot manufacturers have understood the value that a standard can provide to their business. Even if they do not make their industrial robots ROS-enabled from the start, they are adopting ROS Industrial  a flavour of ROS, which allows them to ROSify their industrial robots and re-use all the software created for manipulators in the ROS ecosystem.

But are all companies jumping onto the ROS train? Not all of them!

Some companies like Jibo, Aldebaran or Google still do not rely on ROS for their robot programming. Some of them rely on their own middleware created before the existence of ROS  (that is the case of Aldebaran). Some others, though, are creating their own middleware from scratch. Their reasons: they do not believe ROS is good, they have already created a middleware, or do not want to develop their products dependent on the middleware of others. Those companies have very fair reasons to go their way. However, will that make them competitive? (if we have to judge from history, mobiles, VCRs, the answer may be no).

So is ROS the standard for programming robots?

That question is still too soon to be answered. It looks like it is becoming the standard, but many things can change. It is unlikely that another middleware takes the current title from ROS, but it may happen. There could be a new player that wipes ROS from the map (maybe Google will release its middleware to the public – like they did with Android – and take the sector by storm?).

Still, ROS has its problems, like a lack of security or the instability of some important packages. Even if the OSRF group are working hard to build a better ROS system (for instance ROS2 is in beta phase with many root improvements), some hard work is still required for some basic things (like the ROS controllers for real robots).

Given those numbers, at The Construct we believe that ROS IS THE STANDARD (that is why we are devoted to creating the best ROS learning tutorials of the world). Actually, it was thanks to this standardization that two Barcelona students were able to create an autonomous robot product for coffee shops in only three months with zero knowledge of robotics (see Barista robot).

This is the future, and it is good. In this future, thanks to standards, almost anyone will be able to build, design and program their own robotics product, similar to how PC stores are building computers today.

So my advice, as I said to the Singapore engineer, is to bet on ROS. Right now, it is the best option for a robotics standard.

MATLAB© is a programming language and environment designed for scientific computing. It is one of the best languages for developing robot control algorithms and is widely used in the research community. While it is often thought of as an offline programming language, there are several ways to interface with it to control robotic hardware ‘in the loop’. As part of our own development we surveyed a number of different projects that accomplish this by using a message passing system and we compared the approaches they took. This post focuses on bindings for the following message passing frameworks: LCM, ROS, DDS, and ZeroMQ.

The main motivation for using MATLAB to prototype directly on real hardware is to dramatically accelerate the development cycle by reducing the time it takes to find out out whether an algorithm can withstand ubiquitous real-world problems like noisy and poorly-calibrated sensors, imperfect actuator controls, and unmodeled robot dynamics. Additionally, a workflow that requires researchers to port prototype code to another language before being able to test on real hardware can often lead to weeks or months being lost in chasing down new technical bugs introduceed by the port. Finally, programming in a language like C++ can pose a significant barrier to controls engineers who often have a strong electro-mechanical background but are not as strong in computer science or software engineering.

We have also noticed that over the past few years several other groups in the robotics community also experience these problems and have started to develop ways to control hardware directly from MATLAB.

---

The Need for External Languages

The main limitation when trying to use MATLAB to interface with hardware stems from the fact that its scripting language is fundamentally single threaded. It has been designed to allow non-programmers to do complex math operations without needing to worry about programming concepts like multi-threading or synchronization. However, this poses a problem for real-time control of hardware because all communication is forced to happen synchronously in the main thread. For example, if a control loop runs at 100Hz and it takes a message ~8ms for a round-trip, the main thread ends up wasting 80% of the available time budget waiting for a response without doing any actual work.

A second hurdle is that while MATLAB is very efficient in the execution of math operations, it is not particularly well suited for byte manipulation. This makes it difficult to develop code that can efficiently create and parse binary message formats that the target hardware can understand. Thus, after having the main thread spend its time waiting for and parsing the incoming data, there may not be any time left for performing interesting math operations.

Figure 1. Communications overhead in the main MATLAB thread

Pure MATLAB implementations can work for simple applications, such as interfacing with an Arduino to gather temperature data or blink an LED, but it is not feasible to control complex robotic systems (e.g. a humanoid) at high rates (e.g. 100Hz-1KHz). Fortunately, MATLAB does have the ability to interface with other programming languages that allow users to create background threads that can offload the communications aspect from the main thread.

Figure 2. Communications overhead offloaded to other threads

Out of the box MATLAB provides two interfaces to other languages: MEX for calling C/C++ code, and the Java Interface for calling Java code. There are some differences between the two, but at the end of the day the choice effectively comes down to personal preference. Both provide enough capabilities for developing sophisticated interfaces and have orders of magnitude better performance than required. There are additional interfaces to other languages, but those require additional setup steps.

---

Message Passing Frameworks

Message passing frameworks such as Robot Operating System (ROS) and Lightweight Communication and Marshalling (LCM) have been widely adopted in the robotics research community. At the core they typically consist of two parts: a way to exchange data between processes (e.g. UDP/TCP), as well as a defined binary format for encoding and decoding the messages. They allow systems to be built with distributed components (e.g. processes) that run on different computers, different operating systems, and different programming languages.

The resulting systems are very extensible and provide convenient ways for prototyping. For example, a component communicating with a physical robot can be exchanged with a simulator without affecting the rest of the system. Similarly, a new walking controller could be implemented in MATLAB and communicate with external processes (e.g. robot comms) through the exchange of messages. With ROS and LCM in particular, their flexibility, wide-spread adoption, and support for different languages make them a nice starting point for a MATLAB-hardware interface.

---

Lightweight Communication and Marshalling (LCM)

LCM was developed in 2006 at MIT for their entry to DARPA’s Urban Challenge. In recent years it has become a popular alternative to ROS-messaging, and it was as far as we know the first message passing framework for robotics that supported MATLAB as a core language.

The snippet below shows how the MATLAB code for sending a command message could look like. The code creates a struct-like message, sets desired values, and publishes it on an appropriate channel.

%% MATLAB code for sending an LCM message
% Setup
lc = lcm.lcm.LCM.getSingleton();

% Fill message
cmd = types.command();
cmd.position = [1 2 3];
cmd.velocity = [1 2 3];

% Publish
lc.publish('COMMAND_CHANNEL', cmd);

Interestingly, the backing implementation of these bindings was done in pure Java and did not contain any actual MATLAB code. The exposed interface consisted of two Java classes as well as auto-generated message types.

• The LCM class provides a way to publish messages and subscribe to channels
• The generated Java messages handle the binary encoding and exposed fields that MATLAB can access
• The MessageAggregator class provides a way to receive messages on a background thread and queue them for MATLAB.

Thus, even though the snippet looks similar to MATLAB code, all variables are actually Java objects. For example, the struct-like command type is a Java object that exposes public fields as shown in the snippet below. Users can access them the same way as fields of a standard MATLAB struct (or class properties) resulting in nice syntax. The types are automatically converted according to the type mapping.

/**
 * Java class that behaves like a MATLAB struct
 */
public final class command implements lcm.lcm.LCMEncodable
{
    public double[] position;
    public double[] velocity;
    // etc. ...
}

Receiving messages is done by subscribing an aggregator to one or more channels. The aggregator receives messages from a background thread and stores them in a queue that MATLAB can access in a synchronous manner using aggregator.getNextMessage(). Each message contains the raw bytes as well as some meta data for selecting an appropriate type for decoding.

%% MATLAB code for receiving an LCM message
% Setup
lc = lcm.lcm.LCM.getSingleton();
aggregator = lcm.lcm.MessageAggregator();
lc.subscribe('FEEDBACK_CHANNEL', aggregator);

% Continuously check for new messages
timeoutMs = 1000;
while true

    % Receive raw message
    msg = aggregator.getNextMessage(timeoutMs);

    % Ignore timeouts
    if ~isempty(msg)

        % Select message type based on channel name
        if strcmp('FEEDBACK_CHANNEL', char(msg.channel))

            % Decode raw bytes to a usable type
            fbk = types.feedback(msg.data);

            % Use data
            position = fbk.position;
            velocity = fbk.velocity;

        end

    end
end

The snippet below shows a simplified version of the backing Java code for the aggregator class. Since Java is limited to a single return argument, the getNextMessage call returns a Java type that contains the received bytes as well as meta data to identify the type, i.e., the source channel name.

/**
 * Java class for receiving messages in the background
 */
public class MessageAggregator implements LCMSubscriber {

    /**
     * Value type that combines multiple return arguments
     */
    public static class Message {

        final public byte[] data; // raw bytes
        final public String channel; // source channel name

        public Message(String channel_, byte[] data_) {
            data = data_;
            channel = channel_;
        }
    }

    /**
     * Method that gets called from MATLAB to receive new messages
     */
    public synchronized Message getNextMessage(long timeout_ms) {

		if (!messages.isEmpty()) {
		    return messages.removeFirst();
        }

        if (timeout_ms == 0) { // non-blocking
            return null;
        }

        // Wait for new message until timeout ...
    }

}

Note that the getNextMessage method requires a timeout argument. In general it is important for blocking Java methods to have a timeout in order to prevent the main thread from getting stuck permanently. Being in a Java call prohibits users from aborting the execution (ctrl-c), so timeouts should be reasonably short, i.e., in the low seconds. Otherwise this could cause the UI to become unresponsive and users may be forced to close MATLAB without being able to save their workspace. Passing in a timeout of zero serves as a non-blocking interface that immediately returns empty if no messages are available. This is often useful for working with multiple aggregators or for integrating asynchronous messages with unknown timing, such as user input.

Overall, we thought that this was a well thought out API and a great example for a minimum viable interface that works well in practice. By receiving messages on a background thread and by moving the encoding and decoding steps to the Java language, the main thread is able to spend most of its time on actually working with the data. Its minimalistic implementation is comparatively simple and we would recommend it as a starting point for developing similar interfaces.

Some minor points for improvement that we found were:

• The decoding step fbk = types.feedback(msg.data) forces two unnecessary translations due to msg.data being a byte[], which automatically gets converted to and from int8. This could result in a noticeable performance hit when receiving larger messages (e.g. images) and could be avoided by adding an overload that accepts a non-primitive type that does not get translated, e.g., fbk = types.feedback(msg).
• The Java classes did not implement Serializable, which could become bothersome when trying to save the workspace.
• We would prefer to select the decoding type during the subscription step, e.g., lc.subscribe(‘FEEDBACK_CHANNEL’, aggregator, ‘types.feedback’), rather than requiring users to instantiate the type manually. This would clean up the parsing code a bit and allow for a less confusing error message if types are missing.

---

Robot Operating System (ROS)

ROS is by far the most widespread messaging framework in the robotics research community and has been officially supported by Mathworks’ Robotics System Toolbox since 2014. While the Simulink code generation uses ROS C++, the MATLAB implementation is built on the less common RosJava.

The API was designed such that each topic requires dedicated publishers and subscribers, which is different from LCM where each subscriber may listen to multiple channels/topics. While this may result in potentially more subscribers, the specification of the expected type at initialization removes much of the boiler plate code necessary for dealing with message types.

%% MATLAB code for publishing a ROS message
% Setup Publisher
chatpub = rospublisher('/chatter', 'std_msgs/String');

% Fill message
msg = rosmessage(chatpub);
msg.Data = 'Some test string';

% Publish
chatpub.send(msg);

Subscribers support three different styles to access messages: blocking calls, non-blocking calls, and callbacks.

%% MATLAB code for receiving a ROS message
% Setup Subscriber
laser = rossubscriber('/scan');

% (1) Blocking receive
scan = laser.receive(1); % timeout [s]

% (2) Non-blocking latest message (may not be new)
scan = laser.LatestMessage;

% (3) Callback
callback = @(msg) disp(msg);
subscriber = rossubscriber('/scan', @callback);

Contrary to LCM, all objects that are visible to users are actually MATLAB classes. Even though the implementation is using Java underneath, all exposed functionality is wrapped in MATLAB classes that hide all Java calls. For example, each message type is associated with a generated wrapper class. The code below shows a simplified example of a wrapper for a message that has a Name property.

%% MATLAB code for wrapping a Java message type
classdef WrappedMessage

    properties (Access = protected)
        % The underlying Java message object (hidden from user)
        JavaMessage
    end

    methods

        function name = get.Name(obj)
            % value = msg.Name;
            name = char(obj.JavaMessage.getName);
        end

        function set.Name(obj, name)
            % msg.Name = value;
            validateattributes(name, {'char'}, {}, 'WrappedMessage', 'Name');
            obj.JavaMessage.setName(name); % Forward to Java method
        end

        function out = doSomething(obj)
            % msg.doSomething() and doSomething(msg)
            try
                out = obj.JavaMessage.doSomething(); % Forward to Java method
            catch javaException
                throw(WrappedException(javaException)); % Hide Java exception
            end
        end

    end
end

Due to the implementation being closed-source, we were only able to look at the public toolbox files as well as the compiled Java bytecode. As far as we could tell they built a small Java library that wrapped RosJava functionality in order to provide an interface that is easier to call from MATLAB. Most of the actual logic seemed to be implemented in MATLAB code, but we also found several calls to various Java libraries for problems that would have been difficult to implement in pure MATLAB, e.g., listing networking interfaces or doing in-memory decompression of images.

Overall, we found that the ROS support toolbox looked very nice and was a great example of how seamless external languages could be integrated with MATLAB. We also really liked that they offered a way to load log files (rosbags).

One concern we had was that there did not seem to be a simple non-blocking way to check for new messages, e.g., a hasNewMessage() method or functionality equivalent to LCM’s getNextMessage(0). We often found this useful for applications that combined data from multiple topics that arrived at different rates (e.g. sensor feedback and joystick input events). We checked whether this behavior could be emulated by specifying a very small timeout in the receive method (shown in the snippet below), but any value below 0.1s seemed to never successfully return.

---

Data Distribution Service (DDS)

In 2014 Mathworks also added a support package for DDS, which is the messaging middleware that ROS 2.0 is based on. It supports MATLAB and Simulink, as
well as code generation. Unfortunately, we did not have all the requirements to get it setup, and we could not find much information about the underlying implementation. After looking at some of the intro videos, we believe that the resulting code should look as follows.

%% MATLAB code for sending and receiving DDS messages
% Setup
DDS.import('ShapeType.idl','matlab');
dp = DDS.DomainParticipant

% Create message
myTopic = ShapeType;
myTopic.x = int32(23);
myTopic.y = int32(35);

% Send Message
dp.addWriter('ShapeType', 'Square');
dp.write(myTopic);

% Receive message
dp.addReader('ShapeType', 'Square');
readTopic = dp.read();

---

ZeroMQ

ZeroMQ is another asynchonous messaging library that is popular for building distributed systems. It only handles the messaging aspect, so users need to supply their own wire format. ZeroMQ-matlab is a MATLAB interface to ZeroMQ that was developed at UPenn between 2013-2015. We were not able to find much documentation, but as far as we could tell the resulting code should look similar to following snippet.

%% MATLAB code for sending and receiving ZeroMQ data
% Setup
subscriber = zmq( 'subscribe', 'tcp', '127.0.0.1', 43210 );
publisher = zmq( 'publish', 'tcp', 43210 );

% Publish data
bytes = uint8(rand(100,1));
nbytes = zmq( 'send', publisher, bytes );

% Receive data
receiver = zmq('poll', 1000); // polls for next message
[recv_data, has_more] = zmq( 'receive', receiver );

disp(char(recv_data));

It was implemented as a single MEX function that selects appropriate sub-functions based on a string argument. State was maintained by using socket IDs that were passed in by the user at every call. The code below shows a simplified snippet of the send action.

// Parsing the selected ZeroMQ action behind the MEX barrier
// Grab command String
if ( !(command = mxArrayToString(prhs[0])) )
	mexErrMsgTxt("Could not read command string. (1st argument)");

// Match command String with desired action (e.g. 'send')
if (strcasecmp(command, "send") == 0){
	// ... (argument validation)

	// retrieve arguments
	socket_id = *( (uint8_t*)mxGetData(prhs[1]) );
	size_t n_el = mxGetNumberOfElements(prhs[2]);
	size_t el_sz = mxGetElementSize(prhs[2]);
	size_t msglen = n_el*el_sz;

	// send data
	void* msg = (void*)mxGetData(prhs[2]);
	int nbytes = zmq_send( sockets[ socket_id ], msg, msglen, 0 );

	// ... check outcome and return
}
// ... other actions

---

Other Frameworks

Below is a list of APIs to other frameworks that we looked at but could not cover in more detail.

Project	Notes
RabbitMQ-Matlab-Client	Simple Java wrapper for RabbitMQ with callbacks into MATLAB
URBI (tutorial)	Seems to be deprecated

Lecturer Steffen Pfiffner of University of Weingarten in Germany is teaching ROS to 26 students at the same time at a very fast pace. His students, all of them within the Master on Computer Science of University of Weingarten, use only a web browser. They connect to a web page containing the lessons, a ROS development environment and several ROS based simulated robots. Using the browser, Pfiffner and his colleague Benjamin Stähle, are able to teach how to program with ROS quickly and to many students. This is what Robot Ignite Academy is made for.

“With Ignite Academy our students can jump right into ROS without all the hardware and software setup problems. And the best: they can do this from everywhere,” says Pfiffner.

Robot Ignite Academy provides a web service which contains the teaching material in text and video format, the simulations of several ROS based robots that the students must learn to program, and the development environment required to build ROS programs and test them on the simulated robot.

Student’s point of view

Students bring their own laptops to the class and connect to the online platform. From that moment, their laptop becomes a ROS development machine, ready to develop programs for many simulated real robots.

The Academy provides the text, the videos and the examples that the student has to follow. Then, the student creates her own ROS program and makes the robot perform a specific action. The student develops the ROS programs as if she is in a typical ROS development computer.

The main advantage is that students can use a Windows, Linux or Mac machine to learn ROS. They don’t even have to install ROS in their computers. The only prerequisite of the laptop is to have a browser. So students do not mess with all the installation problems that frustrate them (and the teachers!), especially when they are starting.

After class, students can continue with their learning at home, library or even the beach if there is a wifi available! All their code, learning material and simulations are stored online so they can access them from anywhere, anytime using any computer.

Teacher’s point of view

The advantage of using the platform is not only for the students but also for the teachers. Teachers do not have to create the material and maintain it. They do not have to prepare the simulations or work on multiple different computers. They don’t even have to prepare the exams!! (which are already provided by the platform).

So what are the teachers for?

By making use of the provided material, the teacher can concentrate on guiding the students by explaining the most confusing parts, answer questions, suggest modifications according to the level of each student, and adapt the pace to the different types of students.

This new method of teaching ROS is exploding among the Universities and High Schools that want to provide the latest and most practical teachings to their students. The method, developed by Robot Ignite Academy, combines a new way of teaching based on practice and an online learning platform. Those two points combined make the teaching of ROS a smooth experience and can potentially see the students’ knowledge base skyrocket.

As user Walace Rosa indicates in his video comment about Robot Ignite Academy:

It is a game changer [in] teaching ROS!

The method is becoming very popular in the robotics circuits too, and many teachers are using it for younger students. For example, High School Mundet in Barcelona is using it to teach ROS to 15 years old students.

Additionally, the academy provides a free online certification exam with different levels of knowledge certification. Many Universities are using this exam to certify that their students did learn the material since the exam is quite demanding.

Some examples of past events

•  1 week ROS course in Barcelona for SMART-E project team members. This is a private course given by Robot Ignite Academy at Barcelona for 15 members of the SMART-E project that need to be up to speed with ROS fast. From 8th to 12nd of May 2017
•  1 day ROS course for the Col·legi d’Enginyers de Barcelona. The 17th of May 2017.
•  3 months course for University of La Salle in Barcelona within the Master on Automatics, Domotics and Robotics. From 10th of May to 29th of June 2017.
•  1 weekend ROS course for teenagers in Bilbao, Spain. The 20th and 21st of May 2017.
•  We can also organize a special event like these for you and your team.

Helpful ROS videos

Would you like to make a robot to grasp something, but you think that is impossible to you just because you can’t buy a robot arm? I’m here to tell that you can definitely achieve this without buying a real robot. Let’s see how:

How is that possible?

The Smart Grasping Sandbox built by Shadow Robotics is now available for everybody on the ROS Development Studio – a system that allows you to create and test your robot programs through simulations using only a web browser.

Wait, what is the Smart Grasping Sandbox?

The Smart Grasping Sandbox is a public simulation for the Shadow’s Smart Grasping System with theUR10 robot from Universal Robots. It allows you to make a robot to grasp something without having to learn everything related to Machine Learning, and being available on the ROS Development Studio, it allows you to test it without the hassle of installing all the requirements.

As Ugo Cupcic said:

I don’t want to have to specify every aspect of a problem — I’d rather the system learn the best way to approach a given problem itself.

Using the Development Environment for Grasping

In order to user the Smart Grasping Sandbox on ROS Development Studio—also known as RDS—just go to http://rds.theconstructsim.com and Sign In. Once logged in, go to the Public Simulations, select the Smart Grasping Sandbox simulation and press the red Launch this simulation button.

After pressing the Launch this simulation, a new screen will appears asking you to select the launch file. Just keep the default main.launch and press the red run button.

After a few seconds, the simulation will be loaded and you will be able interact with the simulation.

Once the simulation is loaded, you can see the instructions about how to control it on the left side.

In the center you have the simulation itself, and on the right side you can see the Integrated Development Environment and the Web Shell that allows you to modify the code and send Linuxcommands to the simulation respectively.

You can modify, the simulation, the control programs or even create your own manipulation control programs, make the grasping system learn using deep learning or else. This is up to you as developer!

You can also see what the robot sees using the online ROS 3D Visualizer (RViz) typing the following command on the Web Shell:

$ rosrun rviz rviz

After running Rviz, you press the red Open ROS Graphic Tools button on the bottom left side of the system and a new tab should appear with Rviz.

Conclusion

Here we have seen how to use a simulation to programme a robot to grasp something.

The simulation uses ROS as the middleware to control the robot.

If you want to learn ROS or master your ROS Skills, we recommend you to give a try to Robot Ignite Academy.

If you are a robot builder and want to have your own simulation available for everybody on RDS, or you want to have a course specifically for your robot, contact us through the email info@theconstructsim.com.

Imagine how easy it would be to learn skating, if only it doesn’t hurt everytime you fall. Unfortunately, we, humans,  don’t have that option. Robots, however, can now “learn” their skills on a simulation platform without being afraid of crashing into a wall. Yes, “it learns“! This is possible with the reinforcement learning algorithms provided by OpenAI Gym and the ROS Development Studio.

You can now train your robot to navigate through an environment filled with obstacles just based on the sensor inputs, with the help of OpenAI Gym. In April 2016, OpenAI introduced “Gym”, a platform for developing and comparing reinforcement learning algorithms. Reinforcement learning is an area of machine learning that allows an intelligent agent (for example, robot) to learn the best behaviors in an environment by trial-and-error. The agent takes actions in an environment so as to maximize its rewards. We have deployed the gym_gazebo package from Erle Robotics. in the ROS Development Studio. It enables the users to test their reinforcement learning for their robots in Gazebo.

How to Train your Robot

Robot training to navigate through an environment with obstacles

In this example we will be seeing how a turtlebot is able to learn navigating through an environment without hitting an obstacle. The turtlebot will use a reinforcement learning method known as Q-learning.

There are four environments already available for the user to test their simulations with. These environments can be launched using the respective launch files:

• GazeboCircuitTurtlebotLidar_v0.launch
• GazeboCircuit2TurtlebotLidar_v0.launch
• GazeboRoundTurtlebotLidar_v0.launch
• GazeboMazeTurtlebotLidar_v0.launch

The images of the different environments are given below:

The various environments already available:

Circuit	Circuit2
Round	Maze

The user is requested to try out the existing environment before developing their own environments for training the robot. An environment is where the robot’s possible actions and rewards are defined. For example, in the available environments, there are three possible actions for the Turtlebot robot:

– Forward ( with a reward of 5 points)
– Left ( with a reward of 1 point)
– Right ( with a reward of 1 point)

If it collides into the walls, then the training episode ends (with a penalty of 200 points). The turtlebot has to learn to navigate through the environment, based on the rewards obtained from different episodes. This can be achieved using the Q-learning algorithm. Let us see, how it can be done using the ROS Development Studio.

Using the ROS Development Studio for training the robot

First, we have to set the path in the jupyter-notebook as given below:

import sys
sys.path.append("/usr/local/lib/python2.7/dist-packages/")
sys.path.append("/home/ubuntu/gym-gazebo")
sys.path.append("/home/user/catkin_ws/src/gym_construct/src")
%matplotlib inline


The python scripts in the folder gym_construct/src/ help us simulate the reinforcement learning techniques for a Turtlebot. Currently, the number of episodes has been set to 20.
Feel free to increase the number of episodes in the python scripts (usually up to 5000) to actually train the robot to navigate the environment completely.Run the  only the script corresponding to the environment:

Run the python corresponding to the environment:

## Circuit-2 Environment --> Q-learning
%run /home/user/catkin_ws/src/gym_construct/src/circuit2_turtlebot_lidar_qlearn.py


The robot undergoes several training episodes and each of these episodes are rewarded based on the number of steps taken by the robot before hitting the environment. We will be able to see that the robot incrementally increases its rewards over time compared to its previous versions. With a very large number of episodes, the robot will learn to navigate the environment without hitting the obstacle.

Plotting the learning curve of the robot

The machine learning algorithm generates the output files in the output directory specified in the python script file. In order to plot the curve, we run the display_plot.py. But before that, don’t forget to restart the kernel and set the path once again.

As the number of episodes increases, we will see that the robot’s mean rewards also increases. The user can choose his own robot, environments, action and rewards for testing his reinforcement learning algorithms in OpenAI Gym and RDS. Watch the video below for more on this.

Video describing the procedure to run OpenAI Gym on RDS

I hope you were able to follow the tutorial.  So, that’s all folks. It’s now up to you to develop and test reinforcement learning algorithms in OpenAI Gym and RDS.

Have fun training your robot!

A new book by Lentin Joseph, ROS Robotics Programming, outlines more than 14 robotics projects using ROS that can be engaged with without requiring a lot of hardware. The book starts with an introduction to ROS and its installation procedure. After discussing the basics, you’ll be taken through great projects such as building a self-driving car, an autonomous mobile robot, and image recognition using deep learning and ROS. You can find ROS robotic applications for beginner, intermediate, and expert levels inside.

This book is unique in that it focuses on ROS via the lens of robotics projects only. Lentin is the CEO/Founder of Qbotics Labs and the author of Learning Robotics using Python and Mastering ROS for Robotics Programming.

Below is an overview of the chapters in the book:

Chapter 1, Getting Started with ROS Robotics Application Development, is for absolute beginners to ROS. No need to worry if you don’t have experience in ROS; this chapter will help you give you an idea of the ROS software framework and its concepts.

Chapter 2, Face Detection and Tracking Using ROS, OpenCV and Dynamixel Servos, takes you through a cool project that you can do with ROS and the OpenCV library. This project basically creates a face tracker application in which your face will be tracked in such a way that the camera will always train on your face. We will use intelligent servos such as Dynamixel to rotate the robot on its axis.

Chapter 3, Building a Siri-Like Chatbot in ROS, is for those of you who want to make your robot interactive and intelligent without much hassle. This project creates a chatterbot in ROS that you can communicate with using text or speech. This project will be useful if you’re going to create social or service robots.

Chapter 4, Controlling Embedded Boards Using ROS, helps you build a robot using Arduino, an embedded compatible board, Raspberry Pi, or Odroid and an interface to ROS. In this chapter, you will see a wide variety of embedded boards and the interfacing projects made with them.

Chapter 5, Teleoperate a Robot Using Hand Gestures, will teach you how to build a gesture control device using Arduino and IMU. The gestures are translated into motion commands by ROS nodes.

Chapter 6, Object Detection and Recognition, has an interesting project for detecting objects. You will learn both 2D and 3D object recognition using powerful ROS packages.

Chapter 7, Deep Learning Using ROS and TensorFlow, is a project made using a trending technology in robotics. Using the TensorFlow library and ROS, we can implement interesting deep-learning applications. You can implement image recognition using deep learning, and an application using SVM can be found in this chapter.

Chapter 8, ROS on MATLAB and Android, is intended for building robot applications using ROS, Matlab, and Android.

Chapter 9, Building an Autonomous Mobile Robot, is about creating an autonomous mobile robot with the help of ROS. You can see how to use packages such as navigation, gmapping, and AMCL to make a mobile robot autonomous.

Chapter 10, Creating a Self-driving Car Using ROS, is one of the more interesting projects in this book. In this chapter, we will build a simulation of the self-driving car using ROS and Gazebo.

Chapter 11, Teleoperating Robot Using VR Headset and Leap Motion, shows you how to control a robot’s actions using a VR headset and Leap Motion sensor. You can play around with virtual reality (a trending technology these days).

Chapter 12, Controlling Your Robots over the Web, we will see how to build interactive web applications using rosbridge in ROS.

The book uses ROS Kinetic and Indigo installed on latest Ubuntu L.T.S 16.04.01. The codes are also compatible with ROS Jade.

A basic knowledge in R.O.S, GNU/Linux, and C++ programming concepts is recommended.

The book is published by PACKT and can be purchased at Amazon Global and PACKT Publishing.

You probably know the Sphero robot. It is a small robot with the shape of a ball. In case that you have one, you must know that it is possible to control it using ROS, by installing in your computer the Sphero ROS packages developed by Melonee Wise and connecting to the robot using the bluetooth of the computer.

Now, you can use the ROS Development Studio to create ROS control programs for that robot, testing as you go by using the integrated simulation.

The ROS Development Studio (RDS) provides off-the-shelf a simulation of Sphero with a maze environment. The simulation provides the same interface as the ROS module created by Melonee, so you can test your develop and test the programs on the environment, and once working properly, transfer it to the real robot.

We created the simulation to teach ROS to the students of the Robot Ignite Academy. They have to learn ROS enough to make the Sphero get out of the maze by using odometry and IMU.

Using the simulation

To use the Sphero simulation on RDS go to rds.theconstructsim.com and sign in. If you select the Public simulations, you will quickly identify the Sphero simulation.

Press the red Play button. A new screen will appear giving you details about the simulation and asking you which launch file you want to launch. The main.launch selected by default is the correct one, so just press Run.

After a few seconds the simulation will appear together with the development environment for creating the programs for Sphero and testing them.

On the left hand side you have a notebook containing information about the robot and how to program it with ROS. This notebook contains just some examples, but it can be completed and/or modified at your will. As you can see it is an iPython notebook and follows its standard. So it is up to you to modify it, add new information or else. Remember that any change you do to the notebook will be saved in a simulation in your private area of RDS, so you can come back later and launch it with your modifications.

You must know that the code included in the notebook is directly executable by selecting the cell of the code (do a single click on it) and pressing the small play button at the top of the notebook. This means that, once you press that button, the code will be executed and start controlling the Sphero simulated robot for a few time-steps (remember to have the simulation activated (Play button of the simulation activated) to see the robot move).

On the center area, you can see the IDE. It is the development environment for developing the code. You can browse there all the packages related to the simulation or any other packages that you may create.

On the right hand side, you can see the simulation and beneath it, the shell. The simulation shows the Sphero robot as well as the environment of the maze. On the shell, you can issue commands in the computer that contains the simulation of the robot. For instance, you can use the shell to launch the keyboard controller and move the Sphero around. Try typing the following:

• $ roslaunch sphero_gazebo keyboard_teleop.launch

Now you must be able to move the robot around the maze by pressing some keys of the keyboard (instructions provided on the screen).

You can also launch there Rviz, and then watch the robot, the frames and any other additional information you may want of the robot. Type the following:

• $ rosrun rviz rviz

Then press the Screen red icon located at the bottom-left of the screen (named the graphical tools). A new tab should appear, showing how the Rviz is loading. After a while, you can configure the Rviz to show the information you desire.

There are many ways you can configure the screen to provide more focus to what interests you the most.

To end this post, I would like to indicate that you can download the simulation to your computer at any time, by doing right-click on the directories and selecting Download. You can also clone the The Construct simulations repository to download it (among other simulations available).

If you liked this tutorial, you may also enjoy these:

• UgCS photogrammetry technique for UAV land surveying missions
• Programming for robotics: Introduction to ROS
• Python programming your NAO robot
• Robotics, maths, python: A fledgling computer scientist’s guide to inverse kinematics
• 3-D printing hydraulically-powered robots, no assembly required

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

This handy video-tutorial course gives an introduction to the Robot Operating System (ROS), including many of the available tools that are commonly used in robotics. With the help of different examples, the tutorials offer a great starting point to learn programming robots. You will learn how to create software including simulation, to interface sensors and actuators, and to integrate control algorithms.

The course consists of a guided tutorial and exercises with increasing level of difficulty working with an autonomous robot. We provide recordings of the lectures and give an introduction to the exercises. From the course website, you can download all the material including exercise sheets and templates, and use the provided Virtual Machine (VM) image to start programming right away.

Objectives:

• ROS architecture: Master nodes, topics, messages, services, parameters and actions
• Console commands: Navigating and analyzing the ROS system and the catkin workspace
• Creating ROS packages: Structure, launch-files, and best practices
• ROS C++ client library (roscpp): Creating your own ROS C++ programs
• Simulating with ROS: Gazebo simulator, robot models (URDF) and simulation environments (SDF)
• Working with visualizations (RViz) and user interface tools (rqt)
• Inside ROS: TF transformation system, time, bags

Course 1:

Course 2:

Course 3:

Course 4:

Download the full presentation here.

P. Fankhauser, D. Jud, M. Wermelinger, M. Hutter, “Programming for Robotics – Introduction to ROS”, ETH Zurich, 2017. DOI: 10.13140/RG.2.2.14140.44161

If you liked this tutorial, you may also enjoy these:

• Python programming your NAO robot
• Robotics, maths, python: A fledgling computer scientist’s guide to inverse kinematics
• Sticky business: Five adhesives tested for 3D printing
• Adjust how you learn and quickly pick up robotics programming
• 3-D printing hydraulically-powered robots, no assembly required

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

Clearpath Robotics, a leading provider of mobile robotic platforms for research and development, has partnered with ARGO XTR to release Warthog – a large, amphibious, all-terrain mobile robot designed for application development. Warthog enables researchers to reliably test, validate, and advance their robotics research faster than ever before in real-world conditions, whether on land or in water.

“ARGO XTR (Xtreme Terrain Robotics) has a terrific record of manufacturing rock-solid outdoor platforms,” says Julian Ware, General Manager for Research Solutions at Clearpath Robotics. “Combined with our expertise in robotics, we’ve developed rugged platform suitable for a wide range of robotics applications in mining, agriculture, forestry, space, and environmental monitoring.”

Warthog’s light-weight aluminum chassis, low ground pressure, passive suspension system, and 24” traction tires allow it to easily traverse a variety of tough terrains including soft soils, thick muds and steep grades, all while carrying up to 272 kg of payload.    With built-in bilge pumps and an IP rating of 67, Warthog is fully weather-proof and amphibious, capable of moving through deep waterways at up to 4 km/h, or travel at speeds of up to 18 km/h while on land. The all-electric, skid steer platform has expandable power allowing for a runtime of 6 hrs and can be outfitted with quad tracks for ultimate traction and maneuverability in snow and sand.

“ARGO XTR is excited to partner with a progressive robotics company like Clearpath with our platform,” says Jason Scheib, ARGO XTR Robotics Program Director.  “The combination of our proven experience in amphibious and extreme terrain environments with our platforms with the progressive software and sensor integration from Clearpath Robotics, has created a second to none solution for a myriad of research and commercial applications.”

Designed for end-to-end integration and customization, Warthog includes an internal computer, IMU, wheel encoders, and mounting racks, as well as accessible user power and communication ports for integrating sensors, manipulators, and other third-party hardware.   Warthog is shipped with the Robot Operating System (ROS) preconfigured and a Gazebo simulation model, allowing researchers to get started quickly with existing research and widely available open-source ROS libraries.

Click here for more information.

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

• Interview: International Ground Vehicle Ground Competition (IGVC) winner on “Bigfoot 2” Husky UGV
• 4 reasons why Industry 4.0 will leave AGVs behind
• 5 innovation challenges in materials transport
• Clearpath and Christie demo 3D video game with robots

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

Michael Aeberhard: Automated Driving with ROS at BMW. Source: OSRF Blog

ROSCon is an annual conference focused on ROS, the Robot Operating System. Every year, hundreds of ROS developers of all skill levels and backgrounds, from industry to academia, come together to teach, learn, and show off their latest projects.

Here is the next set of posts from the OSRF blog, along with videos.

Amit Moran (Intel): Introducing ROS-RealSense: 3D Empowered Robotics Innovation Platform

While Intel is best known for making computer processors, the company is also interested in how people interact with all of the computing devices that have Intel inside. In other words, Intel makes brains, but they need senses to enable those brains to understand the world around them. Intel has developed two very small and very cheap 3D cameras (one long range and one short range) called RealSense, with the initial intent of putting them into devices like laptops and tablets for applications such as facial recognition and gesture tracking.

Robots are also in dire need of capable and affordable 3D sensors for navigation and object recognition, and fortunately, Intel understands this, and they’ve created the RealSense Robotics Innovation Program to help drive innovation using their hardware. Intel itself isn’t a robotics company, but as Amit explains in his ROSCon talk, they want to be a part of the robotics future, which is why they prioritized ROS integration for their RealSense cameras.

A RealSense ROS package has been available since 2015, and Intel has been listening to feedback from roboticists and steadily adding more features. The package provides access to the RealSense camera data (RGB, depth, IR, and point cloud), and will eventually include basic computer vision functions (including plane analysis and blob detection) as well as more advanced functions like skeleton tracking, object recognition, and localization and mapping tools.

Intel RealSense 3D camera developer kits are available now, and you can order one for as little as $99.

Michael Aeberhard (BMW): Automated Driving with ROS at BMW

BMW has been working on automated driving for the last decade, steadily implementing more advanced features ranging from emergency stop assistance and autonomous highway driving to fully automated valet parking and 360° collision avoidance. Several of these projects were presented at the 2015 Consumer Electronics Show, and as it turns out, the cars were running ROS for both environment detection and planning.

BMW, being BMW, has no problem getting new research hardware. Their latest development platform is the 335I G. This model comes with an advanced driver assistance system based around cameras and radar. The car has been outfitted with four low-profile laser scanners and one long-range radar, but otherwise, it’s pretty close (in terms of hardware) to what’s available in production BMWs.

Why did BMW choose to move from their internally developed software architecture to ROS? Michael explains how ROS’ reputation in the robotics research community prompted his team to give it a try, and they were impressed with its open source nature, distributed architecture, existing selection of software packages, as well as its helpful community. “A large user base means stability and reliability,” Michael says, “because somebody else probably already solved the problem you’re having.” Additionally, using ROS rather than a commercial software platform makes it much easier for BMW to cooperate with universities and research institutions.

Michael discusses the ROS software architecture that BMW is using to do its autonomous car development, and shows how the software interprets the sensor data to identify obstacles and lane markings and do localization and trajectory planning to enable full highway autonomy, based on a combination of lane keeping and dynamic cruise control. BMW also created their own suite of RQT and rviz plugins specifically designed for autonomous vehicle development.

After about two years of experience with ROS, BMW likes a lot of things about it, but Michael and his team do have some constructive criticisms: message transport needs more work (although ROS 2 should help with this), managing configurations for different robots is problematic, and it’s difficult to enforce compliance with industry standards like ISO.

Jerry Towler (SwRI): Mapviz – An Extensible 2D Visualization Tool for Automated Vehicles

ROS already comes with a fantastic built-in visualization tool called rviz, so why would you want to use anything else? At Southwest Research Institute, Jerry Towler explains how they’ve created a new visualization tool called Mapviz that’s specifically designed for the kind of large-scale outdoor environments necessary for autonomous vehicle development. Specifically, Mapviz is able to integrate all of the sensor data that you need on top of a variety of two-dimensional maps, such as road maps or satellite imagery.

As an autonomous vehicle visualization tool, Mapviz works just like you’d expect that it would, which Jerry demonstrated with several demos at ROSCon. Mapviz shows you a top-down view of where your vehicle is, and tracks it across a basemap that seamlessly pulls image tiles at multiple resolutions from a wide variety of local or networked map servers, including Open MapQuest and Bing Maps. Mapviz is, of course, very plugin-friendly. You can add things like stereo disparity feeds, GPS fixes, odometry, grids, pathing data, image overlays, projected laser scans, markers (including textured markers) from most sensor types, and more. It can’t really handle three dimensional data (although it’ll do two-and-a-half dimensions via color gradients), but for interactive tracking of your vehicle’s navigation and path planning behavior, Mapviz should offer most of what you need.

For a variety of non-technical reasons, SwRI hasn’t been able to release all of its tools and plugins as open source quite yet, but they’re working on getting approval as fast as they can. They’re also in the process of developing even more enhancements for Mapviz, and you can keep up to date with the latest version of the software on GitHub.

Matt Vollrath and Wojciech Ziniew (End Point): ROS-Driven User Applications in Idempotent Environments

Matt Vollrath and Wojciech Ziniew work at an ecommerce consultancy called End Point, where they provide support for Liquid Galaxy; a product that’s almost as cool as it sounds. Originally an open source project begun by Google engineers on their twenty percent time, Liquid Galaxy is a data visualization system consisting of a collection of large vertical displays that wrap around you horizontally. The displays show an immersive (up to 270°) image that’s ideal for data presentations, virtual tours, Google Earth, or anywhere you want a visually engaging environment. Think events, trade shows, offices, museums, galleries, and the like.

Last year, End Point decided to take all of the ad hoc services and protocols that they’d been using to support Liquid Galaxy and move everything over to ROS. The primary reason to do this was ROS support for input devices: you can use just about anything to control a Liquid Galaxy display system, from basic touchscreens to Space Navigator 3D mice to Leap Motions to depth cameras. The modularity of ROS is inherently friendly to all kinds of different hardware.

Check out this week’s ROSCon15 video as Matt and Wojciech take a deep dive into their efforts in bringing ROS to bear for these unique environments.

Tom Moore: Working with the Robot Localization Package

Clearpath Robotics is best known for building yellow and black robots that are the research platforms you’d build for yourself; that is, if it wasn’t much easier to just get them from Clearpath Robotics. All of their robots run ROS, and Clearpath has been heavily involved in the ROS community for years. Now with Locus Robotics, Tom Moore spent seven months as an autonomy developer at Clearpath. He is the author and maintainer of the robot_localization ROS package, and gave a presentation about it at ROSCon 2015.

robot_localization is a general purpose state estimation package that’s used to give you (and your robot) an accurate sense of where it is and what it’s doing, based on input from as many sensors as you want. The more sensors that you’re able to use for a state estimate, the better that estimate is going to be, especially if you’re dealing with real-worldish things like unreliable GPS or hardware that flakes out on you from time to time. robot_localization has been specifically designed to be able to handle cases like these, in an easy to use and highly customizable way. It has state estimation in 3D space, gives you per-sensor message control, allows for an unlimited number of sensors (just in case you have 42 IMUs and nothing better to do), and more.

Tom’s ROSCon talk takes us through some typical use cases for robot_localization, describes where the package fits in with the ROS navigation stack, explains how to prepare your sensor data, and how to configure estimation nodes for localization. The talk ends with a live(ish) demo, followed by a quick tutorial on how to convert data from your GPS into your robot’s world frame.

The robot_localization package is up to date and very well documented, and you can learn more about it on the ROS Wiki.

Moritz Tenorth (Magazino): Maru and Toru — Item-Specific Logistics Solutions Based on ROS

It’s not sexy, but the next big thing for robots is starting to look like warehouse logistics. The potential market is huge, and a number of startups are developing mobile platforms to automate dull and tedious order fulfillment tasks. Transporting products is just one problem worth solving: picking those products off of shelves is another. Magazino is a German startup that’s developing a robot called Toru that can grasp individual objects off of warehouse shelves, a particularly tricky task that Magazino is tackling with ROS.

Moritz Tenorth is Head of Software Development at Magazino. In his ROSCon talk, Moritz describes Magazino’s Toru as “a mobile pick and place robot that works together with humans in a shared environment,” which is exactly what you’d want in an e-commerce warehouse. The reason that picking is a hard problem, as Moritz explains, is perception coupled with dynamic environments and high uncertainty: if you want a robot that can pick a wide range of objects, it needs to be able to flexibly understand and react to its environment; something that robots are notoriously bad at. ROS is particularly well suited to this, since it’s easy to intelligently integrate as much sensing as you need into your platform.

Magazino’s experience building and deploying their robots has given them a unique perspective on warehouse commercialization with ROS. For example, databases and persistent storage are crucial (as opposed to a focus on runtime), and real-time control turns out to be less important than being able to quickly and easily develop planning algorithms and reducing system complexity. Software components in the ROS ecosystem can vary wildly in quality and upkeep, although ROS-Industrial is working hard to develop code quality metrics. Magazino is also working on remote support and analysis tools, and trying to determine how much communication is required in a multi-robot system, which native ROS isn’t very good at.

Even with those (few) constructive criticisms in mind, Magazino says that ROS is a fantastic way to quickly iterate on both software and hardware in parallel, especially when combined with 3D printed prototypes for testing. Most importantly, Magazino feels comfortable with ROS: it has a familiar workflow, versatile build system, flexible development architecture, robust community that makes hiring a cinch, and it’s still (somehow) easy to use.

Michael Ferguson (Fetch Robotics): Accelerating Your Robotics Startup with ROS

Michael Ferguson spent a year as a software engineer at Willow Garage, helping rewrite the ROS calibration system, among other projects. In 2013, he co-founded Unbounded Robotics, and is currently the CTO of Fetch Robotics. At Fetch, Michael is one of the primary people responsible for making sure that Fetch’s robots reliably fetch things. Mike’s ROSCon talk is about how to effectively use ROS as an integral part of your robotics business, including best practices, potential issues to avoid, and how you should handle open source and intellectual property.

Because of how ROS works, much of your software development (commercial or otherwise) is dependent on many external packages. These packages are constantly being changed for the better — and sometimes for the worse — at unpredictable intervals that are completely out of your control. Using continuous integration, consisting of systems that can handle automated builds, testing, and deployment, can help you catch new problems as early as possible. Michael also shares that a useful way to avoid new problems is to not immediately switch over to new software as soon as they are available: instead, stick with long-term support releases, such as Ubuntu 14.04 and ROS Indigo.

While the foundation of ROS is built on open source, using ROS doesn’t mean that all of the software magic that you create for your robotics company has to be given away for free. ROS supports many different kinds of licenses, some of which your lawyers will be more happy with than others, but there are enough options with enough flexibility that it doesn’t have to be an issue. Using Fetch Robotics as an example, Mike discusses what components of ROS his company uses in their commercial products, including ROS Navigation and MoveIt. With these established packages as a base, Fetch was able to quickly put together operational demos, and then iterate on an operating platform by developing custom plugins optimized for their specific use cases.

When considering how to use ROS as part of your company, it’s important to look closely at the packages you decide to incorporate, to make sure that they have a friendly license, good documentation, recent updates, built-in tests, and a standardized interface. Keeping track of all of this will make your startup life easier in the long run. As long as you’re careful, relying on ROS can make your company more agile, more productive, and ready to make a whole bunch of money off of the future of robotics.

If you enjoyed this article, you may also want to read:

• ROSCon 2015 recap and videos – Part 4
• ROSCon 2015 recap and videos – Part 3
• ROSCon 2015 recap and videos – Part 2
• ROSCon 2015 recap and videos – Part 1

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

ROSCon is an annual conference focused on ROS, the Robot Operating System. Every year, hundreds of ROS developers of all skill levels and backgrounds, from industry to academia, come together to teach, learn, and show off their latest projects. ROSCon 2015 was held in Hamburg, Germany. Here’s a recap of the first videos posted on the OSRF blog.

Opening Remarks, with Brian Gerkey

Brian is the CEO of the Open Source Robotics Foundation, which oversees core ROS development and helps to coordinate the efforts of the ROS community. Brian helped found OSRF in 2012, after directing open source development at Willow Garage.

In the video, Brian provides an overview of ROSCon attendees and ROS user metrics that shows how diverse the ROS community has become. Brian touches on what’s happened with ROS over the last year, along with the future of ROS and OSRF, and what we have to look forward to in 2016. Brian also touches on DARPA’s Robotics Fast Track program.

An introduction to Team ViGIR’s Open Source Software and DRC Post Mortem, with Stefan Kohlbrecher

Stefan’s early research using tiny soccer-playing humanoid robots at Technische Universität Darmstadt in Germany prepared him well for software development on much larger humanoid robots that don’t play soccer at all. From the Darmstadt Dribblers RoboCup team to the DARPA Robotics Challenge Team ViGIR, Stefan has years of experience with robots that need to walk on two legs and do things while not falling over (much).

Almost all of the software that Team ViGIR used to control its ATLAS robot (named Florian) was ROS based. Stefan credits both the team’s prior experience with ROS, ROS’s existing software base, and its vibrant community for why Team ViGIR made the choice to go with ROS from the very beginning. Controlling the ATLAS robot is exceedingly complex, and Stefan takes us through the software infrastructure that Team ViGIR used during the DRC; from basic perception to motion planning to manipulation and user interfaces.

With lots of pictures and behind-the-scenes videos, Stefan describes how Team ViGIR planned to tackle the challenging DRC Finals course. The team used both high-level autonomy and low-level control, with an emphasis on dynamic, flexible collaboration between robot and operator. Stefan narrates footage of both of Florian’s runs at the DRC Finals; each was eventful, but we won’t spoil it for you.

To wrap up his talk, Stephan describes some of the lessons that Team ViGIR learned through their DRC experience: about ROS, about ridiculously complex humanoid robots, and about participating in a global robotics competition.

Commercial models for the robot generation, with Mark Shuttleworth

In 2004, Canonical released the first version of Ubuntu, a Debian-based open source Linux OS that provides one of the main operational foundations of ROS. Canonical’s founder, Mark Shuttleworth, was CEO of the company until 2009, when he transitioned to a leadership role that lets him focus more on product design and partnerships. In 2002, Mark spent eight days aboard the International Space Station, but that was before the ISS was home to a ROS-powered robot. He currently lives on the Isle of Man with 18 ducks and an occasional sheep. Ubuntu was a platinum co-sponsor of ROSCon 2015, and Mark gave the opening keynote on developing a business in the robot age.

Changes in society and business are both driven by changes in technology, Mark says, encouraging those developing technologies to consider the larger consequences that their work will have, and how those consequences will result in more opportunities. Shuttleworth suggests that robotics developers really need two things at this point: a robust Internet of Things infrastructure, followed by the addition of dynamic mobility that robots represent. However, software is a much more realistic business proposition for a robotics startup, especially if you leverage open source to create a developer community around your product and let others innovate through what you’ve built.

To illustrate this principle, Mark shows a live demo of a hexapod called Erle-Spider, along with a robust, high-level ‘meta’ build and packaging tool called Snapcraft. Snapcraft makes it easy for users to install software and for developers to structure and distribute it without having to worry about conflicts or inter-app security. The immediate future promises opportunities for robotics in entertainment and education, Mark says, especially if hardware, ROS, and an app-like economy can come together to give developers easy, reliable ways to bring their creations to market.

The rest of the videos from the conference can be found here.

This book begins with a deep overview of the ROS framework, discusses robot manipulation and navigation, and covers how ROS interfaces with I/O boards, sensors, and actuators. Vision sensors are essential ingredients in robotics, and so an entire chapter is dedicated to how they interface with ROS. The book also explores hardware interfacing and the simulation of complex robots in ROS and ROS Industrial, and finishes with a chapter on best practices to follow while programming in ROS.

Below is an overview of the chapters in the book:

1. Introduction to ROS and its package management
2. Working with 3D robot modeling in ROS
3. Simulating  robots using ROS and Gazebo
4. Using the ROS MoveIt! and Navigation stack
5. Working with Pluginlib, Nodelets and Gazebo plugins
6. Writing ROS controllers and visualization plugin
7. Interfacing I/O boards, sensors and actuators to ROS
8. Programming Vision sensors using ROS, Open-CV and PCL
9. Building  and interfacing differential drive mobile robot hardware in ROS
10. Exploring the advanced capabilities of ROS MoveIt!
11. ROS for Industrial Robots
12. Troubleshooting and best practices in ROS

The book uses ROS Indigo installed on latest Ubuntu L.T.S 14.04.03. The codes are also compatible with ROS Jade. https://github.com/qboticslabs/mastering_ros

A basic knowledge in R.O.S, GNU/Linux, and C++ programming concepts is recommended.

The book is published by PACKT and can be purchased at Amazon Global  and PACKT Publishing. More information can be found on the book website and Wiki page.

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

• Learning robotics using Python
• Book Review: Implementation of Robot Systems, by Mike Wilson
• Arduino for Makers #2: Deconstructing Arduino programs
• Arduino for Makers #1: Setting up a development station
• MATLAB Robotics System Toolbox and ROS

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

There are magnificent tutorials about how to create plugins for Gazebo in the GazeboSim webpage. There are even some tutorials about how to create plugins for Gazebo + ROS, which show that there are several types of plugins (world, model, sensor, system, visual), and indicate how to create a plugin for a world-type plugin. But I recently I needed to create a plugin for a light detector and couldn’t find a concrete example. Here’s a how-to post showing you how I did it.

How to: light sensor plugin in Gazebo

Following the indications provided at the answers forum of Gazebo, I decided to build a very simple light detector sensor based on a camera. Instead of using a raytracing algorithm from lights, the idea is to use a camera to capture an image, then use the image to calculate the illuminance of the image, and then publish that illuminance value through a ROS topic.

Since the plugin is meant to be used with ROS, the whole plugin should be compilable using ROS environment.

Creating a ROS package for the plugin

First we need to create the package in our catkin workspace that will allow us to compile the plugin without a problem.

cd ~/catkin_ws/src
catkin_create-pkg gazebo_light_sensor_plugin gazebo_ros roscpp

Creating the plugin code

For this purpose, since we are using a camera to capture the light, we are going to create a plugin class that inherits from the CameraPlugin. The code that follows has been created taking as guideline the code of the authentic gazebo ROS camera plugin.

Create a file called light_sensor_plugin.h inside the include directory of your package, including the following code:

#ifndef GAZEBO_ROS_LIGHT_SENSOR_HH
#define GAZEBO_ROS_LIGHT_SENSOR_HH

#include <string>

// library for processing camera data for gazebo / ros conversions
#include <gazebo/plugins/CameraPlugin.hh>

#include <gazebo_plugins/gazebo_ros_camera_utils.h>

namespace gazebo
{
class GazeboRosLight : public CameraPlugin, GazeboRosCameraUtils
{
/// brief Constructor
/// param parent The parent entity, must be a Model or a Sensor
public: GazeboRosLight();

/// brief Destructor
public: ~GazeboRosLight();

/// brief Load the plugin
/// param take in SDF root element
public: void Load(sensors::SensorPtr _parent, sdf::ElementPtr _sdf);

/// brief Update the controller
protected: virtual void OnNewFrame(const unsigned char *_image,
unsigned int _width, unsigned int _height,
unsigned int _depth, const std::string &_format);

ros::NodeHandle _nh;
ros::Publisher _sensorPublisher;

double _fov;
double _range;
};
}
#endif

As you can see, the code includes a node handler to connect to the roscore. It also defines a publisher that will publish messages containing the illuminance value. Two parameters have been defined: fov (field of view) and range. At present only fov is used to indicate the amount of pixels around the center of the image that will be taken into account to calculate the illuminance.

Then create a file named light_sensor_plugin.cpp containing the following code in the src directory of your package:

#include <gazebo/common/Plugin.hh>
#include <ros/ros.h>
#include "/home/rtellez/iri-lab/iri_ws/src/gazebo_light_sensor_plugin/include/light_sensor_plugin.h"

#include "gazebo_plugins/gazebo_ros_camera.h"

#include <string>

#include <gazebo/sensors/Sensor.hh>
#include <gazebo/sensors/CameraSensor.hh>
#include <gazebo/sensors/SensorTypes.hh>

#include <sensor_msgs/Illuminance.h>

namespace gazebo
{
 // Register this plugin with the simulator
 GZ_REGISTER_SENSOR_PLUGIN(GazeboRosLight)

 ////////////////////////////////////////////////////////////////////////////////
 // Constructor
 GazeboRosLight::GazeboRosLight():
 _nh("light_sensor_plugin"),
 _fov(6),
 _range(10)
 {
 _sensorPublisher = _nh.advertise<sensor_msgs::Illuminance>("lightSensor", 1);
 }

 ////////////////////////////////////////////////////////////////////////////////
 // Destructor
 GazeboRosLight::~GazeboRosLight()
 {
 ROS_DEBUG_STREAM_NAMED("camera","Unloaded");
 }

 void GazeboRosLight::Load(sensors::SensorPtr _parent, sdf::ElementPtr _sdf)
 {
 // Make sure the ROS node for Gazebo has already been initialized
 if (!ros::isInitialized())
 {
 ROS_FATAL_STREAM("A ROS node for Gazebo has not been initialized, unable to load plugin. "
 << "Load the Gazebo system plugin 'libgazebo_ros_api_plugin.so' in the gazebo_ros package)");
 return;
 }

 CameraPlugin::Load(_parent, _sdf);
 // copying from CameraPlugin into GazeboRosCameraUtils
 this->parentSensor_ = this->parentSensor;
 this->width_ = this->width;
 this->height_ = this->height;
 this->depth_ = this->depth;
 this->format_ = this->format;
 this->camera_ = this->camera;

 GazeboRosCameraUtils::Load(_parent, _sdf);
 }

 ////////////////////////////////////////////////////////////////////////////////
 // Update the controller
 void GazeboRosLight::OnNewFrame(const unsigned char *_image,
 unsigned int _width, unsigned int _height, unsigned int _depth,
 const std::string &_format)
 {
 static int seq=0;

 this->sensor_update_time_ = this->parentSensor_->GetLastUpdateTime();

 if (!this->parentSensor->IsActive())
 {
 if ((*this->image_connect_count_) > 0)
 // do this first so there's chance for sensor to run once after activated
 this->parentSensor->SetActive(true);
 }
 else
 {
 if ((*this->image_connect_count_) > 0)
 {
 common::Time cur_time = this->world_->GetSimTime();
 if (cur_time - this->last_update_time_ >= this->update_period_)
 {
 this->PutCameraData(_image);
 this->PublishCameraInfo();
 this->last_update_time_ = cur_time;

 sensor_msgs::Illuminance msg;
 msg.header.stamp = ros::Time::now();
 msg.header.frame_id = "";
 msg.header.seq = seq;

 int startingPix = _width * ( (int)(_height/2) - (int)( _fov/2)) - (int)(_fov/2);

 double illum = 0;
 for (int i=0; i<_fov ; ++i)
 {
 int index = startingPix + i*_width;
 for (int j=0; j<_fov ; ++j)
 illum += _image[index+j];
 }

 msg.illuminance = illum/(_fov*_fov);
 msg.variance = 0.0;

 _sensorPublisher.publish(msg);

 seq++;
 }
 }
 }
 }
}

That is the code that calculates, in a very basic form, the illuminance.

Create a CMakeLists.txt

Copy the following code in your CMakeLists.txt

cmake_minimum_required(VERSION 2.8.3)
project(gazebo_light_sensor_plugin)

# Load catkin and all dependencies required for this package
find_package(catkin REQUIRED COMPONENTS
roscpp
gazebo_ros
)

# Depend on system install of Gazebo
find_package(gazebo REQUIRED)

link_directories(${GAZEBO_LIBRARY_DIRS})
include_directories(${Boost_INCLUDE_DIR} ${catkin_INCLUDE_DIRS} ${GAZEBO_INCLUDE_DIRS})

add_library(${PROJECT_NAME} src/light_sensor_plugin.cpp)
target_link_libraries(${PROJECT_NAME} ${catkin_LIBRARIES} ${GAZEBO_LIBRARIES} CameraPlugin)

catkin_package(
DEPENDS
roscpp
gazebo_ros
)

Update the package.xml

Now you need to include the following line in your package.xml, between the tags <export></export>

<gazebo_ros plugin_path="${prefix}/lib" gazebo_media_path="${prefix}" />

Now you are ready to compile the plugin. Compilation should generate the library containing the plugin inside your building directory.

Create a world file

Below is an example of a world file that includes the plugin. Save this code in a file named light.world inside the directory worlds of your package. This world file simply loads the camera with its plugin, so it might be a bit ugly, but it will be good enough for your tests. Feel free to add more elements and models in the world file.

<?xml version="1.0" ?>
<sdf version="1.4">
 <world name="default">
 <include>
 <uri>model://ground_plane</uri>
 </include>

 <include>
 <uri>model://sun</uri>
 </include>

 <!-- reference to your plugin -->
 <model name='camera'>
 <pose>0 -1 0.05 0 -0 0</pose>
 <link name='link'>
 <inertial>
 <mass>0.1</mass>
 <inertia>
 <ixx>1</ixx>
 <ixy>0</ixy>
 <ixz>0</ixz>
 <iyy>1</iyy>
 <iyz>0</iyz>
 <izz>1</izz>
 </inertia>
 </inertial>
 <collision name='collision'>
 <geometry>
 <box>
 <size>0.1 0.1 0.1</size>
 </box>
 </geometry>
 <max_contacts>10</max_contacts>
 <surface>
 <contact>
 <ode/>
 </contact>
 <bounce/>
 <friction>
 <ode/>
 </friction>
 </surface>
 </collision>
 <visual name='visual'>
 <geometry>
 <box>
 <size>0.1 0.1 0.1</size>
 </box>
 </geometry>
 </visual>
 <sensor name='camera' type='camera'>
 <camera name='__default__'>
 <horizontal_fov>1.047</horizontal_fov>
 <image>
 <width>320</width>
 <height>240</height>
 </image>
 <clip>
 <near>0.1</near>
 <far>100</far>
 </clip>
 </camera>
 <plugin name="gazebo_light_sensor_plugin" filename="libgazebo_light_sensor_plugin.so">
 <cameraName>camera</cameraName>
 <alwaysOn>true</alwaysOn>
 <updateRate>10</updateRate>
 <imageTopicName>rgb/image_raw</imageTopicName>
 <depthImageTopicName>depth/image_raw</depthImageTopicName>
 <pointCloudTopicName>depth/points</pointCloudTopicName>
 <cameraInfoTopicName>rgb/camera_info</cameraInfoTopicName>
 <depthImageCameraInfoTopicName>depth/camera_info</depthImageCameraInfoTopicName>
 <frameName>camera_depth_optical_frame</frameName>
 <baseline>0.1</baseline>
 <distortion_k1>0.0</distortion_k1>
 <distortion_k2>0.0</distortion_k2>
 <distortion_k3>0.0</distortion_k3>
 <distortion_t1>0.0</distortion_t1>
 <distortion_t2>0.0</distortion_t2>
 <pointCloudCutoff>0.4</pointCloudCutoff>
 <robotNamespace>/</robotNamespace>
 </plugin>
 </sensor>
 <self_collide>0</self_collide>
 <kinematic>0</kinematic>
 <gravity>1</gravity>
 </link>
 </model>
 </world>
</sdf>

Create a launch file

Now comes the final step: to create a launch that will upload everything for you. Save the following code as main.launch inside the launch directory of your package.

<launch>
 <!-- We resume the logic in empty_world.launch, changing only the name of the world to be launched -->
 <include file="$(find gazebo_ros)/launch/empty_world.launch">
 <arg name="verbose" value="true"/>
 <arg name="world_name" value="$(find gazebo_light_sensor_plugin)/worlds/light.world"/>
 <!-- more default parameters can be changed here -->
 </include>
 </launch>

Ready to run!

Now launch the world. Be sure that a roscore is running or your machine, and that the GAZEBO_PLUGIN_PATH environment var includes the path to the new plugin.

Now execute the following command:

roslaunch gazebo_light_sensor_plugin main.launch

You can see what the camera is observing by running the following command:

rosrun image_view image_view image:=/camera/rgb/image_raw

You can also have the value of luminance by watching the published topic:

rostopic echo /gazebo_light_sensor_plugin/lightSensor

Conclusion

Now you have a plugin for your Gazebo simulations that can measure (very roughly) the light detected. You can use it in you local copy of Gazebo or even inside The Construct.

Eight years ago, Morgan Quigley, Eric Berger and Andrew Ng published a paper that was not about ROS. It was about STAIR, the STanford Artificial Intelligence Robot, which used a library called Switchyard to pass messages between software modules to perform complex manipulation tasks like stapler grasping. Switchyard was a purpose-built framework that was designed to be modular and robot-independent, and it was such a good idea that in 2009, “ROS: An Open-Source Robot Operating System” was presented at the IEEE International Conference on Robotics and Automation (ICRA) in Japan. As of this month, the paper introducing ROS has been cited 2,020 times, an increase of more than 50% over last year.

The popularity of one single paper is only a minor indicator of the popularity of the robot operating system that it introduced. At eight years old, ROS is growing faster than ever, and helping the robotics community to grow along with it. We’re especially excited to see how brand new startups have been taking advantage of the open source nature of ROS to help them develop useful, reliable robots that are creating entirely new markets. In 2015 alone, more than $150 million in VC funding (that we know of) was invested in businesses that use ROS.

Large, established companies have been taking more and more notice of ROS as well. At ROSCon this year, Fetch Robotics was joined as a platinum sponsor by Ubuntu, and a record number of gold sponsors included NVIDIA, Bosch, and Qualcomm and attendees from companies such as BMW, DJI, Intel and more. ROSCon 2015 was by far the largest conference we’ve ever had: it sold out weeks in advance. Clearly next year we’re going to have to find a much bigger venue to make room for more attendees, more speakers, and more exhibitors.

Taking a look at how much our community has grown this year, it’s easy to see why ROSCon has become so popular: it’s a reflection of the enthusiasm and engagement of the ROS user base. In May 2015 alone, nearly nine million ROS packages were downloaded from over 70,000 unique IP addresses, and these numbers don’t even count mirrors. This suggests that ROS probably has hundreds of thousands of active users. We also have a very robust developer community: 1,840 people have contributed to ROS’ 10 million lines of code, averaging 20 commits per day. The ROS wiki has gotten 10% bigger since last year, and there are over 11,000 users on ROS Answers, a 32% increase over last year, with a total of more than 5,000 questions answered. It’s numbers like these that make us so confident in the long term future of ROS.

Counting ROS

Because of the nature of the ROS license, we actually don’t know how many users, robots, and developers there are utilizing ROS. Many of the numbers that we are citing throughout are likely to be much larger. For example, we specifically know of approximately 80 types of robots using ROS, but almost every day we hear about new ones. And not every company using ROS discloses so publicly, so our estimates on venture capital investment can be better characterized as lower bounds than estimates.

If you’re not part of the ROS community yet, there’s never been a better time to get involved. Even if you don’t have experience with robots or programming, there’s a wide variety of low-cost robots and helpful online tutorials that can get you started, and we’re also delighted to announce (just in time for the holidays!) that O’Reilly Media has published “Programming Robots with ROS: A Practical Introduction to the Robot Operating System,” by Morgan Quigley, Brian Gerkey, and Bill Smart, which will take you from zero to ROS expert in just 448 pages.

Learning ROS will allow you to do all kinds of cool stuff with more than 80 robotic platforms. You can choose from the capable, affordable TurtleBot, one of the many sophisticated humanoid robots that competed in the DARPA Robotics Challenge, or even NASA’s Robonaut, currently undergoing testing on the International Space Station. Robots powered by ROS are everywhere, and here are just a few of them:

For full frame clips see the long version of the montage.

Of course, we have no idea how many robots are actually running ROS, or how many people or companies are using it, because ROS is open source and completely free. We’re often surprised to learn that cutting edge robots that we’re already familiar with are powered by ROS, as when BMW announced at ROSCon that they’ve been using ROS in their autonomous cars for the past few years. We weren’t at all surprised to hear why BMW chose ROS for its autonomous driving research though: they appreciate its popularity, its stability and reliability based on a large user base, the fact that it makes it easy to collaborate, and its open source nature.

As the ROS community has grown, various special interest groups have organized to promote ROS for specific application domains. The ROS Industrial Consortium is one such group. ROS-I is a software library that builds on ROS and leverages its power and flexibility to control manufacturing automation equipment including industrial robot arms. It is supported by the 36-member organizations comprised of companies such as 3M, ABB, Boeing, Ford, Boeing, Siemens and more. Representatives from Boeing, Caterpillar, Yaskawa and more speak on behalf of ROS and ROS-I in this video.

2016 is poised to be the biggest year ever for ROS, and we’d like to highlight two things that are worth getting particularly excited about. The first is ROS 2.0, which we’ve been developing for the past few years. ROS 2 will support the growth of the ROS community by making it much easier to work with small embedded systems, teams of multiple robots, and robots that require real-time control. We’d also like to make sure you’re familiar with Robotics Fast Track (RFT), which is  a program that we’re working on with DARPA. It’s an easy way for you to get government funding for your awesome robotics ideas without having to give up any of your IP, and absolutely anyone can apply.

We write these anniversary posts to help give you a sense of how ROS has a whole has been doing over the past year, but we’d certainly encourage you to find out for yourself, by getting involved. Write or edit a Wiki page. Answer a question on ROS Answers. Come to ROSCon. And, when you’re ready, think about helping to maintain ROS itself, or even contributing a brand new ROS package. OSRF is doing great, but the long-term success of ROS depends on all of the incredibly awesome ROS users themselves. If you’re already an active part of the ROS community, we can’t thank you enough, and if you’re not, think about it: you can help ROS grow and thrive for eight more years, and beyond.

Fully autonomous robotics could be developed today if objects could tell a robot what they are, their purpose and how to utilize them. Liatris is a new open source project built with ROS. Its objective is to reliably read an object’s pose and identity without relying on vision. It presents an opportunity to rip down the barriers that prevent robotics from being present in our everyday lives.

Traditionally, a robot would be required to identify and locate every object in its workspace. Liatris, which is built primarily using ROS, Kivy and Python, instead determines any object’s pose and identity using a touch screen and RFID reader.

The robot in the video is programmed to identify and grasp any object placed on the touch screen, regardless of the object’s shape, size or positioning. It perceives the object by utilizing the CAD model downloaded from Liatris’ API.

This also tells the robot how to grasp an object while avoiding collisions with other objects (thanks to MoveIt).

The result is an accurate 3D perception and mobile manipulation solution. Liatris can even work simultaneously with multiple objects and touch screens.

Learn more at  Liatris.org

Foote explains the benefits of open source and how it helps make research and development more efficient when both researchers and start-ups can focus on their added value, rather than starting from scratch. This is an advantage for the whole robotics community, enabling it to move forward much faster. 

Foote also describes how developers can contribute directly to further developing the ROS standard, for the benefit of the robotics community. 

You can support Robots in Depth on Patreon. Check out all the Robots in Depth videos here.

Each plane – a styrofoam wing with a 56” wingspan – was equipped with a Pixhawk autopilot running a modified version of the open-source Ardupilot firmware and an ODroid u3 “payload” computer running ROS Indigo. The payload used autopilot_bridge (similar to mavros) to bridge between serial communications with the autopilot and ROS messages and services. A network node bridged ROS communications with a lightweight UDP-based protocol that allowed aircraft to share their pose and status with one another and to receive commands from the ground.

Also residing on the payload was a set of controller nodes that could “drive” the plane by sending updated target latitude-longitude-altitude commands to the autopilot. Controllers were individually activated by a state machine, based on commands from the ground. The controller used during the fifty-plane flight was a follower controller. A single ground operator commanded two sets of 25 planes each to configure themselves into leader-follower formations; planes would determine a leader based on highest altitude (which was deconflicted at the start of the flight). The leader would then proceed along a predefined racetrack, and all followers, listening to the broadcast position of the leader, would track its path while remaining at their designated altitudes.

https://youtu.be/-zKDdAw609Y

A detailed writeup of the flight test is posted at DIY Drones and more information on the research project can be found at the ARSENL website.

Erle-Spider is a drone with legs powered by Canonical’s new distribution for robots and IoT devices: Snappy Ubuntu Core. This computer with legs uses the Robot Operating System (ROS), and has been unleashed by Erle Robotics, a spanish startup focused on creating artificial brains for robots and drones. Now crowdfunding on Indiegogo, the Spider is powered by a 900MHz quad-core ARM Cortex-A7 microprocessor that includes 1GB of RAM and exposes several connection interfaces including Ethernet, USB, I2C, UART and HDMI. It also includes several sensors such as gyroscopes, a digital compass, a pressure sensor, gravity sensors or temperature sensors and can be further extended with any sensor that is already supported by ROS.

The robot has been created to meet the increasing demand for low cost robot and drone platforms that help in the process of learning, research and development of new ideas. The spider is subject to low levels of regulation when compared to other drones and will provide support for existing tools already adopted by the Dronecode Foundation. Erle Robotics has announced that the Spider will be opened (both in hardware and software once the campaign is successfully funded).

“We’ve always believed that the future of robotics wouldn’t be about humanoids costing thousands of euros, but about Linux-based, open and affordable robots that allow people to put their creativity into real applications. With Erle-Spider using Ubuntu, millions of developers will have access to a robot that can be programmed using the same tools that they use everyday” – Víctor Mayoral Vilches, CTO at Erle Robotics.

Erle-Spider’s capabilities can be extended using “apps”. Developers can easily create these applications for the drone and sell them through the cloud-based app store. The apps can be as simple as a line follower algorithm or as complicated as a behavior that using SLAM helps the spider explore pipes and provide measurements. Creating these applications for the robot doesn’t require any developer licenses (when compared to existing cloud marketplaces for smartphones) and it’s as simple creating a zip file. Furthermore, ROS is integrated within the store thereby it can be used to develop these applications.

“Erle-Spider has literally been designed to explore terrain that other robots and drones haven’t seen yet.” – Alejandro Hernández Cordero, CRO at Erle Robotics.

Erle-Spider will be delivered this Christmas and is available on Indiegogo for 399$ .

Launched in 2009 by a group of Waterloo engineering students, Clearpath‘s unmistakeable bright yellow and black robots have become synonymous with unmanned vehicle research in university research labs around the world. Now, as the field of robotics matures, Clearpath is forging into industrial applications, too. We caught up with CTO Ryan Gariepy at the 2015 Field and Service Robotics conference (FSR), to talk about their roots in research, the role of ROS and open source in their business model, and the challenges and opportunities of launching a robotics startup in Canada.

[HS] You got your start in the business of robotics while you were still a student at Waterloo. What made you decide to launch a robotics company at that time? Did you have a specific project or technology you were developing that made you think, “Hey, this could actually be useful out there!” …? Or was it that you saw the potential in the field more generally?

[RG] We started Clearpath right out of university in 2009 as we finished our undergraduate degrees – I did my Masters at the same time as we were getting off the ground, which is generally regarded to be a bad idea in terms of stress levels. It’s hard to believe that we just celebrated our sixth anniversary this year.

Starting the company was less about the technology and more about the potential … we just looked at everything around us and said, “Why do we have to shovel snow? This can be automated. Why do we have to do any work that does not require human creativity?” There are a lot of dangerous jobs out there that most people don’t realize are performed on a daily basis by tens of thousands of people in order to keep society going, like mining, farming, construction, stocking warehouses. And yet we need fuel and food and buildings, and we want our same-day deliveries from the Internet. There is a demand for this kind of work to take place.

Around the time we were starting out, Google Maps was getting off the ground. The concept of having information available at your fingertips was also becoming compelling and valuable to people, and the best way to get information about the world on a constant basis is to involve robotics or automation in some form. At the same time, sensors and the cost of sensing were improving due to the rapid uptake in smart phones; we were seeing advances in laptops, smartphones, and electric and hybrid vehicles driving down costs and improving battery density.

People now accept that robotics, automation, and intelligent systems can actually solve some of their problems.

All of this was coming together and we felt that autonomous robotics was possible at a relatively high reliability and low cost, especially when compared with what had been done before.

What would you say have been the biggest changes that you’ve seen in the field of robotics since then?

I think one of the biggest changes is simply that people now accept that robotics, automation, and intelligent systems can actually solve some of their problems.

This recognition means that there are a lot of opportunities out there, both in terms of hardware and software. In some industries – ones that have been around for a long time – they already know how to build solid hardware that could be made robotic, but they need the right parts and the right software to automate it. Then there are other industries that need full solutions. There are a lot of pieces starting to come together now.

Your early customer base was made up of mainly universities and research labs. Do you find yourself getting pulled into a different direction now that you’re expanding more into industry?

The research market is definitely maturing and our product development cycle within that side of the business is very well understood. We’ve released two completely different platforms in the last eight months alone.

Now we are in a position where we can leverage the experience we gained from the R&D market to address challenges in industry. We are actively pushing the development of full robotic solutions (including software), and will soon be releasing a new platform along these lines.

How do you manage the problem of building in more than one direction at the same time?

One of our biggest challenges is that there is no one single clear challenge, especially at the scale we’re at right now. At this stage there are many things that need to be focused on: sales, operations, quality assurance, new features, understanding where the market’s going, product management, marketing … so the challenge is more about managing the priorities of any given department.

How do I provide guidance to the team so that they can spend their time on the right tasks? How do we remain dynamic as a startup? How do we remain flexible enough to change direction quickly if we need to, but still be stable enough to stick to our core values? These are the kinds of questions we are dealing with.

Speaking of core values, Clearpath took a chance from the beginning by focusing on open source and ROS. Does open source make for a good business model?

Why open source? No matter how large a company we become, there will always be more smart people who can build and program robots outside our company than within it.

One of the reasons we looked at open source was the philosophy that no matter how large a company we become, there will always be more smart people who can build and program robots outside our company than within it. So it’s only logical that we work with whatever the community ends up creating around open source robotics, both to reinforce the community, and to hire from it.

That said, from a business model perspective it is more complicated. There are many companies that succeed with open source, but there is still no clear-cut model for building an open source company – and that tends to make people nervous. And yet by now we’ve seen several companies build on open source, including Google and Facebook, and it’s the same thing as building a startup on a LAMP stack: yes, you use open source and you may push back some code to open source, but you still have value you’re bringing on your own.

Earlier on we sold only hardware, which is easier to protect. Now that we’re getting into software sales, open source creates additional considerations for us, but it still hasn’t been an issue. Building on open source makes us more effective, and it certainly helps us engage much more with the robotics community.

Now that you’ve done all the legwork of developing the product and proving the market, do you have any concerns that another company with more resources could just come along and say, “We know who their buyers are, and we know what their markets are, and we can imitate their products …”?

Clearpath is sponsoring the 2015 Robot Launch “Open Source Robotics” Award, offering 10 hours of ROS consulting services to the winner.

ROS is open source and we contribute a lot back to it. We test a lot, we support people, we contribute drivers, and we contribute utilities back. However, the work that we do on autonomy and in controls –planning, mapping localization, interfacing, vehicle management – is not open source. We may open source parts of it in the future as we advance our state of the art, but the ‘secret sauce’ is still closed, even though it’s built on ROS middleware.

Could it make life easier for our competitors in some cases? Yes, but by the same token nobody makes money on having a better robot-logging framework, for example, and everybody saves money by having a good free robot-logging framework. If a better logging framework is your only competitive advantage, it’s not really an advantage, is it? Personally, I’d rather not spend money on a logging framework, and spend more to compete on the actual value that we bring to our clients.

You mentioned snow shoveling as one of your inspirations, which is a stereotypically Canadian problem. Did the Canadian climate and landscape figure into your business plan from the beginning? Is that why you wound up in field and service robotics, as opposed to some other application area?

Of course our robots can survive the winter – we’re Canadian!

One of our competitive advantages is the terrible weather we have in Canada. We have harsh winters, we have a lot of forestry, a lot of primary resources to mine and harvest, and we have a lot of space that is sparsely populated, which makes it easier to do testing. We also happen to have a very well developed technology ecosystem here. When you put those things together, it’s natural to lean towards field robotics.

When we started there were very few platforms out there that could actually do field robotics, and so we set that as our first niche.

How is the Canadian business landscape for robotics?

Many of our first customers were Canadian universities, some of which are leading the way in robotics integration and research. Meanwhile, Industry Canada is looking at how robotics technology can be adapted to existing manufacturing clusters in Southwestern Ontario, like the auto sector, which took a hit when the North American auto industry had a downturn. Canada also has strengths such as communications and optics, which naturally extend into robotics. It also helps when we can do business with Canadian suppliers; we get our GPS’ from NovAtel, which is based in Calgary, for example.

That said, as a Canadian company you’re forced to go multinational almost instantly because there isn’t enough of a robotics market in Canada to stay Canadian for long. We recently announced that we’ll be expanding office space into Silicon Valley and a primary reason for that is because of the opportunity that is available in the US market. Regardless, the Waterloo Region will continue to be Clearpath’s ‘home base’ for the foreseeable future.

People now refer to Waterloo as ‘Silicon Valley North’. What’s changed in the incubation space where Clearpath grew up since you launched?

It used to be that investors would demand that you move to the area where their office was, which was typically Boston or New York City or Silicon Valley, but that’s not always the case anymore.

It used to be that investors and venture capitalists would demand that you move to the area where their office was, which was typically Boston or New York City or Silicon Valley, but that’s not always the case anymore. Investors are starting to recognize that there are also benefits to being in other locations, especially for startups. Waterloo has a very dynamic tech community. It’s also a quarter of the price to buy a house here than in some of those larger US cities, and the time it takes me to get to work is 10 minutes, which makes it pretty livable and affordable compared to Silicon Valley. We found that VCs are now willing to accept that good ideas and businesses can grow and thrive in other areas as long as these areas have the right attitude – and Waterloo certainly has that.

Take the displacement of BlackBerry employees for instance – quite a few very smart people who were working at Blackberry have moved on to bring their skills and experience to other industries. We’ve hired a number of them, and a number of them have gone off to launch their own startups.

On top that is the continual increase in the brand of the Waterloo Region, and specifically the University of Waterloo (UW), as the place to go for getting a great education and practical experience that can lead to entrepreneurship. YCombinator’s Paul Graham has noted that UW has a fantastic record for turning out very strong companies, specifically hardware companies.

The other change worth mentioning is that Clearpath isn’t alone. The first group of startups that came out of UW includes Pebble, Vidyard, and more recently Thalmic Labs. These are all people who have graduated from UW’s engineering program within a few years of each other.

Does that help, too? Having a cluster that’s grown up together?

It certainly does.

Take recruiting, for example. When you’re hiring someone it helps prospective employees to know that there are other options. Clearpath has hired quite a few people from outside the region and if you’re taking a risk and moving a few thousand kilometers to join us, it’s good to know that there are other companies around, whether it’s for future growth opportunities, shared interests, or participating in knowledge transfer. For prospective employees, knowing that you can get back on your feet if you need to, or that your partner can find a job in the region, is very useful.

There is also something to be said for being part of a startup community. We all know each other, and we try to mentor each other. Even if you’re not working in exactly the same market, you can look at other startups and see them succeeding – and this is evidence that you can do it too.

A new book, Learning Robotics using Python, takes a different approach to teaching the Robotics Operating System (ROS). Written by Lentin Joseph, founder and CEO of Indian robotics startup Qbotics Labs, it enables you to learn by building an interactive, autonomous, mobile robot, and is the result of his research while designing the company’s autonomous robot prototype, Chefbot. It features Artificial Intelligence, vision capabilities, speech recognition and synthesis.

Chefbot is designed primarily to serve food in hotels and restaurants and Qbotics plans to release the robot as open hardware to develop a community focussed on improving the design. The company also provides assistance for clients autonomous machines.

Learning Robotics Using Python uses ROS Indigo, a stable version of ROS, installed on the latest Ubuntu L.T.S 14.04.02. The code is also compatible with ROS Jade. After a basic introduction, it looks at the mechanical design of robots using open source tools. ROS is introduced following the building of 2D and 3D models, and Chefbot is simulated using ROS and Gazebo. The Chefbot simulation is adapted from a Turtlebot simulator.

With a successful simulation in Gazebo, the book turns to the hardware element, the selection of the electronic components needed to build the robot. The sensor and actuator interfacing is explored and interfacing embedded boards to ROS using Python.

The Chefbot has (Kinect) sensors, ultrasonics and sound sensors, as well as motor encoders. The book looks at the detailed interfacing of each sensor with ROS and Kinect, and how to work with depth to pointcloud package.

In addition, it examines speech recognition and synthesis in robots, using ROS and Python, and implementing a version of Artificial Intelligence using ROS and Python.

After all this interfacing, the final integration is possible, both in hardware and software, resulting in the complete robot.

It needs a GUI controller, built using PyQt. Debugging is enabled via ROS rqt. Once the GUI has been constructed, it goes into the calibration and testing of the robot before its deployment.

Learning robotics using Python is available on the PACKT website and also Amazon.com.

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

• Book Review: Implementation of Robot Systems, by Mike Wilson
• Arduino for Makers #2: Deconstructing Arduino programs
• Arduino for Makers #1: Setting up a development station
• MATLAB Robotics System Toolbox and ROS

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

By Martin Cote

After working in the terminal, gazebo and RViz, it’s time for a change of pace. For this ROS101 tutorial we’ll be detailing the basics of creating your own rqt dashboard! A dashboard is a single rqt window with one or more plugins displayed in movable, re-sizable frames. Dashboards generally consist of a number of plugins that, in combination, provide a suite of UI capabilities for working with robots and robot data.

Dashboards can be populated and configured interactively in an rqt session. A preferred configuration can be saved as a “Perspective,” which saves the plugins loaded, their layout, where they are supported, their settings, and last-saved initial parameters (such as what topic we were last plotting). In this tutorial we’ll be working with the Husky simulation in ROS Indigo. To install ROS Indigo, please see these instructions, and visit our Husky simulation page to install the Husky simulation.

Getting Started

The first step is to install rqt! We’ll also be installing some common plugins to create our dashboard:

sudo apt-get install ros-indigo-rqt ros-indigo-rqt-common-plugins ros-indigo-rqt-robot-plugins

We can then launch RQT by simply using:

rqt

In the Plugins menu, select each plugin you want to load. You can change the layout by dragging and rescaling each plugin by its title bar or edges.

A practical example

We’ll now create a rqt dashboard with a few useful plugins and demonstrate a potential use case for this particular dashboard. For this tutorial we’ll be using our virtual Husky to simulate sensor data. Open Husky up in Gazebo using:

roslaunch husky_gazebo husky_playpen.launch

You can minimize Gazebo for now as we set up our rqt dashboard. Begin by opening the following plugin from the plugins drop down menu, and re size them as you like,

Rviz
Plot x2
Bag
Robot Steering

Each plugin has their own uses and settings, for more information about a particular plugin, visit the rqt plugins page of the ROS wiki

When you’re happy with a dashboard configuration, you can save the perspective by selecting Perspectives, Create Perspective, giving it a name, and asking it to clone the current perspective. These perspectives are saved locally and persist between sessions.

To export a perspective for closer management such as sharing or persisting to a repository, select Perspectives, Export and give it a name with the filename extension, .perspective

Loading a Perspective

A perspective can be loaded interactively in RQT by selecting Perspectives, import. However a more useful way is to launch them from the command-line, which allows us to wrap them in a script that can be rosrun or roslaunched:

rqt --perspective-file "$(rospack find my_ros_rqt_package)/config/my_dashboard.perspective"

Some plugins allow you to configure options that impact its installation and behavior. For example, the Python Console plugin allows you to choose which console implementation to use. You can access these options for any plugin by selecting the gear icon in its title bar. If no gear icon is present, the plugin has not been configured to provide an options menu.

Rviz: To load Husky into your Rviz plugin, select “open config” from the drop down menu, and navigate to /opt/ros/indigo/share/husky_viz/rviz/view_robot.rviz. You should now see a model of Husky loaded in Rviz! By default, this config file will include the simulated laser, and you can see the object in Husky’s path in the Gazebo environment.

Plot: The Plot tool is very useful to plot a particular topic in real time, for this example we will be plotting the commanded odometery topic versus the simulated odometrey. In the input window on the top right of the plot plugin, add the follow topic in each plot.

/odometry/filtered/twist/twist/angular/z

and

/husky_velocity_controller/odom/twist/twist/angular/z

Robot Steering: The robot steering plugin provides us with a simple way to manually drive Husky, all that is required is to specify  the  topic which accepts the velocity commands to move your Robot, for virtual Husky, that topic is /cmd_vel.

It’s time to put it together! Try commanding Husky to turn in place using the robot steering plugin, and watch your Husky is RViz turn in place while it’s updating the laser scan! You should also see the commanded odometry in one of your plots, while the actual odometry lags slightly behind as it catches up to the desired value.

Rqt bag: Rosbag is an extremely useful tool  for logging, and our support team may often ask for a bag file to take a closer look at your system. It’s possible to record a bag through the terminal, but using rqt is much simpler and more intuitive. Let’s record  a bag file of Husky driving around by clicking the record button, and selecting the topics you want to record. Once you’re happy with the data recorded, stop the recording.

Playing a bag file back is just as simple. Let’s go ahead and close rqt and Gazebo so ROS is no longer running, then start ROS again with just roscore:

roscore

And open rqt back up and load the ROS bag plugin again:

rqt

This time we are going to open up the bag file we just recorded by clicking the 2nd button. You’ll now see all the topics that were recorded, and when messages were sent over that topic. You can take a closer look at a particular ticket by right clicking and selecting to view either the values or plot a particular topic.

For more information regarding rqt, please visit the ROS Wiki page, if you have any questions regarding this particular tutorial, please don’t hesitate to contact us!

Looking for other Clearpath tutorials? Here’s one you might like! See all the ROS101 tutorials here.

The tutorials take developers from the initial setup of TurtleBot through programming a web app to control it. The final demo is to bring coffee to people around an office, but my ultimate goal is for creative new users to learn from this simple idea and modify at their whim to generate inventive uses and expansions.

I produced this free series in hopes of bringing robotics technology to the web development community. As we recently saw with 3D printers, web developers have a long tradition of embracing emerging technologies. My goal, as a member of both the open-source robotics and web development communities, is to encourage web developers to start learning robotics so that we can see the same sort of creativity and popularity take off.

The way I see it, if we can give developers a taste of ROS’ power, they will invest the time to learn ROS properly. Today robotics stands on the foundation built by many brilliant people and engaged, innovative communities; now it is time to mine the untapped potential of developers not previously involved with robotics. By sparking developers’ interest and teaching them the basics of ROS, I hope to break down even more barriers and put us that much closer to making the robot revolution a reality.

The Arduino family of micro controllers has quickly become a go-to board for hobbyists due to its ease of use. Often times roboticists must create communication protocols to allow their embedded hardware to communicate with a computer. One of the most powerful aspects of ROS is that it can communicate with a large variety of hardware. That’s where rosserial comes in! Rosserial is a general protocol for sending ROS messages over a serial interface, such as the UART on Arduino. This allows you to easily interface any sensors attached to Arduino into your ROS environment. Read on to learn more!

This tutorial will get you started  by setting up the Arduino IDE and installing the rosserial libraries. Then, we’ll test it out by driving the Husky simulation using a neat trick with the Arduino board. It should goes without saying you’ll need an Arduino to complete this tutorial. We’ll also be using a Husky simulator, so make sure to run through our “Drive a Husky” tutorial if you haven’t done so yet.

Setup

The first step is to set up your Arduino environment, begin by installing the Arduino IDE and rosserial using:

sudo apt-get install arduino arduino-core ros-hydro-rosserial ros-hydro-rosserial-arduino

Once you open up the Arduino IDE for the first time, a directory named “sketchbook” will be created in your home directory. Now we need to import the rosserial library into your arduino IDE. If your sketchbook directory is empty, you may need to create a directory named “libraries” inside of it.

mkdir ~/sketchbook/libraries
cd ~/sketchbook/libraries
rosrun rosserial_arduino make_libraries.py .

Restart your Arduino IDE and you should see the ros_lib part of your libraries!

You’ll want to ensure that your Ubuntu user is part of the “Dailout” group, which grants you access to serial ports. You can check by using

groups "username”

If you don’t see “dailout”, you can easily add yourself using

sudo gpasswd --add "username" dialout

One last step to make our lives easier will be to create udev rules so your Arduino is  recognized when plugged in and the correct permissions are set. For more information on udev rules check out our udev article . Begin by plugging in your Arduino.

NOTE:If you are using a virtual machine, you will have to connect Arduino to the virtual machine after plugging it in.

You can confirm your system is actually connected to Arduino by running

ls -l /dev

Depending on your specific Arduino board, you should either see a line with ttyAMC# or ttyUSB#, where # is a number. This will also tell you the current permissions for your Arduino. Chances are you wouldn’t be able to upload code to your Arduino at the moment because you don’t sufficient permissions, but we will soon solve that by creating a new udev rule!

The udev rule will require the product and vendor ID to be able to identify when our arduino is connected which you can easily find using

lsusb

You should see a line similar to

Bus 002 Device 005: ID 2341:0043

To confirm this is indeed your Arduino, disconnect it and run the command again, taking note which entry has disappeared. Remember the ID numbers, in this case, 2341 is the vendor ID and 0043 is the product ID. Now venture over to your udev rules at:

cd /etc/udev/rules.d/

and create our new rules file, the naming conventions for rules files follows “##-name.rules”. Chose a number that isn’t in use!

sudo gedit 97-arduino.rules

Copy the following into your new rules file, replacing #### with your product ID and vendor ID. For more information about what these tags mean, check out our article on udev rules.

SUBSYSTEMS=="usb", ATTRS{idProduct}=="###", ATTRS{idVendor}=="####", SYMLINK+="arduino",MODE="0777",

All that is left is to update your udev rules and reboot your system

udevadm trigger
sudo reboot

You should now see “arduino” as an entry in ls -l /dev with full permissions! (rwxrwxrwx)

Code

We’re now set to upload our code to Arduino! The code is fairly straight forward, however if you have any difficulties following along, check out our “Creating a publisher” tutorial. Copy the following code into the Arduino IDE and click upload. If your udev rules were set correctly you should be able to upload without any errors.

If you encounter any errors, verify your arduino is coming up as “arduino” in a ls -l /dev and proper permissions are set. You may also have to point the Arduino IDE towards the correct USB port in tools -> serial port.

#include <ArduinoHardware.h>
#include <ros.h>
#include <geometry_msgs/Twist.h>

ros::NodeHandle nh;

geometry_msgs::Twist msg;

ros::Publisher pub("husky/cmd_vel", &msg);

void setup()
{
 nh.initNode();
 nh.advertise(pub);
} void loop()
{
 if(digitalRead(8)==1)
 msg.linear.x=-0.25;
 
 else if (digitalRead(4)==1)
 msg.linear.x=0.25;
 
 else if (digitalRead(8)==0 && digitalRead(4)==0)
 msg.linear.x=0;
 
 pub.publish(&msg);
 nh.spinOnce();
 }

Driving Husky

Now that Arduino is loaded with our code and publishing velocity commands, we can pass these messages along into our ROS environment. We’ll start by launching a Husky simulation:

roslaunch husky_gazebo husky_empty_world.launch

All that’s left is to attach the Arduino into our ROS environment using:

rosrun rosserial_python serial_node.py _port:=/dev/arduino

We’re ready to try it out! Go ahead and touch the digital pin 8 and you should see Husky drive forward! Similarly if you touch digital pin 4 Husky will drive backwards.

This trick is made possible by a phenomenon known as parasitic capacitance, which is usually an unwanted effect in electronics design, but serves nicely for the purpose of our example. That being said, this isn’t the most reliable method, and is intended to provide a simple example with minimal equipment.  If you are having difficulties moving your simulated Husky, try using rostopic echo /husky/cmd_vel to verify some commands are in fact being sent to Husky when you touch the pins.

Be sure to go through the rest of our ROS tutorials on our knowledge base. If you want to learn more about rosserial, be sure to visit the rosserial page of the ROS wiki.

Looking for other Clearpath tutorials? You might like these ones! Or visit www.support.clearpathrobotics.com.

By Paul Bovbel

Udev is a device manager for Linux that dynamically creates and removes nodes for hardware devices. In short, it helps your computer find your robot easily. By default, hardware devices attached to your Linux (Ubuntu) PC will belong to the root user. This means that any programs (e.g. ROS nodes) running as an unpriveleged (i.e. not root) user will not be able to access them. On top of that, devices will receive names such as ttyACMx and ttyUSBx arbitrarily based on the order in which they were plugged in. Luckily, you can solve this, and more, with udev rules.

You probably already have at least one udev rule on your system that solves the naming problem for network devices, and you can take a peek at it in the /etc/udev/rules.d/ folder – it’s probably named 70-persistent-net.rules.

Some driver/software packages will already provide udev rules you can use. Check the /etc/udev/rules.d/ folder to see if there’s anything installed already. If the package is lazy and gives you a udev rule to install yourself, you can do this using:

sudo cp <rule file> /etc/udev/rules.d/

Writing a new udev rule:

If you still need to write your own rule to setup naming and permissions for your device, read on. Rules can get extremely complex, but the one below should cover 99% of use cases for ROS applications. If you’re looking for 99.9%, I suggest you start here. As an example, we will examine the udev rule provided by the urg_node driver in ROS:

SUBSYSTEMS==”usb”, KERNEL==”ttyACM[0-9]*”, ACTION==”add”, ATTRS{idVendor}==”15d1″, ATTRS{idProduct}==”0000″, MODE=”666″, PROGRAM=”/opt/ros/hydro/lib/urg_node/getID /dev/%k q”, SYMLINK+=”sensors/hokuyo_%c”, GROUP=”dialout”

A udev rule is made up of a bunch of comma separated tags, as above. The tags are divided into two parts: matching and configuration, however they can be written into the rule in any order (confusingly enough).

Matching:

The matching part lets the udev device manager match the rule to the device you want. The manager will try to match all new devices as they get plugged in, so it’s important that the rule be specific enough to capture only the device you’re looking for, otherwise you’ll end up with a /dev/hokuyo symlink to an IMU. There are many potential matching tags, and the best way to pick the useful ones is to get all the device attributes straight from udev.

Run the following command, inserting the <devpath> such as /dev/ttyACM0:

udevadm info -a -p $(udevadm info -q path -n <devpath>)

You will get a list of all device attributes visible to udev. looking at device ‘…/ttyACM0′:

KERNEL=="ttyACM0"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '...':
KERNELS=="3-3:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cdc_acm"
ATTRS{bInterfaceClass}=="02"
ATTRS{bInterfaceNumber}=="00"
looking at parent device '...':
...
ATTRS{idVendor}=="0483"
ATTRS{idProduct}=="5740"
...

Each of the device attributes is a potential tag. You can use any of the tags in the first section to filter, along with tags from a parent device. Use regex to make matching more flexible (e.g. [0-9] to match any number, * to match anything at all).

Example:

SUBSYSTEM=="tty", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ...

Due to the way udev is designed, you can only pull in the tags from one parent device. So in the above example you can always use the KERNEL and the SUBSYSTEM tag in your udev rule, but you cannot use both DRIVERS and ATTRS{idVendor} to do matching. Usually this is not a problem, since idVendor and idProduct are always present, and identify the majority of device types uniquely.

You should also add the ACTION tag, which is usually “add”, sometimes “remove” if you want to do something when the device is unplugged.

..., ACTION=="add", ...

Configuration:

Now that you have a rule that matches the device you want, you can add several configuration tags:

MODE="0666"

SYMLINK+=”hokuyo”

RUN+=”/bin/echo ‘hello world’”

It is good practice to make sure symlinks are unique for each device, so the above is actually poor practice! If you have multiple devices of the same type (e.g. 2 Hokuyos), or if you have multiple devices using a generic USB-to-Serial converter (e.g. FTDI), a basic idVendor and idProduct rule will not properly discriminate between these devices, since udev will map all matching devices to the same symlink. There are several approaches:

Directly through device attributes:

If your device has a unique identifier, such as a serial number, encoded in its attributes, you can painlessly create a unique symlink:

…, SYMLINK+=”device_$attr{serial}”, …

This will usually not be the case. If a parent device has a serial number, you can use the following trick using environment variables. Create a udev rule for the parent device to store an environment variable:

…, <match parent device>…, ENV{SERIAL_NUMBER}=”$attr{serial_number}”

And a rule for the child device that uses the variable in the symlink:

..., <match child device>..., SYMLINK+="device_$env{SERIAL_NUMBER}"

External Program:

If the manufacturer does not expose a unique identifier through the device attributes, you can execute an external command using the PROGRAM tag:

PROGRAM="/bin/device_namer %k", SYMLINK+="%c"

Unlike the RUN tag which spins off, this command will be executed before the rule is fully processed, so it must return quickly. The urg_node driver above uses this tag to execute a ROS binary:

PROGRAM="/opt/ros/hydro/lib/urg_node/getID /dev/%k q", SYMLINK+="sensors/hokuyo_%c"

Substitution argument %k refers to the device path relative to /dev/, and %c refers to the output of the PROGRAM tag.

Running a new udev rule:

Once you have sudo cp’ed your rule into the /etc/udev/rules.d/ folder, you can test it with your device. To get udev to recognize your rule, run the following command:

sudo udevadm control --reload-rules && sudo service udev restart && sudo udevadm trigger

You should be able to find a symlink in /dev/ that links to the full device path (e.g. /dev/ttyACM0), and the permissions on the device path should be read/write for all users.

If your permissions aren’t being set, and you symlink is not being created in /dev/ as expected, you can try simulating udev’s processing of the rule by running the following with the appropriate device path:

udevadm test $(udevadm info -q path -n /dev/ttyACM0)

Things to keep in mind

Check that your rule follows the naming convention – <priority>-<device name>.rules. Technically you can have multiple rules for the same device, and the number determines what order they’d get executed in. Since we’re writing addon rules, a priority of 99 is safest.

You can have multiple rules in a file separated by newlines. Make sure that each individual rule is on one line.

Check that all tags (matching and configuration) are comma separated.

Check that your rule file has a trailing newline.

Check that your rule is owned by the root user – ll /etc/udev/rules.d/ should say ‘root root’ for the rule file.

The post Do More with Udev appeared first on Clearpath Robotics Inc..

By Martin Cote

We previously learned how to write a publisher node to move Husky randomly. BUT: what good is publishing all these messages if no one is there to read it? In this tutorial we’ll write a subscriber that reads Husky’s position from the odom topic, and graph its movements. Instead of just copy-pasting code into a text file, we’ll pull the required packages from GitHub, a very common practice among developers.

Before we begin, install Git to pull packages from GitHub, and pygame, to provide us with the tools to map out Husky’s movements:

sudo apt-get install git
sudo apt-get install python-pygame

Pulling from GitHub

GitHub is a popular tool among developers due to its use of version control – most ROS software has an associated GitHub repository. Users are able to “pull” files from the GitHub servers, make changes, then “push” these changes back to the server. In this tutorial we will be using GitHub to pull the ROS packages that we’ll be using. The first step is to make a new directory to pull the packages:

mkdir ~/catkin_ws/src/ros101
cd ~/catkin_ws/src/ros101
git init

Since we now know the URL that hosts the repositories, we’ll easily be able to pull the packages from GitHub. Access the repositories using the following command:

git pull https://github.com/mcoteCPR/ROS101.git

That’s it! You should see an src and launch folder, as well as a CMakelist.txt and package.xml in your ros101 folder. You now have the package “ros101″, which includes the nodes “random_driver.cpp” and “odom_graph.py”.

Writing the subscriber

We’ve already gone through the random_driver C++ code in the last tutorial, so this time we’ll go over the python code for odom_graph.py. This node uses the Pygame library to track Husky’s movement. Pygame is a set of modules intended to create video games in python; however, we’ll focus on the ROS portion of this code. More information on Pygame can be found on their website. The code for the odom_graph node can be found at:

gedit -p ~/catkin_ws/src/ros101/src/odom_graph.py

Let’s take a look at this code line by line:

import rospy
from nav_msgs.msg import Odometry

Much like the C++ publisher code, this includes the rospy library and imports the Odometry message type from nav_msgs.msg. To learn more about a specific message type, you can visit http://docs.ros.org to see it’s definition, for example, we are using http://docs.ros.org/api/nav_msgs/html/msg/Odometry.html . The next block of code imports the pygame libraries and sets up the initial conditions for our display.

def odomCB(msg)

This is the odometry call back function, which is called every time our subscriber receives a message. The content of this function simply draws a line on our display between the last coordinates read from the odometry position message. This function will continually be called in our main loop.

def listener():

The following line starts the ROS node, anonymous=True means multiples of the same node can run at the same time:

rospy.init_node('odom_graph', anonymous=True)

Subscriber sets up the node to read messages from the “odom” topic, which are of the type Odometry, and calls the odomCB functions when it receives a message:

rospy.Subscriber("odom", Odometry, odomCB)

The last line of this function keeps the node active until it’s shut down:

rospy.spin()

Putting it all together

Now it’s time to test it out! Go ahead and close the odom_graph.py file and build your workspace using the catkin_make function in your workspace directory.

cd ~/catkin_ws
catkin_make

The next step is to launch our Husky simulation to start up ROS and all the Husky related nodes

roslaunch husky_gazebo husky_emepty_world.launch

In this tutorial we have provided a launch file that will start the random_driver and odom_graph node. The launch file is located in ~/ros101/src/launch and is called odom_graph_test.launch. If you want to learn more about launch files, check out our launch file article on our support knowledge base. We will now source our workspace and launch both nodes with the launch file in a new terminal window.

source ~/catkin_ws/devel/setup.bash
roslaunch ros101 odom_graph_test.launch

There you have it! Our subscriber is now listening to messages on the odom topic, and graphing out Husky’s path.

See all the ROS101 tutorials here. 

[ROSCon 2014] Brian Gerkey: Opening Remarks (HD) from OSRF on Vimeo.

[ROSCon 2014] Ryan Gariepy: Closing remarks from OSRF on Vimeo.

See links to all the presentations and slides on the program page. The videos can also be browsed here on Vimeo.

Enjoy!

By Martin Cote

In our previous post, we graduated from driving a Husky to taking on a Grizzly! Now it’s time to get down and dirty with what ROS is really made of: nodes! We will first be creating a workspace to work from, then we will write a simple publisher that will make our virtual Husky drive around randomly. If this is your first time visiting a Clearpath Robotics ROS 101 blog, get started here.

Creating a workspace and package

Before we begin writing a node, we need to create a workspace and a package. Workspaces are simply directories to store all of your packages. First we will need to create a new directory.

mkdir ~/ros101

This created a directory in your home folder, which we will use as a workspace directory. We now need to create a subdirectory in your workspace directory to store all your source code for your packages.

mkdir ~/ros101/src

The last step to creating the workspace will be to initialize the workspace with catkin_init_workspace.

cd ~/ros101/src
catkin_init_workspace

Now that our workspace has been created, we will create a package in the src directory we just created. This can be done by navigating to the ~/ros101/src directory, which you should have already done in the last step, and using the catkin_create_pkg command  followed by what we want the package to be named, and then followed by what other packages our package will be dependent on; this command creates another directory for your new package, and two new configuration files inside that directory with some default settings.

catkin_create_pkg random_husky_driver roscpp std_msgs

You can see that this created CMakeLists.txt and package.xml inside the random_husky_driver directory; this is also where you will store all your source code for your packages. The roscpp and std_msgs  dependencies were added into the CMakeLIst.txt and package.xml.

Writing the publisher

As mentioned in our previous post, a publisher publishes messages to a particular topic. For this tutorial, we will be publishing random commands to the /husky/cmd_vel topic to make your Husky visualization drive itself. Start by creating a file in your ~/ros101/src/random_husky_driver directory called random_driver.cpp, and copy the following code.

#include <ros/ros.h>
#include <geometry_msgs/Twist.h> 
#include <stdlib.h> 

int main(int argc, char **argv) {
     //Initializes ROS, and sets up a node
     ros::init(argc, argv, "random_husky_commands");
     ros::NodeHandle nh;

     //Ceates the publisher, and tells it to publish
     //to the husky/cmd_vel topic, with a queue size of 100
     ros::Publisher pub=nh.advertise<geometry_msgs::Twist>("husky/cmd_vel", 100);

     //Sets up the random number generator
     srand(time(0));

     //Sets the loop to publish at a rate of 10Hz
     ros::Rate rate(10);

       while(ros::ok()) {
            //Declares the message to be sent
            geometry_msgs::Twist msg;
           //Random x value between -2 and 2
           msg.linear.x=4*double(rand())/double(RAND_MAX)-2;
           //Random y value between -3 and 3
           msg.angular.z=6*double(rand())/double(RAND_MAX)-3;
           //Publish the message
           pub.publish(msg);

          //Delays untill it is time to send another message
          rate.sleep();
         }
}

Let’s break down this code line by line:

#include <ros/ros.h>
#include <geometry_msgs/Twist.h> 

These lines includes the headers that we are going to need. The <ros/ros.h> header is required for ROS functionality and the <geometry_msgs/Twist.h> is added so that we can create a message of that type.

ros::init(argc, argv, "random_husky_commands");
ros::NodeHandle nh;

The first line, ros::init,  is used to initialize the ROS node, and name it “random_husky_commands”, while ros:NodeHandle starts the node.

ros::Publisher pub=nh.advertise<geometry_msgs::Twist>("husky/cmd_vel", 100);

Publishing a message is done using ros:Publisher pub=nh.advertise, followed by the message type that we are going to be sending, in this case it is a geometry_msga::Twist, and the topic that we are going to be sending it too, which for us is husky/cmd_vel.

The 100 is the message queue size; that is, if you are publishing message faster than what roscpp can send, 100 messages will be saved in the queue to be sent. The larger the queue, the more delay in robot movement in case of buffering.

Therefore in a real life example, you will want to have a smaller queue in the case of robot movement, where delay in movement commands are undesirable and even dangerous, but dropped messages are acceptable. In the case of sensors, it is recommended to use a larger queue, since delay is acceptable to ensure no data is lost.

ros::Rate rate(10)
...
rate.sleep()

ROS is able to control the loop frequency  using ros:Rate to dictate how rapidly the loop will run in Hz. rate.sleep will delay a variable amount of time such that your loop cycles at the desired frequency. This accounts for time consumed by other parts of the loop. All Clearpath robots require a minimum loop rate of 10Hz.

while(ros::ok())

The ros::ok function will return true unless it receives a command to shut down, either by using the rosnode kill command, or by the user pusing Ctrl-C in a terminal.

geometry_msgs::Twist msg;

This creates the message we are going to send, msg, of the type geometry_msgs:Twist
msg.linear.x=4*double(rand())/double(RAND_MAX)-2;
msg.angular.z=6*double(rand())/double(RAND_MAX)-3;

These lines calculate the random linear x and angular z values that will be sent to Husky.

pub.publish(msg)

We are finally ready to publish the message! The pub.publish adds msg to the publisher queue to be sent.

Compiling the random Husky driver

Compilation in ROS in handled by the catkin build system. The first step would usually be to set up our package dependencies in the CMakeLists.txt and package.xml. However this has already been done for us when we created the package and specified our dependencies. The next step is then to declare our new node as a executable, this is done by adding the following two lines to the CMakeLists.txt files in ~/ros101/src/random_husky_driver

add_executable(random_driver random_driver.cpp)
target_link_libraries(random_driver ${catkin_LIBRARIES})

The first line creates the executable called random_driver, and directs ROS to its source files. The second lines specifies what libraries will be used. Now we need to build our workspace using the catkin_make command in the workspace directory

cd ~/ros101
catkin_make

Let’s bring up the husky visualization as we did in a previous blog post.

roslaunch husky_gazebo husky_empty_world.launch

The final step is to source your setup.bash file in the workspace you have created. This script allows ROS to find the packages that are contained in your workspace. Don’t forget this process will have to be done on every new terminal instance!

source ~/ros101/devel/setup.bash

It’s now time to test it out! Make sure you have a instance of roscore running in a separate terminal, then start the node.

rosrun random_husky_driver random_driver

You should now see Husky drive around! In a new terminal window, we can make sure that our node is publishing to the /husky/cmd_vel topic by echoing all messages on this topic.

rostopic echo /husky/cmd_vel

You should now see a stream of random linear x and angular z values.

See all the ROS101 tutorials here. 

So you have had a taste of driving a virtual Husky in our previous tutorial, but now want to try something a little bigger? How about 2000 lbs bigger?

Read on to learn how to drive a (virtual) Grizzly, Clearpath Robotic’s largest and meanest platform. If you are totally new to ROS, be sure to check out our tutorial series starting here and the ROS Cheat Sheet. Here is your next ROS 101 dose.

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

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-grizzly-simulator 
sudo apt-get install ros-hydro-grizzly-desktop 
sudo apt-get install ros-hydro-grizzly-navigation

Running a virtual Grizzly

Open a terminal window, and enter:

roslaunch grizzly_gazebo grizzly_empty_world.launch

Open another terminal window, and enter:

roslaunch grizzly_viz view_robot.launch

You should be given two windows, both showing a yellow, rugged robot (the Grizzly!). The left one 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, or even entire maps of real places.

The right window is RViz. This tool allows us to see sensor data from a robot, and give it commands (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 /cmd_vel geometry_msgs/Twist -r 100 '[0.5,0,0]' '[0,0,0]'

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

See all the ROS101 tutorials here. If you liked this article, you may also be interested in:

• 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.

If you were to design the worst possible environment for software engineering, the cramped jump seat of a John Deere tractor would be a contender. The sound and vibration of the engine makes conversation and concentration difficult. If the sun isn’t making it impossible to see the monitor, the blowing dust is.

This is a common scenario at Blue River Technology because the company is in the agriculture business. Blue River combines computer vision and robotics to deliver precision thinning to lettuce growers.

Blue River has been using ROS since late 2012. According to Willy Pell, Blue River’s Sr. Systems Engineer: “We love ROS because it makes it easy to find and correct errors in the worst possible circumstances. Any time something is wrong we know within a few dozen lines of code where the problem is presenting itself. It allows us to build systems The UNIX Way. In other words, we make simple, open source programs that communicate well with other programs.”

Blue River makes machines called lettuce thinners. Lettuce growers plant too many seeds because only 80% of seeds actually turn into plants. Since a lettuce head needs 10 inches on either side to get the resources it needs, growers must then thin the field of excess lettuce. Blue River’s machine is pulled behind a tractor and takes pictures of the plant seedlings. It identifies the ones to keep and the ones to kill and toggles a sprayer to render its verdict. There is finality to this machine. If it messes up it doesn’t just waste time, it impacts the grower’s yield.

Added Pell, “ROS has been a fantastic tool for us. I love how you can gut one node and not have it affect the rest of the system. I love how you can break the system apart and test subcomponents. Being able to confidently refactor, test and debug large parts of the system allows us to evolve extremely quickly.”

It never ceases to amaze and delight us when we learn of new and innovative uses of ROS. Just recently, ROS celebrated a celestial milestone when it arrived at the International Space Station as part of Robonaut 2. While Blue River’s solution is certainly more terrestrial it is no less innovative and impactful. Being able to deliver a precision agricultural solution to farmers means higher yield and fewer chemicals.

Because of the permissive open source license of ROS, we aren’t always aware of who is using ROS and for what purposes. In this case, we are very grateful to the team at Blue River for sharing their story with us.

If you are using ROS and have a story to share, please drop us a line at info@osrfoundation.org.

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

• Robots Podcast: Blue River Technology
• Robots Podcast: Zero Tillage Robotics
• Agricultural robot market anticipated to reach $16.3 billion by 2020
• UAV innovation is in the Cloud; 3 precision Ag innovations to watch for in 2014 
• Harvey: A working robot for container crops

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

While developing these robots, Avidbots must iterate rapidly through designs. Two key facilitators of this fast development cycle are ROS and Gazebo. ROS’s communication system promotes a simple modular design, while Gazebo provides for accurate simulation testing. Modular software design and thorough simulation testing enable Avidbots to achieve its rapid development goals. This strategic use of ROS and Gazebo is significantly accelerating Avidbots’ entry into the robotic services space.

Here’s their story:

http://youtu.be/ioGui_OSAKg

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.

As part of a resupply mission to the International Space Station, ROS will board a SpaceX Rocket on March 16 and, barring inclement weather, will launch into space. According to a blogpost by Brian Gerkey at the OSRF, SpaceX will deliver a set of robotic legs for the Robonaut 2 (R2) humanoid torso that is currently aboard the ISS: “Once those legs are attached to R2, ROS will officially be running in space.”

This is a big milestone for ROS. According to Gerkey: “ROS has already powered robots in the air, on the ground, on and under the water, and on every continent, but we at OSRF couldn’t be more excited about ROS journeying to outer space.”

In the previous ROS 101 post, we provided a quick introduction to ROS to answer questions like What is ROS? and How do I get started? Now that you understand the basics, here’s how they can apply to a practical example. Follow along to see how we actually ‘do’ all of these things …

First, you will need to run Ubuntu, and have ROS installed on it. For your convenience, you can download our easy-to-use image 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

Get VMWare Player, and use the virtual disk above. If you don’t want to use the provided image, follow the tutorial here (after installing Ubuntu 12.04):

http://wiki.ros.org/hydro/Installation/Ubuntu

Throughout the rest of the tutorials, we will be referencing the ROS cheatsheet available here.

Open a new Terminal Window (Ctrl + Alt + T).
In the new terminal, type roscore (And press enter).
This should produce something similar to the below.

What you have just done is started the ROS Master as we described above. We can now experiment with some ROS commands.
Open a new Terminal, and type in rostopic. This will give you a list of all the options that the rostopic command can do. For now, we are interested in rostopic list
Type in rostopic list. (And press enter). This should give you a window like the following:

The two entries listed above are ROS’s built in way of reporting and aggregating debug messages in the system. What we want to do is publish and subscribe to a message.
You can open a new Terminal again, or open a new tab on the same terminal window (Ctrl + Shift + T).
In the new Terminal, type in: rostopic pub /hello std_msgs/String “Hello Robot”

Let’s break down the parts of that command.
rostopic pub – This commands ROS to publish a new topic.
/hello – This is the name of the new topic. (Can be whatever you want)
std_msgs/String – This is the topic type. We want to publish a string topic. In our overview examples above, it was an image data type.
“Hello Robot” – This is the actual data contained by the topic. I.E. the message itself.
Going back to the previous Terminal, we can execute rostopic list again.
We now have a new topic listed! We can also echo the topic to see the message. rostopic echo /hello

We have now successfully published a topic with a message, and received that message.
Type Ctrl + C to stop echoing the /hello topic.
We can also look into the node that is publishing the message. Type in rosnode list. You will get a list similar to the one below. (The exact numbers beside the rostopic node may be different)

Because we asked rostopic to publish the /hello topic for us, ROS went ahead and created a node to do so. We can look into details of by typing rosnode info /rostopic_…..(whatever numbers)
TIP: In ROS, and in Linux in general, whenever you start typing something, you can press the Tab key to auto-complete it. If there is more than one entry, double tap Tab to get the list. In the above example, all I typed was rosnode info /rost(TAB)

We can get info on our topic the same way, by typing rostopic info /hello.

You will notice that the node listed under “Publishers:” is the same node we requested info about.

Up till now, we have covered the fundamentals of ROS, how to use rostopic, rosnode.

Next time, we will compile a short example program, and try it out.

See all the ROS101 tutorials here. If you liked this article, you may also be interested in:

• 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.

Clearpath Robotics brings us a new tutorial series on ROS!

Since we practically live in the Robot Operating System (ROS), we thought it was time to share some tips on how to get started with ROS. We’ll answer questions like where do I begin? How do I get started? What terminology should I brush up on? Keep an eye out for this ongoing ROS 101 blog series that will provide you with a top to bottom view of ROS that will focus on introducing basic concepts simply, cleanly and at a reasonable pace. This guide is meant as a groundwork for new users, which can then be used to jump into in-depth data at wiki.ros.org. If you are totally unfamiliar with ROS, Linux, or both, this is the place for you!

The ROS Cheat Sheet

This ROS Cheat Sheet is filled with tips and tricks to help you get started and to continue using once you’re a true ROS user. This version is written for ROS Hydro Medusa. Download the ROS Cheat Sheet here.

What is ROS?

ROS (Robot Operating System) is a BSD-licensed system for controlling robotic components from a PC. A ROS system is comprised of a number of independent nodes, each of which communicates with the other nodes using a publish/subscribe messaging model. For example, a particular sensor’s driver might be implemented as a node, which publishes sensor data in a stream of messages. These messages could be consumed by any number of other nodes, including filters, loggers, and also higher-level systems such as guidance, pathfinding, etc.

Why ROS?

Note that nodes in ROS do not have to be on the same system (multiple computers) or even of the same architecture! You could have a Arduino publishing messages, a laptop subscribing to them, and an Android phone driving motors. This makes ROS really flexible and adaptable to the needs of the user. ROS is also open source, maintained by many people.

General Concepts

Let’s look at the ROS system from a very high level view. No need to worry how any of the following works, we will cover that later.

ROS starts with the ROS Master. The Master allows all other ROS pieces of software (Nodes) to find and talk to each other. That way, we do not have to ever specifically state “Send this sensor data to that computer at 127.0.0.1. We can simply tell Node 1 to send messages to Node 2.

How do Nodes do this? By publishing and subscribing to Topics.

Let’s say we have a camera on our Robot. We want to be able to see the images from the camera, both on the Robot itself, and on another laptop.

In our example, we have a Camera Node that takes care of communication with the camera, a Image Processing Node on the robot that process image data, and a Image Display Node that displays images on a screen. To start with, all Nodes have registered with the Master. Think of the Master as a lookup table where all the nodes go to find where exactly to send messages.

In registering with the ROS Master, the Camera Node states that it will Publish a Topic called /image_data (for example). Both of the other Nodes register that they are Subscribed to the Topic /image_data.

Thus, once the Camera Node receives some data from the Camera, it sends the /image_data message directly to the other two nodes. (Through what is essentially TCP/IP)

Now you may be thinking, what if I want the Image Processing Node to request data from the Camera Node at a specific time? To do this, ROS implements Services.

A Node can register a specific service with the ROS Master, just as it registers its messages. In the below example, the Image Processing Node first requests /image_data, the Camera Node gathers data from the Camera, and then sends the reply.

We will have another tutorial “ROS 101 – Practical Example” next week.

See all the ROS101 tutorials here. If you liked this article, you may also be interested in:

• 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 academia, where robotics researchers look to open source as a means of advancing community knowledge, the answer is perhaps more obvious. But in business, it’s clearly a balancing act. And so, ‘To be open, or not to be open?’ — that is the question for our panelists this month.

We asked Frank Tobe, Robert Morris and Brian Gerkey to weigh in. Here’s what they have to say …

Brian Gerkey on “Is open source a good business model for robotics?”

The IT economy has powerfully demonstrated what happens when companies can leverage open source infrastructure when they build new products and services.  A company like Google would never have come into existence had they not been able to rely from the beginning on solid open source tools like Python and GCC.  IBM would arguably have not been able to make its immensely successful pivot from products to services without Linux.  How many startups these days begin as a cloud-hosted machine running some derivative of the venerable LAMP stack? …

Read more →

Robert Morris on “Is open source a good business model for robotics?”

The premise of this question is that robotics companies are manufacturers and that there is choice between an open source and closed source business model.  Robotics companies are best thought of as service companies (even manufacturers, especially when moving beyond early adopters) and openness is not an ‘either/or’ choice, but rather a continuum.  In this day and age the question is, ‘What do you need to keep open create value for your customers?’ …

Read more →

Frank Tobe on “Is open source a good business model for robotics?”

Certainly robotics has its share of proprietary software and control systems. Each robot manufacturer markets their products based on the need for secure, proprietary and un-shared systems so that they can ensure stability and control. Whole industries have been set up to bridge those proprietary barriers so that multi-vendor solutions can happen …

Read more →

While arguing by analogy is fraught with peril, I believe that the similarities between robotics and the rest of the IT world are strong enough to justify it.  In robotics, we have many shared problems to solve when developing a product or service, from low-level drivers to high-level capabilities, and all the developer libraries and tools in between.  I have yet to see a successful robotics business for whom any of that stuff is the competitive advantage.  Rather, success comes from the innovative composition and application of that technology in a form that somebody will pay for.  The hard part is figuring out what the robot should *do*.  By working together on the common underlying problems, we end up with better, more reliable solutions, and we free ourselves to spend more time at the application level, which is where we can differentiate ourselves.

In other words, I believe that open source is a great model for the robotics business as a whole.  Now, is it a good model for any individual company?  It certainly can be.  As examples, we see small-to-medium companies, such as Clearpath Robotics, Rethink Robotics, and Yujin Robot, which use ROS directly in their products. And we see larger companies, such as Bosch and Toyota, using ROS in R&D and prototyping efforts.  These are all profit-motivated companies making what is presumably a rational economic decision to rely on open source software.  They’re each holding something back that is their “special sauce,” whether that’s higher level application software, configuration data, customizations to the open source code, or the designs for the hardware.  And that’s expected: unless you’re in a pure consulting business (selling your time), then you need to own and control something that forms the basis of your product or service offering (to allow you to sell something other than your time).

Fortunately, open source software is entirely compatible with such business models.  In fact, it was our hope to one day see such commercial users of ROS that led us to choose a permissive license (BSD, or Apache 2) for the code that we developed.  We’re now witnessing, with the debut of so many new robotics companies, the fruits of those earlier labors in building a shared development platform.

Read more answers →

Small and medium shops and factories (SMEs) are an untapped marketplace for robotics but direly in need of automation to remain competitive in this global economy. Two new start up companies: Rethink Robotics and Universal Robots have entered that marketplace. Both companies have U.S. sales in the hundreds of units; Universal has a head start internationally and has sold about 3,000 to-date, but Rethink is way ahead in the US. Both have similar 60-100/mo manufacturing run rates – so the future looks bright for selling flexible, lightweight, low-cost robots that are easily programmed, safe for humans to work alongside, don’t require a caged or roped off area, and perform at affordable metrics.

The importance of this new robotic capability and its effect on jobs was the subject of a CBS News piece on October 5. A few of the quotes from that newscast:

• U.S. productivity and efficiency are three times greater than China.
• Baxter’s effective cost is $3 per hour.
• 3-5 million new jobs will happen this decade due to the deployment of Baxter and other co-robots.

Boston-based Rethink Robotics – the maker of the low-cost two-armed Baxter robot shown above on the left – has already begun to sell to small and medium-sized U.S. businesses (SMEs) as well as schools and colleges. They recently announced beginning to sell to European academic institutions.

Danish-based Universal Robots has started to benefit from sales from their new distributor network in the U.S. supplementing their growing European, Asian and International distributor networks and robot sales.

Each company has provided a video profiling how their client companies are using and benefitting from the use of their respective robots. Although these videos are public relations puff pieces, they are also an information resource describing the needs smaller companies have and the benefits offered by robotics.

UNIVERSAL ROBOTS

Of the two companies, for the present time, Universal Robots UR robots are better able to handle industrial tasks than Baxter robots. Universal’s UR5 and UR10 robots can handle 5 and 10 kilos respectively and have sufficient torque to pull open doors and operate hand tools. They also run faster.

Universal Robots got lots of publicity last month when it became known that a UR robot was working at a VW diesel engine production plant in Germany. It was the first publicly-known instance of a robot working alongside a human in an auto factory. In that example, the robot carefully picks up delicate glow plugs and places them into hard-to-reach drill holes alongside a human who then insulates the cylinder head. The robot acts as an assistant and enables the worker to carry out their activities in an upright, healthy posture, unlike previous methods. This week MIT Technology Review showed another Universal robot, this time at a BMW factory in South Carolina, helping workers perform door assembly by doing the strenuous task of applying door sealant thereby freeing human workers to do the less physical tasks.

In the following video, a 72-person short-run metal products maker displays two applications for their new UR robot: CNC machine tending and loading and unloading a metal bender.

[In a recent case study, machine-loaded costs for a part came to $0.97/part in the U.S. and $0.76/part in China. When a robot was used for machine tending and loading, the total cost shifted to $0.73/part in the U.S. versus $0.76/part in China (including offshore costs like duties and transportation fees). In the study, using the robot boosted efficiency. The machine utilization under manual loading was 82%, when you account for shift changes and breaks. When robots did the tending and loading, the efficiency figure approached 99%. Source: PlasticsToday and Fanuc Robotics.]

RETHINK ROBOTICS

Interchangeability of h/w components through standardized interfaces and intelligent software components for flexible production are the benefits.

With centers covering The Americas (located at SwRI in Texas) and for Europe (located at Fraunhofer IPA in Germany), ROS-I is looking for a partner to cover Asia.

A one-year video montage shows some industrial robotics applications made possible by the ROS-I repository was founded in 2012. One can see ROS-I controlling robots by ABB, KUKA, Fanuc, Adept, Universal Robots, and Yaskawa-Motoman.

So, depending on who you ask, Willow Garage is shutting down, pursuing commercial interests, or changing direction. But things are not as dire as some may think: ROS is fine (the OSRF will support it) and there are many options for Willow Garage to explore. Personally I’m hoping it will be snatched up by Stanford or another academic institution and become a research institute. But given the number of robots they have out (and their price tags!), a commercial path into the future seems even more likely. In any case, I doubt that Willow Garage will disappear just like that.

What caused the changes is that Willow’s founder and funder, Scott Hassan, has decided that it’s time to wean Willow Garage from his private financial support.

I’ve never met Scott, but first and foremost I think we – roboticists and robot enthusiasts around the globe – all owe him a huge THANK YOU! I think it’s fair to say that if it had not been for Scott, we would not have universities around the world sharing a common robot operating system. And, looking at the amazing contributions on the Willow Garage blog, it seems clear that the past five years in robotics would have been a lot less exciting without ROS and Willow Garage’s robots.

Scott brought the model of impact first, monetize later to robotics. Together with Steve Cousins he assembled an amazing team of people and established a network of external collaboration far and beyond anything ever seen in robotics. Did it get us a household robot that can serve us a cup of tea? No. But WOW, did it ever fast-forward us towards that goal.

So thank you Scott, for your vision, incredibly generous financial contributions, and for leading with actions. Willow Garage has already had a huge impact, and I’m sure there’s much more to come. I’m greatly looking forward to the next steps of Suitable Technologies. We all have much to look forward to from Willow Garage’s other already existing spinoffs (convenience links below) – and, who knows, from Willow Garage itself in one form or another.

Change and innovation are usually good friends, at least in my book. In spite of all the negativity out there I, for one, think the future of robotics has never been brighter.

Official info:

• Willow Garage’s official statement: Willow Garage is changing
• The Open Source Robotics Foundation’s statement: ROS @ OSRF

Willow Garage’s spin offs (to date):

• Open Source Robotics Foundation (OSRF)
• Suitable Technologies
• Industrial Perception Inc. (IPI)
• hiDOF Inc.
• Redwood Robotics
• OpenCV
• Open Perception Foundation

• ROS (Robot Operating System) and ROS-enabled software packages and libraries can be found in most universities and research labs.
• The 50 PR2 research robots and development platforms around the world and at Willow Garage’s offices in Menlo Park have enabled countless roboticists and research labs to spend their time innovating instead of having to re-invent.
• The spin-offs abound as well: TurtleBot, OpenCV, Galapagos, ROS and ROS-Industrial, Suitable Technologies’ Beam Remote Presence System, HiDOF consulting, the detection and perception leading to the establishment of Industrial Perception, are all indicators of WG’s policy of spinning out entities with a sustaining business plan.
• Joint ventures like Redwood Robotics and Industrial Perception.

The PR2s around the world will continue to be supported and the recent establishment of non-profit organizations will continue the open source platform and libraries.

People appear willing to pay more to get the extra features of an iPad or tablet. Thus e-readers were a device for a particular moment in time that has been replaced by a newer technology. This process is analogous to secretaries being replaced by word processing machines and then by PCs, WordStar and Microsoft Word.

Temporary, Incremental and Transitional Solutions

CyPhyWorks new EASE drone.

A great example of a temporary solution is CyPhy Works‘ new pair of drones (EASE and PARC): timely, innovative and providing solutions for specific needs with a transitional solution: a tether.

CyPhy Works began with funding to research methods to view and analyze bridges and other potential security targets but soon concluded that conventional drones couldn’t handle the payload of cameras and instruments, sensor processing, security, and flight duration needed to get the job done.

“The biggest problem with [surveillance] robots today is they send them inside a building, they go down the stairs, no communications; they go around the corner, no comms. You go into a bunker and it’s got some rebar and you don’t get comms,” CEO Helen Greiner says.

“The problems are power and communications. It all comes down to that.”

“When you have a flying vehicle of a size, a diameter that can fit through a door comfortably, it will last for, you know, 20 minutes. And then the customers will want to carry something else, and that something else requires power, and it weighs the robot down and it ends up lasting 15 minutes, and somebody else puts something on and it ends up lasting 10 minutes, and none of it’s acceptable. You would have to be small and fly for at least a few hours to make it useful. With the filament, basically you get high-definition video images all the time, and then it has the added advantages in that it can’t be jammed, it can’t be spoofed, it can’t be intercepted. And it has unlimited power.”

Hence the tether, a clever adaption to today’s limitations enabling the drones to fly for as long as necessary, stream high-def images and sensor data to the base station for processing (instead of onboard), and with security assured (from the device at least) to the base station. [As an aside, the tether is enhanced by having the spooler autonomously controlled by the drone instead of the base station thereby reducing the chances for entanglement. Should it happen to snag or break, the vehicle can use its battery power to fly back to its point of origin.]

An example of an incremental product is the slow but steady movement toward autonomous cars. First there was adaptive cruise control (2001) which automatically adjusts your speed depending on the car in front. Next came active braking (2004), which could detect if a crash was imminent and apply the brakes if necessary. This was followed by lane assist (2008) and self parking systems. The 2014 Mercedes-Benz S Class by Daimler AG (ETR:DAI), will be the first car capable of fully driving itself (under certain minor limitations) by adding new rear-end sensors, pedestrian awareness and driver alertness cameras. The system will rely on 26 separate sensors, including radar and stereo cameras, to monitor traffic and pedestrians up to 650 feet in front. “Steering Assist” will steer in stop-and-start situations and at speeds up to 124 mph; it will slow entering curves but stay in its lane until the driver takes over. [This is just the beginning folks!]

Other incremental and transitionally useful consumer products include CaddyTrek‘s follow-the-golfer carts, Zodiac Marine & Pool‘s Polaris pool cleaners, Husqvarna‘s lawn mower (STO:HUSQ-B) and iRobot‘s (NASDAQ:IRBT) family of floor care products – all examples of early-adopter products for the tech savvy offering some level of utility for their stated tasks. 3D printers also fall into this category with a range of products from $300 on up to $1 million. The stocks of these companies have been highlighted by many of the analysts in recent months as great buys: Stratasys (NASDAQ:SSYS) (which just acquired competitor Objet), 3D Systems (NYSE:DDD) and Arcam AB (STO:ARCM). All three stocks have doubled in the last year. Alas, MakerBot, the do-it-yourself (DIY) phenom, is still privately held.

Really Great Inventions

The da Vinci surgical system by Intuitive Surgical (NASDAQ:ISRG), Kiva’s warehouse robots and goods-to-man concept (Kiva was acquired by Amazon (NASDAQ:AMZN) earlier this year), and Liquid Robotic‘s wave gliders are present-day robotics stars. Each is unique and disruptive to the way things were done and each is just a precursor to how things will be in the near future.

Less well known inventions are the inroads the larger industrial robot makers have been making with lightweight single and dual-armed robots capable of working alongside their human counterparts – without a protective barrier between them. Yaskawa Electric (TYO:6506), ABB (NYSE:ABB), KUKA (ETR:KU2), ST Robotics and Universal Robots all have new products making waves in the industry. Rethink Robotics‘ Baxter is the newest player in this trend toward robotic co-workers.

Toys, Kits and Academic Training Bots

WowWee’s Femsapien, Parrot’s AR.Drone quadcopter and Aldebaran’s Nao.

Toys like Parrot‘s (EPA:PARRO) AR.Drone quadcopter (a present-day global hit) and WowWee‘s line of robotic toys and pets (Robosapien, Roboraptor, etc.) have sold millions of units. Aldebaran‘s Nao robots have a large following in high schools and colleges partly because of their enticing humanoid form, their involvement in robotic soccer games, and their high functionality for low cost.

But there are also toys and other robotic items that whither because the developer didn’t want to be diverted into a business when all he/she wanted was to build something fresh and fun. Many of the tele-presence devices getting crowd-funding in recent months are fun-tech gimmick products with no long-term business plan or even interest in having one.

Don’t get me wrong. Robotic toys are likely to be the precursor to more useful robotic inventions – perhaps from the same inventors. But there is definitely an explosion of this kind of robotic toy – SWIVL, Autom, Sphero, Romo and Botiful being examples.

Within academia, industrial robot companies have donated and made available low-cost robots and teacher’s guides for high schools, junior colleges, tech schools and universities for years to help stimulate STEM careers and robotics in particular. Staubli’s Robot House at SCI-Arc, a leading architectural school in Southern California, is an example. But in recent years, more humanoid and open source robots are becoming affordable. Also helping speed up development are open source software resources such as Willow Garage’s ROS.

Healthcare Robotics

In a few recent articles in robotics and healthcare media, including one by the editor of Robotics Review, there has been a call for leadership – for national direction in strategic areas of the robotics industry, particularly in the area of healthcare. Henrik Christensen and the team involved with the publication and presentation of “A Roadmap for U.S. Robotics: from Internet to Robotics” began the process and it has slowly gained momentum.

Early last year President Obama established the National Manufacturing Competitiveness Initiative which included a section for robotics. The initiative was funded with $500 million, 10% earmarked for robotics. The scope of his directive was to insure that critical (defense and security) products were manufactured by Americans in America. Tom Clancy’s new book “Threat Vector” shows just how critical this can be in his fictional account of a virus planted on a foreign-made hard drive component installed in an American-made disk integrated into a high-security American defense installation.

Other countries – the EU, Korea and Japan in particular – have public-private consortiums working on difficult problems for which solutions are in the national interest, hence the reason why they are funded. Other than the American Manufacturing Initiative, American doesn’t have any such strategically-funded national interest projects (except military and defense).

To my way of thinking, advancements in healthcare shouldn’t be held up or otherwise thwarted because of patents, research funding or other corporate or personal (selfish) rationalizations. Patient care should be paramount, profits and profitability secondary. But that’s not the way it is at present nor will it change without political intervention.

I’d like to suggest a change similar to what Henry Ford did when confronted with a similar situation 100 years ago.

In the early years of automobile development, a group owned the rights to a two-cycle gasoline engine patent. By controlling this patent, they were able to monopolize the industry and force car manufacturers to adhere to their demands or risk a lawsuit. In 1911, Henry Ford won a challenge to the patent. The result was that the patent became virtually worthless and a new association – which would eventually become the Motor Vehicle Manufacturers Association – was formed. The new association instituted a cross-licensing agreement among all U.S. auto manufacturers: although each company would develop technology and file patents, those patents were shared openly and without the exchange of money between all the manufacturers. By the time the U.S. entered WWII, 92 Ford patents and 515 patents from other companies were being shared between these manufacturers, without any exchange of money – or lawsuits. The best braking system was shared by all as was the best window wiper, and many, many other inventions passed freely from one car company to the others. The result was that the user – the car driver – benefitted with the safest and best cars, no matter the brand – and the auto industry flourished as a result.

If an association like the MVMA – with a charismatic and visible leader – were to be launched in the medical robotics arena, perhaps the wonderful new inventions we’ve all read about would become available quicker and with less constraints, patents, and other hold-ups. Patients – you and I – care-givers and healthcare systems would all share in the benefits and lives saved which would come from focused development speed-ups in the robotics-related healthcare marketplace.

10. Robot and Frank Film looks toward elderly care future

Among films like Real Steel and I, Robot, Robot & Frank emerged from the Sundance Film Festival as a refreshing film that offered roboticists a realistic vision for robots in elderly care.

9. First robotics ethics and law conference

The University of Miami School of Law hosted the first conferenceon legal and policy issues relating to robotics, a sign of things to come as unique enable robotics technologies raise new philosophical and legal concerns for lawyers and policymakers.

8. Baxter brings manufacturing robotics to small businesses

For four years, Rodney Brooks’ Heartland Robotics (now called Rethink Robotics) remained in stealth mode as many wondered what the acclaimed researcher and iRobot co-founder was plotting for the “manufacturing” domain. Finally, we met Baxter, a two-armed robot that can be programmed by demonstration to perform pick-and-place tasks. But it’s the small $20,000 price tag that is turning heads.

7. Amazon acquires Kiva for $775M

Amazon shocked the robotics world with its $775 million acquisition of Kiva Systems, maker of the automated warehouse logistics robots. It may not be a price we’ll see again any time soon, but the purchase signals a maturation of mobile robots that have become an integral part of business logistics.

6. Robonaut, Curiosity pave the way in space, WAVE glider robot traverses Pacific

With recent news in Washington considering the future of NASA, 2012 was a great year for the agency’s robotics program. First, Robonaut aboard the International Space Station began the year with an iconic handshake with the ISS commander. Since then, it has performed a variety of tasks in flipping switches, turning knobs, and grabbing handrails. b. Of course there was the “terrifying” Mars landing of the Curiosity rover in July. Armed with an arsenal of tools and laboratory equipment, Curiosity is turning out to be a successful robotic explorer. And just this month we learned that an autonomous wave glider robot from Liquid Robotics completed its one-year, 9000-mile Pacific voyage from California to Australia.

5. U.S. Government flexes muscle with DARPA ROBOTICS challenge and NRI

Back in 2004 when DARPA announced its first Grand Challenge in robotics, a reliable driverless car was a dream. Now, well, see the #4 story of the year below. The blue sky agency is at it again with the Robotics Challenge, a $34 million effort with the goal of producing a capable humanoid robot for disaster response scenarios. An added innovation to the challenge is an open-source simulator being developed by the Open Source Robotics Foundation (OSRF), which will serve as a contribution to the community but also permit a software-only team to earn a humanoid hardware platform and advance to the second phase of the challenge.

A year after the Obama Administration announced the National Robotics Initiative, the National Science Foundation, the National Institutes of Health, and the U.S. Department of Agriculture announced $50 million in funding toward collaborative robots. While the amount is small compared to programs in Europe, Japan, and South Korea, the NRI is the first coordinated research funding focus in the U.S. for non-military robotic applications. For that, U.S. efforts come in at number five.

4. Driverless car legislation becomes law

The Google self-driving car has racked up 300,000 miles on the road as California, Florida and Nevada (last year) passed legislation setting up the procedures and requirements that will be needed for commercial driverless products. Several others, including D.C., are reviewing bills. With car manufacturers now introducing advanced sensors and increasing autonomy features in upcoming models, the legislation is ahead of the technological curve for once.

3. ROS turns 5

The Robot Operating System from Willow Garage. There’s not much more to say than I already have in previous posts. But a five-year anniversary for an open-source robotics software framework that continues to grow is a significant achievement. How fast has it grown? According to Tully Foote’s blog post at ros.org, there are 3699 public ROS packages (up from 1600 three years ago), 90 community-supported robot platforms (up from 50), and people are using ROS on all seven (yes, seven) continents. The recently launched Open Source Robotics Foundation is also a good sign for a sustainable movement.

2. Maker and start-up culture pushes robotics

In the same year that the iRobot Roomba celebrated 10 years on the market, we saw an acceleration of viable robotics businesses and products. For years many said that venture capitalists wanted nothing to do with hardware startups; they were too risky and required upfront capital, manufacturing, and inventory. That has clearly changed now, with increasing investments in robotics startups and entrepreneurs figuring out how to create products and solutions using robotics technology. The prestigious Y Combinator program funded Double Robotics and their price-shattering telepresence robot. Dmitry Grishin, a Russian investor, launched Grishin Robotics with $25 million of his own funds to invest in personal robotics companies. As of this writing, he’s invested in Double and the RobotAppStore. Furthermore, The Robot Report’s detailed map of nearly 1000 companies indicates 173 startups, 89 in the U.S. alone (not including many others still in stealth mode). And lest we forget the crowdfunding movement, which has spawned several robotics products and dozens more related “Internet of Things” devices. Some of our favorites: Romo, Hexy the Hexapod, OpenROV, and Autom.

Feeding into this hardware movement has been the growing maker culture, with a combination of 3D printers, hacker spaces, and inexpensive microcontrollers like the Arduino reducing the barrier to tinkering, building, and experimenting. Similarly, the Do-It-Yourself drone community has taken off with Wired Editor-in-Chief Chris Anderson leaving his post to take over 3D Robotics full-time.

1. Drones take center stage

It seems a week didn’t go by without a major story involving unmanned aerial vehicles (UAVs) as they continue to be used in warzones in Afghanistan and shadow campaigns in Pakistan, Yemen, and the horn of Africa. Regardless of the ethics, sovereignty concerns, and the like, drones have saturated the national discourse and are here to stay on the battlefield, and there is little doubt we will begin to see remote-controlled and semi-autonomous UAVs in domestic surveillance and commercial applications as soon as 2015 in the United States. For these reasons, they take the number one spot.

Have another top story we didn’t list? We’d love to hear them! Let us know in the comments section.

… In 2011, Motoman USA partnered with SwRI (Southwest Research Institute) to enable ROS software to be available to Motoman users. “The next step for industrial robotics is to be more sensor aware; to be able to accomodate the many new capabilities showing up in the service sector. It’s clear that ROS is able to handle all of these,” said Erik Nieves, Technology Director for Yaskawa America’s Motoman Robotics Division.

… From that venture came the SwRI-led ROS-Industrial Consortium (2012), dedicated to providing a common interoperable software language for existing industrial hardware. Last month, Fraunhofer IPA became the ROS-I organizer for the EU.

… ROS-I enables workcell visualization and simulation capabilities, and material handling in dynamic environments with on-the-fly object ID and grasp planning. It allows 2D-vision and 3D-point cloud perception systems.
… “It’s an exciting time in industrial robotics,” said SwRI senior research engineer Shaun Edwards. “After the economic downturn, the U.S. is now seeing a new government focus on manufacturing, a surge of venture capital spending in this area, and a trend toward returning manufacturing to homeland countries due to rising labor costs in other countries.”
… This is also the 5th anniversary of ROS. There are many hundreds of robots running ROS. More than 90 types and 28 robots come with supported installation instructions.

1.  iRobot Roomba or Create
2. ROS Electric installed on Ubuntu Linux and configured according to the tutorials
3. Some way of connecting the robot to your computer (1, 2, or modify a USB-to-serial connector to interface with the mini-DIN port). For teleoperation, you can use the connected computer, another computer, smart phone, tablet, iPad, or anything with a browser supporting web sockets.

Let’s get into the specifics. With ROS installed, you’ll need a few more packages that aren’t included in the base install. Rosbridge is a solid middleware package that is going to enable communication with ROS through a webpage. It can do a lot more, but this satisfies our goal for now. Let’s install that (from Brown screencast):

> sudo apt-get install ros-electric-brown-remotelab

You’ll also need a package to enable ROS to communicate with the robot. The package, at its most basic functionality, will listen for Twist messages (ROS-speak for motor drive commands), and convert it to the low-level serial commands for the roomba. (Though this tutorial focuses on roomba/create, you can use any robot with an existing ROS package, or write your own!) You have three options, based on your roomba model:

1. iRobot Roomba 500 series or up (uses iRobot OI spec [pdf])
2. iRobot Roomba pre-500 series (uses iRobot SCI spec [pdf])
3. iRobot Create (uses iRobot OI spec)

> mkdir ros_workspace
> cd ros_workspace
> mkdir myStacks
> cd myStacks
> git clone https://github.com/dpiet/robotsindc-ros-pkg

Be sure to rosmake. Check to make sure the directory (or parent directory) is included in the ROS package path:

> echo ROS_PACKAGE_PATH

If it’s not, add it:

> export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:/home/david/ros_workspace

There’s one more piece we need in order to control the robot through a webpage: the webpage. Fortunately, there are plenty of rosbridge examples out there and a javascript novice like me was able to hack together a simple page with keyboard inputs and button inputs. Download the page (or you already have it if you cloned the git repo) to your web server directory (if you’re running one) or to you /home and you need only modify the IP address to point to the computer controlling the robot. And that’s it!

Here’s the procedure for putting this altogether at execution:

In a separate terminal for each line, run the following commands:

> roscore
> rosrun roomba_400_series roomba400_light_node (assumes robot is attached to /dev/ttyUSB0)
> rosrun rosbridge rosbridge.py
(Optional) if you don't have a webserver, cd to your /home directory with the teleop.html file and use the magic of python:
> python -m SimpleHTTPServer

1. Grab your iPad (or other device), make sure it’s on the same wifi local network as the robot computer, and load up the page. If you’re running SimpleHTTPServer, type this in: http://[robot ip address here]:8000/teleop.html
2. If all goes according to plan you’ll get a rudimentary screen with buttons for directional control and a log showing connection status messages
3.  Happy roomba driving!

To recap, we connected a roomba to a laptop running: ROS, the open source Robot Operating System from Willow Garage; Rosbridge, a convenient middleware package from Brown University; and a web server (in this case Python’s SimpleHTTPServer). We were then able to load up a webpage with some javascript from a laptop, android smartphone, or iPad, with each able to drive the roomba with basic forward/reverse/left/right commands. Cool.

By using ROS and a few open source packages, we were able to get going with a moving robot via teleoperation with a simple user interface relatively quickly, or at least much quicker than if we were to program everything from scratch. So the benefit has been the ability to stand up a teleoperation robot in short order through code reuse. A criticism is that we used a fairly heavy framework, with a lot of pieces working under the hood, which means a lot of upfront work to read system documentation/tutorials and review examples. But as I argued above, the upfront cost is worth it, because now the robot is based on software modules with a vibrant community of contributors that facilitates code reuse without you having to reinvent the wheel or become a path-planning expert.

To take advantage of the upfront work we put in to learning ROS, we can now easily extend the first part of the tutorial and add a video feed to our web interface so we can now teleoperate remotely. Here’s what we need to add:
//

• The mjpeg_server ROS package (to install, download the package or svn checkout. cd into the directory and run “rosmake –rosdep-install”)
• Microsoft Kinect ROS package using OpenNI drivers (to install, run “sudo apt-get install ros-electric-openni-kinect”)
• A new html file with some additional javascript

The following video demonstrates the first run after integrating all the components on the robot. Not too bad, but there’s definitely room for improvement. Next steps will be to add a roslaunch file to our repo to simplify startup, accelerometer controls for navigation, and further testing to identify sources of lag.

Here’s the procedure for getting the demo running. Be sure to change the robot’s IP address as appropriate. Please note: this demo is currently compatible with ROS Electric, not the latest version, Fuerte.

In a separate terminal for each line, run the following commands:

> roscore
> rosrun roomba_400_series roomba400_light_node (assumes robot is attached to /dev/ttyUSB0)
> rosrun rosbridge rosbridge.py
> rosrun mjpeg_server mjpeg_server _port:=9091
> roslaunch openni_launch openni.launch
(Optional) if you don't have a webserver, cd to your /home directory with the teleop_video.html file and use the magic of python:
> python -m SimpleHTTPServer

Where can we go from here? We’ve essentially built a Turtlebot, replacing the iRobot Create with the roomba (though we’re obviously missing the convenient mounting hardware). So there are plenty of resources for integrating advanced behaviors like mapping, autonomous navigation, or even a manipulator arm. In particular, the Pi Robot project has done some interesting demonstrations with the Turtlebot platform.

Have a roomba gathering dust and a Kinect sitting next to your Xbox? Then you have all the major components to build a moving robot.

Robot manufacturers are beginning to shift their attention from industrial to service robots.

The robotics industry is on the cusp of a major transformation. Today’s factory robots are solitary precision instruments, mimicking the repertoire of capabilities of skilled craftsmen while repeating a handful of tasks thousands of times over. But future factory robots will likely have to be capable of thousands of tasks, performing each only several times, and they will work in collaboration with humans.

Furthermore, interest in nonindustrial robots is emerging at an even quicker pace, and new and larger marketplaces are opening up as never before. But that means some pretty significant shifts in design from caged robots to adjacent workers, from stationary position to portable motion, from programming intensive to easily trainable, and from connected to autonomous robots. Even as they work to improve upon their current industrial offerings, robotics companies are closely watching demand for co-robots, which are the safe, flexible, vision-enabled and easily trainable robotic assistants that science fiction movies made culturally popular.

Thus the reinvention of robotics is fundamentally a transition from industrial robotics to service robotics, and one that is demanding flexibility and versatility beyond what is presently available.

Facing the Major Technological Challenges:

The big industrial robot manufacturers are reinventing themselves in an effort to accommodate these changing realities. Companies such as Yaskawa Electric (Motoman), KUKA, Adept Technologies, and Bosch are fighting against technological challenges and against the clock to be relevant players in the robotics industry 2.0. However, companies face three major technological challenges that are impeding this shift and will require significant breakthroughs to propel the industry forward into the era of service robotics:

1. Grasping and manipulation in human-centered and open-ended environments
2. Learning through observation of human actions
3. Interaction and natural communication, including gestures and sounds

Examining the strategies and unique approaches of companies making this transition can lend insight into how manufacturers will overcome the technological challenges, position themselves among competitors, and bring new robots quickly to market.

Four Strategies for Transitioning from Industrial to Service and Co-Robotics:

• KUKA:

They’ve released a new lightweight and sensitive arm that can be affixed to a tabletop or workbench that is sensitive enough to safely work alongside humans. They also have plans to take their manufacturing and automation experience and enter new marketplaces, particularly entertainment (they have a ride robot), assembly and co-robotics (delta-type robots and lightweight arms working alongside humans), and healthcare and medical (cleanroom robots, lab robots).

Kuka has also developed an entirely different type of robot: the youBot.  It’s organized for the education and research marketplace and includes a mobile and also fixed 2-fingered 5 DOF plug and play robot arm selling for $31,000 and $21,000 respectively. youBots run the open source robotic operating system ROS prevalent in most major robotic learning centers and could be Kuka’s inroad to the co-robotic market.

• YASKAWA ELECTRIC (MOTOMAN):

Graphic from Yaskawa.co.jp website.

Yaskawa is developing a line of robotic products to fill the “Robotics Human Assist Business.” The SME marketplace is included in their plan as are new market areas where robotic devices augment and assist humans. Their plan covers workers, seniors, disabled people, and early adopters of other human-assist products.

On a recent visit to Tokyo, I met with Dr. Koji Tomita, Manager, Smart Robotics Center, Kazuo Miyazawa, General Manager, Smart Robotics Center and Shingo Ando, Manager, RT Control Technology Team (from left to right) and they showed me SmartPal V, a prototype for their next generation human assist robot.

Yaskawa is already marketing their two-armed Motoman multi-tasking robots and expects to begin introducing additional products and capabilities in 2015. They recently restructured their R&D by creating a new Smart Robotics Center (SRC) with the mission of accelerating R&D to enable human assist products and their 2015 target date.

• ADEPT:

Adept’s strategy is meshing proven business processes with new tech to form commercially ready solutions and involves (1) acquisitions to supplement and acquire capabilities it feels it needs for the future, and (2) aggressively marketing into new markets in food processing and materials handling.


One acquisition enabled Adept to add mobility to its line of products; another supplemented Adept’s food processing technology arsenal and offered a European base as well. Through it’s 2010 acquisition of MobileRobots, Adept now provides a mobile platform for a variety of purposes. One purpose is as a gofor in a hospital. They’ve teamed with Swisslog to ferry medicine from the dispensary to nurses stations and back again thereby enabling nurses to focus on patient care instead of getting things.

By acquiring InMoTx, a Danish provider of food-processing technology in 2011, Adept was able to add a portfolio of flexible gripping IP (intellectual property) for inspecting, sorting, grading and hygienically packaging unwrapped food products. Hygienically gripping irregularly shaped food products has emerged as one of the biggest constraints in automating food packaging. This acquisition expands Adept’s capabilities and supplements their goal of further capturing a share of the global food processing and handling market.

• BOSCH:

Many of the parts involved in Bosch’s manufacturing process are too small for present-day factory robots. So they have a two-pronged approach: learn, buy and partner from everyone and, if necessary, build their own robots. Their new home-built APAS robot is already being field tested in their factories for intricate handling and assembly work.

These four companies are each demonstrating the kinds of efforts required to make the transition successfully, but other companies are making moves that are noteworthy for this discussion:

• HEARTLAND ROBOTICS AND OTHER START-UPS:

• FOXCONN:

Foxconn assembly workers. Photo: Bobby Yip/Reuters/File

A version of this post originally appeared on Singularity Hub, June 6, 2012.

A version of this post originally appeared on Singularity Hub, June 6, 2012.

By Frank Tobe, Editor and Publisher

Robot manufacturers are beginning to shift their attention from industrial to service robots.

The robotics industry is on the cusp of a major transformation. Today’s factory robots are solitary precision instruments, mimicking the repertoire of capabilities of skilled craftsmen while repeating a handful of tasks thousands of times over. But future factory robots will likely have to be capable of thousands of tasks, performing each only several times, and they will work in collaboration with humans.

Furthermore, interest in nonindustrial robots is emerging at an even quicker pace, and new and larger marketplaces are opening up as never before. But that means some pretty significant shifts in design from caged robots to adjacent workers, from stationary position to portable motion, from programming intensive to easily trainable, and from connected to autonomous robots. Even as they work to improve upon their current industrial offerings, robotics companies are closely watching demand for co-robots, which are the safe, flexible, vision-enabled and easily trainable robotic assistants that science fiction movies made culturally popular.

Thus the reinvention of robotics is fundamentally a transition from industrial robotics to service robotics, and one that is demanding flexibility and versatility beyond what is presently available.

Facing the Major Technological Challenges:

The big industrial robot manufacturers are reinventing themselves in an effort to accommodate these changing realities. Companies such as Yaskawa Electric (Motoman), KUKA, Adept Technologies, and Bosch are fighting against technological challenges and against the clock to be relevant players in the robotics industry 2.0. However, companies face three major technological challenges that are impeding this shift and will require significant breakthroughs to propel the industry forward into the era of service robotics:

1. Grasping and manipulation in human-centered and open-ended environments
2. Learning through observation of human actions
3. Interaction and natural communication, including gestures and sounds

Examining the strategies and unique approaches of companies making this transition can lend insight into how manufacturers will overcome the technological challenges, position themselves among competitors, and bring new robots quickly to market.

Four Strategies for Transitioning from Industrial to Service and Co-Robotics:

• KUKA:

• YASKAWA ELECTRIC (MOTOMAN):

Graphic from Yaskawa.co.jp website.

Yaskawa is developing a line of robotic products to fill the “Robotics Human Assist Business.” The SME marketplace is included in their plan as are new market areas where robotic devices augment and assist humans. Their plan covers workers, seniors, disabled people, and early adopters of other human-assist products.

On a recent visit to Tokyo, I met with Dr. Koji Tomita, Manager, Smart Robotics Center, Kazuo Miyazawa, General Manager, Smart Robotics Center and Shingo Ando, Manager, RT Control Technology Team (from left to right) and they showed me SmartPal V, a prototype for their next generation human assist robot.

Yaskawa is already marketing their two-armed Motoman multi-tasking robots and expects to begin introducing additional products and capabilities in 2015. They recently restructured their R&D by creating a new Smart Robotics Center (SRC) with the mission of accelerating R&D to enable human assist products and their 2015 target date.

• ADEPT:

Adept’s strategy is meshing proven business processes with new tech to form commercially ready solutions and involves (1) acquisitions to supplement and acquire capabilities it feels it needs for the future, and (2) aggressively marketing into new markets in food processing and materials handling.


One acquisition enabled Adept to add mobility to its line of products; another supplemented Adept’s food processing technology arsenal and offered a European base as well. Through it’s 2010 acquisition of MobileRobots, Adept now provides a mobile platform for a variety of purposes. One purpose is as a gofor in a hospital. They’ve teamed with Swisslog to ferry medicine from the dispensary to nurses stations and back again thereby enabling nurses to focus on patient care instead of getting things.

• BOSCH:

• HEARTLAND ROBOTICS AND OTHER START-UPS:

• FOXCONN:

Foxconn assembly workers. Photo: Bobby Yip/Reuters/File

This is the continuation/conclusion of Morgan Quigley’s keynote address at ROSCon 2012. Part 2 of 2.
(Duration 42:05)

ROSCon 2012 Keynote, by Morgan Quigley, with introduction by Brian Gerkey, Part 1 of 2.
(Duration 23:46) Post revised 08Aug2012.

This video introduces TurtleBot 2, which was shown this past weekend at ROSCon 2012. TurtleBot 2, built around an iClebo Kobuki from Korean firm Yujin Robot, improves upon the original from Willow Garage. (Note that Sam Park, Executive Vice President of Yujin Robot, recently joined Brian Gerkey, Director of Open Source Development at Willow Garage, on the board of directors for the Open Source Robotics Foundation.)

1. Identify a need that can be filled with a robotic solution in a large marketplace and build a practical and specialized robotic product to satisfy that need.
2. Make it free and easy to design, program, simulate and test robotic applications and share your progress, problems and results with others all over the world using a common platform and the applications will come.

These two points of view were presented in a spirited cocktail party debate the other evening in Lyon, France at InnoRobo 2012, an innovation forum and trade show for service robotics. Here’s how it happened, who they were, and what they said.

Left: Robert Bauer, Executive Director, Commercialization, Willow Garage, a privately held corporation. Right: Colin Angle, Chairman of the Board, co-founder and CEO, iRobot (NASDAQ:IRBT).

I interviewed Colin Angle shortly after he gave a presentation about the need for robotic solutions in health care and asked him, amongst other questions, what he thought about Willow Garage’s ROS open source software concept. He said he thought it was dangerous to the industry and was fearful that it was also detrimental to the monetizing of the service robotics sector in particular.

Later I was meeting with Tim Field from Willow Garage when Robert Bauer joined the conversation. Bauer was a substitute Willow Garage speaker because Steve Cousins had to alter his travel plans. In his presentation, Bauer made the point that hardware was farther along than AI software and that AI, 3D and application software were where the robotics industry needed help.

Out of fun I told Bauer what Angle said and he became feisty and said he’d love to debate Angle as to which method contributed more to product development and commercialization.

Coincidentally, at a cocktail party for speakers, exhibitors and hosts that same evening, I was casually talking with Bauer when Angle came by to say hello to me and I introduced him to Bauer — and the fun began.

Angle suggested that freely providing such a key and critical component as the robotic operating and simulation system – and the extensive libraries that go with ROS – as Willow Garage does with their open source and unprotected robotic operating system (ROS) – was tantamount to letting the biggest consumer giant(s) gobble up any mass market applications and re-market them globally at low cost because they already have (or could easily reverse-engineer) the hardware, could produce it cheaply, the operating system was free courtesy of ROS, and the only real cost was the acquisition of the application(s).

Cover of 3/19/2012 issue of Bloomberg Businessweek magazine

Angle thought that it was dangerous and led to losing a potentially American/European market to offshore commodity conglomerates and said:

Robotics innovation represents a tremendous opportunity for economic growth akin to automobiles, aerospace and information technology. If we are to freely share our ‘intellectual capital’ on the open market we risk losing the economic engine that will advance our economies and send growth and jobs overseas.

The issue of losing trade secrets to foreign conglomerates was the subject of this week’s Bloomberg Businessweek magazine. Here’s a particularly relevant quote from the cover story – and keep in mind that the operating system mentioned was protected but hacked; nevertheless the story is relevant to this discussion:

In November, 14 U.S. intelligence agencies issued a report describing a far-reaching industrial espionage campaign by Chinese spy agencies. This campaign has been in the works for years and targets a swath of industries: biotechnology, telecommunications, and nanotechnology, as well as clean energy.

As the toll adds up, political leaders and intelligence officials in the U.S. and Europe are coming to a disturbing conclusion. “It’s the greatest transfer of wealth in history,” General Keith Alexander, director of the National Security Agency, said at a security conference at New York’s Fordham University in January.

[The article went on to describe the plight of AMSC, an American wind turbine developer, as they discovered that not only had their software been stolen, but Chinese companies had duplicated most of their component parts as well.]

AMSC technicians tapped into the turbine’s computer to get to the bottom of the glitch. The problem wasn’t immediately clear, so the technicians made a copy of the control system’s software and sent it to the company’s research center which produced some startling findings. The Sinovel turbine appeared to be running a stolen version of AMSC’s software. Worse, the software revealed that Sinovel had complete access to AMSC’s proprietary source code. In short, Sinovel didn’t really need AMSC anymore.

… On April 5, AMSC had no choice but to announce that Sinovel—its biggest customer, accounting for more than two-thirds of the company’s $315 million in revenue in 2010—had stopped making purchases. Investors fled, erasing 40 percent of AMSC’s value in a single day and 84 percent of it by September. The company’s stock chart looks like the EKG of a person rushing toward white light.

Colin Angle has consistently held that we are going about developing the robotics industry wrong: “The idea that a humanoid robot with arms would push a vacuum cleaner is an image that has set many expectations and, in some ways, has set back the industry,” when, by just rethinking what needs to be done, we can build a product that satisfies a specific need (vacuuming), as iRobot did with their Roomba line of robotic vacuums. “I used to think that I was a self-respecting high-tech entrepreneur, but it took me becoming a vacuum cleaner salesman to actually have some success for my company, my investors and myself.”

Bauer said that Willow Garage’s objectives were to stimulate the industry by enabling participants to not have to reinvent the many cross-science elements of robotics ventures; to reuse software under the premise that by so doing it saves developer time and allows researchers to focus on research. By giving them free access to the tools, libraries and simulation capabilities of ROS, its many libraries, and access to the PR2s that are available for testing and experimentation, Willow Garage hopes to advance the state-of-the-art in autonomous robotics technologies. Says Steve Cousins, CEO, “We want everyone to work together. We’re happy having a smaller piece of the pie, but having the pie be much bigger.”

Bauer also said that, once a successful app was developed, then the new endeavor would likely lock down the operating system and application software in order to protect their invention.

A version of this post originally appeared on Automaton, IEEE Spectrum’s robotics blog.

What’s the best approach to building commercially successful robotics companies? Here are two arguments from two prominent people in the robotics industry:

1. Identify a need that can be filled with a robotic solution in a large marketplace and build a practical and specialized robotic product to satisfy that need.
2. Make it free and easy to design, program, simulate and test robotic applications and share your progress, problems and results with others all over the world using a common platform and the applications will come.

These two points of view were presented in a spirited cocktail party debate the other evening in Lyon, France at InnoRobo 2012, an innovation forum and trade show for service robotics. Here’s how it happened, who they were, and what they said.

Left: Robert Bauer, Executive Director, Commercialization, Willow Garage, a privately held corporation. Right: Colin Angle, Chairman of the Board, co-founder and CEO, iRobot (NASDAQ:IRBT).

I interviewed Colin Angle shortly after he gave a presentation about the need for robotic solutions in health care and asked him, amongst other questions, what he thought about Willow Garage’s ROS open source software concept. He said he thought it was dangerous to the industry and was fearful that it was also detrimental to the monetizing of the service robotics sector in particular.

Later I was meeting with Tim Field from Willow Garage when Robert Bauer joined the conversation. Bauer was a substitute Willow Garage speaker because Steve Cousins had to alter his travel plans. In his presentation, Bauer made the point that hardware was farther along than AI software and that AI, 3D and application software were where the robotics industry needed help.

Out of fun I told Bauer what Angle said and he became feisty and said he’d love to debate Angle as to which method contributed more to product development and commercialization.

Coincidentally, at a cocktail party for speakers, exhibitors and hosts that same evening, I was casually talking with Bauer when Angle came by to say hello to me and I introduced him to Bauer — and the fun began.

Angle suggested that freely providing such a key and critical component as the robotic operating and simulation system – and the extensive libraries that go with ROS – as Willow Garage does with their open source and unprotected robotic operating system (ROS) – was tantamount to letting the biggest consumer giant(s) gobble up any mass market applications and re-market them globally at low cost because they already have (or could easily reverse-engineer) the hardware, could produce it cheaply, the operating system was free courtesy of ROS, and the only real cost was the acquisition of the application(s).

Cover of 3/19/2012 issue of Bloomberg Businessweek magazine

Angle thought that it was dangerous and led to losing a potentially American/European market to offshore commodity conglomerates and said:

Robotics innovation represents a tremendous opportunity for economic growth akin to automobiles, aerospace and information technology. If we are to freely share our ‘intellectual capital’ on the open market we risk losing the economic engine that will advance our economies and send growth and jobs overseas.

The issue of losing trade secrets to foreign conglomerates was the subject of this week’s Bloomberg Businessweek magazine. Here’s a particularly relevant quote from the cover story – and keep in mind that the operating system mentioned was protected but hacked; nevertheless the story is relevant to this discussion:

In November, 14 U.S. intelligence agencies issued a report describing a far-reaching industrial espionage campaign by Chinese spy agencies. This campaign has been in the works for years and targets a swath of industries: biotechnology, telecommunications, and nanotechnology, as well as clean energy.

As the toll adds up, political leaders and intelligence officials in the U.S. and Europe are coming to a disturbing conclusion. “It’s the greatest transfer of wealth in history,” General Keith Alexander, director of the National Security Agency, said at a security conference at New York’s Fordham University in January.

[The article went on to describe the plight of AMSC, an American wind turbine developer, as they discovered that not only had their software been stolen, but Chinese companies had duplicated most of their component parts as well.] 

AMSC technicians tapped into the turbine’s computer to get to the bottom of the glitch. The problem wasn’t immediately clear, so the technicians made a copy of the control system’s software and sent it to the company’s research center which produced some startling findings. The Sinovel turbine appeared to be running a stolen version of AMSC’s software. Worse, the software revealed that Sinovel had complete access to AMSC’s proprietary source code. In short, Sinovel didn’t really need AMSC anymore.

… On April 5, AMSC had no choice but to announce that Sinovel—its biggest customer, accounting for more than two-thirds of the company’s $315 million in revenue in 2010—had stopped making purchases. Investors fled, erasing 40 percent of AMSC’s value in a single day and 84 percent of it by September. The company’s stock chart looks like the EKG of a person rushing toward white light.

Colin Angle has consistently held that we are going about developing the robotics industry wrong: “The idea that a humanoid robot with arms would push a vacuum cleaner is an image that has set many expectations and, in some ways, has set back the industry,” when, by just rethinking what needs to be done, we can build a product that satisfies a specific need (vacuuming), as iRobot did with their Roomba line of robotic vacuums. “I used to think that I was a self-respecting high-tech entrepreneur, but it took me becoming a vacuum cleaner salesman to actually have some success for my company, my investors and myself.”

Bauer said that Willow Garage’s objectives were to stimulate the industry by enabling participants to not have to reinvent the many cross-science elements of robotics ventures; to reuse software under the premise that by so doing it saves developer time and allows researchers to focus on research. By giving them free access to the tools, libraries and simulation capabilities of ROS, its many libraries, and access to the PR2s that are available for testing and experimentation, Willow Garage hopes to advance the state-of-the-art in autonomous robotics technologies. Says Steve Cousins, CEO, “We want everyone to work together. We’re happy having a smaller piece of the pie, but having the pie be much bigger.”

Bauer also said that, once a successful app was developed, then the new endeavor would likely lock down the operating system and application software in order to protect their invention.

Kiva Systems shelf-moving robots. They slip under the shelves, screw themselves tight, and then bring the shelves to the picker/packers.

Supporting Angle’s position to find a problem and develop a unique robotic solution is today’s news that Amazon has acquired Kiva Systems (for $775 million!). Kiva Systems is the company that turned warehousing upside down by using robots to bring shelves to the pickers and packers instead of vice versa.

To Bauer, Angle suggested that ROS itself could be locked down, protected, and commercialized now – and that it should be done right away – and that what the robotic industry needs for inspiration is winning robotics companies – profitable companies with millionaire employees selling in-demand products, as would happen if ROS privatized; not more notches on the oversized belts of big offshore conglomerates. But he also said that unless ROS is protected and made stable and secure, it could never be used for sensitive (defense, space, security) solutions, and until it became rugged, secure and stable, it could never be used in factories that cannot afford down time from their robots or software.

He said it would make him happy if all the people that displayed their robots at Innorobo were successful and wealthy, but that the opposite was more likely because the right big-market robotic applications hadn’t happened just yet.

The discussion went on and ended with Bauer inviting Angle to continue the discussion onsite at Willow Garage and Angle agreeing to do it.

I hope I have presented the two positions fairly because I think that both sides have merit. Using the analogy that developing apps for smartphones and tablets is similar to developing applications for service robots in the open source community of shared libraries, imagine how much talent is being squandered in the whimsy of making a fun app? Do we have to sift through the chaos and diversity of thousands of apps to find the few – if any – that are suitable for real business tasks? Or would we be better served to rethink how we satisfy real needs by building specific products to satisfy those needs?

What do you think?

Willow Garage is out to make it happen in robotics.

They not only have developed a robot, the PR2, with sufficient dexterity to fold towels, and given eleven of these to research institutions around the world, but they’ve also released “an open-source, meta-operating system” for robots, called ROS, which you can download and use for free.

This is a great beginning, and could prove to be the seed of what develops into a standard platform.

Reposted from Cultibotics.