Monday, October 31, 2011

Happy Halloween

I hope our future robot overlords understand that this PR2 is a delicious chocolate robot and it is not capable of computation. Though I'm sure I'll be disturbed when I see our robot overlords eating human shaped chocolates.

Also if you need more disturbing thoughts, perhaps Blinky can help.

BLINKY Teaser HD from Ruairi Robinson on Vimeo.

Sunday, October 30, 2011

Ascending Technologies Firefly and more

One of the highlights of IROS 2011 was meeting up with the team from Ascending Technologies and getting to spend some time talking with them in person.

At their booth they had a Falcon 8 on display, which is an eight rotor sUAS designed for aerial photography and surveying.

Ascending Technologies also brought along some of their newer products including the Firefly and the Mastermind. The Firefly has several notable design features that make is a great research platform.

First, the Firefly includes an easy to see indicator light that can be used to determine the battery status or other alarms.

The six rotor design provides redundancy in the event of a motor or propeller failure. The IMU and 400 gram payload area of the Firefly are decoupled from the main frame of the vehicle helping to isolate sensors from vibrations. The Firefly will be available in 2012 starting at 5,695 Euros. A sales brochure can be found here.

The AscTec Mastermind is a new on-board computer custom designed for computationally intensive sUAS research. Available with processors up to Intel Core i7, the system can now handle running significantly more complex tasks than previously possible. The additional performance allows more tasks to be run on-board instead of on a ground station. This frees up communications bandwidth for enhanced teleoperation and make autonomous operation of the aircraft more stable in environments where WiFi is unreliable. The Mastermind supports Firewire, USB and Ethernet and additional functionality can be added via MiniPCI. Storage can be provided via CFast, mSATA, SATA or SDHC devices. Available in 2012 starting at 1,795 Euros.

If you already have an AscTec Pelican or Hummingbird you will be excited to know that there are significant software improvements and new firmware on the way. We got a chance to take a look at some of the code for the new communications interface, and believe that you will find the new software to be well worth the wait. Available soon for Free!

In addition to showing off all of the great new hardware and software, they also taught us the word 'Wachstumsschmerzen' which is German for what we seem to be going through right now. On that note, our regular posting schedule should now resume.

Saturday, October 29, 2011

Will robots take our jobs?

There's a saying which I think I first heard on the Robots podcast which goes something like the following:
Americans are worried that robots are going to kill them
Europeans are worried that robots will take their jobs
Japanese want robots to be their friends
What automation already has done and will do in future to the employment market is a question which has been debated for many decades.  A fairly intelligent discussion about this can be found here between Martin Ford and Robin Hanson.

The standard narrative about automation has typically been that robots will do the dull, dirty and dangerous work which people mostly don't want to do, but that they won't encroach much beyond that, leaving an intellectual refuge within which human "knowledge workers" can remain as the non plus ultra.  This is true now, and also for the immediate future, but I tend to agree with people like Hans Moravec and Martin Ford that in the long run - assuming no major setbacks such as asteroid strikes or insurmountable energy/material shortages - that practically nobody's job is going to escape from the rising tide of automation.

You can always point out the limitations of particular contemporary technologies.  Hanson mentions how Google Translate does not entirely do away with the need for human translators, and I've had some first hand experience of those situations.  Most industries have their own specialized vocabulary and set of acronyms which automatic translation doesn't handle well.  However, given more time and training data there is no fundamental obstacle to having automatic translators also handle niche vocabularies.

Martin Ford describes in more detail in his book how anyone doing what he calls a "software job" will be at risk from technological unemployment in the foreseeable future and that the economic value of possessing a college degree will fall accordingly.  In his opinion what has been happening to blue collar workers (outsourcing, offshoring and replacement by automation) will also increasingly happen to white collar knowledge workers in this century.

Is technological unemployment a component of the current economic troubles?  Perhaps.  But if it is then it's only a small component.  One thing which is however conspicuous is that it's possible to have something like 10-25% of the population classified as being "economically inactive" without any really major downturn in overall productivity.  GDP can be rising at the same time as unemployment rates.  There are a few possible interpretations as to why this might be, but one is that this could indicate that over time a smaller fraction of the population is required to be in the loop of economic production in order for it to still continue to function effectively.

