Monoprice Vacuums Are Tempting For Robot Hacking

The original research hardware for ROS is the Willows Garage PR2, a very expensive robot. To make ROS accessible to people with thinner wallets, the TurtleBot line was created. The original TurtleBot was based on the iRobot Create, a hacking-friendly variant of their Roomba home robot vacuum. Even then, the “low-cost” robot was still several thousand dollars.

The market has advanced in that time. TurtleBot 3 has evolved beyond a robot vacuum base, and the iRobot Create 2 itself is available for $200. Not exactly pocket change but far more accessible. The market pioneered by Roomba is also no longer dominated by iRobot, with lots of competitors, which brings us to cheap Chinese clones. Some of which are sold by Monoprice, and right now, it seems like Monoprice is either abandoning the market or preparing for new products – their robot vacuums are on clearance sale presenting tempting targets for robotic hacking.

Monoprice Cadet 512The low-end option is the “Cadet“, and looking at the manual we see its basic two-wheel differential drive mechanism is augmented by three cliff sensors in addition to the bump sensors. The hardware within only has to support the basic random walk pattern, so the expectation is not high. But that might be fine at its clearance sale price of $55.

Monoprice Intelligent Vacuum 512The higher-end option is the “Intelligent Vacuum“. It has a lot more features, some of which are relevant for the purposes of robot hacking. It still has all the cliff sensors, but it also has a few of those proximity sensors pointing outwards to augment the bump sensors. But most interesting to robot hacking – it is advertised to vacuum in one of several patterns and not just random walk. This implies wheel encoders or something to track robot movement. There’s also a charging base docking station that the robot can return to charge, backing up the speculation there exists mechanisms on board the robot for odometry. Its clearance sale price of $115 is not significantly higher than the cost of building a two-wheeled robot with encoder, plus its own battery, charger, and all the sensors.

As tempting as they are, though, I think I’ll go down a different path…

HTML with Bootstrap Control Interface for ROSBot

While learning ROS, I was confident that it would be possible to replicate the kind of functionality I had built for SGVHAK rover. That is to say: putting up a HTML-based user interface for the user and talking to robot mechanical based on user input. Except that, in theory, the modular nature of ROS and its software support should mean it’ll take less time to build one. Or at least, it should be for someone who had already invested in the learning curve of ROS infrastructure.

At the time I didn’t know how long it would take to ramp up on ROS. I’m also a believer that it is educational to do something the hard way once to learn the ropes. So SGVHAK Rover received a pretty simple robot control built from minimal use of frameworks. Now that I’m ramping up on ROS, I’m debating whether it’s worthwhile to duplicate the functionality for self-education’s sake or if I want to go straight to something more functional than a remote control car.

This week I have confirmation a ROS web interface pretty simple to do: this recent post on Medium described one way of creating a web-based interface for a ROS robot. The web UI framework used in this tutorial is Bootstrap, and the sample robot is ROSBot. The choice of robot is no surprise since the Medium post was written by CEO of Husarion, maker of the robot. At MSRP of $1,299 it is quite a bit out of my budget for my own ROS experimentation at least for now. Still, the information on Medium may be useful if I tackle this project myself for a different robot, possibly SGVHAK rover or Sawppy.

Processed by: Helicon Filter;


New Addition To ROS: Bridge To OpenAI

OpenAI LogoWhile we’re on the topic of things I wanted to investigate in the future… there was a recent announcement declaring availability of the openai_ros package, a ROS toolkit to connect OpenAI to robots running ROS. Like the Robotis demo on how to use TensorFlow in ROS, it reinforces that ROS is a great platform for putting these new waves of artificial intelligence tools into action on real robots. Of course, that assumes I’ve put in the time to become proficient with these AI platforms and that has yet to happen. Like TensorFlow, learning about OpenAI is still on my to-do list and most of the announcement information didn’t mean anything to me. I understood the parts talking about Gazebo and about actual robot, but the concept of an OpenAI “task” is still fuzzy, as are details on how it relates to OpenAI training.

What’s clear is that my to-do list is growing faster than I can get through them. This is not a terrible problem to have, as long as it’s all interesting and rewarding to learn. But I can only take so much book learning before I lose my anchor and start drifting. Sometime soon I’ll have to decide to stop with the endless reading and put in some hands-on time to make abstract ideas concrete.

It’ll be fun when I get there, though. OpenAI recently got some press with their work evolving a robotic hand to perform dexterous manipulations of a cube. It looks really slick and I look forward to putting OpenAI to work on my own projects in the future.

New Addition To TurtleBot 3 Manual: TensorFlow

TensorFlow LogoBeing on the leading edge carries its own kind of thrill. When I started looking over the TurtleBot 3 manual I noticed the index listed a “Machine Learning” chapter. As I read through all the sections in order, I was looking forward to that chapter. Sadly I was greatly disappointed when I reached that chapter and saw it was a placeholder with “Coming Soon!”

I didn’t know how soon that “soon” was going to be, but I did not expect it to be a matter of days. But when I went back to flip through the material today I was surprised to see it’s no longer a placeholder. The chapter got some minimal content within the past few days, as confirmed by Github history of that page. Nice! This is definitely a strength of an online electronic manual versus a printed one.

