Category Archives: Robot Thoughts

Leading Applications for Autonomous Vehicles

I collect news daily for my website, The Robot Database. At this time, articles related to autonomous vehicles really dominate the newscape. Aggressive progress is evident related to organization partnerships and acquisitions, state laws to allow the entry of these vehicles, and technology advances related to important component and autonomous intelligence. I like to discuss the future of driverless vehicles with whomever has the interest. The opinions and concerns range as you would expect. Some folks look forward to safer roads, increased convenience, and new opportunities for people who currently don’t have access to automobiles. Other people are less amendable to turning the wheel over to an invisible source that cannot be reasoned with. Autonomous garbage truck by JMH.Obviously autonomous vehicles will be introduced incrementally and deliberately. In this short article I identify some applications that I consider good candidates for early phases of autonomous driving. I avoided precision farming and mining categories as those areas have numerous applications, many of which are already being developed. I will also keep out of the skies. I’ll save autonomous drone applications for another post. With each candidate application in this post, I indicate why I believe it is suitable to the early adoption of autonomous driving.

Trash collection
Occasionally I witness our garbage being collected. The large truck pulls up and a large, hydraulic metal claw grips our hundred gallon container and lifts it until the contents are emptied into the truck. I can see the driver monitoring this maneuver from a small screen on the dashboard. Each time I watch this sequence I wonder how long it will be until the whole operation is automated. I know that companies are already experimenting with driverless garbage trucks, but in the current cases, people are still required to empty the containers into the truck. It’s interesting to note that these trucks are already mechanically equipped with the “robot” required to empty the trash. The delta just involves automating the task that the drive performs here. Given the state of deep learning and object recognition, it’s no stretch to believe that the robot arm within the truck could perform this operation. Challenges would exist for the exception cases of a container that has been knocked over and anything else beyond the “sunny day” scenario.
Beyond the technical feasibility, there are some other aspects of trash collection that make it suitable to autonomous vehicles:

  • Speed: The vehicles will often travel at a low speed since they make frequent stops. If a municipality was willing to allow autonomous vehicles as long as they maintained speed below a certain threshold, that should not pose a serious limitation to the garbage trucks.
  • Time of day: The garbage trucks could travel their routes when the least amount of traffic could be expected on the roads. Traveling in these timeframes would minimize the trucks’ interactions with other vehicles.
  • Cost efficiency: Automation is expected to reduce cost in the long term. The cost savings realized by automated garbage collection would be relevant to this service if was provided by a private vendor or the local municipality.
  • Nature of work: Automation is particularly relevant to jobs that are mundane and dangerous. The job of trash collection is probably more mundane than dangerous but that quality makes the opportunity ripe for automation.

Delivery to the elderly and disabled
Not very long ago I was at a community event where the director of the “Meals-On-Wheels” program indicated that their biggest challenge is finding drivers (as opposed to food preparation and other administrative support). I immediately thought: it’s too bad these programs don’t have autonomous vehicles at their disposal. In addition to meal delivery, the elderly and disabled could benefit from cost-effective delivery of groceries and medicine as well.
So this application is suitable to driverless vehicles for several reasons:

  • Speed: Similar to the garbage collection scenario, these vehicles would not be significantly limited by speed restrictions; they would not be handling emergency situations.
  • Community sentiment: It is likely that a typical hurdle for the introduction of automated vehicles into communities will be overcoming the concerns of the community. But if this particular application serves the community, it may serve as an entry point for driverless cars: the community may decide to allow autonomous vehicles for this specific purpose. And perhaps after a time period of expected minimal incident, the community may be open to expanding the use of autonomous vehicles.

Admittedly there is probably some need for mechanical innovation with the vehicles that handle this task. The would require secured compartments to allow the delivery of the appropriate items to the appropriate recipients. Depending on how many customers a vehicle needed to serve on one route, the compartments may require heating or cooling. And given the nature of the customers being serviced, the vehicles would likely require cameras and some potentially semi-automated alerting system.

Snow removal in office complexes
For now I’m limiting the snow removal job to business parking lots. I believe the job is simpler than handling individual driveways and avoids the likely hazardous public road scenarios. I know that companies such as Kobi are looking into automated snow removal for the private consumer. For this application, I envision a vehicle that may look different from the typical plow-mounted truck. Picture a snow-throwing type unit that throws the snow behind it and caught in an open-top trailer container. Upon filling, the container could be dumped hydraulically (yes, I know first hand that snow is heavy…) on the parking lot perimeter. A complex could potentially utilized a fleet of these vehicles if necessary.
Snow removal offers a good opportunity for driverless vehicles for these reasons:

  • Setting: As mentioned above, isolating these vehicles to a private lot could alleviate concern and possibly circumvent state and municipal laws. If these vehicles need to serve multiple corporate premises, they could potentially be moved by person-driven hauler trucks.
  • Cost efficiency: Again, we would expect this approach to reduce cost in the long run as automation typically proves to do.
  • Nature of work: For obvious reasons, the work of removing snow can be unpleasant, uncomfortable due to the cold conditions, and even dangerous. The timing of the storm may cause the drivers to work through the night. This type of task is suitable to automation due to its nature.
  • Leveraging algorithms: I indicated that a corporate site may want to utilize one or more of these vehicles to handle snow removal. Given the number of vehicles involved and the layout of the parking lot, the vehicles could be coordinated by algorithms that assign them the most efficient routes where they avoid each other and dump the snow in a properly distributed manner. The entire fleet solution could sync constantly with weather feeds and human supervisors in case more vehicles need to be awakened or deployed. The assigned routes would be adjusted appropriately. Although a bit complicated, this routing is a task that is solved by a computer much more easily that it could be worked out by human drivers in real time.

Weed harvesting in lakes
I recently vacationed on Lake Minnetonka in Minnesota. While out on the boat one day, I noticed a strange looking barge-like vessel with a large wire basket in front of it. Our hosts explained that the craft was a weed harvester…kind of like a lawnmower for the lake. It was larger than but somewhat similar to the boat pictured here. Bdg kosiarka Brda 1 7-2015
The drivers of these boats navigate the lake and remove excess seaweed as necessary. I asked the locals if the seaweed was used to make compost but they didn’t know (or really care all that much).

  • Time of day: The harvesting could be done at night when there are fewer boats on the water. The autonomous harvester would rely on GPS and LIDAR for its navigation. I imagine LIDAR and other sensor technologies could be used to find and identify the weeds.
  • Nature of work: I have to admit I have never worked as a weed harvester but the task seems straightforward enough to believe that it could be automated. Like the other tasks mentioned the mundaness of the task makes it appropriate for automation.

So there is a short list of applications for driverless vehicles that could lead the widespread presence of autonomous vehicles on the public roads across the country. I understand there are many operational and safety details that I haven’t addressed for each idea. I’ll be keeping an eye out for progress in this area and I’ll be sure to update the list with new ideas that occur to me. Thanks for reading.

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