Topic

There have been a wide variety of announcements of late giving the impression that somebody has “solved the problem” of making a robocar affordable, usually with camera systems. It’s widely reported how the Velodyne LIDAR used by all the advanced robocar projects (including Google, Toyota and many academic labs) costs $75,000 (or about $30,000 in a smaller model) and since that’s more than the cost of the car, it is implied that is a dead-end approach.

I have written an analysis of the issues comparing LIDARS (which are currently too expensive, but reliable in object detection) and vision systems (which are currently much less expensive, but nowhere near reliable enough in object detection) and why different teams are using the different technologies. Central is the question of which technology will be best at the future date when robocars are ready to be commercialized.

In particular, many take the high cost of the Velodyne, which is hand-made in small quantities, and incorrectly presume this tells us something about the cost of LIDARs a few years down the road, with the benefits of Moore’s Law and high-volume manufacturing. Saying the $75,000 LIDAR is a dead-end is like being in 1982, and noting that small disk drives cost $3,000 and declaring that planning for disk drive storage of large files is a waste of time.

I will add some notes about Ionut Budisteanu, the 19-year old Romanian. His project was great, but it’s been somewhat exaggerated by the press. In particular, he mistakenly calls LIDAR “3-D radar” (an understandable mistake for a non-native English speaker) and his project was to build a lower-cost, low-resolution LIDAR, combining it with cameras. However, in his project, he only tested it in simulation. I am a big fan of simulation for development, learning, prototyping and testing, but alas, doing something in simulation, particularly with vision, is just the first small step along the way. This isn’t a condemnation of Mr. Budisteanu’s project, and I expect he has a bright future, but the press coverage of the event was way off the mark.

Today the National Highway Transportation Safety Agency (NHTSA) released their plan on regulation of automated vehicles, a 14 page document on various elements of the technology and how it might be regulated.

No regulations yet of course, but a message that they plan to look hard at the user interface, particularly on the handoff between a human driver and the system. All reasonable stuff. They define 4 levels of autonomy (similar to prior lists) and say they don’t expect full unmanned operation for some time, and discourage states from even making it legal to use level 3 (where the driver can do another task) by ordinary folks yet — only testing should be allowed.

It’s good that NHTSA is studying this, and they seem to understand that it’s too early to write regulations. It’s pretty easy to make mistakes if you write regulations before the technologists have even figured out what they intend. For example this document, as well as some Nevada law documents, suggested regulations that required the vehicle to hand over control if the driver used the wheel, brakes or accelerator. Yet by another logic, if the driver kicks the gas pedal by mistake and does not have her hands on the wheel, would we want the law to demand that the system relinquish the wheel, causing the vehicle to leave the lane if the driver doesn’t get on it quickly?

At this point their goal is lots of research on what to do, and that’s reasonable. Of course, the sooner the vehicles can get on the road safely, the sooner they can save lives, and NHTSA understands that. I also hope that the laws will not push small players out of the market entirely, as long as they can test and demonstrate safety as well as the bigger players.

I have owned a laptop for decades, and I’ve always gone for the “small and light” laptop class because as a desktop user, my laptop is only for travel, and ease of carrying is thus very important. Of course once I get there I have envied the larger screens and better keyboards and other features of the bigger laptops people carry, but generally been happy with the decision.

Others have gone for “desktop replacement” laptops which are powerful, big and heavy. Those folks don’t have a desktop, at most they plug their laptop into an external monitor and other peripherals at home. The laptop is a bitch to carry but of course all files come with it.

Today, the tablet is changing that equation. I now find that when I am going into a situation where I want a minimal device that’s easy to carry, the tablet is the answer, and even better the tablet and bluetooth keyboard. I even carry a keyboard that’s a fair bit larger than the tablet, but still very light compared to a laptop. When I am in a meeting, or sitting attending an event, I am not going to do the things I need the laptop for. Well, not as much, anyway. On the airplane, the tablet is usually quite satisfactory — in fact better when in coach, though technically the keyboard is not allowed on a plane. (My tablet can plug in a USB keyboard if needed.)

Planes are a particular problem. It’s not safe to check LCD screens in your luggage, so any laptop screen has to come aboard with you, and this is a pain if the computer is heavy.

With the tablet dealing with the “I want small and light” situations, what is the right laptop answer?

One obvious solution are the “convertible tablet” computers being offered by various vendors. These are laptops where the screen is a tablet and it can be removed. These tend to be Windows devices, and somewhat expensive, but the approximate direction is correct.

Another option would be to break the laptop up into 3 or more components: read more »

The tablet, running your favourite tablet OS

A keyboard, of your choice, which can be carried easily with the tablet for typing-based applications. Able to hold the laptop and connect to it in a permitted way on the plane. Touchpad or connection for mouse.

A “block,” whose form factor is now quite variable, with the other stuff.

But I do believe in the idea of the self-driving electric taxi as the best answer for our future urban transportation. So how do you make it happen?