So it’s no longer “Coming Soon!” but it is also by no means complete. Or at least, the user is already assumed to understand machine learning via DQN algorithms. Since I put off my own TensorFlow explorations to look at ROS, I have no idea what that means or how I might tweak the parameters to improve results. This page looks especially barren when compared to the mapping section, where the manual had far more information on how the algorithm’s parameters can be modified.

Maybe they have plans to return a flesh it out some more in the future, which would be helpful. Alternatively, it’s possible that once I put some time into learning TensorFlow I will know exactly what’s going on with this page. But right now that’s not the case.

Still, it’s encouraging to know that there are documented ways to use TensorFlow machine learning algorithms in the context of driving a robot via ROS. I look forward to the day when I know enough to compose all these pieces together to build intelligent robots.

TurtleBot3 Demo Navigating Gazebo Simulation World

Continuing on this beginner’s exploration of ROS, I got a taste of how a robot can be more intelligent about its movement than the random walk of turtlebot3_drive. It also gave me a taste of how much I still have to learn about how to effectively use all these open source algorithms available through the ROS ecosystem, but seeing these things work is great motivation to put in the time to learn.

There’s an entire chapter in the manual dedicated to navigation. It is focused on real robots but it only needs minimal modification to run in simulation. The first and most obvious step is to launch the “turtle world” simulation environment.

roslaunch turtlebot3_gazebo turtlebot3_world.launch

Then we can launch the navigation module, referencing the map we created earlier.

roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=$HOME/map.yaml

When RVis launches, we see one and a half turtle world. The complete turtle world is the map data, the incomplete turtle world is the laser distance data. We see the two separately because the robot doesn’t yet know where it is, resulting in a gross mismatch between map data and sensor data.

Navigation Startup

ROS navigation can determine the robot’s position, but it needs a little help with initial position. We provide this help by clicking on “2D Pose Estimate” and drawing an arrow. First we click on the robot’s position on the map, then we drag upwards to point the arrow up representing the direction our robot is facing.


In theory, once the robot knows roughly where it is and which direction it is facing, it can match laser data up to the map data and align itself the rest of the way. In practice it seems like we need to be fairly precise about the initial pose information for things to line up.

Navigation Aligned

Once aligned, we can click on “2D Nav Goal” to tell our robot navigation routine where to go. The robot will then plan a route and traverse that route, avoiding obstacles along the way. During its travel, the robot will continuously evaluate its current position against the original plan, and adjust as needed.

Navigation Progress

That was a pretty cool demo!

Of course there’s a lot of information shown on RViz, representing many things I still need to sit down and learn in the future. Such as:

  • What are those little green arrows? They’re drawn in RVis under the category named “Amcl Particles” but I don’t know what they mean yet.
  • There’s a small square surrounding the robot showing a red-to-blue gradient. The red appears near obstacles and blue indicates no obstacles nearby. The RViz check box corresponding to this data is labelled “Costmap”. I’ll need to learn what “cost” means in this context and how it can be adjusted to suit different navigation goals.
  • What causes the robot to deviate off the plan? In the real world I would expect things like wheel slippage to cause a robot to veer off its planned path. I’m not sure if Gazebo helpfully throws in some random wheel slippage to simulate the real world, or if there are other factors at play causing path deviations.
  • Sometimes the robot happily traverses the route in reverse, sometimes it performs a three-point-turn or in-place turn before beginning its traversal. I’m curious what dictates the different behaviors.
  • And lastly: Why do we have to do mapping and navigation as two separate steps? It was a little disappointing this robot demo separates them, as I had thought state of the art is well past the point where we could do both simultaneously. There’s probably a good reason why this is a hard problem, I just don’t know it yet in my ignorance.

Lots to learn!

Running TurtleBot3 Mapping Demonstration (With a Twist)

We’ve found our way to the source code for the simple turtlebot3_drive node. It’s a simple starting point to explore writing code in ROS that’ll be worth returning to in the future. In the meantime I keep looking at the other fun stuff available in ROS… like making the robot a little bit smarter. Enter the TurtleBot SLAM (simultaneous location and mapping) demonstration outlined in the manual.

Like all of the TurtleBot3 demo code from the e-Manual, we start by launching the Gazebo simulation environment.

roslaunch turtlebot3_gazebo turtlebot3_world.launch

Then we can launch the node to run one of several different algorithms. Each have strengths and weaknesses, this one has the strength of “it’s what’s in the manual” for a starting point.

roslaunch turtlebot3_slam turtlebot3_slam.launch slam_methods:=gmapping

Note: If this node failed to launch with the error ERROR: cannot launch node of type [gmapping/slam_gmapping]: gmapping it means the required module has not been installed. Install (on Ubuntu) with sudo apt install ros-kinetic-slam-gmapping.

If successful, this will launch RViz and we can see the robot’s map drawn using what it can detect from its initial position.

Initial SLAM map