Ultimately this challenges the notion that in order to have income you need to be personally and directly involved in economic production activities, and whatever happens I think it's going to be true that advances in automation will fundamentally change the way that the economy functions - sacrificing a few ideological sacred cows along the way. 

Hanson talks about democratic ownership of the means of production, and that seems quite likely to me.  RepRap is an obvious pointer in that direction, but it's also not too hard to imagine that mobile robots equipped with appropriate tools and sophisticated enough software could perform jobs of significant economic value which effectively free the owner of needing to be personally involved at all.  If the automation is cheap enough, or can be produced in a viral manner similar to RepRap components, then potentially anyone can manufacture things which they might need, or want to sell or barter.

Wednesday, October 26, 2011


There are plenty of UAVs around, but this design may turn out to be one of the more successful ones. The spherical frame means that it would be difficult to destroy, and if it's constructed from a material which has some elasticity then if it hit the ground at speed it would just bounce and roll.

Sunday, October 23, 2011

Mapping the Environment

The next stage is to test out the mapping performance of the Turtlebot.  It's also interesting to compare the maps to those I created earlier with my larger GROK2 robot, which is using the same ROS/Gmapping software.

Initially I performed the calibration of the gyro and odometry, as described here.  Then I created a launch file using the same Gmapping parameters as for my other robot, and also including the calibration results.

  <param name="robot_description" command="$(find xacro)/ '$(find turtlebot_description)/urdf/turtlebot.urdf.xacro'" />

  <param name="turtlebot_node/gyro_scale_correction" value="1.003914"/>
  <param name="turtlebot_node/odom_angular_scale_correction" value="0.925940"/>

  <!--- Run Robot Pose EKF -->
  <include file="$(find turtlebot_bringup)/base.launch" />

  <!--- Run the kinect -->
  <include file="$(find turtlebot_bringup)/kinect.launch" />

  <!--- Run gmapping -->
  <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
    <param name="odom_frame" value="odom"/>
    <param name="map_update_interval" value="30.0"/>
    <param name="maxUrange" value="16.0"/>
    <param name="sigma" value="0.05"/>
    <param name="kernelSize" value="1"/>
    <param name="lstep" value="0.05"/>
    <param name="astep" value="0.05"/>
    <param name="iterations" value="5"/>
    <param name="lsigma" value="0.075"/>
    <param name="ogain" value="3.0"/>
    <param name="lskip" value="0"/>
    <param name="srr" value="0.01"/>
    <param name="srt" value="0.02"/>
    <param name="str" value="0.01"/>
    <param name="stt" value="0.02"/>
    <param name="linearUpdate" value="0.5"/>
    <param name="angularUpdate" value="0.436"/>
    <param name="temporalUpdate" value="-1.0"/>
    <param name="resampleThreshold" value="0.5"/>
    <param name="particles" value="80"/>

    <param name="xmin" value="-1.0"/>
    <param name="ymin" value="-1.0"/>
    <param name="xmax" value="1.0"/>
    <param name="ymax" value="1.0"/>

    <param name="delta" value="0.02"/>
    <param name="llsamplerange" value="0.01"/>
    <param name="llsamplestep" value="0.01"/>
    <param name="lasamplerange" value="0.005"/>
    <param name="lasamplestep" value="0.005"/>

  <!--- Run Move Base -->
  <include file="$(find turtlebot_navigation)/config/move_base_turtlebot.launch" />


The only parameter which is different from the defaults here is the grid cell size delta

I also made a teleoperation launch file with reduces speeds to make the movement of the robot less jerky and prone to wheel slippage.

  <node pkg="turtlebot_teleop" type="turtlebot_teleop_key" name="turtlebot_teleop_keyboard"  output="screen">
    <remap from="cmd_vel" to="/turtlebot_node/cmd_vel"/>
    <param name="scale_linear" value="0.2" type="double"/>
    <param name="scale_angular" value="0.3" type="double"/>

Using these I obtained the following map:

This compares quite favorably with previous mapping runs using my other robot.  I don't know what type or resolution the wheel encoders on the iRobot Create are, but I expect that they will be lower resolution than the quadrature encoders that I'm using elsewhere.

I also tried mapping with the default parameters, which have a grid cell size of 5cm.

As you can see the results are not as good, which might translate into poor localization performance in some areas of the map, so if your CPU is good enough then it's well worth using a smaller cell size.

Some thoughts on mapping in general