There’s a big problem with this vision. Electric cars today have perhaps 100 to 150 miles of range, which means 3 to 6 hours of operation, depending on the speeds you go. You can make more range (like a Telsa S) but only by adding a lot of weight and cost. But an effective taxi is on shift all day, or at least all the waking hours, and could easily operate 8 to 10 hours per day. While any taxi will have downtime during the day (particularly at off-peak hours) the recharge of the battery takes so long it’s hard to do during the day. Ideally you want to charge at night, when power is cheap. So let’s consider the options.

Large battery pack

You could make a vehicle with enough battery for a full day’s work, and charge it at night. This is very expensive today, and also takes a lot of room and weight in the vehicle, reducing its efficiency. You also need taxis at night so either way you have to have some taxis that work at night and recharge in the day, but not as many.

Battery swap

While battery swap did not pan out for Better Place, it actually makes much more sense for a robotic taxi fleet. You just need a few swap stations in the city. It doesn’t bother the robots if they take a while for a swap (mainly it bothers you because you need more stations.) And while humans would get very angry if they came to the swap station and saw they were 4th in line at 5 minutes/swap, robots would just schedule their swaps and get in and get out.

That’s all good, and it solves a few other problems. Taxis will be putting on lots of miles every day, and they will probably wear out their battery quickly. If the rest of the vehicle has not worn out, swap becomes ideal — replace the vehicle’s components when you need to, including the most expensive part, the battery. It also makes it easier to charge all batteries only at night, on cheap baseload power.

Swap also allows the batteries to be only used in the “easy” part of their duty cycle (from 80% to 20%) without much hassle. You only get 60% of the range, but you don’t care a lot, other than in having to
buy more battery packs. You just do the math on what’s cheaper.

Superchargers

A working supercharger that can recharge a vehicle in an hour solves the problem as well. Robotic taxis can always find a spare hour without much loss of efficiency. (Indeed with none as they will age by active mile or hour.) The big problem is that supercharging generally is felt to stress the batteries and reduce the lifetime of the packs. Certainly running a car on full cycle every day and supercharging it is not going to produce a happy battery.

A robocar supercharging station could do a few extra things, though. For example, you could hook the car up to a special cooling system to pump externally chilled coolant through the batteries, as heat is the big killer in the supercharge. You might even find a way to put some pressure in to keep the cases from expanding that much, as this is a big stressor when charging.

Supercharging probably has to be done in the day, with more expensive power. One charge for the morning peak and another for the evening. Some speculate it’s worth using your inventory of old battery packs to store power during the night to release in the day. Solar can also help during the day — on sunny days, at least.

While automated connection is good, you really would not have many supercharging centers, due to their high power needs, so they could have human staff to do the work.

Both the supercharging and battery swap stations do not need to be located all that conveniently for humans. Instead, you can put them near power substations where megawatts can be purchased.

More vehicles and ordinary L2 charging

If the batteries are more expensive than the vehicles, then perhaps just having more vehicles to house all your battery packs is the answer. Then you have vehicles spending their time idle, and charging at ordinary level 2 (6kw) rates. Full level 2 can add about 20 miles of range to a car like a Leaf in an hour. Depending on the usage patterns that might not be too bad. Of course it’s daytime power again, which is expensive. Urban taxis won’t go more than about 25mph on average if they are lucky, often less, particularly at rush hour. Suburban will go a bit faster. You need stations that allow a robot to recharge, which could mean inductive, or human-staffed, or eventual robotic plug-in systems. Don’t laugh at the idea of human-staffed. The robot will not be in a super rush, so stations near retail shops or existing gas stations would work fine as long as somebody can come out and tend to the robot on connect and disconnect within 5 minutes.

It may seem like more vehicles is more expensive, but that’s not necessarily true. It depends on how and why the vehicles wear out. Ideally you design the vehicle so battery and most major vehicle components all reach end-of-life at a similar time or that they can be replaced easily. That may mean a battery that can be swapped — but in the shop, not at an automatic swap station.

Plug in hybrids?

Plug in hybrids of course solve the problem, and they can charge when they can to be mostly electric and only use that gas engine more rarely. This actually creates a downside — it’s expensive to have a fossil fuel power train around to barely use it. And it adds a fair bit to the maintenance cost. This does allow for highway travel. Otherwise, you send a liquid fuel car to anybody wanting to do a long highway trip - save the electrics for the urban travel.

Very light vehicles

Today’s electrics use about 250 to 300 watt-hours/mile. OK, but not great. Efficient designs can go below 100 watt/hours per mile. That means doing 300 miles, which is enough for a full day in a city cab, needs only 30kwh (probably a 45kwh battery.) That’s a $22K battery today, but it will be a $9K battery by the end of this decade according to predictions. This might be quite reasonable.

First is a report on the Volkswagen XL1 the car that gets 100km per litre, or 260mg.

As you read the description, you would be likely to ask, who would buy a car like this, which takes so long to get to highway speed and skimps on anything that would add weight?

The answer of course is that only a small minority are willing to buy lightweight, super-efficient cars with poor acceleration because they save a bunch of fuel. The average American car owner spends less than $2,000 a year on fuel, and while dropping it to $200 would be very nice, it’s not something people are ready to compromise a ton of other important car features for when they buy a car. It’s even harder to justify it to go from $800/year in a Prius to $200 in an ultralight, especially if the car costs more because of it.

