Category Archives: Robot Thoughts

Is This Robot Worth It?

Eight inches of new-fallen snow covers my driveway. As the final flakes drop, I ponder how and when I will address the situation. Suddenly, there is a knock at my front door. I open it and a man with a snow shovel says, “Hello. I will shovel your driveway for $40 if that offer pleases you.” Well, it does. I agree to the terms and he begins the task. When he finishes, I gladly pay him the amount he proposed. Putting the money in his pocket he then says, “For another $40 I will come into your house and dance while playing my accordion.” I try to present a polite expression as I answer, “I’m sorry…it’s nothing against you or accordions, it’s just that it’s not worth it to me.” He looks towards the ground pensively and nods. Then he turns to me and says somewhat contemplatively, “This is really how things are with service robotics, right?”
My eyes widen, “Yes!”, I respond. “You’re exactly right!”
Then I suddenly awake from the dream. Somewhat disoriented. Enlightened. A little hungry…

In order to maintain the content on my website, The Robot Database, I follow the news on robotics daily. There seems to be consensus on the prediction that the market for service robotics is poised for tremendous growth over the foreseeable future. The term “service robotics” is a catch-all category involving robots other than the manipulator arms and similar structures that weld, paint, palletize, build circuit boards, etc. This latter group of machines is referred to as “industrial robots”. I expect the definition of service robots to evolve and be refined over time. Right now the category is being subclassed somewhat informally into field robotics, healthcare robotics, consumer robotics, etc. I wouldn’t be surprised if the term “service robots” becomes somewhat meaningless in the not-too-distant future due to the scope of applications it eventually covers.

Robotics is not a fad market. Consumers and businesses will eternally be attracted to the promise that robots deliver. They afford us more quality time by performing work we don’t want to do. They save corporations money by automating manual labor, often more effectively. But
in order to fulfill the optimistic projections in growth, service robots must match market demands in capability and price. I see value of service robots described in three levels: utility value, niche value, and novelty value.

The robots that succeed in providing utility value have the widest market and will be appropriately priced. This market includes products like robot vacuum cleaners and personal assistants or home automators. Companies like iRobot had a good year in 2016 as more people are sold on the value of robot vacuum cleaners. As far as personal assistants and home automation, I’m pretty sure I placed my order for an Amazon Echo the day I found out about it. I was working on a software application that would help me manage my calendar and to-do list and could perform tasks like reporting the weather. When I saw a product that could provide these services being sold for under $200 the value proposition was very compelling to me. I haven’t bought a robot vacuum cleaner yet but that is mostly due to the fact that my house is too cluttered for the robot to be reasonably effective. There are robots that will be very interesting to watch. One such robot is a lawn maintenance and snow removal machine from the Kobi Company priced at around $4000. Another is a laundry-focused robots such as Laundroid and FoldiMate.