To fill out the rest of the map, our virtual TurtleBot needs to explore its space. The manual suggests running the ‘turtlebot3_teleop‘ module so we can use our keyboard to drive TurtleBot around turtle world. But I think it’s more fun to watch the robot map its own world, so let’s launch turtlebot3_drive instead.

roslaunch turtlebot3_gazebo turtlebot3_simulation.launch

Using this simple self-exploration mode the turtle world will be mapped out eventually. How long this will take depends on luck. One interesting observation is that there’s no explicit randomness in the turtlebot3_drive source code, but because the Gazebo simulation environment inserts randomness in the data to simulate unpredictability of real sensors, turtlebot3_drive ends up being a random walk.

Once our robot has completed mapping its world, we can save it for the navigation demo.

rosrun map_server map_saver -f ~/map

Final SLAM map

More details on how to tune SLAM algorithm parameters are in the SLAM chapter of the manual, which is mainly focused on running the real robot rather than simulation but most of the points still apply.

Pasadena Alpha Muse Block Party

I appreciate being near Pasadena, California. It is a large enough community to have an organization like Innovate Pasadena, focused on spreading the word about some pretty interesting things in the area. A recent announcement on the mailing list was for an event titled Pasadena Alpha Muse Block Party. The title didn’t mean anything to me, and even after reading the Eventbrite page I only have a vague idea what to expect. But it is at a location I haven’t visited, and the event promised local companies, artists, and musicians. That was interesting enough to investigate.

The venue, CTRL Collective, appears to be a co-working facility along similar lines to WeWork or Cross Campus, except it seems to be more focused on creative companies versus technical. I’m sure there are other competitive differences that I failed to pick up, but it is generally along the lines of a facility that hosts multiple small companies who share a common infrastructure. There are offices upstairs, and downstairs is an open area for collaborative work or it can be opened up for events like today.

Pasadena Alpha Muse

Trying to learn about the companies represented by each table was difficult, because the musicians were playing at far too loud of a volume for conversation. Nevertheless, some interesting companies stood out. Top of the list is STEM World Pasadena. Their main focus is after-school STEM education for school age children, but they also advertise a maker space with laser cutter and CNC engraver, which is good motivation for me to go check out their facility.

Happily, there were more than enough interesting artists present, offering different styles for the audience to find something that speaks to them. Sometimes the different styles come from a single artist. Alicia Gorecki had many pieces featuring different topics like architecture, people, and a few others. Each of which had a different style. I loved the series with little just-hatched baby birds in black-and-white line art. I didn’t quite love them enough to buy an original (one of which Alicia is holding up here) but I did buy a greeting card of that series.

Alicia Gorecki

And no, I never did figure out what the event’s title “Alpha Muse” meant.

Understanding a Simple ROS Robot Control Program

In the previous post, a simple “Hello World” Gazebo robot simulation was parsed into its components. I was interested in the node named “turtlebot3_drive” and I’ve figured out how to go from the rqt_graph diagram shown yesterday to its source code.

  1. Decide the node /turtlebot3_drive was interesting.
  2. Look back at the command lines executed and determine it’s most likely launched from roslaunch turtlebot3_gazebo turtlebot3_simulation.launch
  3. Look at the launch file by running rosed turtlebot3_gazebo turtlebot3_simulation.launch
  4. Look through the XML file to find the node launch element <node name="$(arg name)_drive" pkg="turtlebot3_gazebo" type="turtlebot3_drive" required="true" output="screen"/>
  5. Go into the turtlebot3_gazebo package with roscd turtlebot3_gazebo
  6. Look at its makefile CMakeLists.txt
  7. See the executable turtlebot3_drive declared in the line add_executable(turtlebot3_drive src/turtlebot3_drive.cpp)
  8. Look at the source file rosed turtlebot3_gazebo turtlebot3_drive.cpp

Now we can look at the actual nuts and bolts of a simple ROS control program. I had hoped it would be pretty bare-bones and was happy to find that I was correct!

I had feared the laser rangefinder data parsing code would be super complicated, because the laser scanner looks all around the robot. As it turns out, this simple random walk only looks at distance in three directions: straight ahead (zero degrees), 30 degrees one way (30 degrees) and 30 degrees the other (330 degrees) inside the laser scanner data callback Turtlebot3Drive::laserScanMsgCallBack() This particular piece of logic would have worked just as well with three cheap individual distance sensors rather than the sophisticated laser scanner.

The main decision-making is in the GET_TB3_DIRECTION case of the switch statement inside Turtlebot3Drive::controlLoop(). It goes through three cases – if straight ahead is clear, proceed straight ahead. If there’s an obstacle near the right, turn left. And vice versa for right.


This is a great simple starting point for experimentation. We could edit this logic, go back to catkin root and run catkin_make, then see the new code in action inside Gazebo. This feels like the kind of thing I would write for competitions like RoboRodentia, where there’s a fixed scripted task for the robot to perform.

I could stay and play with this for a while, but honestly the motivation is not strong. The attraction of learning ROS is to buid on top of the work of others, and to play with recent advances in AI algorithms. Hand-coding robot logic would be an excellent exercise in using ROS framework but the result would not be novel or innovative.