This is the fact about robocars which changes the game. Mobility on demand from self-delivering robocars rewrites all the economics of cars because it changes the question from “What car should I buy?” to “What car do I want to ride in for this trip?”

If you buy such a car, you know you will do almost all your car travel in it. You are saying to yourself, I will never go driving for fun. I will never go on a trip in the mountains. I’ll never put 4 friends in my car. Never, or almost never. People don’t want to say that to themselves.

All that goes away when asking the question about what to ride in for an upcoming trip. If you’re going to be taxied across town, never even taking the wheel, you don’t care that the car can’t accelerate. In fact, you would prefer a gentle trip with smooth accelerations. You don’t care if the car can climb a mountain, or drive in snow, or even go on the highway if this trip doesn’t involve a highway.

Because you don’t care about those things, you will bump the priority of other things — is it comfortable? Does it come quickly? Is the price low? The latter question will make you prefer the efficient car.

Some questions will remain the same. You’ll always want safety. But so many of the other factors change so much that all the economics of cars get rewritten. So expect to see more cars like this, or the Very Light Car or the half-width vehicles I have written about.

Google [x]

You might like to read this story today that looks inside Google[x] the lab which is making Googl’es robocar and where I have been a consultant. That lab rarely lets the press in. You may not learn a lot about the Google car project from it, but you will learn about the thinking there.

Back in the 90s, my close friend Kathy Kleiman was researching computer history and came upon photos of the ENIAC and wondered who the unnamed women in the photos were. At first, she was told they were models hired to decorate the computer, but further investigation revealed they were the ones programming it.

The six women were professional computers, which was a job title early in the century — people with math degrees hired to perform calculations, in particular ballistic firing tables for the war. Because of the war, skilled women got these jobs, and the best of the team were asked to write software to get the machine to do the tables they were doing by hand. They were given no instruction, just the wiring diagrams and other machine designs, and created the first software applications, including inventing things like the first sort routine and many other things fundamental to our profession.

Because nobody knew the history of these founders of our profession, Kathy sought them out, and was able to record video interviews with 4 of them. These interviews have languished in the can for many years, and alas, all 6 of them are now deceased. I’ve been trying to help for many years, but in a fortuitous lunch, I was able to make the introductions necessary to arrange funding through the efforts and support of my friends Megan Smith, Anne Wojcicki and Lucy Southworth.

Kathy got to make the announcement at Google I/O in a special session about female techmakers featuring an array of accomplished women in technology. She showed a small section of the movie’s trailer. Her section can be seen 9 minutes into the video, and the programmers at 11:30. (Megan accidentally called me Brad Feldman, but I forgive her :-)

Software development is perhaps the most important new profession of the 20th century — and there were many — and the story of the six unsung founders of that profession will finally be presented to a large audience. I’ll announce when the documentary is released.

There are a growing number of apps designed to help people find parking, and even reserve and pay for parking in advance. Some know the state of lots. These apps are good for the user but also can produce a public good by reducing the number of people circling looking for parking. Studies suggest in certain circumstances a large fraction of the cars on the road are doing that.

This weekend, I attended the Maker Faire. I’ve been to almost every Make Faire, including the first, and now it’s grown to be far too successful — you can hardly walk down the aisles at the busy times. They need more space and a way to put more of it outside so thin out the crowds. Still, it is one of those places that makes you feel very clearly you are in the 21st century.

Early on Maker Faire realized it had a parking problem. The lot at the fairgrounds fills up now even before the event opens, and they manage various satellite lots and run shuttle buses to them.

This year they tried something interesting, a twitter feed with parking updates. They tweeted when lots filled up or re-opened, and suggested where to go. They took some limited feedback about lack of shuttles. I think that it by and large worked and reduced traffic around the event.

However, my judgment is that they were not entirely honest in their tweets. This year, and in prior years, they strongly encouraged people to go to one of the most remote lots, regularly telling people it was the fastest route to the event. This was not true. I don’t want to ascribe any particular malice here, but there is a suspicion that there is a temptation to make reports in the interest of the event rather than the user. This does have positives, in that cars diverted from near the event reduce traffic which makes the shuttle buses run much faster, but if you give wrong information (deliberately or by accident) this means people stop trusting it and you get the traffic back as more people ignore it.

For example, we stopped at a remote lot, and saw a very long shuttle line. We drove on to a closer lot (also reported as having spaces, but not reported as clearly a better choice) to find lots of spaces, no shuttle line, frequent shuttles and also a walk that was only slightly longer than the shuttle trip. read more »

Studies have shown that if you leave USB sticks on the ground outside an office building, 60% of them will get picked up and plugged into a computer in the building. If you put the company logo on the sticks, closer to 90% of them will get picked up and plugged in.

USB sticks, as you probably know, can pretend to be CD-ROMs and that means on many Windows systems, the computer will execute an “autorun” binary on the stick, giving it control of your machine. (And many people run as administrator.) While other systems may not do this, almost every system allows a USB stick to pretend to be a keyboard, and as a keyboard it also can easily take full control of your machine, waiting for the machine to be idle so you won’t see it if need be. Plugging malicious sticks into computers is how Stuxnet took over Iranian centrifuges, and yet we all do this.