This kind of mapping performance using a hobby robot with a total cost in the order of $1000-2000 represents a massive advance over anything which was possible in that price range previously, but I expect that in future with improved software that even better will be possible.

The main limitation with Gmapping, and similar particle filter based SLAM systems is that there needs to be a distinct mapping phase, after which the map is assumed to be "done" as a one-time operation.  However, for practical service robotics I expect that lifelong learning is going to be needed, since the environment may change occasionally and the robot may need to relearn its surroundings.  To facilitate this sort of situation I think the way to go will be to use graph based 3D SLAM methods.

Getting Stuck

One of the problems which I found with the Turtlebot is its tendency to get stuck in particular places.  Obviously for mapping and localization purposes if wheel odometry is being used then this could significantly reduce the performance.  From overhead it just appears that the robot is getting stuck on the carpet, but taking a closer look something else is going on.

Here you can see that the rear roller gets stuck on the transition between floor surfaces.

In another situation there is no obvious obstacle, but there is a slight incline in the transition between carpets.  This is probably enough to cause the front spring loaded roller to reach its upper limit and for the robot to become balanced on the rollers in such a way that the drive wheels lose traction.

My original first generation Roomba didn't get stuck all that often, so by comparing it to the Create base the design changes can be seen.

The original Roomba also has a front spring loaded roller, but has no rear roller.  It also has a similar tapering of the width at the back end which potentially allows it to tilt, nose upwards, on uneven surfaces.  In the case of the Create it seems that the rear roller to a large extent prevents this tilting action.

I noticed that on the Create the rear roller is removable.  Unlike the front roller it's not spring loaded, and potentially it could be replaced with something else.  Ideally I think that the rear roller should also be spring loaded, such that if it snags on some low object it could move upwards and over it.

Removing the rear roller has the disadvantage that the Turtlebot is typically at a slightly tilted angle, and nods forwards when it comes to a stop.  Potentially this could be factored into the URDF model.  There will be more drag, making the motion less energy efficient, but testing in the same areas without the rear roller indicates that this definitely resolves the snagging problem.

Mechanical design features such as this may seem trivial, especially if your floors are completely flat, but if service robotics is ever to become mainstream it's attention to these sorts of factors which will make all the difference.

Monday, October 17, 2011

Testing the Turtlebot

I recently received a Turtlebot to test out.  This is based on the iRobot Create, and like my main robot also uses ROS and a Kinect RGBD sensor.  It's construction is fairly simple, and I found that it takes more time to remove the packaging than it does to put together.  There were no obvious instructions included, although there is a Turtlebot web site with some downloadable assembly details.

One thing that I hadn't noticed previously is that the Turtlebot is also an open hardware design:
"Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design."

So in principle you could make and sell these, or produce derivative variants based upon a similar design.  Bilibot is another comparable iRobot Create oriented design, although as far as I know that's not open hardware.


The assembly consists of four shelves held together by metal struts and screws.  As a framework it's quite sturdy, and doesn't wobble or distort if you try applying some sideways force, so this may be suitable for carrying objects such as cups or plates.

I had no previous experience with the iRobot Create, but I was an early adopter of the Roomba cleaner.  My first generation Roomba is now quite aged and out of service, having endured years of tireless service.  The Create is really just a Roomba, but with the cleaning gadgetry removed such that there is an empty space in the trailing section within which alternative electronics could be stowed.

There's a socket which looks like an old parallel printer port into which a separate circuit board is connected, which provides power to the Kinect sensor and (I think) exposes some digital I/O.

Software Installation

The USB drive suppled is 4GB in size, and seems to be exclusively for the purposes of installing a modified version of Ubuntu to the netbook hard drive.  Just to be awkward I chose to eschew any hard drive installations and stick to keeping everything on a USB drive containing a liveCD install.  From experience with my other robot I knew that 4GB wasn't large enough for ROS, but I had an old 8GB Sandisk USB drive not in use which has just about enough capacity to install the Turtlebot related parts of ROS.

One problem that I came across while installing the software was that it looks as if there are missing components for the i386 architecture version of ROS Electric, so I reverted to a diamondback installation instead.  Why use i386?  Well, it just so happens that I have an ISO for Ubuntu 11.04/i386 already downloaded, and that architecture is highly likely to work on all of my currently running computers.  So for instance I could pull out the USB drive from the Turtlebot, plug it into my laptop and boot from it for testing purposes even though my laptop doesn't support 64bit processing.  The near universal functionality of a liveCD installation on a USB drive, together with it's low power consumption and near indestructibility are attractive attributes.