Maybe I’ll have the patience to sit down and do my homework later, but for now, it’s off to chasing shiny objects elsewhere in the ROS ecosystem.

A Beginner’s Look Into The Mind of a Simulated ROS Robot

The previous post outlined a relatively minimal path to getting a virtual robot up and running in the Gazebo simulation environment. The robot is a virtual copy of the physical TurtleBot 3 Burger, and they both run code built on ROS. This setup should be pretty close to a ROS “Hello World” for a beginner like myself to get started poking at and learning what’s going on.

The first thing to do is to run rostopic list. As per tutorial on ROS topics, this is a tool to see all the information topics being published by all components running under a ROS core.


That’s a pretty long list of topics, which might seem intimidating at first glance until we realize just because it’s available doesn’t mean it’s being used.

How do we look at what’s actually in use? Again from the ROS topics tutorial, we can use a ROS utility that graphs out all active nodes and the topics they are using to talk to each other. rosrun rqt_graph rqt_graph

random walk rqt_graph.png

Ah, good. Only a few things are active. And this was only when we have everything running as listed at the end of the previous post, which were:

  1. TurtleBot in Gazebo
  2. TurtleBot performing a random walk with collision avoidance
  3. Rviz to plot laser range-finder data.

If we stop Rvis, the /robot_state_publisher node disappears, so that was used exclusively for visualization. The two nodes prefixed with gazebo are pretty obviously interface points to the simulator, leaving /turtlebot3_drive as the node corresponding to the random walk algorithm.

The velocity command topic /cmd_vel looks just like the one in the basic turtlesim used in the ROS tutorial, and I infer it is a standardized way to command robot movement in ROS components. The /scan topic must then be the laser rangefinder data used for collision avoidance.

To find the source code behind item #2, the obvious starting point is the command line used to start it: roslaunch turtlebot3_gazebo turtlebot3_simulation.launch. This tells us the code lives in the turtlebot3_gazebo module and we can look at the launch instructions by giving the same parameters to the ROS edit command. rosed turtlebot3_gazebo turtlebot3_simulation.launch. This brings up a XML file that described components for the random walk. From here I can see the node comes from something called “turtlebot3_drive“.

I found a turtlebot3_drive.cpp in the source code tree by brute force. I’m sure there was a better way to trace it from the .launch file to the .cpp, I just don’t know it yet. Maybe I’ll figure that out later, but for now I have a chunk of ROS C++ that I can tinker with.


ROS Notes: Gazebo Simulation of TurtleBot 3 Burger

TurtleBot 3 is the least expensive standard ROS introductory robot, and its creator Robotis has put online a fairly extensive electronic manual to help owners. The information is organized for its target audience, owners of the physical robot, so someone whose primary interest is simulation will have to dig through the manual to find the relevant bits. Here are the pieces I pulled out of the manual.

Operating System and ROS

Right now the target ROS distribution is Kinetic Kame, the easiest way is to have a computer running Ubuntu 16.04 (‘Xenial’) and follow ROS Kinetic instructions for a full desktop installation.

Additional Packages

After ROS is installed, additional packages are required to run a TurtleBot 3. Some of these, though probably not all, are required to run TB3 in simulation.

sudo apt-get install ros-kinetic-joy ros-kinetic-teleop-twist-joy ros-kinetic-teleop-twist-keyboard ros-kinetic-laser-proc ros-kinetic-rgbd-launch ros-kinetic-depthimage-to-laserscan ros-kinetic-rosserial-arduino ros-kinetic-rosserial-python ros-kinetic-rosserial-server ros-kinetic-rosserial-client ros-kinetic-rosserial-msgs ros-kinetic-amcl ros-kinetic-map-server ros-kinetic-move-base ros-kinetic-urdf ros-kinetic-xacro ros-kinetic-compressed-image-transport ros-kinetic-rqt-image-view ros-kinetic-gmapping ros-kinetic-navigation ros-kinetic-interactive-markers

TurtleBot 3 Code

The Catkin work environment will need to pull down a few Github repositories for code behind TurtleBot 3, plus one repo specific to simulation, then run catkin_make to build those pieces of source code.

$ cd ~/catkin_ws/src/
$ git clone
$ git clone
$ git clone
cd ~/catkin_ws && catkin_make

Simple Simulation

There are several simulations available in the manual’s “Simulation” chapter, here is my favorite. First: launch a Gazebo simulation with a TurtleBot 3 Burger inside the turtle-shaped test environment. At a ROS-enabled terminal, run

$ export TURTLEBOT3_MODEL=burger
$ roslaunch turtlebot3_gazebo turtlebot3_world.launch

(Note: If this is the first run of Gazebo, it will take several minutes to start. )

Once started, there will be a little virtual TurtleBot 3 Burger inside a turtle-shaped virtual room, sitting still and not doing anything. Which isn’t terribly interesting! But we can open a new ROS-enabled terminal to launch a very simple control program. This performs a random walk of the robot’s space, using the distance sensor to avoid walls.