I wish we could trust unknown USB and bluetooth devices, but we can’t, not when they can be pointing devices and mice and drives we might run code from.

New OS generations have to create a trust framework for plug-in hardware, which includes USB and firewire and to a lesser degree even eSata.

When we plug in any device that might have power over the machine, the system should ask us if we wish to trust it, and how much. By default, we would give minimum trust to drives, and no trust to pointing devices or keyboards and the like. CD-Roms would not get the ability to autorun, though it could be granted by those willing to take this risk, poor a choice as it is.

Once we grant the trust, the devices should be able to store a provided key. After that, the device can then use this key to authenticate itself and regain that trust when plugged in again. Going forward all devices should do this.

The problem is they currently don’t, and people won’t accept obsoleting all their devices. Fortunately devices that look like writable drives can just have a token placed on the drive. This token would change every time, making it hard to clone.

Some devices can be given a unique identifier, or a semi-unique one. For devices that have any form of serial number, this can be remembered and the trust level associated with it. Most devices at least have a lot of identifiers related to the make and model of device. Trusting this would mean that once you trusted a keyboard, any keyboard of the same make and model would also be trusted. This is not super-secure but prevents generic attacks — attacks would have to be directly aimed at you. To avoid a device trying to pretend to be every type of keyboard until one is accepted, the attempted connection of too many devices without a trust confirmation should lock out the port until a confirmation is given.

The protocol for verification should be simple so it can be placed on an inexpensive chip that can be mass produced. In particular, the industry would mass produce small USB pass-through authentication devices that should cost no more than $1. These devices could be stuck on the plugs of old devices to make it possible for them to authenticate. They could look like hubs, or be truly pass-through.

All of this would make USB attacks harder. In the other direction, I believe as I have written before that there is value in creating classes of untrusted or less trusted hardware. For example, an untrusted USB drive might be marked so that executable code can’t be loaded from it, only classes of files and archives that are well understood by the OS. And an untrusted keyboard would only be allowed to type in boxes that say they will accept input from an untrusted keyboard. You could write the text of emails with the untrusted keyboard, but not enter URLs into the URL bar or passwords into password boxes. (Browser forms would have to indicate that an untrusted keyboard could be used.) In all cases, a mini text-editor would be available for use with the untrusted keyboard, from where one could cut and paste using a trusted device into other boxes.

A computer that as yet has no trusted devices of a given class would have to trust the first one plugged in. Ie. if you have a new computer that’s never had a keyboard, it has to trust its first keyboard unless there is another way to confirm trust when that first keyboard is plugged in. Fortunately mobile devices all have built in input hardware that can be trusted at manufacture, avoiding this issue. If a computer has lost all its input devices and needs a new one, you could either trust implicitly, or provide a pairing code to type on the new keyboard (would not work for mouse) to show you are really there. But this is only a risk on systems that normally have no input device at all.

For an even stronger level of trust, we might want to be able to encrypt the data going through. This stops the insertion of malicious hubs or other MITM intercepts that might try to log keystrokes or other data. Encryption may not be practical in low power devices that need to be drives and send data very fast, but it would be fine for all low speed devices.

Of course, we should not trust our networks, even our home networks. Laptops and mobile devices constantly roam outside the home network where they are not protected, and then come back inside able to attack if trusted. However, some security designers know this and design for this.

Yes, this adds some extra UI the first time you plug something in. But that’s hopefully rare and this is a big gaping hole in the security of most of our devices, because people are always plugging in USB drives, dongles and more.

Hints from the release this week of the 2014 Mercedes S-Class suggest that it doesn’t have the promised traffic jam assist. Update: Other reports suggest it might still be present.

The S-class only gets major updates infrequently, though an intermediate update will come in 2017.
A story on Auto Express quotes Mercedes as saying “We can do it now, but there are rules in place that we have to accept” but that a fully autonomous car will come before the next full-revision of the S class due in 2021.

Instead, this car features a lanekeep + ACC mode that requires your hand be “touching” the wheel, and starts complaining if you take your hands off for a while.

This is a setback on what was to be the first commercially released car. While the various state laws do not tend to cover cars that provide an autopilot that requires constant visual attention from the driver, Mercedes may have been afraid of the regulatory environment in the Europe.

In addition, there has always been a special risk to this approach. Even if you insist to the driver that they must pay attention, they will surely ignore that warning once they get away with occasional inattention — after all, they will send text messages now with no auto-driving at all. Car companies can build a lane-keeping car today, but to stop you from trusting it too much they end up with systems like “keep touching the wheel” or a gaze detector that makes sure you keep watching the road, and people don’t like these systems very much.

Will Volvo and Audi, who have also announced plans for lakekeep+ACC super-cruise cars also pull back? Cadillac, which actually uses the name super-cruise, has pulled back from their 2015 date while at the same time talking to the press about their testing program.

Senate Hearings

In other news, the hearings in the Senate yesterday had most of their focus on these early technologies, and as expected, both David Strickland of NHTSA and the various industry folks were gung-ho on DSRC for V2V and very eager to recommend that the FCC not be allowed to convert the DSRC spectrum to unlicenced as it wishes to do. Here is a summary of the meeting which was attended by only a few senators. Both Johnson and Rockefeller surprised me with their skill in the questions. While Johnson was not up on all the ADAS technologies, he was able to see through a number of the industry claims.

