Reinforcement learning has been used extensively in robotics for many years, ranging from the simple types of obstacle avoidance seen in the seven dwarfs all the way up to the elaborate brain based Darwin automata capable of more sophisticated associative learning This is predicated upon a psychological school of thought known as behaviorism, which was extremely popular for most of the 20th century but which has fallen out of favor in recent decades.
In the realm of learning robotics there don't seem to have been many attempts thus far to go beyond the limited bounds of behaviorism. Clearly in animals classical conditioning does play an important role, but it's by no means the whole story. For example, young children don't learn language by being explicitly rewarded or punished every time some new concept is acquired. Much of learning seems to be self-organised, where the creature has a spontaneous ability to classify and is engaging in a kind of synchronization with its environment where the resulting conceptual framework converges towards stable forms, like eddies in the flow of causality.
Is human language Turing complete?
Even reinforcement learning, when combined with self-organization aren't sufficient to fully explain complex behaviors described as "intelligent". To be capable of a wide range of adaptation the system needs to be Turing complete in a manner which supports the generation of a population of virtual machines capable of implementing arbitrary transformations or behaviors.
Turing machines can of course be implemented in many different kinds of ways, and there are many possible systems which are computationally equivalent to them. As noted by people like Chomsky, human language seems to exhibit qualities similar to Turing completeness, such as the ability to generate recursive structures. If human language is a Turing complete system, as I suspect that it is, then this may explain why it is such a powerful tool for regimenting thought processes, and has class 4 type behavior. Interactions between multiple such systems, both within a single mind and between multiple minds could be the way in which the problems of classical incompleteness are overcome, since at the interfaces between machines undefined behavior can occur and the systems themselves may comprise heterogeneous but symbiotic formalisms which like the bimetallic strip of a mechanical clock work against each other in a complementary way.
The language augmented nature of human thought is probably also the reason why reinforcement learning can have more extensive consequences than you might see in other creatures, up to and including the complete reorganization of a person's world view based upon one or a small number of learning instances. So instead of just reinforcing some single isolated categorization the reinforcing event becomes the input to a Turing machine which has consequences that are not always easy to foresee (without running the program) and may spawn new virtual machines or erase existing ones.
Dimensions of Affect
Another issue with reinforcement learning as typically practiced in robotics is that learning itself tends to be unidimensional. The learning rate may vary, but there are not usually more than one learning parameter. Hence it's difficult to simulate fading affect memory biases, where memories associated with positive or negative consequences are differentially weighted and can have multidimensional results. A possible research programme would be to apply the biologically based affect theory of Silvian Tomkins to robotics and try to replicate learning scenarios which have similar outcomes to those seen in people.
Many good points about the commercial prospects for robotics are made in a recent episode of the robots podcast. I think it is true that we're at a turning point where mobile robotics is becoming much more practical than it was in the past, and where a hunt for new kinds of applications can commence.
It's not that sensor technologies comparable to the Kinect sensor didn't exist before, since time-of-flight sensors have been around for at least five years and scanning laser rangefinders have been around for longer, but that the current generation of depth sensing technology has a far more favourable price/performance such that applications other than traditional high cost industrial automation ones can be considered.
One way to address the unfocused research problem would be to have some percentage of research activities biased towards application areas. However, the issue remains that what constitutes good application areas for mobile robotics at this point remains largely undefined. What's going to happen with robotics will I think be similar to what happened with computers. In the early days of home computers people didn't really know what they would be used for. At first they didn't do much more than run simple kinds of games, then they were used for spreadsheets, accountancy and wordprocessing. In the early 1990s there was a vague idea that computers would be used for "multi media" education, interactive TV or "virtual reality", then in the late 1990s with the rise of the internet the computer became a machine for communicating and doing shopping.
Even in the late 1990s there were still people who asked the question "why would I want a computer in my home?" or "why would I ever want or need to look at the internet?". People say similar things today about robotics.
So whenever new technology arrives within a consumer price range there is always a long, messy and meandering process of discovery which unfolds and which is not easy to foresee in the research lab. This means that it's not necessarily a simple task to pick applications towards which research may be biased without being able to foresee the future, and what looks like the hot application of today (elder care or hospital work perhaps) may not be quite so hot by the time something actually gets to the stage of being built and sold.
Here is an amusing tale of how a military drone was hijacked and forced to land at what it believed to be it's home airfield. Drones like this havn't been around for very long, and their guidance systems are presumably quite simple - similar to the growing number of DIY drones based upon Arduino and similar microcontrollers or DSPs - so there is probably lots of low hanging fruit in terms of security vulnerabilities.
As I supposed many years ago there will now ensue an evolution of telerobot and counter-telerobot technologies. The most obvious thing which could be done to avoid denial of GPS or fake GPS scenarios would be to add visual localization. This could be as simple as dead reckoning based upon optical flow, similar to the method by which an optical mouse works. More accurate visual localization would combine an internal map with standard planar object recognition techniques based upon things like SIFT or SURF features in order to have the drone recognise certain locations and dead reckon between them. Those bag of words-like techniques can scale to thousands of objects, so there could be many landmark locations upon which the drone could localize. Of course, this assumes that the drone is able to see features on the ground, but if they're primarily used for surveillance then that's likely to be true most of the time anyway.
Sensor fusion between GPS and visual localization/odometry is the most likely solution. Also, this isn't only a problem which applies to military drones. In future I expect that most civilian aircraft will be flown in the same way, without human pilots, so increasing the robustness of the navigation is a worthwhile goal.
There are a variety of reasons why it's probably not a good idea to have robots moving around at high speed indoors.
There's likely to be more wear on the carpet, and "tracks" will become conspicuous.
There's a tripping hazard. One second there is no robot and the next there is.
If anything goes wrong and the robot hits something, it could cause non-trivial damage - possibly including generating fire hazards.
Last but not least, more speed usually means more noise. Noise level is something often forgotten, but for robots operating indoors I think it will be a factor. People already fuss over noisy PC cooling fans.
However, in industrial settings such as warehouses where there are rarely people around and it's a more controlled environment I expect that it will be normal for robots to be moving at this kind of speed.
For most domestic or office space service robots probably a very pedestrian Turtlebot-like speed of 0.3m/s will be about as fast as it gets, and may even be slower if handling objects.
A quick note from I Heart Engineering. Please order by Dec 14th at 7pm EST to have purchases guaranteed to arrive via standard shipping in time for Xmas. Orders placed after the 14th via standard shipping may or may not arrive in time. You will have until the 19th for guaranteed delivery of express shipments.
Here is some video which I took at an exhibition in Glasgow in 1996. Kevin Warwick demonstrates machine learning and flocking behavior with the "Seven Dwarf" robots.
This is not the "cognitive" robotics which you can now see in robots running ROS, where they're mapping the environment and planning paths through it, but is a much simpler and more behavioristic system in which sensors and actuators are connected fairly directly with only a negligible amount of internal state.
It is interesting to think about these types of robots, which only have a small amount of computation onboard, in terms of Stephen Wolframs classes of automata, and whether or not they could converge towards collective behavior systems which are Turing complete - facilitating an open-ended cultural evolution. It's a conjecture of mine that something like this happened in human evolution, such that whereas most social creatures have quite predictable behaviors and a fairly static culture some accident of circumstance or mutation meant that the collective human socio-cognitive system fell into class 4 type behaviors, and what followed was the emergence of history and technology.
There was a great deal of interest in behavioristic robotics throughout the 1990s, particularly promoted by Rodney Brooks, in spite of behaviorism's having fallen out of favor within the realm of psychology by that time. Within the last decade robotics systems have tended to move back towards GOFAI, with much more internal state and elaborate environmental modeling and planning.
Sandwich making activities. This is pretty much the state of the art at present, but maybe in another five or ten years this will be something that you could buy and install in a Café. There may also be an industry in creating plans for the robots to follow which are customized to the particular working environment.
Here's an interview with Sebastian Thrun. He's one of the professors running the current online Introduction to AI course, and a co-author of Probabilistic Robotics. I think that the implementation of Monte Carlo Localisation within ROS is based upon the description of the algorithm from that book.
I'm not a very enthusiastic driver myself, so I hope that within the next couple of decades it will become possible to get into a car and just select the destination, then not have to be concerned about the details of manual driving.
Conversations such as the above are ok up to a point, although there are some confusions and omissions along the way. The familiar standard narrative about technology is wheeled out once again, with the talk about the transition from agrarianism to industrialism. Although this transition undoubtedly did take place in more or less the manner described this doesn't mean that a similar transition is occurring today. In fact the current data suggests the opposite, with employment rising in low skilled jobs and stagnant or falling in higher skilled ones within newer high technology or software-related industries.
There is also the question of the use of AI to help resolve social problems at a political level, and unfortunately here I think the responses from Thrun and Diamandis were weak. It's not the case that political elites (governments and their various agencies) aren't interested in data collection or analytics, which typically involves some amount of AI. Governments obsessively collect and analyze data, using it to guide policy in a wide variety of ways. It's just that this activity is rarely conveyed in any intelligible form to the general populace, and almost never features within popular debate. Recent examples of use of AI by governments would be eigenbehavior analysis of entire nations via mobile phone location logs, drone aircraft, persona management, "screening" at national borders and of civil service employees, and so on.
From what I've seen, Thrun and Norvig's online AI course has been pretty good so far - although
definitely rough around the edges - and I hope that this is the way that
higher education goes in future. However, there is also the question of
over-production of highly educated elites (people with good education
and high expectations about their future status), which according to things I've been reading more recently tends to lead to political
instability. So I don't think it's the case that we're facing an inevitable exponential march towards a Star Trek style future, as many of the Singularitarians seem to assume. The future is likely to be complex, and will include strange loops, paradigmatic phase changes and all sorts of unexpected challenges.
The new package called rxdeveloper-ros-pkg looks quite interesting, and may help to make the process of creating and editing ROS launch files easier. The appearance is similar to the function block editing UIs found in many industrial control systems.
Here the Qbo robot recognizes itself in a mirror. This is quite a nice looking robot, and I like the way that the head moves in a semi-anthropomorphic kind of way.
This is probably just using simple 2D feature based recognition (SIFT, SURF, etc), but the problem of recognizing yourself is a deeper issue which is related to self awareness and theory of mind. If any creature wants to survive it needs to be able to do things such as detect damage to itself, and this involves having a self model which is learned through early interactions with the world, such as play behaviors, together with lifelong habituation. In humans, and presumably also other animals, this can lead to curious phenomena such as phantom limb syndrome.
Currently in systems such as ROS the model of the robot is something which is hand coded by traditional engineering, but in a hypothetical AGI system the model would be learned via self observation and interaction in the environment.
Qbo also uses stereo vision rather than an RGBD sensor. Stereo vision has been a classic problem in computer science, due to the high ambiguity of feature matching, but current dense stereo algorithms have seen great improvements in recent years to the point where the results are similar to those which the Kinect can produce, especially at close range.
Example depth maps from stereo vision are shown in these videos - one of me, and another of a cup on a table. I don't know whether Qbo uses this type of algorithm, but it's one of the open source implementations which are available for use in robotics projects.
Get ready to assume the party submission position, because here is a TurtleBot that is equipped with a 6 Unit Beverage Delivery Interface and is ready to initiate party mode.
While more work and testing needs to be done, the upward facing center mounted sonar sensor should provide a means of reliably signaling to the robot that a beverage is needed by waving a hand over the robot. This should help prevent unnecessary collisions between robots and humans who have reached their beverage capacity.
The Beverage Delivery Interface will likely undergo productification after further development and debugging during holiday testing season. Impatient TurtleBot owners interesting in beta testing should send an email.
There are some minor changes from the above photo and two or three parts that are coming in later this week but orders will ship out at the beginning of next week.
If there is demand we will look at another run next year.
Over at I Heart Engineering the Cybernetic Sales Systems are coming on-line and will be offering a selection of deals through out the day. You can find the currently featured deal by clicking the Cyber Madness animated GIF. The ad banner may be garish but the store is guaranteed to be 100% music free, so at least one of your sensor subsystems should remain intact.
As an adaptation to the Turtlebot I've added a button and audio user interface similar to the one on my larger robot. This uses an Arduino as a means of sensing button presses and communicating those to the netbook.
If you have a small number of locations that you wish the robot to visit then this provides an easy way to tell the robot where to go, which once it has been trained doesn't require that you run Rviz or need any separate computer. If two places are defined on the map then merely pressing the start button will cycle between them to implement a sort of fetch and carry.
Transporting things around within a building at slow speed is pretty much a business model in some scenarios, such as warehouses, hospitals and supermarkets, and could form the basis for more sophisticated domestic applications such as watering plants or dusting/cleaning surfaces like shelves or tabletops.
The button user interface is completely generic and doesn't necessarily require a Turtlebot. It could be used with any PC based robot which runs the ROS navigation system.
Jerome Laplace from Generation Robots sent us some information about their excellent work getting a Nao humanoid robot to play 'Connect 4' versus a human opponent.
There are several interesting things about this video and the technical approach taken for getting everything working. The video production quality is excellent and helps explain to a non-technical audience how humans need to perform roughly the same functions as the robot without getting distracted by mathematics or jargon.
The 'Connect 4' game has some interesting properties in terms of robotics, the game pieces are geometrically uniform cylinders with easy to distinguish colors and the playing field is a grid of circles with a known and fixed spacing. If you were to design a game for a robot to play using computer vision you would be hard pressed to make something better, given that the playing field is basically a camera calibration pattern.
One other nice thing is how the robot is designed to uses it's weaknesses as a strength. If there is a problem with the robot's game play it can detect the failure and ask the human player to correct the placement of the game piece. This robustness also gives it the ability to detect cheating on the part of the human player and the robot can react as needed.
While for now this is a single game, it is pretty clear that this approach could be extended to playing checkers, Othello, or perhaps even a game of Go. It is easy to imagine an accretion of such hacks to the point where a generalized solution becomes possible, at the very least it seems reasonable to build a state machine that can make a reasonable guess as to which game the human wants to play and load the correct computer vision hacks and AI game play code.
I was initially uncertain about the business model behind the development of an emotive game engine for robots to play with children. After contemplation I now believe that this idea holds some promise as a de-virtualization of the Tamagotchi.
Thanks to your continued support, I Heart Engineering has leveled up! Now with a bigger and better unified shipping and manufacturing facility in Brooklyn, NYC.
A recent example of navigation with the Turtlebot. Tuning the navigation parameters is quite tricky and the default values didn't work very well. The parameters I used can be found here.
The next step is to have a way of defining map locations and interactively teaching them in a way similar to my larger robot. Once points of interest are defined within the map then an executive planner can be devised to organize the robot's behavior in terms of high level semantics.
An example of straight legged walking on the HRP-4C robot. Most humanoids have constantly bent knees, and this gives them some leeway to handle vertical forces throughout the stride. Real humans do this by having a curved spine which is flexible, and this robot presumably has something comparable at the waist section.
If you pause the video as the leg is about to be lifted you can see that - unusually for most humanoids - there is a separate toe section which facilitates the push off.
Humans are the only primates who routinely walk upright, and it turns out that being able to do this efficiently requires pretty accurate sensing and motion control, which is why we're now only just beginning to see really human-like walking in robots.
I'm not expecting there to be practical uses of large humanoids like this in the near future, simply because of their large complexity and cost, although in the longer term assuming that current technology trends continue a humanoid form seems to be considered desirable and would fit best with existing infrastructure.
Analog Devices newest inertial sensor is now available with a new 'Tactical Grade' rating on the data sheet. The specs seem ideal for flying robotics with ±450°/sec gyros, ±18 g accelerometers, ±2.5 gauss magnetometer, and an integrated 300-1100 mbar pressure sensor. There is also an embedded temperature sensor included but for some reason they chose to limit themselves to 'Ten Degrees of Freedom'.
The inertial sensor has a low profile package measuring 44mm x 47mm x 14mm, and does away with the ribbon cable used by Analog's other integrated inertial sensors.
The communication interface is via SPI and operates at 3.0-3.3VDC at temperatures from −40°C to +85°C. Interestingly there are four integrated FIR filter banks which could be very useful for removing internal noise sources such as motor vibrations. Alarms and digital I/O round out the feature set.
If you are buying a 'Tactical Grade' gyro, you would expect the best in terms of accuracy, precision and sample rates. The sensor has an internal factor calibration and has optional support to compensate for the effect of linear acceleration on gyroscope bias. Gyros and accelerometers sample at 2.46 kHz after averaging and decimation. The barometric pressure sensor runs at 51.25 Hz. The IMU uses a 32bit twos-complement register to store most measurements. The gyro for example uses the upper 16bits in twos-complement format with a LSB of 0.02°/sec. For the lower 16bits, "[t]he MSB has a weight of 0.01°/sec, and each subsequent bit has 1⁄2 the weight of the previous one". The datasheet could use some more statistical details on the A/D conversion process but it is only Rev. 0.
I look forward to seeing the 'Ultra Mega Tactical Grade' IMU from Analog Devices in the future. This sensor should include an on-board GPS with external antenna connector, additional pressure sensors for airspeed measurement, humidity sensor and integrated real-time quantum clock. The on-board 64bit ARM core provides for maximum bandwidth to the sensors.
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.
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.
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.
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.
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.
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.
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.
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.
Unboxing
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).
Summary
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.
Another Boston Dynamics demonstration. The adaptation to sideways perturbations is pretty impressive. Also this sounds a lot quieter than previous demos, although that may be because there is a compressor located elsewhere via the harness.
For those of you who are interested in OMPL and motion planning in ROS, you can play along at home with the home version of the game [ No real PR2s :(, only simulations ]
OMPL seems to have gotten to the point where it is useful for real robots. More importantly it looks like it is ready for integration on your robot. More after the workshop.
And now for something altogether more practical. Creating a bootable USB drive is likely to be a common task for anyone using ROS on a mobile robot. Hard drives installations will also work, but they contain moving parts which may be vulnerable to failure on a platform which is subject to vibrations and jolts. USB drives are cheap and easily available, difficult to destroy, consume little energy, are easy to create backups from and take up minimal physical space inside the robot. Once you have your system set up on a USB drive you can then easily create a copy on a second drive so that you can have a "stable" version for quick demonstration purposes and a separate development version for all other occasions.
These instructions assume that you're installing some version of Ubuntu, and in this case I was using 11.04. For ROS installation, Ubuntu seems to be the most supported distro. Other distros may work, but sometimes have issues with dependencies when using the --rosdep-install option. It's also a good idea not to use the very latest version, since it typically takes a while before new versions are fully supported by ROS.
One thing to be aware of from the outset is that not all USB flash drives are created equal. There are a variety of storage sizes, but more importantly there are also different access speeds. Try to use a drive which has the highest access speed possible in order to avoid excessive latencies. I used a 16GB Sandisk Cruzer Blade, which seems quite adequate for the task.
2. Format a USB drive as fat32. You can do this easily with Gparted.
3. Using Unetbootin, create a USB install, specifying some non-zero storage space size.
4. Using Gparted unmount the USB drive, then resize the partition so that it's close in size to the amount of data installed. Create a new partition, formatted as ext4, called casper-rw.
Why create this extra partition? Without this the maximum amount of storage is only a couple of gigabytes. ROS is quite a large installation and without the additional partition won't fit onto the drive.
5. Boot from the USB drive.
6. Click on the wireless network icon, select "wireless", pick the current connection then click "Edit". Make sure that "connect automatically" and "available to all users" are selected.
This assumes that you're on an IPv4 network. Click on IPv4 settings, select "manual" as the method then click on "Add". Enter a fixed IP address for the robot, with a netmask of 255.255.255.0 and with the gateway being the IP address of the wireless router. Enter the DNS server IP addresses, which are usually visible from the router's administration page. "Search domains" can be left blank.
Click on "Save".
It makes sense to have the robot on a fixed local IP address, since you can then assign a name to it within the /etc/hosts file and therefore be able to connect to it in a reliable way. It makes even more sense if you have multiple robots.
7. Run synaptic and under "repositories" make sure that other software sources (community, multiverse) are enabled.
10. Create a user that will be used for ssh logins.
sudo adduser <username>
11. Add this user to the sudoers
sudo visudo -f /etc/sudoers
Under the line:
root ALL=(ALL:ALL) ALL
add the line:
user ALL=(ALL:ALL) ALL
Then save with CTRL-X then Y
12. Under "Users and Groups" select the user you made earlier, then click on "Advanced" and make sure that they can use video and audio devices.
13. You may wish to enable remote desktop sharing so that you can use a VNC client to view the robot desktop. If so make sure that "confirm each access" and "enter password" are unticked.
14. Follow the instructions for installing ROS from
16. You may wish to update the package path within:
/opt/ros/${ROS_VERSION_NAME}/setup.sh
In order to include any additional packages which you are using. It's also a good idea to keep a copy of the setup.sh file elsewhere, since subsequent updates can overwrite it.
17. When you've tweaked and tested the installation to your satisfaction you can easily create a backup of it using the dd command line program.
Posts