$ export TURTLEBOT3_MODEL=burger
$ roslaunch turtlebot3_gazebo turtlebot3_simulation.launch

Turtle Room

Which is great, but I also want to see what the robot sees with its laser distance sensor. This information can be explored using Rvis, the data visualization tool built into ROS. Open up yet another ROS-enabled terminal to launch it.

$ export TURTLEBOT3_MODEL=burger
$ roslaunch turtlebot3_gazebo turtlebot3_gazebo_rviz.launch

This opens up an instance of Rvis, which will plot out the relative location of the robot and where it sees return pulses from its laser distance sensor.

Laser Rangefinder

ROS Notes: TurtleBot 3 Burger

Now that I have a very basic understanding of robotic simulation environment Gazebo, I circled back to ROS tutorial’s Where Next page. They suggested running virtual versions of one of two robots to learn about ROS: either a PR2 or a TurtleBot. I knew the PR2 is an expensive research-oriented robot that costs about as much as a Lamborghini, so whatever I build will be more along the lines of a TurtleBot. Sadly, the official TurtleBot’s idea of “low cost” is only relative to the six-figure PR2: when I last looked at ROS over a year ago, a TurtleBot 2 would still cost several thousand dollars.

Today I’m happy to learn that my information is out of date. When I last looked at ROS a year ago, the third generation of TurtleBot would have just launched and either it wasn’t yet publicly available or I just missed that information. Now there are two siblings in the far more affordable TurtleBot 3 family: the TurtleBot 3 Waffle is a larger robot suitable as platform for more elaborate projects, and the TurtleBot 3 Burger is a smaller robot with less room for expansion. While the Waffle is still over a thousand dollars, hobbyists without a kilobuck toy budget can consider the entry level TurtleBot 3 Burger.

Offered at $550, that price tag is within the ballpark of robot projects like my own Sawppy rover. If we look at the MSRP of its major components (OpenCR board + Raspberry Pi + IMU + laser scanner + 2 Dynamixel XL430 servos + battery) they add up to roughly $550. So it doesn’t feel like a horribly overpriced package.

My primary goal is still to get ROS running on Sawppy. But if I have a TurtleBot 3 Burger to play with established ROS libraries, that might make it easier down the road to adapt Sawppy to run ROS. While I stew over that decision, I can start my Gazebo simulation exploration using the virtual TurtleBot 3 Burger.


Notes on Gazebo Simulator Beginner Tutorial

My computer science undergraduate degree program required only a single class from the Chemistry department. It was an introductory course that covers basic chemistry concepts and their applications. Towards the end of the quarter, during a review session held by my Teaching Assistant, there was a mixup between what the TA was saying and lecture material that might be on the final exam. After some astute classmates brought up the difference, the TA was apologetic and his explanation made a strong impression:

Sorry about that. The simplification we use for this intro class isn’t what we actually use in research. Those of you who continue to get a chem degree will learn later how all of this is wrong.

This was a theme that repeated several more times in an undergraduate curriculum across different departments: The introductory course of a subject area uses a lot of simplifications that communicated rough strokes of ideas, but isn’t totally accurate.

I bring up this story because it is again true for Gazebo: a powerful and complex system for robotics simulation research and the beginner’s tutorial covers the basics by using simplifications that aren’t how serious work gets done. It’s not deceptive or misleading – it’s just a way to get oriented in the field.

This mostly manifested in the third part of the beginner’s tutorial. The first two are fairly straightforward: a brief overview page, followed by a page that described general UI concepts in the software. The third page, a quick tour of Gazebo Model Editor, is where beginners actually get some hands-on time using these simplifications.

Following the tutorial, the beginner will build a simplified model of a differential drive robot. A simple cylinder represents each of the two wheels, and a sphere represents the caster. They are connected to the box of a chassis by the barest joint relationship description possible. This model skipped all of the details necessary for building a real robot. And when it comes to simulating real robots, it’s not expected to be built from scratch using Gazebo Model Editor UI. More realistic simulation robots would be written using SDF and there’s an entirely separate category of tutorials for the topic.

But despite all these simplifications not representative of actual use… the model editor tutorial does its job getting a beginner’s feet wet. I know I’ll have to spend a lot more time to learn the depths of Gazebo, but this beginner’s tutorial was enough foundation for me to look at other related topics without getting completely lost.

Gazebo Model Editor Tutorial


ROS Notes: Downgrading from Lunar to Kinetic

kinetic 400After realizing my beginner’s mistake of choosing the wrong ROS distribution to start my self-education, I set out to downgrade my ROS distribution from the newer but less supported “L” (Lunar) release to the previous “K” (Kinetic) release. Given the sheer number of different packages involved in a ROS installation, I had been worried this was going to be a tangled mess chasing down files all over the operating system. Fortunately, this was not the case, though there were a few hiccups that I’ll document today for other fellow beginners in the future.

The first step is to undo the package installation, which can be accomplished by asking the Ubuntu package manager to remove the desktop package I used to install.

sudo apt remove ros-lunar-desktop-full