Today, a survey conducted by Cisco showed very high numbers of people saying, “yes, they would ride in a robocar.” 57% said yes globally, with 60% in the USA and an incredible 95% in Brazil. (Perhaps it is the trully horrible traffic in the big cities of Brazil which drives this number.) A bit more surprising was the 28% number for Japan.

When they asked people if they would put their kids in a car, the answer was lower, but only slightly lower, which surprises me, as I felt it should take a bit more trust demonstration for people do do that. The reality is that if 60% are saying yes right now, without having seen the technology at all, the real number is actually quite a bit higher.

The Japanese number is also curious, since our stereotype is that the Japanese are the people most accepting of robotics in the world.

An British Survey reported similar results, with highest desire in London — possibly also related to the amount of traffic.

Another survey from the UK asked the question “which company would you trust to improve car safety” with astonishing results. The winner was Apple, which has no announced car safety plans, with Google in 2nd place. What is shocking is that Volvo comes 3rd — really a close tie with Google, and Mercedes 4th. Volvo’s entire brand is to be the car safety leader, and Mercedes has been trying to take that status away, but I would never have guessed that the silicon valley tech companies would win this.

It’s even more surprising that Apple beats Google. While Apple certainly has a quality brand, Google is the only one known to be working on cars and safety. One has to wonder just how the questions were put to these new-car buyers.

Yesterday’s KALW radio show went pretty well, the phone-in questions were pretty reasonable. The MP3 is up on their site.

I will be a guest on Monday the 13th (correction — I originaly said the 14th) on a the “City Visions” program, produced by one of San Francisco’s NPR affiliates, KALW. The show runs at 7pm, and you can listen live and phone in (415-841-4134), or listen to the podcast later. Details are on the page about the show.

Other guests include Bryant Walker Smith of Stanford, Martin Sierhuis of the Nissan robocar lab and Bernard Soriano from the California DMV. Should be a good panel.

Here’s a roundup of various recent news items on robocars. There are now a few locations, such as DriverlessCarHQ and the LinkedIn self-driving car group which feature very extensive listing of news items related to robocars. Robocars are now getting popular enough that there are articles every day, but only a few of them contain actual real news for readers of this site or others up on the technology.

Tesla

An offhand remark from Elon Musk reveals he is interested in an “autopilot” some day for Tesla models, and has spoken to Google about it. Google declined comment. Musk says he wants a cheaper, camera based system, a surprising mistake for him. (Cameras are indeed much cheaper but not yet up to the task. LIDARs are super expensive but Musk’s mistake is in not remembering that electronics technology that’s expensive in early, small volume models does not stay expensive.)

The Tesla Model S is not a good car to make into a robocar though — it’s super fun to drive, and that’s part of why you pay so much money for it. Nothing wrong with fun to drive cars, but you should automate the boring car and leave the fun car on manual, at least for now.

Shuttles driven by maps

The Cybergo made by French company Induct is a low speed robotic shuttle for campus use. Particularly interesting is that it drives using a laser and mapping for localization — a similar fashion to the Google car and other DARPA challenge cars. It is able to mingle with pedestrians by virtue of just going slow enough to be able to stop in time and be safe.

The Oregon pullback is notable because one of the cited reasons was the desire to study V2V. While I have written recently on issues with V2V this moves it out of the “mostly harmless” category. V2V efforts will be useful for robocars, but not for decades, and I strongly believe it would be extreme folly to allow V2V issues to affect the progress of robocars.

Unlike Nevada’s law, many of the other state laws do not cover unmanned operation. While the reasons for this are obvious, because it’s harder to understand unmanned operation in the context of existing law, we should not forget that unmanned operation is where most of the real benefits of robocars accrue — self-delivery, mobility on demand, parking, self-refueling, service to the elderly and disabled and much more. Not that manned operation is a slouch, offering the reduced accidents and recovery of productive time as benefits.

California’s DMV recently held hearings in Sacramento as part of their process of writing the regulations required by the California bill, passed in 2012. The regulations need to be done by 2015 but may be done sooner. The US DOT also solicited comments last month.

Google hits 500,000

I noted earlier that Google announced it had hit 500,000 miles of autonomous operation on ordinary streets. Even more notable was chief engineer Chris Urmson’s report of over 90,000 miles without a safety-critical incident. (This is an incident where the safety drivers had to take over where the vehicle would have probably caused an accident.) That’s not as good as a human yet — humans have an accident about ever 250,000 miles in the USA, but getting much closer. 500,000 miles, by the way, is more than the distance to the moon and back — Google [X] always talks about moonshots — and more than many people will drive in their lifetimes.

Cadillac & Car Companies

Cadillac has pushed back the supposedly 2015 delivery for their “super cruise” product. It now will come later in the decade. Car maker conservatism is to be expected, but other makers are pushing their dates forward. The Mercedes 2014 S Class is still on track to be first.

