I'm at the Pod Car City conference, taking place today and tomorrow in San Jose for PRT developers and customers. Some news tidbits from the conference:

There's news about the world's two small PRT (Personal Rapid Transit) projects, which are both fairly robocar like, in that they involve self-steered rubber tired vehicles.

The AutoNOMOS team at Freie Universität Berlin led by Raul Rojas has shown a demo of their robocar acting as what I have called a whistlecar. Their latest car, named "Made in Germany" performed an autonomous taxi pickup for the press which you can see played out in this video.

This weekend's announcement that Google had logged 140,000 miles of driving in traffic with their prototype robocars got lots of press, but it's not the only news of teams making progress. A team at TU Braunschweig in Germany has their own model which has been driving on ordinary city streets with human oversight. You can watch a video of the car in action though there is a lot of B-roll in that video, so seek ahead to 1:50 and particularly 3:20 for the inside view of the supervisor's hands hovering just over the self-turning steering wheel. There is some information on Stadtpilot here, but we can see many similarities, including the use of the Velodyne 64 line LIDAR on the roof and a typical array of sensors, and more use of detailed maps.

The team at Vislab in Milan has completed most of their Milan to Shanghai autonomous car journey which I have been following. You can read their blog or watch video (sometimes live) of their trip. A lot of the blog has ended up being not about the autonomous challenges, but just the challenges of taking a fleet of very strange looking vehicles in a convoy across Eastern Europe and Asia. For example, they have trucks which can carry their robocars inside, and once decided it was simpler to cross a border into Hungary this way. However, they left driving the vehicles, and the exit officials got very concerned that there was no record of the robocars coming into the country. I presume it wasn't hard to convince them they were not smuggling Hungarian robocars out.

Just released in a New York Times article and sidebar about highways and video, Google has unveiled an internal robot car project that has attained a remarkable level of robotic driving sooner than I and many others had predicted.

There was a bit of a stir when Google last week announced that one of the winners of their 10^100 contest would be Shweeb, a pedal-powered monorail from New Zealand that has elements of PRT. Google will invest $1M in Shweeb to help them build a small system, and if it makes any money on the investment, that will go into transportation related charities.

While I had a preference that Google fund a virtual world for developing and racing robocars I have come to love a number of elements about Shweeb, though it's not robocars and the PRT community seems to not think it's PRT. I think it is PRT, in that it's personal, public and, according to the company, relatively rapid through the use of offline stations and non-stop point to point trips. PRT is an idea from the sixties that makes sense but has tried for almost 50 years to get transit planners to believe in it and build it. A micro-PRT has opened as a Heathrow parking shuttle, but in general transit administrators simply aren't early adopters. They don't innovate.

What impresses me about Shweeb is its tremendous simplicity. While it's unlikely to replace our cars or transit systems, it is simple enough that it can actually be built. Once built, it can serve as a testbed for many of PRT's concepts, and go through incremental improvements.

An Italian team has built a prototype robot they call Dustbot which is aimed (in a backwards way) at the deliverbot vision.

Here's an idea that seems a bit wild and scary at first, but it's doable today and has broad benefits: Small aircraft that don't have landing gear, but instead land and take off from robotic "can't miss" platforms pulled by cables on short airfields.

UPDATE: Some updated ideas and a link to a funded research project looking at similar ideas.

For every small aircraft purchaser, a big decision is whether to get retractable landing gear. They are very expensive, and create a risk of failure, but your plane will fly a lot faster and be more fuel efficient if you get them. What if we could leave the landing gear on the ground?

Imagine a wheeled platform on the runway with robotic control and a variety of systems to perfectly track an approaching aircraft. Pulled by cables, it can accelerate at several "g"s forward and back and left and right. As the aircraft approaches it tracks it and the cockpit display indicates positive lock. If the plane veers left, it veers left. If the plane speeds up it speeds up. Pretty much no matter what the pilot or winds do (other than missing the runway entirely) the plane can't miss landing on it. It's spring loaded so even if the landing is a bit hard the shock is cushioned. Done right, it's just like having fancy shock absorbing landing gear.

This story from the Register about a test at the Stanford VAIL Lab reports an interesting result. They created a fake robocar, with a human driver hidden in the back. The test subjects then were told they could push the autopilot button and use the car. And they did, immediately picking up their newspapers to read as they would in a taxi (which is what they really were in.)

Today marks the start of a remarkable robocar trek from Italy to China. The team from the Vislab International Autonomous Challenge start in Italy and will trek all the way to Shanghai in electric autonomous vehicles, crossing borders, handling rough terrain and going over roads for which there are no maps in areas where there is no high-accuracy GPS.

I don't often write about robots that don't go on roads, but last night I stopped by Willow Garage, the robot startup created by my old friend Scott Hassan. Scott is investing in building open robotics platforms, and giving much of it out free to the world, because he thinks progress in robotics has been far too slow.

Last week, I attended a talk by Marc Raibert the former MIT Professor who founded Boston Dynamics, the makers of the BigDog 4-legged walking robot. If you haven't seen the various videos of BigDog you should watch them immediately, as this is some of the most interesting work in robotics today.

