Brad Templeton is an EFF director, Singularity U faculty, software architect and internet entrepreneur, robotic car strategist, futurist lecturer, hobby photographer and Burning Man artist.
This is an "ideas" blog rather than a "cool thing I saw today" blog. Many of the items are not topical. If you like what you read, I recommend you also browse back in the archives, starting with the best of blog section. It also has various "topic" and "tag" sections (see menu on right) and some are sub blogs like Robocars, photography and Going Green. Try my home page for more info and contact data.
Had my second RAID failure last week. In the end, things were OK but the reality is that many RAID implementations are much more fragile than they should be. Write failures on a drive caused the system to hang. Hard reset caused the RAID to be marked dirty, which mean it would not boot until falsely marked clean (and a few other hoops,) leaving it with some minor filesystem damage that was reparable. Still, I believe that a proper RAID-like system should have as its maxim that the user is never worse off because they built a RAID than if they had not done so. This is not true today, both due to fragility of systems, and the issues I have outlined before with deliberately replacing a disk in a RAID, where it does not make use of the still-good but aging old disk when rebuilding the replacement.
A few years ago I outlined a plan for disks to come as two-packs for easy, automatic RAID because disks are so cheap that everybody should be doing it. The two-pack would have two SATA ports on it, but if you only plugged in one, it would look like a single disk, and be a RAID-1 inside. If you gave it a special command, it could look like other things, including a RAID-0, or two drives, or a JBOD concatenation. If you plugged into the second port it would look like two disks, with the RAID done elsewhere.
I still want this, but RAID is not enough. It doesn’t save you from file deletion, or destruction of the entire system. The obvious future trend is network backup, which is both backup and offsite. The continuing issue with network backup is that some people (most notably photographers and videographers) generate huge amounts of data. I can come back from a weekend with 16gb of new photos, and that’s a long slog over DSL with limited upstream for network backup. To work well, network backup also needs to understand all databases, as a common database file might be gigabytes and change every time there is a minor update to a database record. (Some block-level incrementalism can work here if the database is not directly understood.)
Network backup is also something that should be automatic. There are already peer-to-peer network backups, that make use of the disks of friends or strangers (encrypted of course) but it would be nice if this could “just happen” when any freshly installed computer unless you turn it off. The user must keep the key stored somewhere safe, which is not zero-UI, though if all they want is to handle file-deletion and rollback they can get away without it.
Another option that might be interesting would be the outdoor NAS. Many people now like to use NAS boxes over gigabit networks. This is not as fast as SATA with a flash drive, or RAID, or even modern spinning disk, but it’s fast enough for many applications.
An interesting approach would be a NAS designed to be placed outdoors, away from the house, such as in the back corner of a yard, so that it would survive a fire or earthquake. The box would be waterproof and modestly fireproof, but ideally it is located somewhere a fire is unlikely to reach. It could either be powered by power-over-ethernet or could have its own power and even use WIFI (in which case it is only suitable for backup, not as a live NAS.)
This semi-offsite backup would be fast and cheap (network storage tends to be much more expensive than local drives.) It would be encrypted, of course, so that nobody can steal your data. Encryption would be done in the clients, not the NAS, so even somebody who taps the outside wire would get nothing.
This semi-offsite backup could be used in combination with network backup. Large files and new files would be immediately sent to the backyard backup. The most important files could then go to network backup, or all of them, just much more slowly.
A backyard backup could also be shared by neighbours, especially on wifi, which might make it quite cost effective. Due to encryption, nobody could access their neighbour’s data.
If neighbours are going to cooperate, this can also be built by just sharing servers or NAS boxes in 2 or more houses. This provides decent protection and avoids having to be outside, but there is the risk that some fires burn down multiple houses depending on the configuration.
A backyard backup would be so fast that many would reverse what I said above, and have no need for RAID. Files would be mirrored to the backyard backup within seconds or minutes. RAID would only be needed for those who need to have systems that won’t even burp in a disk failure (which is a rare need in the home) or which must not lose even a few minutes of data.
This week I attended the Transportation Research Board Workshop on Automated Road Vehicles which has an academic focus but still has lots of industry-related topics. TRB’s main goal is to figure out what various academics should be researching or getting grants for, but this has become the “other” conference on robocars. Here are my notes from it.
Bryant Walker Smith told of an interesting court case in Ontario, where a truck driver sued over the speed limiter put in his truck and the court ruled that the enforced speed limiter was a violation of fundamental rights of choice. One wonders if a similar ruling would occur in the USA. I have an article pending on what the speed limit should be for robocars with some interesting math.
Cliff Nass expressed skepticism over the ability to have easy handover from self-driving to human driving. This transfer is a “valence transfer” and if the person is watching a movie in a tense scene that makes her sad or angry, she will begin driving with that emotional state. More than one legal scholar felt that quickly passing control to a human in an urgent situation would not absolve the system of any liability under the law, and it could be a dangerous thing. Nass is still optimistic — he notes that in spite of often expressed fears, no whole field has been destroyed because it caused a single fatality.
There were reports on efforts in Europe and Japan. In both cases, government involvement is quite high, with large budgets. On the other hand, this seems to have led in most cases to more impractical research that suggests vehicles are 1-2 decades away.
Volkswagen described a couple of interesting projects. One was the eT! — a small van that would follow a postman around as he did his rounds. The van had the mail, and the postman did not drive it but rather had it follow him so he could go and get new stacks of mail to deliver. I want one of those in the airport to have my luggage follow me around.
VW has plans for a “traffic jam pilot” which is more than the traffic jam assist products we’ve seen. This product would truly self-drive at low speeds in highway traffic jams, allowing the user to not pay attention to the road, and thus get work done. In this case, the car would give 10 seconds warning that the driver must take control again. VW eventually wants to have a full vehicle which gives you a 10 minute warning but that’s some distance away. read more »
The Vislab team from Parma, Italy, which you may remember did the intermittently autonomous drive from Italy to Shanghai a couple of years ago is back with a new vehicle, dubbed BRAiVE which tomorrow begins testing on real urban streets.
The difference is this car is mostly based on vision systems, the specialty of Vislab. You can see a photo gallery of the car but it deliberately does not look particularly different. You can see a few low profile sensors. They claim the car uses “mostly cameras” so it’s not clear if there is still a LIDAR on the vehicle or it’s just cameras and radar. The cars to Shanghai used an array of both cameras and single plane LIDARs. It is said that the sensors are “low cost” though an exact list is not given.
This will be an interesting experiment. Previous vision based systems have not proven adequate for urban driving. They have been able to do it but not reliably enough to trust people’s lives to it. Cameras remain attractive for their low cost and other reasons outlined in my recent article on LIDAR vs. cameras.
The sensors on this vehicle are not that obvious. There remain two schools of thought on this. One believes that a significant change in the car form factor with obvious sensors will be a turn-off for buyers. Others think buyers, especially early adopters, will actually consider unusual looking sensors a huge plus, wanting the car to stand out. I’m in the latter camp, and think the Prius is evidence of this. Its unusual shape outsells all other hybrids combined, even the more ordinary looking Camry hybrid, where the Camry is the best selling car there is. However, there will be markets for both designs.
It will be interesting to see the results of this research, and what rates of accuracy they gain for their vision system. Lots of competing approaches is good for everybody.
BART, one of the SF Bay Area’s transit systems, is on strike today, and people are scrambling for alternatives. The various new car-based transportation companies like Uber, Lyft and Sidecar are all trying to bump their service to help with the demand, but in the future I think there will be a much bigger opportunity for these companies.
The average car has 1.47 people in it, and the number is less on urban commutes. Since most cars hold 4-5 people, the packed roads have a huge amount of excess capacity in empty seats. While Lyft and Sidecar call themselves ridesharing companies, they are really clever hacks at providing taxi service. Lyft’s original product, Zimride, is more ridesharing but aimed at the long-distance market. Many companies have tried to coordinate true ridesharing for commuters and people in a city, but with only limited success.
A transit strike offers an interesting opportunity. Without commenting on the merits of the sides in the strike, the reality is that we can do much better with the empty seat resource than we do, and a transit strike can prompt that.
Of course, the strike is already naturally increasing carpooling, and casual carpooling (also known as slugging) also gets a large boost. In the Bay Area, things are complicated because BART is the main alternative to the Bay Bridge, and that bridge is going to get very heavily loaded. Ferry service is increasing but it’s still a 25 minute trip every 45 minutes from the various Ferry docks. The bridge and highways are increasing incentives for HOV-3+ carpools.
Casual carpooling tends to only get you to a rough area near your destination. In this case that may be OK, as other transit is still running, only BART is out. At the semi-official casual carpool stations, there are signed waiting places that get long lines for all the general destinations. You take what you can get, and it’s also efficient in moving cars in and out.
Computer assisted carpooling could schedule people together who are both starting and ending their trip fairly close together, for maximum convenience and efficiency. If the trip starts at people’s houses, or some common point, you don’t have the casual carpool concentration issue. If you start from stops of the transit lines which are running, you still have a problem.
Because of the load on the bridge, the ferry seems attractive, though there you have a chokepoint, particularly in picking up people from the boat. To do that, you would need a parking lot with numbered spaces. People allocated to a car because of a common destination would be given a spot number, and walk to the car there as they get off the ferry. A simple curb (which suffices for casual carpools) would not be enough.
Companies like Lyft and Sidecar make use of people who want to become part-time taxi drivers. While they pretend (for legal reasons) that they are people who were “already going that way” who take along others for a donation, that fiction could become reality in a transit strike. Most carpoolers would probably take along extras for no money, or gas money, especially when they gain a special carpool lane or toll saving as they do on the Bay Bridge. There would also be value in Jitney service, where a “professional” driver (who is just driving for the money, officially or not) takes 3-4 passengers along the common route, and they all pay a reasonable share.
Within a city, that share could be competitive, even with the subsidized cost of transit, which tends to be close to $2/ride. Taxi fares are $2.50/mile plus a flag drop, which means a trip of 3-4 miles could be competitive if split among 4 people, and not that bad (considering the higher level of service) even on trips that are twice as long. (The Bay Bridge is 10 miles long so taxi fares will have a hard time competing with even the higher BART fare.)
Jitney service (shared door to door or on-demand fixed route) is quite popular outside the USA, and indeed there are many cities with active private transit systems and jitney systems. But most Americans are not interest in the inconvenience of going slightly out of their way to deal with the needs of other passengers, and so attempts at such rideshare here don’t rule the world. It’s probably too late for this strike, but the next transit strike might end up demonstrating there are other systems aside from transit that are efficient and cost-effective.
The interface would not be too different from existing systems, except people would specify how much inconvenience they would tolerate from having others in the vehicle and going out of their way, in exchange for savings.
When it comes to robocars, this might happen as well, and it could even happen with vans to provide a very effective shared system that still offers door-to-door. Robocars also offer the potential for mixed-mode vanpool trips. In such a trip, a single person robocar takes you to a parking lot, where 12 other people all arrive within the same minute and you call get into a van. The van does the bulk of the trip, and stops near your set of destinations in a parking lot where a set of small single-person robocars sit waiting to take people the last mile. This highly efficient mode should be able to beat any existing transit because of its flexibility and door-to-door service. The vans offer the ability to be luxury vans, with business class seats with privacy screens, so that upscale transit is also possible.
Yahoo announced that in a few days they will shut down the altavista web site. This has prompted a few posts on the history of internet search, to which I will add an anecdote.
The first internet search engine predated the “web” and was called Archie search engine. Archie (an archive search) was basic by today’s standards. The main protocol for getting files on the internet in those days was FTP. Many sites ran an open FTP server, which you could connect to and download files from. If you had files or software to share with people, you put it up on an FTP server, in particular one that allowed anonymous login to get public files. The Archie team (from Montreal) built a tool to go to all the open servers, read their indexes and generate a database. You could then search, and get a pointer to all the places you could get a file. It was hugely popular for the day.
(You will probably note that this is almost exactly the way Napster worked, the only difference being that Napster was a bit more sophisticated and people used it to share files that were copyrighted. FTP servers had copyrighted material, but mostly they had open source software and documents.)
Around the same time, a lot of folks were building full-text search engines for use on large collections of documents. You could find these on private databases around the world, and the WAIS protocol was developed by Brewster Kahle to make a standardized interface to text search and his own text search tools.
Not long after the web started to grow, Fuzzy Mauldin at CMU made Lycos which was a full-text search engine applied to documents gathered from the web. The ability to search the web generated much attention, and a few other competing spiders and search engines appeared. Everybody had a favourite. (To add to my long list of missed opportunities, in April of 95 I wrote a few notes to Fuzzy looking to get his spider index so we could sort web pages based on how many incoming links they had. Nothing ever came of that but as you may know that concept later had some value. :-) And I also turned down a $4M offer from Lycos to buy ClariNet (which would have turned into $40M when their stock shot up in the bubble. Sigh.)
In 1995, for many people that favourite changed to Alta Vista, a new search engine from Digital Equipment Corp. DEC was a huge name at the time, the biggest name in minicomputers, and it was just losing the Unix crown to Sun. The team at DEC put a lot of computing power into Alta Vista, and so it had two useful attributes. First, they spidered a lot more pages, and thus were more likely to find stuff. They were also fast compared to most of the other engines. In a precursor to other rapid turnarounds in the internet business, you could switch your favourite search engine in a heartbeat and many did. It was big and fast due to DEC putting a lot of fancy computer hardware on it, and DEC eventually justified the money they were spending on it (there was no revenue for search in those days) by saying it showed off just how powerful DEC’s computers with big address spaces were. Indeed the limits of Alta Vista were the limits of the architecture, using the 64-bit Alpha to address 130gb of RAM and 500gb of disk — huge for the day.
On Alta Vista’s home page, they gave you a sample query to type in the search box, to show you how to use it. That query was:
kayak sailing “san juan islands”
Indeed, if you typed that, you got a nice array of pages which talked about kayaking up in the San Juan islands, tour operators, etc. — just what you wanted to get from a query.
My devious mind wondered, “what if I put up a page on my own web site with this as the title?” I created the Kayak Sailing “San Juan Islands” home page on the rec.humor.funny site, which was already a very popular site in those days. (Indeed it’s around 1995 that RHF fell behind Yahoo as the most widely read thing on the internet, but that refers to the USENET group, not the page.)
You will note as you look at the page that it contains the words in the title and headers, and repeated many times in invisible comments. In those days the search engines were ranking higher simply based on where words were, and if they were repeated many times. So I gave it a whirl. This was an early attempt at what is now called “black hat search engine optimization” though I was doing it for fun, rather than nefarious gain.
The results didn’t change though. Alta Vista relied on huge computer power, but it only rebuilt the index by hand. It would be a month or more before Alta Vista recalculated its index. One day I went to type in the query and bingo — there was my page on the first page of search results. Along with a dozen other people who had tried the same thing, and a few pages that were articles writing about Alta Vista and giving the example query, or which were copying its search page which of course had that string.
More to the point, not a single item on the results page was about actual Kayaking! The sample query was ruined, though the results were quite amusing. Not long after, Alta Vista changed the example to Pizza “deep dish” Chicago and of course I added it to my page as well. So not much longer after that AV switched to showing different examples from a rotating and changing collection so people could not play this game any more.
While Alta Vista ruled Search, in spite of efforts from Infoseek, Inktomi/Hotbot and others, we all know that a few years later, Google was born at Stanford, and it proved again how quickly people could switch to a new favourite search engine, and lives under that fear (but with great success) to this day. And Google’s dominance turned SEO into a giant industry.
I always feel strange when I see blog and social network posts about the death of a pet or even a relative. I know the author but didn’t know anything about the pet other than that the author cared.
So as I report the end for our kitty, Bijou, I will make it interesting by relaying a fun surveillance related story of how she arrived at our house. She had been rescued as a stray by a distant relative. When that relative died there was nobody else to take the cats, so we took two of them, even though the two would have nothing to do with each-other. Upon arrival at our house, both cats discovered that the garage was a good place to hide, but the hiding was quite extreme, and after about 4 days we still could not figure where Bijou was hiding. Somebody was coming to eat the food, but we could not tell from where.
I had a small wireless camera with an RF transmitter on it. So I set it up near the food bowl, and we went into the TV room to watch. As expected, a few minutes later, the cat emerged — from inside the bottom of the washing machine through a rather small hole. After emerging she headed directly and deliberately to the camera and as she filled the screen, suddenly the view turned to distortion and static. It was the classic scene of any spy movie, as shot from the view of the surveillance camera. The intruder comes in and quickly disables the camera.
What really happened is that the transmitter is not very powerful and you must aim the antenna. When a cat sees something new in her environment, her first instinct is to come up to it and smell it, then rub her cheek on it to scent-mark it. And so this is what she did, bumping the antenna to lose the signal, though it certainly looked like she was the ideal cat for somebody at the EFF.
It’s also a good thing we didn’t run the washing machine. But I really wish I had been recording the video. Worthy of Kittywood studios.
She had happy years in her new home (as well as some visits to her old one before it was sold) and many a sunbeam was lazily exploited and evil bright red dot creature never captured, but it could not be forever.
The AUVSI summit on “driverless” cars last week contained 2 days of nothing but robocars, and I reported on issues regarding Google and policy in part 1.
As noted, NHTSA released their proposal for how they want to regulate such vehicles. In it, they defined levels 0 through 4. Level 2 is what I (and GM) have been calling “super cruise” — a car which can do limited self driving but requires constant human supervision. Level 3 is a car which can drive without constant attention, but might need to call upon a human driver (non-urgently) to handle certain streets and situations. Level 4 is the fully automatic robocar.
Level 2 issues
Level 2 is coming this year in traffic jams in the Mercedes S and the BMW 5, and soon after from Audi and Volvo. GM had announced super cruise for the 2015 Cadillac line but has pulled back and delayed that to later in the decade. Nonetheless the presentation from GM’s Jeremy Salinger brought home many of the issues with this level.
GM has done a number of user studies in their super cruise cars on the test track. And they learned that the test subjects very quickly did all sorts of dangerous things, definitely not paying attention to the road. They were not told what they couldn’t do, but subjects immediately began texting, fiddling around in the back and even reading (!) while the experimenters looked on with a bit of fear. No big surprise, as people even text today without automatic steering, but the experimental results were still striking.
Because of that GM is planning what they call “countermeasures” to make sure this doesn’t happen. They did not want to say what countermeasures they liked, but in the past, we have seen proposals such as:
You must touch the wheel every few seconds or it disengages
A camera looks at your eyes and head and alerts or disengages if you look away from the road for too long
A task for your hands like touching a button every so often
The problem is these countermeasures can also get annoying, reducing the value of the system. It may be the lack of ability to design a good countermeasure is what has delayed GM’s release of the product. There is a policy argument coming up about whether level 2 might be more dangerous than the harder levels 3 and above, because there is more to go wrong with the human driver and the switches between human and machine driving. (Level 4 has no such switches, level 3 has switches with lots of warning.)
On the plus side, studies on existing accidents show that accident-avoidance systems, even just forward collision avoidance, have an easy potential for huge benefits. Already we’re seeing a 15% reduction in accidents in some studies just from FCA, but studies show that in 33% of accidents, the brakes were never applied at all, and only in just 1% of accidents were the brakes applied with full force! As such, systems which press the brakes and press them hard when they detect the imminent accident may not avoid the accident entirely, but they will highly reduce the severity of a lot of accidents. read more »
I was sadly informed this morning by Ann Lowson that transportation pioneer Martin Lowson has fallen to a stroke this weekend.
Martin had an amazing career but it was more amazing that he was still actively engaged at age 75. We shared a panel last month in Phoenix at the people-mover conference and continued our vigourous debate on the merits of cars like his on closed guideways compared to robocars.
His career included leading a large team on the Apollo project, and building the world’s fastest helicopter, as well as faculty positions at Bristol, and you can read some about it here. For me, his big contribution was to found the ULTra PRT company, the first to commercially deploy a PRT. It runs today at Heathrow, moving people between the terminal and the business parking lot.
PRT was conceived 50 years ago, and many, including Martin and myself, were fascinated by the idea. More recently, as readers know, I decided the PRT vision of personal transportation could be realized on city streets by robocars. It’s easier to do it today on dedicated guideway, but the infrastructure costs tell me the future lies off the guideway.
That doesn’t diminish the accomplishment of being the first to make it work on the guideway. ULTra uses small cars on rubber tires, not a train on rails. They are guided by a laser rangefinder and are fully automated, with no steering wheel.
Last year I invited Martin in to give a talk to Google’s car team, and he got a ride in the car, which he quite enjoyed, even though it didn’t convince him that they were the future. But unlike other skeptics, I gave him the deepest respect for his skill and experience. People who can found companies and lead engineering and public acceptance breakthroughs while senior citizens are a very rare thing, and the world will miss him.
This week I attended AUVSI’s “Driverless Car Summit” in Detroit. This year’s event, the third, featured a bigger crowd and a decent program, and will generate more than one post.
I would hardly call it a theme, but two speakers expressed fairly negative comments about Google’s efforts, raising some interesting subjects. (As an important disclaimer, the Google car team is a consulting client of mine, but I am not their spokesman and the views here do not represent Google’s views.)
The keynote address came from Bryan Reimer of MIT, and generated the most press coverage and debate, though the recent NHTSA guidelines also created a stir.
Reimer’s main concern: Google is testing on public streets instead of a test track. As such it is taking the risk of a fatal accident, from which the blowback could be so large it stifles the field for many years. Car companies historically have done extensive test track work before going out on real streets. I viewed Reimer’s call as one for near perfection before there is public deployment.
There is a U-shaped curve of risk here. Indeed, a vendor who takes too many risks may cause an accident that generates enough backlash to slow down the field, and thus delay not just their own efforts, but an important life-saving technology. On the other hand, a quest for perfection attempts what seems today to be impossible, and as such also delays deployment for many years, while carnage continues on the roads.
As such there is a “Goldilocks” point in the middle, with the right amount of risk to maximize the widescale deployment of robocars that drive more safely than people. And there can be legitimate argument about where that is.
Reimer also expressed concern that as automation increases, human skill decreases, and so you actually start needing more explicit training, not less. He is as such concerned with the efforts to make what NHTSA calls “level 2” systems (hands off, but eyes on the road) as well as “level 3” systems (eyes off the road but you may be called upon to drive in certain situations.) He fears that it could be dangerous to hand driving off to people who now don’t do it very often, and that stories from aviation bear this out. This is a valid point, and in a later post I will discuss the risks of the level-2 “super cruise” systems.
Maarten Sierhuis, who is running Nissan’s new research lab (where I will be giving a talk on the future of robocars this Thursday, by the way) issued immediate disagreement on the question of test tracks. His background at NASA has taught him that you “fly where you train and train where you fly” — there is no substitute for real world testing if you want to build a safe product. One must suspect Google agrees — it’s not as if they couldn’t afford a test track. The various automakers are also all doing public road testing, though not as much as Google. Jan Becker of Bosch reported their vehicle had only done “thousands” of public miles. (Google reported a 500,000 mile count earlier this year.)
Heinz Mattern, research and development manager for Valeo (which is a leading maker of self-parking systems) went even further, starting off his talk by declaring that “Google is the enemy.” When asked about this, he did not want to go much further but asked, “why aren’t they here? (at the conference)” There was one Google team employee at the conference, but not speaking, and I’m not am employee or rep. It was pointed out that Chris Urmson, chief engineer of the Google team, had spoken at the prior conferences. read more »
I’m off for AUVSI’s “Driverless Car Summit” in Detroit. I attended and wrote about last year’s summit, which, in spite of being put on by a group that comes out of the military unmanned vehicle space, was very much about the civilian technology. (As I’ve said before, I have a dislike for the term “driverless car” and in fact at the summit last year, the audience expressed the same dislike but could not figure out what the best replacement term was.)
I’ll be reporting back on events at the summit, and making a quick visit to my family in Toronto as well. I will also attend the Transportation Research Board’s conference on automated vehicles at Stanford in July.
Then I’m back for the opening of our Singularity University Graduate Studies Program for 2013 at NASA Ames Research Park this coming weekend. My students will get some fun lectures on robocars, as well as many other technologies. Early bird tickets for the opening ceremony are still available.
On June 20, I will give a talk at a meeting of the new Silicon Valley Autonomous Vehicle Enthusiasts group. This group has had one talk. The talks are being hosted at Nissan’s new research lab in Silicon Valley, where they are researching robocars. I just gave a 10 minute version of my talk at Fujitsu Labs’ annual summit last week, this will be the much longer version!
SU consumes much of my summer. In the fall, you’ll see me giving talks on Robocars and other issues in Denmark, London, Milan as well as at our new Singularity University Summit in Budapest in November, as well as others around the USA.
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.
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.
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.
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.
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.