BMW has announced a partnership with Continental, the major auto parts supplier. Continental has been pushing their cruising car for a while — I’ve ridden in it — but BMW has its own impressive effort in ConnectedDrive Connect. Today, it is quite common for systems branded by a car maker to actually be made entirely by a supplier, who gives up the branding and limelight for money. It will be interesting to see how this collaboration works. They will be testing on the autobahn.

Car company date forecasts continue to be long term, with dates in the range of 2025 for full autonomy as cited by BMW.

Bosch, another top supplier, has been making its own announcements of advanced sensors and other tools.

Fake Google Car in New York

A crew created a fake Google car and drove it around NYC. What’s impressive is how many people thought they were seeing the real thing.

Articles

While there have been scores of articles, I will point to my friend Virginia Postrel’s Bloomberg article on Silicon Valley and robocars since I was her prime source — so it must be good. :-)

A nice trick from Daimler which I liked — a system to be kind to pedestrians as they walk down the street near parked robocars that sense them. Their plan is to light the way for these pedestrians as a favour.

Whole magazine issue

The military magazine Mission Critical has devoted an entire issue to civilian robocars which includes an article on insurance by Guy Fraker (formerly of State Farm) and a few other items of interest.

More news to come. I have also updated my Robocar Teams page with more details on teams around the world building robocars.

You’ve probably noticed that with many of our portable devices, especially phones and tablets, a large fraction of the size and weight are the battery. Battery technology keeps improving, and costs go down, and there are dreams of fancy new chemistries and even ultracapacitors, but this has become a dominant issue.

Every device seems to have a different battery. Industrial designers work very hard on the design of their devices, and they don’t want to be constrained by having to standardize the battery space. In many devices, they are even giving up the replaceable battery in the interests of good design. The existing standard battery sizes, such as the AA, AAA and even the AAAA and other less common sizes are just not suitable for a lot of our devices, and while cylindrical form factors make the most sense for many cell designs they don’t fit well in the design of small devices.

So what’s holding back a new generation of standardization in batteries? Is it the factors named above, the fact that tech is changing rapidly, or something else?

I would propose a small, thin modular battery that I would call the EStick, for energy stick. The smaller EStick sizes would be thin enough for cell phones. The goal would be to have more than one b-stick, or at least more than one battery in a typical device. Because of the packaging and connections, that would mean a modest reduction in battery capacity — normally a horrible idea — but some of the advantages might make it worth it.

Quick swap

There are several reasons to have multiple sticks or batteries in a device. In particular, you want the ability to quickly and easily swap at least one stick while the device is still operating, though it might switch to a lower power mode during the swap. The stick slot would have a spring loaded snap, as is common in many devices like cameras, though there may be desire for a door in addition.

Swapping presents the issue that not all the cells are at the same charge level and voltage. This is generally a bad thing, but modern voltage control electronics has reached the level where this should be possible with smaller and smaller electronics. It is possible with some devices to simply use one stick at a time, as long as that provides enough current. This uses up the battery lifetime faster, and means less capacity, but is simpler.

The quick hot swap offers the potential for indefinite battery life. In particular, it means that very small devices, such as wearable computers (watches, glasses and the like) could run a long time. They might run only 3-4 hours on a single stick, but a user could keep a supply of sticks in a pocket or bag to get arbitrary lifetime. Tiny devices that nobody would ever use because “that would only last 2 hours” could become practical.

While 2 or more sticks would be best for swap, a single stick and an internal battery or capacitor, combined with a sleep mode that can survive for 20-30 seconds without a battery could be OK. read more »

I have prepared a large new Robocar article. This one covers just what will happen when the first robocars are involved in accidents out on public streets, possibly injuring people. While everybody is working to minimize this, perfection is neither possible nor the right goal, so it will eventually happen. As such, when I see public discussion of robocars and press articles, people are always very curious about accidents, liability, insurance and to what extent these issues are blockers on the technology.

This article comes in part from having attended the “We Robot” conference in April at Stanford University. While it was generally about robots and the law, robocars were probably the most popular topic. Several of the papers in the proceedings are well worth it for those interested in the law of robotics. (The real law, not the silly Asimov laws.)

In a curious coincidence, last week saw an unusual robocar accident in Brazil that caused minor injuries — on live TV no less. On a Brazilian TV show, professor Alberto Ferreira do Souza from the Federal University of Espirito Santo has just shown TV Presenter Ana Maria Braga their robocar, which features the smaller 32-line Velodyne LIDAR on the roof and various other sensors. After the successful demo, he reaches into the car to turn off the system and restore the car to manual. Unfortunately, the car has stopped on an incline, and in doing so from outside the car, this releases the hold on the brakes that their drive-by-wire system had and the car starts rolling down the hill, and the open door whacks Braga hard, though fortunately with only minor injuries. Here is a video and Here’s the story in Portuguese with a different video clip. I have no idea why a puppet parrot is commenting on the accident.

As you can surmise, the self-driving software was not directly at fault here, but rather bad human judgement in turning it off. Curiously, this is not the first time we’ve seen serious problems with humans not correctly handling turning systems on and off. I routinely show a video of my friend Anthonly Levandowski, who built a motorcycle for the DARPA grand challenge and forgot to turn on an important system just before the race, causing his bike to tip over right out of the starting gate. Volvo also had the “press demo from hell” when their crash-prevention system did not operate. It was reported that a battery had discharged by mistake, and that in recharging it they had disabled the collision system.