Once the top-level package was removed, all of its related packages were marked as unnecessary and could be auto-removed.

sudo apt autoremove

At this point ROS Lunar is gone. If a new terminal is opened at this point, there will be an error because the Lunar setup script called by ~/.bashrc is gone.

bash: /opt/ros/lunar/setup.bash: No such file or directory

This is not an immediate problem. We can leave it for now and install Kinetic.

sudo apt install ros-kinetic-desktop-full

After this completes, we can edit ~/.bashrc and change the reference from /opt/ros/lunar/setup.bash to /opt/ros/kinetic/setup.bash. This will address the above “No such file or directory” error when opening up a new terminal.

Then we can fix up the build environment. If we now go into the catkin workspace and run source devel/setup.bash as usual, that command will succeed but trying to run catkin_make will result in an error:

The program 'catkin_make' is currently not installed. You can install it by typing:

sudo apt install catkin

This is a misleading error message because catkin_make was installed as part of ROS Kinetic. However, devel/setup.bash still pointed to ROS Lunar which is now gone and that’s why our system believes catkin_make is not installed.

How to fix this: open a new terminal window but do NOT run source devel/setup.bash. Go into the catkin workspace and run catkin_make there. This will update devel/setup.bash for ROS Kinetic. After this completes, it is safe to run source devel/setup.bash to set up ROS Kinetic. Now catkin_make will execute successfully using ROS Kinetic version of files, and we’re back in business!

ROS Notes: Choosing Which Distribution

ROS-Lunar 400x400ROS gives creative names to each release, but the key part is that the names are in alphabetical order. When I looked into the ROS nodes to help control Dynamixel serial bus servos, I was confused as to their support of ROS distributions.

Both options supported the ‘K’ release (Kinetic Kame.) One of them seemed to have gotten stale, not getting maintenance or newer versions. The other one — officially built by Robotis — supported ‘K’ and ‘M’, skipping over ‘L’. There must be a reason, but why?

When I picked up learning ROS again this time around, I looked at the latest version M (“Melodic”) first. I saw it did not support Ubuntu 16.04. I needed to run Ubuntu 16.04 because of TensorFlow, so I went with the newest version that supported 16.04, which is how I ended up with Lunar Loggerhead. In hindsight, this was not the best choice. It appears every other distribution of ROS has a far shorter support life than its siblings, as seen on the list of ROS distributions. On this list, Kinetic Kame is marked as “(Recommended)” as of today.

It appears that “Kinetic” is the long-term support version, which is tied to Ubuntu’s 16.04 long term support version. “Melodic” is quite new, built on the recently released Ubuntu 18.04 LTS, so it makes sense that stabilization work is still ongoing. At some point in the near future, I’m sure “Melodic” will become the recommended version.

“Lunar” seems to be in an awkward middle spot where it is neither the latest release nor the stable long-term supported release. In fact, even though it is younger than “Kinetic”, the calendar says it will fall out of support sooner.

Even worse than that, its shorter lifespan meant people are less motivated to align their software packages to the release. Hence why packages like Robotis Dynamixel SDK has a Kinetic release and a Melodic release, skipping over Lunar. Looks like users like me should stick with the long-term support releases: not just for support from core ROS team, but also from third-parties like Robotis.

Given that I’m tied to Ubuntu 16.04, I should follow the recommendation and downgrade my installation of ROS to Kinetic Kame.

JPL Open Source Rover is Officially Official

OSR RocksBack in January of this year I joined a team of pre-release beta testers for a project out of nearby Jet Propulsion Laboratory (JPL). While not exactly a state secret, we were asked not to overtly broadcast or advertise the project until after JPL’s own publicity office started doing so. This publicity release happened two days ago so the JPL Open Source Rover is now officially public.

Our team members drew from SGVHAK, so we’ve been calling our rover SGVHAK rover instead of JPL open source rover. Past blog entries talking about SGVHAK’s customization were described as done in contrast to a vague undefined “baseline rover.” I’ve gone back and edited those references (well, at least the ones I could find) to point to JPL’s rover web site. Which had gone live a few weeks ago but that was a “soft opening” until JPL’s publicity office made everything officially public.

After SGVHAK team completed the rover beta build in March, I went off on my own to build Sawppy the Rover as a much more affordable alternative to a rover model. To hit that $500 price point, I had described the changes and trade-offs against SGVHAK rover but it was really against JPL’s open source rover. I’ve fixed up these old blog posts minimally – the references are now correct though some of the sentence structures got a little awkward.

As part of JPL’s open source rover project, they had established a public web forum where people can post information about their builds. To share our story I’ve gone ahead and created a forum thread for SGVHAK rover, and a separate one for Sawppy.

I look forward to seeing what other people will build.

ROS Notes: Dynamixel Servos

serialservo-dynamixelReading over the list of links on ROS wiki tutorials page, one item caught my attention: a link to Dynamixel Tutorials. The name Dynamixel wouldn’t have meant anything to me when I looked at ROS a year ago, but I recognize it now due to my research for components to build Sawppy the Rover. Robotis Dynamixel is a serial bus servo and as the industry veteran, it has the most software support which I knew included a factory SDK with support for ROS.