One note of caution is that installing and using the software does to some extent assume a familiarity with Linux.  This might be off-putting to Windows using hobbyists who have never previously encountered Linux, but I expect that the majority of people interested in this sort of robotics will already be technical types who are accustomed to a variety of modern operating systems and their use.  There is quite a lot of help available on the ROS wiki and also on the answers site.  So in summary this might not be the best Christmas gift if the receiver is someone who just expects it to switch on and do something interesting immediately, like a Roomba or a WoWee robot, without some technical software effort being required.

Another problem which I came across was that if you're installing the OS from scratch without using the pre-built Turtlebot ISO image then the turtlebot service described in the bringup tutorial doesn't exist.  This flummoxed me for a while, but after asking questions it seems that you can just use roslaunch to run the appropriate demos.

Some observations on design

From trying some demo programs, such as teleop and follower, some design limitations become apparent.  Switching on the Create base involves pressing the power button on its upper surface towards the centre (you can see it in the picture above).  However, with the Turtlebot fully assembled this is quite a fiddly operation.  Also powering on the netbook is of course a very manual operation involving removing it from the robot and opening it up.  Ideally there would be a way of powering on the robot without a lot of awkward fiddling about.  For a hobby or research robot this is probably just about acceptable, but if you wanted to turn the Turtlebot into a workhorse platform then I think the power buttons would need to be exposed in a more convenient location.

Another design limitation is common to all Roomba form factors.  The Roomba has very little ground clearance.  Measuring it it's about 10mm.  This means that on occasion it has a habit of getting stuck on transitions between carpets.  While this doesn't happen all of the time it does happen some of the time, especially with thicker carpets.  This may be a minor point, or it may be a non-issue if all of your floors are perfectly flat, but it's always the small percentage of failures which are the gotcha in any engineering endeavor.  For a cleaning robot there will always be a trade-off between the ground clearance and the brushing efficiency.

The power button fiddlyness probably can be resolved with a certain amount of hacking.  For anyone buying a Turtlebot I'd suggest that instead of using a high end netbook you use a mini-ITX board, as I did with the GROK2 robot.  I used an Intel D525MW Atom board, and this means that you can connect up an external momentary switch which can then be mounted in some convenient location on the robot.  Just make sure that the board has at least three USB sockets and that it fulfills the minimum processing/memory specification recommended by Willow Garage, which is at least dual core and about 2GB of RAM.  The mini-ITX route is also cheaper, even including the memory and power adapter, although the cost equation will no doubt change over time as low end netbooks become more powerful.

A good aspect of the Turtlebot's design is the way that the Kinect sensor is relatively protected by the top shelf, and that the top shelf potentially acts as a surface for transporting objects.  On my larger robot, and also on other robots such as Bilibot, the sensor is far more exposed and could be damaged more easily.

A demo

The following behavior is certainly the most fun demo to run.  It works pretty well and manages to follow me from one room to another fairly reliably at a slow walking pace.

This behavior probably could be improved by initiating a search for new people to follow if it comes up against a flat surface (a wall).  There are some existing functions within the point cloud library for detecting planar surfaces.  Alternatively it could search based upon a simple timeout (rotates, waits to observe any nearby motion, then follows).


Turtlebot ticks many of the boxes which robot hobbyists have been waiting for.  It's sufficiently low cost to be within the bounds of sanity.  It's based upon a PC, so that people who previously were not robotics developers can transition to becoming so with minimal relearning of new languages or software tools.  It's sensing is of sufficiently high resolution for there to be interesting possibilities (this was the main barrier for a very long time).  And also the open source nature of ROS means that conventional development methodology can be applied such that you can stand on the shoulders of giants and not have to reinvent the wheel all the time.

Obviously the Turtlebot isn't the last word in hobby robotics.  There's still a long way to go.  But it is a kind of transition point moving beyond the limited sensing capabilities and pure teleoperation of the past, with the potential for increasingly autonomous navigation and learning behavior in a way which is cognitively more sophisticated than your typical Roomba.

Sunday, October 9, 2011

Robot security, again

Here is another fine reason why you might want to improve your robot's security, now rather than later.

Running a modern operating system on your ground control station might also help.