There have been several small robocar accidents. Just about every team in the DARPA Grand Challenges had a car go awry during early development and testing, and a few even had accidents during the challenge, with one small car to car fender bender and a fairly hard hit on concrete barriers. Google has also reported their car has been rear-ended while stopped at a light during testing — a situation where blame is always placed on the rear car.

I follow the Hugo awards closely, and 20 years ago published the 1993 Hugo and Nebula Anthology which was probably the largest anthology of currently released fiction ever published at the time.

The Hugo awards are voted by around 1,000 fans who attend the World SF Convention, so they have their biases, but over time almost all the greats have been recognized. In addition, until the year 2000, in the best novel Hugo, considered the most important, the winner was always science fiction, not fantasy even though both and more were eligible. That shifted, and from 2001 to 2012, there have been 6 Fantasy winners, one Alternate History, and 5+1 SF. (2010 featured a tie between bad-science SF in the Windup Girl and genre-bending political science fiction in The City & The City.)

That’s not the only change to concern me. A few times my own pick for the best has not even been nominated. While that obviously shows a shift between my taste and the rest of the fans, I think I can point to reasons why it’s not just that.

The 2013 nominees I find not particularly inspiring. And to me, that’s not a good sign. I believe that the Hugo award winning novel should say to history, “This is an example of the best that our era could produce.” If it’s not such an example, I think “No Award” should win. (No Award is a candidate on each ballot, but it never comes remotely close to winning, and hasn’t ever for novels. In the 70s, it deservedly won a few times for movies. SF movies in the mid and early 70s were largely dreck.)

What is great SF? I’ve written on it before, but here’s an improvement of my definition. Great SF should change how you see the future/science/technology. Indeed, perhaps all great literature should change how you view the thing that is the subject matter of the literature, be it love, suffering, politics or anything else. That’s one reason why I have the preference for SF over Fantasy in this award. Fantasy has a much harder time attaining that goal.

I should note that I consider these books below as worth reading. My criticism is around whether they meet the standard for greatness that a Hugo candidate should have.

2312 by Kim Stanley Robinson

This is the best of the bunch, and it does an interesting exploration into the relationship of human and AI, and as in all of Stan’s fiction, the environment. His rolling city on Mercury is a wonder. The setup is great but the pace is as glacial as the slowly rolling city and the result is good, but not at the level of greatness I require here. read more »

Last year, I met Oliver Kuttner, who led the team to win the Progressive X-Prize to build the most efficient and practical car over 100mpg. Oliver’s Edison2 team won with the VLC (Very Light Car) and surprised everybody by doing it with a liquid fuel engine. There was a huge expectation that an electric car would win the prize, and in fact the rules had been laid out to almost assure it, granting electric cars an advantage over gasoline that I thought was not appropriate.

The Edison2 team made their focus on weight, though they far from ignored drag. Everybody made an aerodynamic car, but what they realized was that making the car light was key. And batteries are heavy, heavier than efficient liquid fuel engines. Hybrid systems, with both batteries and two motors are even heavier than what they built. They also developed a new type of suspension which was much lighter and allowed a simpler car.

Since the X prize, they have built electric cars as well — their techniques still work there, even if that’s not where they found the greatest X-prize results — and recently showed of their latest 1,400lb model which seats 4. (Though I can’t say I think it’s comfortable with 4.) Equally impressive, Oliver reports they have done succesful forward offset collision tests, and done well at them, contradicting a popular impression that small, light cars must be death traps on the road.

This bodes well for robocars. As I wrote 2 weeks ago, I think the small, light car is the future of transportation if we want it to be efficient, and the robocar can, by delivering such vehicles for people making shorter solo or 2 person trips — ie. the vast majority of all trips — make this happen.

Earlier, I brought Oliver in to give a talk at Google in the Greeen@Google series. Here is a video where I host him describing the car and their thinking around it. His thinking on cars is fresh and while it’s very challenging to start a new car company, here’s somebody who might just do it.

We’ve often said that in the most distant future, when car accidents are very rare, we will be able to make our cars lighter because over 30% of the weight of a modern vehicle goes into safety features. I think we can get those light vehicles even sooner.

Bitcoin is having its first “15 minutes” with the recent bubble and crash, but Bitcoin is pretty hard to understand, so I’ve produced this analogy to give people a deeper understanding of what’s going on.

It begins with a group of folks who take a different view on several attributes of conventional “fiat” money. It’s not backed by any physical commodity, just faith in the government and central bank which issues it. In fact, it’s really backed by the fact that other people believe it’s valuable, and you can trade reliably with them using it. You can’t go to the US treasury with your dollars and get very much directly, though you must pay your US tax bill with them. If a “fiat” currency faces trouble, you are depending on the strength of the backing government to do “stuff” to prevent that collapse. Central banks in turn get a lot of control over the currency, and in particular they can print more of it any time they think the market will stomach such printing — and sometimes even when it can’t — and they can regulate commerce and invade privacy on large transactions. Their ability to set interest rates and print more money is both a bug (that has sometimes caused horrible inflation) and a feature, as that inflation can be brought under control and deflation can be prevented.