Walking pack robots like BigDog have a number of obvious applications, but at present they are rather inefficient. BigDog is powered by a a 2 stroke compressor that drives hydraulics. That works well because the legs don't need engines but can exert a lot of force. However, its efficiency is in the range of 2 gallons per mile, though this is just a prototype level. It is more efficient on flat terrain and pavement, but of course wheels are vastly more efficient there. As efficient as animals are, wheeled vehicles are better if you don't make them heavy as tanks and SUVs.

BigDog walks autonomously but today is steered by a human, or in newer versions, can follow a human walking down a trail, walking where she walked. In the future they want to make an autonomous delivery robot that can be told to take supplies to troops in the field, or carry home a wounded soldier.

I wondered if BigDog isn't trying too hard to be a mule, carrying all the weight up high. This makes it harder for it to do its job. If it could just tow a sledge (perhaps a container with a round teflon bottom with some low profile or retractable wheels) it might be able to haul more weight. Particularly because it could pay out line while negotiating something particularly tricky and then once stable again, reel in the line. This would not work if you had to go through boulders that might catch the trailer but for many forms of terrain it would be fine. Indeed, Boston Dynamics wants to see if this can work. On the other hand, they did not accept my suggestion that they put red dye in the hydraulic fluid so that it spurts red blood if damaged or shot.

The hydraulic design of BigDog made me wonder about applications to robocars. In particular, it seems as though it will be possible to build a light robocar that has legs folded up under the chassis. When the robocar got to the edge of the road, it could put down the legs and be able to climb stairs, go over curbs, and even go down dirt paths and rough terrain. At least a lightweight single person robocar or deliverbot might do this.

At the positive end of my prediction that robocars will enable people to travel in "the right vehicle for the trip" and given that most trips are short urban ones, it follows that most robocars, if we are efficient, will be small light vehicles meant for 1-2 people, with a lesser number of larger ones for 4-5 people.

Last week, Volvo was demoing some new collision avoidance features in their S60. I've talked about the S60 before, as it surprised me putting pedestrian detection into a car before I expected it to happen. Unfortunately in an extreme case of demo disease known to all computer people, somebody has made an error with the battery, and in front of a crowd of press, the car smashed into the truck it was supposed to avoid. The wired article links to a video.

This weekend I attended the annual "Robogames" competition, which took place here in the Bay Area. Robogames is mostly a robot battle competition, with a focus on heavily armed radio-controlled robots fighting in a protected arena. For several years robot fighting was big enough to rate some cable TV shows dedicated to it. The fighting is a lot of fun, but almost entirely devoid of automation -- in fact efforts to use automation in battle robots have mostly been a failure.

The RC battles are fierce and violent, and today one of the weapons of choice is something heavy that spins at very high speed so that it builds up a lot of angular momentum and kinetic energy, to transfer into the enemy. People like to see robots flying through the air and losing parts to flying sparks. (I suspect this need to make robots very robust against attack makes putting sensors on the robots for automation difficult, as many weapons would quickly destroy a lot of popular sensors types.) The games also featured a limited amount of automated robot competition. This included some lightweight (3lb and 1lb) automated battles which I did not get to watch, and some some hobby robot competitions for maze-running, line following, ribbon climbing and LEGO mindstorms. There was also semi-autonomous robot battle called "kung fu" where humanoid robots who take high level commands (like punch, and step) try to push one another over. There is also sumo, a game where robots must push the other robot out of the ring.

I had hoped the highlight would be the Robo-magellan contest. This is a hobbyist robot car competition, usually done with small robots 1 to 2 feet in length. Because it is hobbyists, and often students, the budgets are very small, and the contest is very simple. Robots must make it through a simple outdoor course to touch an orange cone about 100 yards away. They want to do this in the shortest time, but for extra points they can touch bonus cones along the way. Contestants are given GPS coordinates for the target cones. They get three tries. In this particular contest, to make it even easier, contestants were allowed to walk the course and create some extra GPS waypoints for their robots.

These extra waypoints should have made it possible to do the job with just a GPS and camera, but the hobbyists in this competition were mostly novices, and no robot reached the final cone. The winner got within 40 feet on their last run, but no performance was even remotely impressive. This was unlike past years, where I was told that 6 or more robots would reach the target and there would be real competition. This year's poor showing was blamed on budgets, and the fact that old teams who had done well had moved on from the sport. Only 5 teams showed up.

The robots were poor for sensors. While all would have a GPS, in 1 or 2 cases the GPS systems failed and the robots quickly wandered into things. A few had sonar or touch-bars for obstacle detection, but others did not, and none of them did their obstacle detection well at all. For most, if they ran into something, that was it for that race. Some used a compass or accelerometers to help judge when to turn and where to aim, since a GPS is not very good as a compass.

I've been predicting a great deal of innovation in cars with the arrival of robocars and other automatic driving technologies. But there's a lot of other computerization and new electronics that will be making its way into cars, and to make that happen, we need to make the car into a platform for innovation, rather than something bought as a walled garden from the car vendor.