As I got into the tutorial, though, a few inconsistencies stood out as odd. Eventually I realized these tutorials were written by someone with no relation to Robotis, talking about a ROS control library with no relation to the Robotis Dynamixel SDK. According to the Github repository for the library, it was last updated eighteen months ago. It aligned with ROS ‘K’ release (Kinetic Kame) and hasn’t been updated for the two following releases ‘L’ (Lunar Loggerhead) or ‘M’ (Melodic Morenia)

This is pretty common in the world of open source… something is interesting so multiple parties each present their solution. The fact “anybody can do it” is both an upside and downside, depending on the situation. I should be more used to it by now but it still catches me off guard. This library also shows another downside: when the author loses interest for whatever reason, the code stops getting maintained.

Here’s its package information:

Package: ros-kinetic-dynamixel-controllers
Version: 0.4.1-0xenial-20180516-150315-0800
Priority: extra
Section: misc
Maintainer: Antons Rebguns <></>
Installed-Size: 760 kB
Depends: ros-kinetic-actionlib, ros-kinetic-control-msgs, ros-kinetic-diagnostic-msgs, ros-kinetic-dynamixel-driver, ros-kinetic-dynamixel-msgs, ros-kinetic-rospy, ros-kinetic-std-msgs, ros-kinetic-trajectory-msgs
Download-Size: 56.0 kB
APT-Sources: xenial/main amd64 Packages
Description: This package contains a configurable node, services and a spawner script to start, stop and restart one or more controller plugins.
Reusable controller types are defined for common Dynamixel motor joints. Both speed and torque can be set for each joint. This python package can be used by more specific robot controllers and all configurable parameters can be loaded via a yaml file.

In contrast to this “dynamixel-controllers”, we have “dynamixel-sdk” whose maintainer is listed with an e-mail address, so it looks pretty official. According to this post on ROS Answers forum, Robotis intends to continue supporting ROS with their factory SDK.

Package: ros-kinetic-dynamixel-sdk
Version: 3.5.4-0xenial-20180308-062313-0800
Priority: extra
Section: misc
Maintainer: Pyo <>
Installed-Size: 293 kB
Depends: libc6 (>= 2.17), libgcc1 (>= 1:3.0), libstdc++6 (>= 4.1.1), ros-kinetic-roscpp
Download-Size: 38.5 kB
APT-Sources: xenial/main amd64 Packages
Description: This package is wrapping version of ROBOTIS Dynamxel SDK for ROS.
The ROBOTIS Dynamixel SDK, or SDK, is a software development library that provides Dynamixel control functions for packet communication. The API is designed for Dynamixel actuators and Dynamixel-based platforms.

Though Sawppy ended up not using Dynamixel servos, my research into the devices gave me enough familiarity with their control protocol that I think the Dynamixel SDK will be a good precedent to follow when I start looking into creating my own ROS controller nodes.

While I’m not ready to embark on that project just yet, I thought it might be good to take a quick look. This attempt failed but the failure became its own ROS learning adventure.

I had installed ROS ‘L’ distribution (Lunar Loggerhead) and the Robotis SDK supported ‘K’ and ‘M’, skipping over ‘L’. Why is that? My effort to understand is the story of the next blog.




ROS Notes: URDF vs. Gazebo SDF

SDFormatOne of the higher-level mysteries to this ROS beginner is why Gazebo, a sibling product, has a separate XML-based description format SDF instead of using the same URDF files of ROS. The answer came in this particular page in Gazebo’s collection of tutorials. “Tutorial: Using a URDF in Gazebo” explains why a different format was invented, but it also outlines Gazebo features to bridge the two worlds. By adding Gazebo-specific tags to URDF files, authors can specify all the information necessary for Gazebo to convert it to a SDF for internal use.

My understanding can be boiled down to this: URDF specifies a robot, but SDF also specifies a world for the robot to live in, which is a much larger set of things. Based on this premise, SDF is designed to represent a superset of everything that can be represented in URDF.

Which leads to the obvious next question: if SDF is a proper superset, why not standardize on SDF across the board? The best answer I could find is the idea being floated (and shot down?) as something to do for ROS2. I can understand the perspective that ROS really only cares about the robot and doesn’t need all the extra features of specifying a simulation world.

And while reading that discussion thread, I also learned Gazebo isn’t the only one unhappy with URDF. There’s also a SRDF file format for describing things not in a URDF, and I have even less of an idea how SRDF relates to SDF. Fortunately, there is an enlighening comment block in the generic example on that page:

This does not replace URDF, and is not an extension of URDF.

So whatever SRDF may be, it’s not yet another way to specify a robot, which is a relief.

Summary of my current understanding:

  • URDF is the established format for describing robot structure in ROS, and it is not going away anytime soon.
  • URDF could not specify information necessary for other robotics domains.
    • SDF was devised by Gazebo to meet simulation needs, but Gazebo can consume URDF when it is augmented by information within <gazebo> tags.
    • SRDF was devised to meet needs of MoveIt! Motion Planning Framework and does not replace URDF.