The creators of Bitcoin wanted to build a system without many of these flaws of fiat money, without central control, without anybody who could control the currency or print it as they wish. They wanted an anonymous, privacy protecting currency. In addition, they knew an open digital currency would be very efficient, with transactions costing effectively nothing — which is a pretty big deal when you see Visa and Mastercard able to sustain taking 2% of transactions, and banks taking a smaller but still real cut.

With those goals in mind, they considered the fact that even the fiat currencies largely have value because everybody agrees they have value, and the value of the government backing is at the very least, debatable. They suggested that one might make a currency whose only value came from that group consensus and its useful technical features. That’s still a very debatable topic, but for now there are enough people willing to support it that the experiment is underway. Most are aware there is considerable risk.

Update: I’ve grown less fond of this analogy and am working up a superior one, closer to the reality but still easy to understand.

Wordcoin

Bitcoins — the digital money that has value only because enough people agree it does — are themselves just very large special numbers. To explain this I am going to lay out an imperfect analogy using words and describe “wordcoin” as it might exist in the pre-computer era. The goal is to help the less technical understand some of the mechanisms of a digital crypto-based currency, and thus be better able to join the debate about them. read more »

Today and Tomorrow I am at the We Robot conference at Stanford, where people are presenting papers puzzling over how robots and the law will interact. Not enough technology folks at this iteration of the conference — we have a natural aversion to this sometimes — but because we’re building big moving things that could run into people, the law has to be understood.

On Wednesday is the Robot Block Party, also at Stanford, and always fun, with stuff for kids.

Thursday has the xconomy robot conference which looks good though I probably won’t be there.

After the Phoenix APM event on the 21st I will be at Asilomar attending two conferences simultaneously. One is MLove, where I will join a session on connected cars. In a strange coincidence, MLove is located at the same conference center as another invite-only conference I attend annually for old-time (and new-time) microprocessor hackers. The odd thing was that normally when I get an invite that conflicts with a conference I am at, I have to say no — but if they are nice enough to do it at the same conference center on the same days, things can change. Both conferences are lots of fun, and it’s actually annoying to have them overlap since I would like to go to most of both of them.

A few Singularity U events are coming up, but most are sold out are invite-only in the coming month.

Last night I gave a short talk at the 3rd “Personal Clouds” meeting in San Francisco, The term “personal clouds” is a bit vague at present, but in part it describes what I had proposed in 2008 as the “data deposit box” — a means to acheive the various benefits of corporate-hosted cloud applications in computing space owned and controlled by the user. Other people are interpreting the phrase “personal clouds” to mean mechanisms for the user to host, control or monetize their own data, to control their relationships with vendors and others who will use that data, or in the simplest form, some people are using it to refer to personal resources hosted in the cloud, such as cloud disk drive services like Dropbox.

I continue to focus on the vision of providing the advantages of cloud applications closer to the user, bringing the code to the data (as was the case in the PC era) rather than bringing the data to the code (as is now the norm in cloud applications.)

Consider the many advantages of cloud applications for the developer:

You write and maintain your code on machines you build, configure and maintain.

That means none of the immense support headaches of trying to write software to run on mulitple OSs, with many versions and thousands of variations. (Instead you do have to deal with all the browsers but that’s easier.)

It also means you control the uptime and speed

Users are never running old versions of your code and facing upgrade problems

You can debug, monitor, log and fix all problems with access to the real data

You can sell the product as a service, either getting continuing revenue or advertising revenue

You can remove features, shut down products

You can control how people use the product and even what steps they may take to modify it or add plug-ins or 3rd party mods

You can combine data from many users to make compelling applications, particuarly in the social space

You can track many aspects of single and multiple user behaviour to customize services and optimize advertising, learning as you go

Some of those are disadvantages for the user of course, who has given up control. And there is one big disadvantage for the provider, namely they have to pay for all the computing resources, and that doesn’t scale — 10x users can mean paying 10x as much for computing, especially if the cloud apps run on top of a lower level cloud cluster which is sold by the minute.

Tomorrow (April 4) I will give a very short talk at the meeting of the personal clouds interest group. As far as I know, I was among the first to propose the concept of the personal cloud in my essages on the Data Deposit Box back in 2007, and while my essays are not the reason for it, the idea is gaining some traction now as more and more people think about the consequences of moving everything into the corporate clouds.

My lighting talk will cover what I see as the challenges to get the public to accept a system where the computing resources are responsible to them rather than to various web sites.

On April 22, I will be at the 14th International Conference on Automated People Movers and Automated Transit speaking in the opening plenary. The APM industry is a large, multi-billion dollar one, and it’s in for a shakeup thanks to robocars, which will allow automated people moving on plain concrete, with no need for dedicated right-of-way or guideways. APMs have traditionally been very high-end projects, costing hundreds of millions of dollars per mile.

The best place to find me otherwise is at Singularity University Events. While schedules are being worked on, with luck you see me this year in Denmark, Hungary and a few other places overseas, in addition to here in Silicon Valley of course.