Robots that provide niche value have a smaller market but will be typically priced much higher due to the specialized capability they provide. These robots are often in markets that offer high-priced services to their end customers. Robot surgical systems are a good example of this category. These devices can cost several million dollars and incur ongoing service contracts on top of that. But the success of the incumbent companies in this space and the emergence of new competitors validates the market. There are at least two companies creating bricklaying robots. Fastbrick Robotics recently put a $2million price tag on its flagship robot. These robots are not as mature in the market as their surgical counterparts. That being said, if they prove capable, they will disrupt the industry. At the time of this writing, Fastbrick Robotics is trading around $0.10 a share (#wishICouldInvestOnTheAustralianExchange…). Other robots that may provide niche value include mobile security robots, germ-zapping robots, and the impressive humanoids and quadrupeds from companies like Boston Dynamics that haven’t yet seemed to find a reasonable market outside of research.

Some robots are intended for novelty value. Cozmo, the intelligent little truck from Anki sold very successfully in the 2016 holiday season for about $180. I saw some videos and read reports on Cozmo and it sounded really neato. Now I am not ready to spend $180 on “neato” but it’s clear that other people are. The robots that provide novelty value will require a market with enough disposable income to get past the price tag. So that “purchase threshold” will be driven by how much novelty the robot provides and how expensive it is. I mentioned that some robots are intended to provide novelty value. Some robots that are intended for utility value or niche value may have to settle for novelty value if they can’t provide the appropriate capability for the cost. Interesting examples of robots that currently straddle the niche/novelty divide are the humanoid robots from Alderbaran and Softbank such as Nao and Pepper. The price of these robots runs into the thousands of dollars but they cannot perform any type of labor that a human can. Don’t get me wrong…if somebody handed me a Nao robot and said, “It’s all yours…no strings attached…”, I would be incredibly happy and would probably be up all night just trying to make it do silly things like dance and play the accordion. But due to their sticker price I can’t justify a purchase because, for my needs, it just isn’t worth it. However, these robots are being applied to niche applications including concierge services, education, and even to help children with autism. Most of these applications are experimental so I believe it’s fair to say that the question of “niche or novelty” is still open.

Some closing thoughts on service robots and their value… Recently my seven-year-old son asked me if I could play a game with him and I explained I had to first finish washing the dishes. A bit disappointed, he asked me if there was a robot that could do all the housework and how much would it cost? His question caused me to ask myself: how much would I pay for a robot that could do all my chores effectively? After considering it for a bit I arrived at the qualitative answer: a lot. Seriously, a whole lot of money. I’m talking about “nice car” kind of money. Things aren’t very different for robots than they are for any sellable product. The market is just not well-tested for many of these revolutionary machines so the companies making them may not have a good idea of the marketable price. In order to successfully sell their robot products, these companies will need to understand the capabilities and level of value they offer, and price them appropriately. Like many people that are interested in these developments, I’m betting on the eventual ubiquity of service robots. It will be interesting to see just how and when the events occur.

Categorizing Robots

I’ve started working on an open source project that involves the design of a database schema to support the collection and searching of information related to robotics. I ran into a challenge that is fundamental to the database’s design and value: how to construct and populate categories for the robots. Naturally, I searched the web for relevant resources that could provide insight on these values. Although I am admittedly much more of an application designer than robot expert, I was not comfortable with the way information was organized in many cases.

Some examples of the items that confused me:

  • One prominent, robotics-focused website listed these values as “market segments” (or at least implied that categorization):
    Airborne, Education & Research, Engineering, Humanoid, Industrial, Manipulator, Maritime, Medical & Assistive, Mobile, Software. But I would argue that the values: Humanoid, Manipulator, Mobile, and Software do not really identify market segments (a group of individuals or companies that comprise a categorical market for your products and services).
  • I’ve also seen content that differentiated between tethered vs. autonomous robots. This differentiation seems to address the mobility of robots, but I think the “autonomous” term should be used to described how well a robot can “think and act on its own” regardless of whether or not it is tethered at all. And if I had a humanoid robot in my house that could walk around but required a very long tether for power and/or communication, I would consider that robot mobile.
  • Some terms like “field robotics” seem ubiquitous and important but I’m having trouble finding a structured home for them…

Rather than elaborate with more examples, I would like to (humbly and carefully) propose a categorization scheme that I believe would effectively support a user’s search for robots based on defining criteria. I am very much interested in getting feedback from others on this effort.

For starters, I am currently using these properties to categorize a robot:

  • Structure Type
  • Category
  • Market Segment
  • Applications
  • Features
  • Qualifiers

I’ll explain what each of these properties means and what the expected values would be.

Structure Type

  • This property defines the basic physical structure of the robot.
  • For ease of entry and searching, I will attempt to maintain structure types as a flat list without a hierarchy.
  • A robot in the robot database should be associated to exactly one structure type.
  • Proposed values for this property include:
    • Humanoid
    • Rover
    • UAV/Drone
    • Manipulator/Arm
    • Aquatic Submersible
    • Aquatic Surface Vessel
    • Exoskeleton
  • I know this categorization isn’t perfect. How do you classify a wheeled robot that has an articulated arm? I would classify it as a Rover, since that is the primary defining structure, with a feature of an arm (more on that when I cover features). How would you classify Baxter on a wheeled platform? I would classify it as a Manipulator/Arm with a mobile feature for similar reasons.

Category

  • This property defines the general area or domain for the robot.
  • The category will be maintained as as a flat list without a hierarchy.
  • A robot in the robot database should be associated to exactly one category.
  • Proposed values for this property include:
    • Fields Robotics
    • Medical Assistive
    • Industrial
  • On a side note, when designing applications in general, I try to avoid or qualify properties with names like “type” or “category” because all of these properties are designed for typing and categorizing. However, I will use them when no better terms come to mind.

Market Segment

  • The market segment indicates the target group of persons or companies that would utilize the robot.
  • For ease of entry and searching, I will attempt to maintain market segment as a flat list without a hierarchy.
  • A robot in the robot database can be associated to many market segments.
    The proposed list of market segments includes:

    • Aerospace
    • Agriculture
    • Defense
    • Healthcare
    • Manufacturing
    • Private Consumer
    • Retail
    • Transportation

I expect I will find some reason to modify this list as I collect data.
Some examples related to these market segment values:

  • I would indicate that robots that automate warehouses belong in the Retail market segment (maybe others). I would include “Warehouse automation” as one of their applications, but more on applications later…
  • I would say that autonomous automobiles primarily apply to the Private Consumer and Transportation markets segments. Note that since market segments categorize the target market, the transportation market segment in this case would identify the likes of cab companies that might want an autonomous automobile. If we were discussing a robotic bus, I would argue that the transportation market would make sense but the private consumer would not since the average person is not in the market for a bus (as they may be for an automobile).

Applications

  • Applications will identify specific uses for a robot. These values will typically line up with market segments but the database will not link applications to market segments at this point — just to robots.
  • Applications will be managed as a flat list without a hierarchy.
  • A robot in the robot database can be associated to many applications.
  • I imagine the list of values could become extensive. Here is an abbreviated list of proposed values:
    • Aerial photography
    • Autonomous driving
    • Building construction
    • Bomb disposal
    • Caretaking
    • Electronic component production (IC, PCB, etc)
    • Education
    • Entertainment
    • Floor vacuuming
    • Fruit-picking
    • Home/business security
    • Lawn maintenance
    • Medical surgery support
    • Mining
    • Packaging
    • Painting
    • Personal mobility assistance
    • Personal service assistance
    • Research
    • Rescue support
    • Soldering
    • Surveillance
    • Telepresence
    • Transport/haulage
    • Warehouse automation
    • Welding
  • Note that with this approach “Agriculture” would not be a good application as it is too broad. The model prefers more specific values like “Weed control”, “Fruit-picking”, “Pest control”, and so forth.

Features

  • Features will be used to identify certain characteristics of a robot.
  • These features will be geared to support valuable robotic searches; values like “Elegant” and “Plastic” are not appropriate values for this list.
  • A robot in the robot database can be associated to many features.
  • I imagine the list of values will also become extensive. Here is an abbreviated list of proposed values:
    • Articulated arm
    • Autonomous
    • Bipedal
    • Collaborative
    • Differential drive
    • Hexapod
    • Mobile
    • Quadruped
    • Swarm
    • Tethered
    • Treaded

Qualifications

  • An all-encompassing definition of what constitutes a robot seems to be elusive. There are however certain characteristics that exemplify what many will consider to be a robot. This property presents a predefined set of criteria to help determine how the individual robot measures against qualifications.
  • The database defines these qualifications to be evaluated per robot:
    • Has Sensors (does the machine have environmental sensors?)
    • Has Actuators (does the machine include motors and devices that move?)
    • Sensor/Actuator Controlled (does the machine include logic to drive actuators based on sensor input?)
    • Programmable (can the machine be programmed with instructions?)
    • Autonomous (does the machine employ algorithms to handle challenges without user-intervention?)
  • Every robot may be rated for each of these qualifications with one of these values:
    • Demonstrates
    • Partially demonstrates
    • Does not demonstrate
  • We can evaluate the robot-ness of machines using this scale. Take these examples:
    • Remote controlled car
      • Has Sensors : Partially demonstrates (has an RC receiver)
      • Has Actuators : Demonstrates (has motors that drive wheels)
      • Sensor/Actuator Controlled : Partially demonstrates (user sending RC signals drives motors)
      • Programmable : Does not demonstrate
      • Autonomous : Does not demonstrate
    • da Vinci Surgical System (best guesses…)
      • Has Sensors : Demonstrates
      • Has Actuators : Demonstrates
      • Sensor/Actuator Controlled :Partially demonstrates
      • Programmable : Does not demonstrate
      • Autonomous : Does not demonstrate
    • Mars Curiosity Rover
      • Has Sensors : Demonstrates
      • Has Actuators : Demonstrates
      • Sensor/Actuator Controlled : Demonstrates
      • Programmable : Demonstrates
      • Autonomous : Partially demonstrates

Finally, I plan on including some fields in the robot table that are commonly used to describe a robot including physical dimensions and weight and degrees of freedom.

Once again, the structuring and population of all the classification properties described above are intended to best support categorical searches for robots. I kept that goal in mind when writing this content. That being said, I am very interested in feedback from anybody, especially experts in robotics.

Thanks!

 

Simple tutorial on rosbridge and roslibjs

This tutorial demonstrates how to create a simple web page that communicates with ROS using rosbridge and roslibjs.
No previous knowledge of ROS is really necessary to try out the code in this tutorial but I will not go into great detail on the concepts of ROS and its commands and utilities.

Configuring your system for the tutorial

This section will step you the installations required to carry out the demo.

1. Install ROS

If you do not have ROS installed on your computer, install it following the instructions here.
I am using the hydro release on my computer. Other releases will probably work but the names and structures of topics and messages might be slightly different. Also, this tutorial will use the turtelsim demo program so you will need that installed. The desktop-full installation of ROS includes this demo. I chose to set my environment as indicated in section 1.6 to add the ROS environment variables to all new terminal windows. Finally, this tutorial will assume you are running ROS on Linux.

2. Install rosbridge

Open up a terminal window and type

 sudo apt-get install ros-hydro-rosbridge-suite

Detailed instructions can be found here, but note that they relate to the groovy release, not hydro.

Turtlesim introduction

Before I get into the details of rosbridge, I will use the turtlesim demo to introduce some fundamental ROS concepts and commands. If you encounter problems in this section, your computer is probably not configured correctly. Refer back to the installation links for details on setting everything up.

1. Run roscore

Open up a terminal window and type

 roscore

This command runs the ROS master program that runs the services and coordinates communication between publishing and subscribing nodes. More detail on those terms and concepts will follow.
You can minimize this terminal window after you start roscore.

2. Run the turtlesim simulator window

Open up a terminal window and type

 rosrun turtlesim turtlesim_node

This command will launch the application that displays the simulated turtle robot. ‘turtlesim’ is the name of the ROS package and ‘turtlesim_node’ is the name of the application within the package that will be executed. The turtle icon in the window is essentially listening for movement message instructions.
You can minimize the terminal window used to launch the simulator.

3. Run the turtlesim control window

Open a terminal window and type

 rosrun turtlesim turtle_teleop_key

This command will run the ‘turtle_teleop_key’ application node within the ‘turtlesim’ package. In order to send commands to the ROS master, this terminal will need to have focus as you type the left, right, up and down arrow keys.

4. See the list of ROS topics

Open a terminal window and type

 rostopic list

This command will list the currently available topics driven by roscore and the nodes that were launched. Topics are essentially channels that node applications can publish and subscribe to. The concept pub/sub messaging systems is a common model in software systems. I will not go into the ideas in detail but quickly say that the concept is fundamental to ROS and very relevant to a system were sensors, actuators, and so forth may be interdependent and interchanged.
One of the topics that you should see displayed by this command will be of particular interest to us. It’s fully qualified name is:
/turtle1/cmd_vel

5. Find the message type for the relevant topic

In the same terminal window type

 rostopic info /turtle1/cmd_vel

This command will display information about the topic including the type of messages that will be published and consumed. Messages are objects in the sense that they can be composed of primitive values and other structures containing primitive values. The message type for the /turtle1/cmd_vel topic is indicated as
geometry_msgs/Twist

6. Investigate the message structure

In the same terminal window type

 rosmsg show geometry_msgs/Twist

You will see this output

 geometry_msgs/Vector3 linear
   float64 x
   float64 y
   float64 z
 geometry_msgs/Vector3 angular
   float64 x
   float64 y
   float64 z

This output indicates that the geometry_msgs/Twist message structure is composed of two structures of another ROS-type: geometry_msgs/Vector3. The properties of this type within the geometry_msgs/Twist type are named linear and angular.
If you run this command in the terminal window

 rosmsg show geometry_msgs/Vector3

you will see that type is composed of three float64 properties named x, y, and z.

7. Monitor messages sent to the relevant topic

In the same terminal window type

 rostopic echo /turtle1/cmd_vel

This command will display information related to the messages published to the named topic, in this case: /turtle1/cmd_vel
The command will run in the terminal window until it is terminated with a Ctrl+C.

8. Run the demo

Finally, time to take the turtle for a ride. The three relevant terminal windows for this step are the simulator display (step 2), the control window (step 3), and the window that will echo messages sent to the relevant topic (step 7). Make sure all three windows are visible on your desktop.
Click in the control window to give it focus. Then use the arrow keys to rotate and move the turtle.
Observer the output in the topic echo window. Note how the values change depending on the keys you press. For example, if you press the up arrow you should see this output:

 linear:
   x: 2.0
   y: 0.0
   z: 0.0
 angular:
   x: 0.0
   y: 0.0
   z: 0.0

Before we start on the next section that investigates how rosbridge works, I will summarize the important points of this section:
The roscore master was started in order to manage the communication of messages between publishing and subscribing nodes
The simulator window node was launched as a subscriber to the topic relevant to the demo
A terminal window was opened to publish messages to the topic relevant to this demo

Controlling turtlesim from a web page

In this section we will build a minimal html page to control the turtle in the simulator.
The section will use rosbridge which includes a set of tools that provide a JSON API for communication with the ROS server. I should point out that I am fairly new to ROS in general. One of the first things I learned was that node applications were typically written in C++ or Python: two languages that I am not proficient in. So I was interested in the idea of rosbridge that would allow ROS communication using tools like JavaScript over WebSocket. This section will also use the ROS JavaScript library, rosblibjs. Much of what I am writing in this section is based on what I learned in this tutorial.

1. Launch rosbridge

Open a terminal window and type this command

 roslaunch rosbridge_server rosbridge_websocket.launch

This command will run rosbridge and open a WebSocket on port 9090 that our web page will use to communicate with ROS.

2. Create an html file control panel

This web page is intended to demonstrate how roslibjs and rosbridge can be used to communicate with ROS. The page will not employ best practices like the use of style sheets or JavaScript libraries like jQuery. I will annotate the web page with comments that will explain the important lines.

<!DOCTYPE html>
<html>
<head>
<!-- Based on demo found here:
http://wiki.ros.org/roslibjs/Tutorials/BasicRosFunctionality
http://wiki.ros.org/roslibjs/Tutorials/BasicRosFunctionality
-->

<!--
The next two lines bring in the JavaScript files that support rosbridge integration.
-->
<script type="text/javascript" src="http://cdn.robotwebtools.org/EventEmitter2/current/eventemitter2.min.js"></script>
<script type="text/javascript" src="http://cdn.robotwebtools.org/roslibjs/current/roslib.min.js"></script>

<script type="text/javascript" type="text/javascript">

// This function connects to the rosbridge server running on the local computer on port 9090
var rbServer = new ROSLIB.Ros({
    url : 'ws://localhost:9090'
 });

 // This function is called upon the rosbridge connection event
 rbServer.on('connection', function() {
     // Write appropriate message to #feedback div when successfully connected to rosbridge
     var fbDiv = document.getElementById('feedback');
     fbDiv.innerHTML += "<p>Connected to websocket server.</p>";
 });

// This function is called when there is an error attempting to connect to rosbridge
rbServer.on('error', function(error) {
    // Write appropriate message to #feedback div upon error when attempting to connect to rosbridge
    var fbDiv = document.getElementById('feedback');
    fbDiv.innerHTML += "<p>Error connecting to websocket server.</p>";
});

// This function is called when the connection to rosbridge is closed
rbServer.on('close', function() {
    // Write appropriate message to #feedback div upon closing connection to rosbridge
    var fbDiv = document.getElementById('feedback');
    fbDiv.innerHTML += "<p>Connection to websocket server closed.</p>";
 });

// These lines create a topic object as defined by roslibjs
var cmdVelTopic = new ROSLIB.Topic({
    ros : rbServer,
    name : '/turtle1/cmd_vel',
    messageType : 'geometry_msgs/Twist'
});

// These lines create a message that conforms to the structure of the Twist defined in our ROS installation
// It initalizes all properties to zero. They will be set to appropriate values before we publish this message.
var twist = new ROSLIB.Message({
    linear : {
        x : 0.0,
        y : 0.0,
        z : 0.0
    },
    angular : {
        x : 0.0,
        y : 0.0,
        z : 0.0
    }
});

/* This function:
 - retrieves numeric values from the text boxes
 - assigns these values to the appropriate values in the twist message
 - publishes the message to the cmd_vel topic.
 */
function pubMessage() {
    /**
    Set the appropriate values on the twist message object according to values in text boxes
    It seems that turtlesim only uses the x property of the linear object 
    and the z property of the angular object
    **/
    var linearX = 0.0;
    var angularZ = 0.0;

    // get values from text input fields. Note for simplicity we are not validating.
    linearX = 0 + Number(document.getElementById('linearXText').value);
    angularZ = 0 + Number(document.getElementById('angularZText').value);

    // Set the appropriate values on the message object
    twist.linear.x = linearX;
    twist.angular.z = angularZ;

    // Publish the message 
    cmdVelTopic.publish(twist);
}
</script>
</head>

<body>
<form name="ctrlPanel">
<p>Enter positive or negative numeric decimal values in the boxes below</p>
<table>
 <tr><td>Linear X</td><td><input id="linearXText" name="linearXText" type="text" value="1.5"/></td></tr>
 <tr><td>Angular Z</td><td><input id="angularZText" name="angularZText" type="text" value="1.5"/></td></tr>
</table>
<button id="sendMsg" type="button" onclick="pubMessage()">Publish Message</button>
</form>
<div id="feedback"></div>
</body>
</html>

 What Did We Do?

So what did we accomplish in this tutorial? Something pretty cool in my opinion: we created a new controller for the existing turtlesim node without modifying that code
at all. The decoupled publish/subscribe approach that ROS supports made this accomplishment possible. I could argue that the simple node we created is superior in some ways to the command window that comes with the complete ROS installation:

  • It seems that the arrow keys always send a 2 or -2. We can send any values using our web page to make the movements greater or finer grained.
  • As much as I tried, I could not send linear and angular values in the same message by pressing the keys simultaneously. We can do that with the web page which allows the turtle to travel in arc paths.

Of course we only published a message in this tutorial. I should point out that there is much more you can do with roslibjs including:

  • Subscribing to topics in order to receive messages
  • Utilizing services hosted within ROS
  • Retrieving a list of current topics within the ROS server

Next Steps

So what’s next? I think I’m going to get myself one of those Baxter robots for $25K, build the appropriate web application and never wash dishes again. Ok, maybe not yet…soon, but not just yet. There are probably a couple of other tracks I can progress on first.
Implementation on Raspberry Pi
I have another long term goal to build a disruptively affordable mobile robot platform and implement the first one as an outdoor rover. I imagine that the robot will be controlled by an SBC like a Raspberry Pi and involve an Arduino board. I have heard that some people have found it challenging to run ROS on the Raspberry Pi but it looks like there have been some successes as well. I imagine I would start by just running the minimal amount of ROS on the Raspberry Pi and use my desktop computer for development and debugging, etc. I imagine I could install Apache or Tomcat on the Raspberry Pi, but it may make sense to build a lightweight http server using libraries like Node.js and socket.io. I also want to try to use Cylon.js for tasks like communicating with the Arduino.

Better UI

Ok, I feel like we’re pretty close friends now so I will tell you this: the web page built in this tutorial is not all that attractive or slick. There are a lot of options for incorporation:

  • jQuery UI has a number of great widgets
  • jQuery mobile makes it very easy to develop applications for mobile devices
  • I know some great developers that are favoring Ember.js in order to create ambitious web applications

Looking forward to seeing what others to with rosbridge and roslibjs. Many thanks to everyone involved in these projects.

turtle