In the old days, it was fairly common to get a car without a radio, and to buy the radio of your choice. This happened even in higher end cars. However, the advantages in sound quality and dash integration from a factory-installed radio started to win out, especially with horizontal market Japanese companies who were both good at cars and good at radios.

For real innovation, you want a platform, where aftermarket companies come in and compete. And you want early adopters to be able to replace what they buy whenever they get the whim. We replace our computers and phones far more frequently than our cars and the radios inside them.

To facilitate this, I think the car's radio and "occupant computer" should be merged, but split into three parts:

1. The speakers and power amplifier, which will probably last the life of the car, and be driven with some standard interface such as 7.1 digital audio over optical fiber.
2. The "guts" which probably live in the trunk or somewhere else not space constrained, and connect to the other parts
3. The "interface" which consists of the dashboard panel and screen, with controls, and any other controls and screens, all wired with a network to the guts.

Ideally the hookup between the interface and the guts is a standardized protocol. I think USB 3.0 can handle it and has the bandwidth to display screens on the dashboard, and on the back of the headrests for rear passenger video. Though if you want to imagine an HDTV for the passengers, its possible that we would add a video protocol (like HDMI) to the USB. But otherwise USB is general enough for everything else that will connect to the guts. USB's main flaw is its master-slave approach, which means the guts needs to be both a master, for control of various things in the car, and a slave, for when you want to plug your laptop into the car and control elements in the car -- and the radio itself.

Of course there should be USB jacks scattered around the car to plug in devices like phones and memory sticks and music players, as well as to power devices up on the dash, down in the armrests, in the trunk, under the hood, at the mirror and right behind the grille.

Finally there need to be some antenna wires. That's harder to standardize but you can be we need antennas for AM/FM/TV, satellite radio, GPS, cellular bands, and various 802.11 protocols including the new 802.11p. In some cases, however, the right solution is just to run USB 3.0 to places an antenna might go, and then have a receiver or tranceiver with integrated antenna which mounts there. A more general solution is best.

This architecture lets us replace things with the newest and latest stuff, and lets us support new radio protocols which appear. It lets us replace the guts if we have to, and replace the interface panels, or customize them readily to particular cars.

A couple of weeks ago I wrote about the need for a good robocar driving simulator. Others have been on the track even earlier and are arranging a pair of robotic driving contests in simulator for some upcoming AI conferences.

It is no coincidence that two friends of mine have both founded companies recently to build telepresence robots. These are easy to drive remote control robots which have a camera and screen at head height. You can inhabit the robot, and drive it around a flat area and talk to people by videoconferencing. You can join meetings, go visit people or inspect a factory. Companies building these robots, initially at high prices, intend to sell them both to executives who want to remotely tour remote offices and to companies who want to give cheaper remote employees a more physical presence back at HQ.

There are also a few super-cheap telepresence robots, such as the Spykee, which runs Skype video conferencing and can be had for as low as $150. It's not very good, and the camera is very low down, and there's no screen, but it shows just how cheap such a product can get.

"Anybots" QA telepresence robot

When they get down to a price like that, it seems inevitable to me that we will see an emergency services robot on every block, primarily for use by the police. When there is a police, fire or ambulance call to an address, an officer could immediately connect to the robot on that block and drive it to the scene, to be telepresent. The robot would live in a small, powered protective closet either paid for by the city, but more likely just donated by some neighbour on the block who wants the fastest possible emergency response. Called into action, the robot's garage door would open and the robot would drive out, and probably be at the location of the emergency within 60 to 120 seconds, depending on how densely they are placed. In the meantime actual first responders might also be on the way.

What could such a robot do?

Watching and managing children is one of the major occupations of the human race. A true robot babysitter is still some time in the future, and getting robocars to the level that we will trust them as safe to carry children is also somewhat in the future, but it will still happen much sooner.

Today I want to explore the implications of a robocar that is ready to safely carry children of certain age ranges. This may be far away because people are of course highly protective of their children. They might trust a friend to drive a child, even though human driving records are poor, because the driver is putting her life on the line just as much as the child's, while the robot is just programmed to be safe, with no specific self-interest.

A child's robocar can be designed to higher safety standards than an adult's, with airbags in all directions, crumple zones designed for a single occupant in the center and the child in a 5-point seatbelt. As you know, with today's modern safety systems, racecar drivers routinely walk away from crashes at 150mph. Making a car that won't hurt the child in a 40mph crash is certainly doable, though not without expense. A robocar's ability to anticipate an accident might even allow it to swivel the seat around so that the child's back is to the accident, something even better than an airbag.

The big issue is supervision of smaller children. It's hard to say what age ranges of children people might want to send via robocar. In some ways infants are easiest, as you just strap them in and they don't do much. All small children today are strapped in solidly, and younger ones are in a rear facing seat where they don't even see the parent. (This is now recommended as safest up to age 4 but few parents do that.) Children need some supervision, though real problems for a strapped in child are rare. Of course, beyond a certain age, the children will be fully capable of riding with minimal supervision, and by 10-12, no direct supervision (but ability to call upon an adult at any time.)

One of the things that's harder to predict about robocars is what they will mean for how cities are designed and how they evolve. We're notoriously bad at predicting such things, but it is still tempting.