Given the above, as a beginner I should be safe to start with URDF when I start defining my own physical robots (like Sawppy) for ROS. But that’s a ways down the road, for now it’s back to tutorials.

ROS Notes: Robot Simulation with Gazebo

GazeboNumber one on the list of suggested “What Next” at the end of ROS tutorial is an invitation to run a virtual robot in a simulation environment. Two robots were linked – first the very capable and expensive Willows Garage PR2 research platform, and the second a much more accessible TurtleBot platform. Either way, the virtual world for these simulated robots is a product called Gazebo.

The big red notification at the top of the PR2 Gazebo tutorial tells us that particular page is out of date. It implied Gazebo used to be part of ROS but has been spun off as a standalone project. This is different from the story at the bottom of Gazebo’s own front page, which implied Gazebo has always been standalone and ROS just happens to interface with it. Either way, a little poking around found that Gazebo is a peer of ROS both under the umbrella of Open Source Robotics Foundation.

The good news is that Gazebo provides tutorials to help people learn Gazebo. The bad news is… well, there is A LOT of it. The tutorial section front page has about 35 links to other pages, which seemed fine until I realized each of the links under “Categorized” leads to a page with several tutorials in that category. This drastically increases the number of tutorial pages, many of which seemed to be aimed at people who might be new to that category of Gazebo but are familiar with Gazebo in general.

I’m definitely not yet familiar with Gazebo in general.

As far as this beginner can determine so far, Gazebo provides a virtual simulation environment for robotic software, but that software need not be written with ROS. Gazebo simulation behavior is controlled by assembling multiple plugins, each written to control some aspect of the simulation world. Plugins are assembled alongside other assets in a SDF file to be loaded into a Gazebo simulation.

I haven’t yet figured out how Gazebo plugins relate to ROS nodes, or how the SDF files relate to ROS URDF files. I know the advertising pitch is to write high level robot intelligence that can be easily swapped between running on physical hardware and running in Gazebo. As of right now, it is still a mystery where that physical/virtual swap layer lives.




Pasadena Public Library STEAM Fair 2018

Pasadena Library STEAM fair

Yesterday, nearby Pasadena Public Library held their STEAM Fair, a celebration of a bunch of things that you could learn from a book alone… but it’s more fun when accompanied by hands-on activities. Though the event seemed to be mainly geared towards elementary school age children, there were smattering of other things appealing to other age brackets.

My primary interest in this event is that it marks the official opening of the library’s Innovation Lab. It’s a small room with several pieces of equipment with maker appeal. There are two 3D printers that appear to be LulzBot TAZ 6 which are more capable printers than what I have at home. There are two sewing/embroidery machines, a CNC engraver, and my primary interest: a laser cutter. Made by Full Spectrum Laser, this machine is from their hobby line.

I enjoyed playing with the laser cutter at Tux-Lab. Not quite enough for me to spend the considerable amount of money to buy my own, but enough for me to seek out alternate sources so I have options when Tux-Lab equipment is not available.

Overall it is encouraging to see libraries expand beyond a collection of books. I’ve read of libraries experimenting with how they can appeal to the maker audience, and it’s great to have a local library exploring this space. What happens next will depend on the kind of library patrons this facility would attract. Would people embark on interesting creations of their own? Or will these machines be fated to replicate designs downloaded from the internet? Time will tell.


ROS Notes: Picking Up Where I Left Off

rosorg-logo1About a year ago I went through the beginner level tutorial for ROS, the open-source Robot Operating System. The beginner’s track ends with a “Where next?” page with lots of options. At the time I did not have a specific robot or a specific project in mind, so there was no particular motivating factor to help me choose from the list of options. This has the unfortunate side effect of analysis paralysis and so that’s where I stopped on the last go-around. At the time, laser cutting an acrylic enclosure for a network attached storage server seemed more interesting, and I got distracted.

Things have changed in the past year. The most important change is that I have access to multiple robot platforms. We have the SGVHAK Rover, my Sawppy the Rover, and Emily’s Craglist acquisition Bart the robot. All of these hardware would benefit from a powerful and sophisticated software platform to elevate them from fancy remote control vehicles to something really interesting.

Another change was a realization as I got started thinking about deep neural networks and playing with AI. I started with the powerful laptop and got TensorFlow installed, but as I went through the tutorials I realized it’s all very interesting in the abstract but I can see myself getting distracted again. I need a goal to work towards as I apply my AI education and experimentation, and this circled me back to the robot platforms we have running around.

ROS is the software infrastructure where these two would meet – the hardware robot platforms and the TensorFlow neural networks. So before I get started on another big complicated software framework like TensorFlow, I should finish what I started with ROS.

As a refresher, I went through all the beginner tutorials again. It made a lot more sense this time around given the context of what I’ve learned in the past year. Ranging from Python programming, to Linux fundamentals, to getting a better feel of why ROS features are desirable viewed through the lens of building Sawppy.

The progress was a lot faster this time… and now I’m at the Where Next page once again.

Hello, old friend. This time, let’s keep the momentum moving.