Transportation

Short Big Think video piece on Privacy vs. Security

There’s another video presentation by me that I did while visiting Big Think in NYC.

This one is on The NSA, Snowden and the “tradeoff” of Privacy and Security.

Earlier, I did a 10 minute piece on Robocars for Big Think that won’t be news to regular readers here but was reasonably popular.

The Neighbourhood Elevator and a new vision of urban density

I’ve been musing more on the future of the city under the robocar, and many visions suggest we’ll have more sprawl. Earlier I have written visions of Robocar Oriented Development and outlined all the factors urban planners should look at.

In the essay linked below, I introduce the concept of a medium density urban neighbourhood that acts like a higher density space thanks to robocars functioning like the elevators in the high-rises of high density development.

Read The Neighbourhood Elevator and 21st century urban density at robocars.com.

Robocar News: UK Legalization, MobilEye IPO, Baidu, new Lidar, Nissan pullback, FBI Weapons, Navia, CityMobil2

A whole raft of recent robocar news.

UK to modify laws for full testing, large grants for R&D

The UK announced that robocar testing will be legalized in January, similar to actions by many US states, but the first major country to do so. Of particular interest is the promise that fully autonomous vehicles, like Google’s no-steering-wheel vehicle, will have regulations governing their testing. Because the US states that wrote regulations did so before seeing Google’s vehicle, their laws still have open questions about how to test faster versions of it.

Combined with this are large research grant programs, on top of the £10M prize project to be awarded to a city for a testing project, and the planned project in Milton Keynes.

Jerusalem’s MobilEye going public in largest Israeli IPO

The leader in doing automated driver assist using cameras is Jerusalem’s MobilEye. This week they’re going public, to a valuation near $5B and raising over $600 million. MobilEye makes custom ASICs full of machine vision processing tools, and uses those to make camera systems to recognize things on the road. They have announced and demonstrated their own basic supervised self-driving car with this. Their camera, which is cheaper than the radar used in most fancy ADAS systems (but also works with radar for better results) is found in many high-end vehicles. They are a supplier to Tesla, and it is suggested that MobilEye will play a serious role in Tesla’s own self-driving plans.

As I have written, I don’t believe cameras are even close to sufficient for a fully autonomous vehicle which can run unmanned, though they can be a good complement to radar and especially LIDAR. LIDAR prices will soon drop to the low $thousands, and people taking the risk of deploying the first robocars would be unwise to not use LIDAR to improve their safety just to save a few thousand for early adopters.

Chinese search engine Baidu has robocar (and bicycle) project

Baidu is the big boy in Chinese search — sadly a big beneficiary of Google’s wise and moral decision not to be collaborators on massive internet censorship in China — and now it’s emulating Google in a big way by opening its own self-driving car project.

Various stories suggest a vehicle which involves regular handoff between a driver and the car’s systems, something Google decided was too risky. Not many other details are known.

Also rumoured is a project with bicycles. Unknown if that’s something like the “bikebot” concept I wrote about 6 years ago, where a small robot would clamp to a bike and use its wheels to deliver the bicycle on demand.

Why another search engine company? Well, one reason Google was able to work quickly is that it is the world’s #1 mapping company, and mapping plays a large role in the design of robocars. Baidu says it is their expertise in big data and AI that’s driving them to do this.

Velodyne has a new LIDAR

The Velodyne 64 plane LIDAR, which is seen spinning on top of Google’s cars and most of the other serious research cars, is made in small volumes and costs a great deal of money — $75,000. David Hall, who runs Velodyne, has regularly said that in volume it would cost well under $1,000, but we’re not there yet. He has released a new LIDAR with just 16 planes. The price, while not finalized, will be much higher than $1K but much lower than $75K (or even the $30K for the 32 plane version found on Ford’s test vehicle and some others.)

As a disclaimer, I should note I have joined the advisory board of Quanergy, which is making 8 plane LIDARs at a much lower price than these units.

Nissan goes back and forth on dates

Conflicting reports have come from Nissan on their dates for deployment. At first, it seemed they had predicted fairly autonomous cars by 2020. A later announcement by CEO Carlos Ghosn suggested it might be even earlier. But new reports suggest the product will be less far along, and need more human supervision to operate.

FBI gets all scaremongering

Many years ago, I wrote about the danger that autonomous robots could be loaded with explosives and sent to an address to wreak havoc. That is a concern, but what I wrote was that the greater danger could be the fear of that phenomenon. After all, car accidents kill more people every month in the USA than died at the World Trade Center 13 years ago, and far surpass war and terrorism as forms of violent death and injury in most nations for most of modern history. Nonetheless, an internal FBI document, released through a leak, has them pushing this idea along with the more bizarre idea that such cars would let criminals multitask more and not have to drive their own getaway cars.  read more »

The two cultures of robocars

I have many more comments pending on my observations from the recent AUVSI/TRB Automated Vehicles Symposium, but for today I would like to put forward an observation I made about two broad schools of thought on the path of the technology and the timeline for adoption. I will call these the aggressive and conservative schools. The aggressive school is represented by Google, Induct (and its successors) and many academic teams, the conservative school involves car companies, most urban planners and various others.

The conservative (automotive) view sees this technology as a set of wheels that has a computer.

The aggressive (digital) school sees this as a computer that has a set of wheels.

The conservative view sees this as an automotive technology, and most of them are very used to thinking about automotive technology. For the aggressive school, where I belong, this is a computer technology, and will be developed — and change the world — at the much faster pace that computer technologies do.

Neither school is probably entirely right, of course. It won’t go as gung-ho as a smartphone, suddenly in every pocket within a few years of release, being discarded when just 2 years old even though it still performs exactly as designed. Nor will it advance at the speed of automotive technology, a world where electric cars are finally getting some traction a century after being introduced.

The conservative school embraces the 4 NHTSA Levels or 5 SAE levels of technology, and expects these levels to be a path of progress. Car companies are starting to sell “level 2” and working on “level 3” and declaring level 4 or 5 to be far in the future. Google is going directly to SAE level 4.

The two cultures do agree that the curve of deployment is not nearly-instant like a smartphone. It will take some time until robocars are a significant fraction of the cars on the road. What they disagree on is how quickly that has a big effect on society. In sessions I attended, the feeling that the early 2020s would see only a modest fraction of cars being self-driving meant to the conservatives that they would not have that much effect on the world.

In one session, it was asked how many people had cars with automatic cruise control (ACC.) Very few hands went up, and this is no surprise — the uptake of ACC is quite low, and almost all of it is part of a “technology package” on the cars that offer it. This led people to believe that if ACC, now over a decade old, could barely get deployed, we should not expect rapid deployment of more complete self-driving. And this may indeed be a warning for those selling super-cruise style products which combine ACC and lanekeeping under driver supervision, which is the level 2 most car companies are working on.

To counter this, I asked a room how many had ridden in Uber or its competitors. Almost every hand went up this time — again no surprise. In spite of the fact that Uber’s cars represent an insignificant fraction of the deployed car fleet. In the aggressive view, robocars are more a service than a product, and as we can see, a robocar-like service can start affecting everybody with very low deployment and only a limited service area.

This dichotomy is somewhat reflected in the difference between SAE’s Level 4 and NHTSA’s. SAE Level 4 means full driving (including unmanned) but in a limited service area or under other limited parameters. This is what Google has said they will make, this is what you see planned for services in campuses and retirement communities. This is where it begins, and grows one region at a time. NHTSA’s levels falsely convey the idea that you slowly move to fully automated mode and immediately do it over a wide service area. Real cars will vary as to what level of supervision they need (the levels) over different times, streets and speeds, existing at all the levels at different times.

Follow the conservative model and you can say that society will not see much change until 2030 — some even talk about 2040. I believe that is an error.

Another correlated difference of opinion lies around infrastructure. Those in the aggressive computer-based camp wish to avoid the need to change the physical infrastructure. Instead of making the roads smart, make the individual cars smart. The more automotive camp has also often spoken of physical changes as being more important, and also believes there is strong value in putting digital “vehicle to vehicle” radios in even non-robocars. The computer camp is much more fond of “virtual infrastructure” like the detailed ultra-maps used by Google and many other projects.

It would be unfair to claim that the two schools are fully stratified. There are researchers who bridge the camps. There are people who see both sides very well. There are “computer” folks working at car companies, and car industry folks on the aggressive teams.

The two approaches will also clash when it comes to deciding how to measure the safety of the products and how they should be regulated, which will be a much larger battle. More on that later.

Robotics: Science and Systems and Automated Vehicles Symposium this week

It’s a big week for Robocar conferences.

In Berkeley, yesterday I attended and spoke at the “Robotics: Science and Systems” conference which had a workshop on autonomous vehicles. That runs to Wednesday, but overlapping and near SF Airport is the Automated Vehicles Symposium — a merger of the TRB (Transportation Research Board) and AUVSI conferences on the same topic. 500 are expected to attend.

Yesterday’s workshop was pretty good, with even a bit of controversy.

Yesterday saw:

  • Ed Olson on more of the lessons from aviation on handoff between automation and manual operation. This keeps coming up a a real barrier to some of the vehicle designs that have humans share the chores with the system.
  • Jesse Levinson of Stanford’s team showed some very impressive work in automatic calibration of sensors, and even fusion of LIDAR and camera data, aligning them in real time in spite of movement and latency. This work will make sensors faster, more reliable and make fusion accurate enough to improve perception.
  • David Hall, who runs Velodyne, spoke on the history of their sensors, and his plans for more. He repeated his prediction that in large quantities his sensor could cost only $300. (I’m a bit skeptical of that, but it could cost much, much less than it does today.) David made the surprising statement that he thinks we should make dedicated roads for the vehicles. (Surprising not just because I disagree, but because you could even get by without much LIDAR on such roads.)
  • Marco Panove of Stanford showed research they did on Taxi models from New York and Singapore. The economics look very good. Dan Fagnant also presented related research assuming an on-demand semi shared system with pickup stations in every TAZ. It showed minimal vacant miles but also minimal successful rideshare. The former makes sense when it’s TAZ to TAZ (TAZs are around a square mile) but I would have thought there would be more rideshare. The conclusion is that VMT go up due to empty miles, but that rideshare can partially compensate, though not as much as some might hope.
  • Ken Laberteaux of Toyota showed his research on the changing demographics of driving and suburbs. Conclusion: We are not moving back into the city, suburbanization is continuing. Finding good schools continues to drive people out unless they can afford private school are are childless.

The event had a 3-hour lunch break, where most went to watch some sporting event from Brazil. The Germans at the conference came back happier.

Some good technical talks presented worthwhile research

  • Sheng Zhao and a team from UC Riverside showed a method to get cm accuracy in position and even in pose (orientation) from cheap GPS receivers, by using improved math on phase-matching GPS. This could also be combined with cheap IMUs. Most projects today use very expensive IMUs and GPSs, not the cheap ones you find in your cell phone. This work may lead to being able to get reliable data from low cost parts.
  • Matthew Cornick and a team from Lincoln Lab at MIT showed very interesting work on using ground penetrating radar to localize. With GPR, you get a map of what’s below the road — you see rocks and material patterns down several feet. These vary enough, like the cracks and lines on a road, and so you can map them, and then find your position in that map — even if the road is covered in snow. While the radar units are today bulky, this offers the potential for operations in snow.
  • A team from Toyota showed new algorithms to speed up the creation of the super-detailed maps needed for robocars. Their algorithms are good at figuring out how many lanes there are and when they start and stop. This could make it much cheaper to build the ultramaps needed in an automatic way, with less human supervision.

The legal and policy sessions got more heated.

  • Bryant Walker Smith laid out some new proposals for how to regulate and govern torts about the vehicles.
  • Eric Feron of Georgia Tech made proposals for how to do full software verification. Today formally proving and analysing code for correctness takes 0.6 hours per line of code — it’s not practical for the 50 million line (or more) software systems in cars today. Jonathan argues it can be made cheaper, and should be done. Note that fully half the cost of developing the 787 aircraft was software verification!

The final session, on policy included:

  • Jane Lappin on how DoT is promoting research.
  • Steve Shladover on how we’re all way to optimistic on timelines, and that coming up with tests to demonstrate superior safety to humans is very far away, since humans run 65,000 hours between injury accidents.
  • Myself on why regulation should keep a light touch, and we should not worry too much about the Trolley Problem — which came up a couple of times.
  • Raj Rajkumar of CMU on the success they have had showing the CMU/GM car to members of congress.

Now on to the AVS tomorrow.

Robocars 101 on Big Think, NPR Interview and many talks

Some recent press and talks:

Earlier in June I sat down with “Big Think” for an interview they have titled “Robocars 101” explaining some of the issues around the cars.

I also did a short interview on NPR’s “All Things Considered” not long after Google’s new car was announced. What you might find interesting is how I did it. I was at a friend’s house in Copenhagen and went into a quiet room where they called me on my cell phone. However, I also started a simple audio recorder app on my phone. When we were done, I shared the mp3 of a better sample from the same microphone with them, which they mixed in.

As a result, the interview sounds almost like it was done in-studio instead of over an international cell phone call.

Videos of my talks at Next Berlin at at Dutch Media Future Week 2014 are also up. And a shortened talk at Ontario Centers for Excellence Discovery 2014 in Toronto May 12. There we had the Governor General of Canada as our opening act. :-) That’s just 3 of the 11 events I was at on that trip.

Completely off the Robocar track is a short interview with CNBC where I advise people to invest in Bitcoin related technology, not in bitcoins.

Small startup "Cruise" plans to sell modification kits for highway driving

So far it’s been big players like Google and car companies with plans in the self-driving space. Today, a small San Francisco start-up named Cruise, founded by Kyle Vogt (a founder of the web video site Justin.tv) announces their plans to make a retrofit kit that will adapt existing cars to do basic highway cruise, which is to say, staying in a lane and keeping pace behind other cars while under a driver’s supervision.

I’ve been following Cruise since its inception. This offering has many similarities to the plans of major car companies, but there are a few key differences:

  • This is a startup, which can be more nimble than the large companies, and having no reputation to risk, can be bolder.
  • They plan to make this as a retrofit kit for a moderate set of existing cars, rather than custom designing it to one car.

They’re so dedicated to the retrofit idea that the Audi A4 they are initially modifying does not even have drive-by-wire brakes like the commonly used hybrid cars. Their kit puts sensors on the roof, and puts a physical actuator on the brake and another physical actuator on the steering wheel — they don’t make use of the car’s own steering motor. They want a kit that can be applied to almost any car the market tells them to target.

They won’t do every car, though. All vendors have a strong incentive to only support cars they have given some solid testing to, so most plans don’t involve retrofit at all, and of course Google has now announced their plans to design a car from scratch. Early adopters may be keen on retrofit.

I rode in the car last week during a demo at Alemeda air station, a runway familiar to viewers of Mythbusters. There they set up a course of small orange cones, which are much easier to see than ordinary lane markings, so it’s hard to judge how well the car does on lane markings. It still has rough edges, to be sure, but they don’t plan to sell until next year. In the trial, due to insurance rules, it kept under 40mph, though it handled that speed fine, though drifted a bit in wider parts of the “lane.”

On top is an aerodynamic case around a sensor pack which is based on stereo cameras and radar from Delphi. Inside is just a single button in the center arm console to enable and disable cruise mode. You take the car to the lane and push the button.

All stuff we’ve seen before, and not as far along, but the one key difference — being a nimble startup — may make all the difference. Only early adopters will pay the $10,000 for a product where you must (at least for now) still watch the road, but that may be all that is needed.

Live Google transit directions seriously changes the value of transit

On my recent wanderings in Europe, I became quite enamoured by Google’s latest revision of transit directions. Google has had transit directions for some time, but they have recently improved them, and linked them in more cities to live data about where transit vehicles actually are.

The result not a mere incremental improvement, it’s a game-changing increase in the utility of decent transit. In cities like Oslo and London, the tool gives the user the ability to move with transit better than a native. In the past, using transit, especially buses, as a visitor has always been so frustrating that most visitors simply don’t use it, in spite of the much lower cost compared to taxis. Transit, especially when used by an unfamiliar visitor, is slow and complex, with long waits, missed connection and confusion about which bus or line to take during shorter connections, as well as how to pay.

Not so any more. With a superhuman ability, your phone directs you to transit stops you might not figure out from a map, where the right bus usually appears quite quickly. Transfers are chosen to be quick as well, and directions are given as to which direction to go, naming the final destination as transit signs often do, rather than the compass direction. It’s optimized by where the vehicles actually are and predicted to be, and this will presumably get even better.

By making transit “just work” it becomes much more useful, and gives us a taste of the robocar taxi world. That world is even easier, of course — door to door with no connections and no need for you to even follow directions. But while Uber also shows us that world well in user experience, Uber is expensive, as are cabs, while transit is closer in cost to the anticipated robocar cost of well below $1/mile.

It also helps to have transit systems with passes or contactless pay cards, to avoid the hassles of payment.

Why does this work so well? In the transit-heavy cities, it turns out there are often 2, 3 or even 4 ways to get to your destination via different transit lines and connections. The software is able to pick among them in a way even a native couldn’t, and one is often leaving soon, and it finds it for you.

In some cities, there is not live data, so it only routes based on schedules. This cuts the utility greatly. From a user experience standpoint, it is often better to give people a wait they expect than to do a better job but not give accurate expectations.

What’s clear now is that transit agencies should have done this a lot sooner. Back in the 1980s a friend of mine built one of the first systems which tracked transit vehicles and gave you a way to call to see when the bus would come, or in some cases signs on the bus stops. Nice as those were they are nothing compared to this. There is not much in this technology that could not have been built some time ago. In fact, it could have been built even before the smartphone, with people calling in by voice and saying, “I am at the corner of X and Y and I need to get to Z” with a human helper. The cost would have actually been worth it because by making the transit more useful it gets more riders.

That might be too expensive, but all this needed was the smartphone with GPS and a data connection, and it is good that it has come.

In spite of this praise, there is still much to do.

  • Routing is very time dependent. Ask at 1:00 and you can get a very different answer than you get asking at 1:02. And a different one at 1:04. The product needs a live aspect that updates as you walk and time passes.
  • The system never figures out you are already on the bus, and so always wants to route you as though you were standing on the road. Often you want to change plans or re-look up options once you are on the vehicle, and in addition, you may want to do other things on the map.
  • Due to how rapidly things change, the system also needs to display when multiple options are equivalent. For example, it might say, “Go to the train platform and take the B train northbound.” Then due to how things have change, you see a C train show up — do you get on it? Instead, it should say, “Take a B, C or E train going north towards X, Y or Z, but B should come first.”
  • For extra credit, this should get smarter and combine with other modes. For example, many cities have bikeshare programs that let you ride a bike from one depot to another. If the system knew about those it could offer you very interesting routings combining bikes and transit. Or if you have your own bike and transit lines allow it on, you could use that.
  • Likewise, you could combine transit with cabs, getting a convenient route with low walking but with much lower cab expense.
  • Finally, you could also integrate with one-way car share programs like car2go or DriveNow, allowing a trip to mix transit, car, bike and walking for smooth movement.
  • Better integration with traffic is needed. If the buses are stuck in traffic, it’s time to tell you to take another method (even cycling or walking) if time is your main constraint.
  • Indoor mapping is needed in stations, particularly underground ones. Transit agencies should have beacons in the stations or on the tracks so phones can figure out where they are when GPS is not around. Buses could also have beacons to tell you if you got on the right one.
  • The systems should offer an alert when you are approaching your stop. Beacons could help here too. For a while the GPS map has allowed the unfamiliar transit rider to know when to get off, but this can make it even better.
  • This is actually a decent application for wearables and things like Google glass, or just a bluetooth earpiece talking in your ear, watching you move through the city and the stations and telling you which way to go, and even telling you when you need to rush or relax.
  • In some cities going onto the subway means loss of signal. There, storing the live model for relevant lines in a cache would let the phone still come up with pretty good estimates when offline for a few minutes.

A later stage product might let you specify a destination and a time, and then it will buzz you when it’s time to start walking, and guide you there, through a path that might include walking, bike rides, transit lines and even carshare or short cab rides for a fast, cheap trip with minimal waiting, even when the transit isn’t all that good.

Conan O'Brien's Google Car, Nissan in 2018 and more

I’m in the home stretch of a long international trip — photos to follow — but I speak tomorrow at Lincoln Center on how computers (and robocars) will change the worlds of finance. In the meantime, Google’s announcement last month has driven a lot of news in the Robocar space worthy of reporting.

On the lighter side, this video from the Conan O’Brien show highlights the issues around people’s deep fear of being injured by machines. While the video is having fun, this is a real issue that will dominate the news when the first accidents and injuries happen. I cover that in detail in my article about accidents but the debate will be a major one.

Nissan announced last year that it would sell cars in 2020. Now that Tesla has said 2016, Google has said civilians will be in their small car within a year and Volvo has said the same will happen in Sweden by 2017, Nissan CEO Carlos Ghosn has said they might do it 2 years earlier.

As various locations rush to put in robocar laws, in Europe they are finally getting around to modifying the Vienna convention treaty, which required a human driver. However, the new modifications, driven by car companies, still call for a steering wheel that a driver can use to take over (as do some of the US state laws.) These preclude Google’s new design, but perhaps with a bit of advance warning, this can be fixed. Otherwise, changing it again will be harder. Perhaps the car companies — none of whom have talked about anything like Google’s car with no controls — will be happy with that.

The urban test course at the University of Michigan, announced not very long ago, is almost set to open — things are moving fast, as they will need to if Michigan is to stay in the race. Google’s new prototype, by the way, is built in Michigan. Google has not said who but common speculation names not a major car company, but one of their big suppliers.

The Ernst & Young auto research lab (in Detroit) issued a very Detroit style forecast for autonomous vehicles which said their widespread use was 2 decades away. Not too surprising for such a group. Consultants are notoriously terrible at predictions for exponential technology. Their bad smartphone predictions are legendary (and now erased, of course.) A different study predicts an $87 billion market — but the real number is much larger than that.

This article where top car designers critique Google’s car illustrates my point from last week how people with car company experience are inclined to just not get it. But at the same time some of the automotive press do get it.

Hotel rooms and temporary apartments need to adapt better for the digital nomad

I’ve been on the road for the last month, and there’s more to come. Right now I’m in Amsterdam for a few hours, to be followed by a few events in London, then on to New York for Singularity U’s Exponential Finance conference, followed by the opening of our Singularity University Graduate Studies Program for 2014. (You can attend our opening ceremony June 16 by getting tickets here — it’s always a good crowd)

But while on the road, let me lament about what’s missing from so many of the hotel rooms and AirBnB apartments I’ve stayed in, which is an understanding of what digital folks, especially digital couples need.

Desk space

Yes, rooms are small, especially in Europe, and one thing they often sacrifice is desk space. In particular, desk space for two people with laptops. This is OK if you’ve ditched the laptop for a tablet, but many rooms barely have desk space enough for one, or the apartments have no desk, only the kitchen table. And some only have one chair.

We need desk space, and we need a bit of room to put things, and we need it for two. Of course, there should be plugs at desk level if you can — the best thing is to have a power strip on the desk, so we can plug in laptops, camera chargers, phone chargers and the like.

Strangely, at least half the hotels I stay in have a glass tabletop for their desk. The once surface my mouse won’t work on. Yes, I hate the trackpad so I use a mouse if I am doing any serious computing. I can pull over a piece of paper or book to be a mousepad, but this is silly.

Monitor

Really sweet, but rarely seen, is an external monitor. Nice 24” computer monitors cost under $150 these days, so there should be one — or two. And there should be cables (HDMI and VGA at least) because while I bring cables sometimes, you never know which cable the monitor in a room will use. Sometimes you can plug into the room’s TV — but sometimes it has been modified so you can’t. It’s nice if you can, though a TV on the while is not a great monitor for working. It’s OK for watching video if I wanted to.

For extra credit, perhaps the TV can support some of the new video over wireless protocols, like Miracast, Widi or Apple’s TV protocol, to make it easy to connect devices, even phones and tablets.

Sadly, there is no way yet for you to provide me with a keyboard or mouse in the room that I could trust.

Power

Though when it comes to phone chargers, many use their phone as their alarm clock, and so they want it by the bed. There should be power by the bed, and it should not require you to unplug the bedside lamp or clock radio.

Another nice touch would be plugs or power strips with the universal multi-socket that accepts all the major types of plugs. Sure, I always have adapters but it’s nice to not have to use them. My stuff is all multi-voltage of course.

Luggage holders

Most hotel rooms come with a folding luggage stand, which is good. But they should really come with two. Couples and families routinely have 3 bags. A hotel should know that if you’ve booked a double room, you probably want at least two. Sometimes I have called down to the desk to get more and they don’t have any more — just one in each room. If you are not going to put them in the room, the bell desk should be able to bring up any you need.

Free Wifi (and wired) without a goddamned captive portal

I’ve ranted about this before, but captive portals which hijack your browser — thus breaking applications and your first use — are still very common. Worse, some of them reset every time you turn off your computer — or your phone, and you have to re-auth. Some portals are there to charge you, but I find that not an excuse any more. When hotels charge me for internet, I ask them how much the electricity and water are in the room. It’s past time that hotels that charge for internet just have that included in the online shopping sites like Kayak and Tripadvisor when you search for hotels. Or at the least I should be able to check a box for “show me the price with internet, and any taxes and made-up resort fees” so I can compare the real price.

But either way, the captive portals break too many things. (Google Glass can’t even work at all with them.) Cheap hotels give free wifi with no portal — this is a curse of fancier hotels. If you want sell premium wifi, so be it — but let me log into the basic one with no portal, and then I can go to a URL where I can pay for the upgrade. If you insist give me really crappy internet, 2G speed internet, with no portal, so that things at least work, though slowly, until I upgrade.

If you need a password, use WPA2. You can set up a server so people enter their room number and name with WPA2-Enterprise. You can meet certain “know your user” laws that force these portals on people that way.

And have wired internet — with a cable — if you can. At a desk, it’s more reliable and has no setup programs and needs no password or portal at all.

Why Google's "ridiculous" looking car is brilliant

It’s not too surprising that the release of images of Google’s prototype robocar have gotten comments like this:

Revolutionary Tech in a Remarkably Lame Package from Wired

A Joy Ride in Google’s Clown Car says Re/Code

I’ve also seen comparisons to the Segway, and declarations that limited to 25 mph, this vehicle won’t get much adoption or affect the world much.

Google’s own video starts with a senior expressing that it’s “cute.”

I was not involved in the specifics of design of this vehicle, though I pushed hard as I could for something in this direction. Here’s why I think it’s the right decision.

First of all, this is a prototype. Only 100 of this design will be made, and there will be more iterations. Google is all about studying, learning and doing it again, and they can afford to. They want to know what people think of this, but are not scared if they underestimate it at first.

Secondly, this is what is known as a “Disruptive Technology.” Disruptive technologies, as described in the Silicon Valley bible “The Innovators Dilemma” are technologies that seem crazy and inferior at first. They meet a new need, not well understood by the incumbent big companies. Those big companies don’t see it as a threat — until years later, they are closing their doors. Every time a disruptive technology takes over, very few of the established players make it through to the other side. This does not guarantee that Google will dominate or crush those companies, or that everything that looks silly eventually wins. But it is a well established pattern.

This vehicle does not look threatening — not to people on the street, and not to existing car companies and pundits who don’t get it. Oh, there are many people inside those car companies who do get it, but the companies are incapable of getting it in their bones. Even when their CEOs get it, they can’t steer the company 90 degrees — there are too many entrenched forces in any large company. The rare exception are founder-led companies (like Google and Facebook and formerly Apple and Microsoft) where if the founder gets it, he or she can force the company to get it.

Even large companies who read this blog post and understand it still won’t get it, not most of the time. I’ve talked to executives from big car companies. They have a century of being car companies, and knowing what the means. Google, Tesla and the coming upstarts don’t.

One reason I will eventually move away from my chosen name for the technology — robocar — along with the other popular names like “self-driving car” is that this future vehicle is not a car, not as we know it today. It is no more a “driverless car” than a modern automobile is a horseless carriage. 100 years ago, the only way they could think of the car was to notice that there was no horse. Today, all many people notice about robocars is that no human is driving. This is the thing that comes after the car.

Some people expected the car to look more radical. Something like the Zoox or ATMBL by Mike and Maaike (who now work in a different part of Google.) Cars like those will come some day, but are not the way you learn. You start simple, and non threatening, and safe. And you start expensive — the Google prototype still has the very expensive Velodyne LIDAR on it, but trust me, very soon LIDAR is going to get a lot less expensive.

The low speed is an artifact of many things. You want to start safe, so you limit where you go and how fast. In addition, US law has a special exception from most regulations for electric vehicles that can’t go more than 25mph and stick to back roads. Some may think that’s not very useful (turns out they are wrong, it has a lot of useful applications) but it’s also a great way to start. Electric vehicles have another big advantage in this area. Because you can reverse electric motors, they can work as secondary brakes in the event of failure of the main brake system, and can even be secondary steering in case of failure of the steering system at certain speeds. (Google has also said that they have two steering motors in order to handle the risk of failure of one steering motor.) Electric vehicles are not long-range enough to work as taxis in a large area, but they can handle smaller areas just fine.

If you work in the auto industry, and you looked at this car and saw a clown car, that’s a sign you should be afraid.

Google to custom make its own car with no steering wheel

In what is the biggest announcement since Google first revealed their car project, it has announced that they are building their own car, a small low-speed urban vehicle for two with no steering wheel, throttle or brakes. It will act as a true robocar, delivering itself and taking people where they want to go with a simple interface. The car is currently limited to 25mph, and has special pedestrian protection features to make it even safer. (I should note that as a consultant to that team, I helped push the project in this direction.)

This is very different from all the offerings being discussed by the various car companies, and is most similar to the Navia which went on sale earlier this year. The Navia is meant as a shuttle, and up to 12 people stand up in it while it moves on private campus roads. It only goes 20 km/h rather than the 40 km/h of Google’s new car. Google plans to operate their car on public roads, and will have non-employees in test prototype vehicles “very soon.”

This is a watershed moment and an expression of the idea that the robocar is not a car but the thing that comes after the car, as the car came after the horse. Google’s car is disruptive, it seems small and silly looking and limited if you look at it from the perspective of existing car makers. That’s because that’s how the future often looks.

I have a lot to say about what this car means, but at the same time, very little because I have been saying it since 2007. One notable feature (which I was among those pushing for inside) is a soft cushion bumper and windshield. Clearly the goal is always to have the car never hit anybody, but it can still happen because systems aren’t perfect and sometimes people appear in front of cars quickly making it physically impossible to stop. In this situation, cars should work to protect pedestrians and cyclists. Volvo and Autoliv have an airbag that inflates on the windshield bars, which are the thing that most often kills a cyclist. Of the 1.2 million who are killed in car accidents each year, close to 500,000 are pedestrians, mostly in the lower income nations. These are first steps in protecting them as well as the occupants of the car.

The car has 2 seats (side-by-side) and very few controls. It is a prototype, being made at first in small quantities for testing.

More details, and other videos, including a one of Chris Urmson giving more details, can be found at the new Google Plus page for the car. Also of interest is this interview with Chris.

I’m in Milan right now about to talk to Google’s customers about the car — somewhat ironic — after 4 weeks on the road all over Europe. 2 more weeks to go! I will be in Copenhagen, Amsterdam, London and NYC in the coming weeks, after having been in NYC, Berlin, Krakow, Toronto, Amsterdam, Copenhagen, Oslo, the fjords and Milan. In New York, come see me at Singularity U’s Exponential Finance conference June 10-11.

Google announces urban driving milestone

News from Google’s project is rare, but today on the Google blog they described new achievements in urban driving and reported a number of 700,000 miles. The car has been undergoing extensive testing in urban situations, and Google let an Atlantic reporter get a demo of the urban driving which is worth a read.

You will want to check out the new video demo of urban operations:

While Google speakers have been saying for a while that their goal is a full-auto car that does more than the highway, this release shows the dedication already underway towards that goal. It is the correct goal, because this is the path to a vehicle that can operate vacant, and deliver, store and refuel itself.

Much of the early history of development has been on the highway. Most car company projects have a focus on the highway or traffic jam situations. Google’s cars were, in years past, primarily seen on the highways. In spite of the speed, highway driving is actually a much easier task. The traffic is predictable, and the oncoming traffic is physically separated. There are no cyclists, no pedestrians, no traffic lights, no stop signs. The scariest things are on-ramps and construction zones. At low speed the highway could even be considered a largely solved problem by now.

Highway driving accounts for just over half of our miles, but of course not our hours. A full-auto car on the highway delivers two primary values: Fewer accidents (when delivered) and giving productive time back to the highway commuter and long distance traveller. This time is of no small value, of course. But the big values to society as a whole come in the city, and so this is the right target. The “super-cruise” products which require supervision do not give back this time, and it is debatable if they give the safety. Their prime value is a more relaxing driving experience.

Google continues to lead its competitors by a large margin. (Disclaimer: They have been a consulting client of mine.) While Mercedes — which is probably the most advanced of the car companies — has done an urban driving test run, it is not even at the level that Google was doing in 2010. It is time for the car makers to get very afraid. Major disruption is coming to their industry. The past history of high-tech disruptions shows that very few of the incumbent leaders make it through to the other side. If I were one of the car makers who doesn’t even have a serious project on this, I would be very afraid right now.

New regulations are banning the development of delivery robots

Many states and jurisdictions are rushing to write laws and regulations governing the testing and deployment of robocars. California is working on its new regulations right now. The first focus is on testing, which makes sense.

Unfortunately the California proposed regulations and many similar regulations contain a serious flaw:

The autonomous vehicle test driver is either in immediate physical control of the vehicle or is monitoring the vehicle’s operations and capable of taking over immediate physical control.

This is quite reasonable for testing vehicles based on modern cars, which all have steering wheels and brakes with physical connections to the steering and braking systems. But it presents a problem for testing delivery robots or deliverbots.

Delivery robots are world-changing. While they won’t and can’t carry people, they will change retailing, logistics, the supply chain, and even going to the airport in huge ways. By offering very quick delivery of every type of physical goods — less than 30 minutes — at a very low price (a few pennies a mile) and on the schedule of the recipient, they will disrupt the supply chain of everything. Others, including Amazon, are working on doing this by flying drone, but for delivery of heavier items and efficient delivery, the ground is the way to go.

While making fully unmanned vehicles is more challenging than ones supervised by their passenger, the delivery robot is a much easier problem than the self-delivering taxi for many reasons:

  • It can’t kill its cargo, and thus needs no crumple zones, airbags or other passive internal safety.
  • It still must not hurt people on the street, but its cargo is not impatient, and it can go more slowly to stay safer. It can also pull to the side frequently to let people pass if needed.
  • It doesn’t have to travel the quickest route, and so it can limit itself to low-speed streets it knows are safer.
  • It needs no windshield or wheel, and can be small, light and very inexpensive.

A typical deliverbot might look like little more than a suitcase sized box on 3 or 4 wheels. It would have sensors, of course, but little more inside than batteries and a small electric motor. It probably will be covered in padding or pre-inflated airbags, to assure it does the least damage possible if it does hit somebody or something. At a weight of under 100lbs, with a speed of only 25 km/h and balloon padding all around, it probably couldn’t kill you even if it hit you head on (though that would still hurt quite a bit.)

The point is that this is an easier problem, and so we might see development of it before we see full-on taxis for people.

But the regulations do not allow it to be tested. The smaller ones could not fit a human, and even if you could get a small human inside, they would not have the passive safety systems in place for that person — something you want even more in a test vehicle. They would need to add physical steering and braking systems which would not be present in the full drive-by-wire deployment vehicle. Testing on real roads is vital for self-driving systems. Test tracks will only show you a tiny fraction of the problem.

One way to test the deliverbot would be to follow it in a chase car. The chase car would observe all operations, and have a redundant, reliable radio link to allow a person in the chase car to take direct control of any steering or brakes, bypassing the autonomous drive system. This would still be drive-by-wire(less) though, not physical control.

These regulations also affect testing of full drive-by-wire vehicles. Many hybrid and electric cars today are mostly drive-by-wire in ordinary operations, and the new Infiniti Q50 features the first steer-by-wire. However the Q50 has a clutch which, in the event of system failure, reconnects the steering column and the wheels physically, and the hybrids, even though they do DBW regenerative braking for the first part of the brake pedal, if you press all the way down you get a physical hydraulic connection to the brakes. A full DBW car, one without any steering wheel like the Induct Navia, can’t be tested on regular roads under these regulations. You could put a DBW steering wheel in the Navia for testing but it would not be physical.

Many interesting new designs must be DBW. Things like independent control of the wheels (as on the Nissan Pivo) and steering through differential electric motor torque can’t be done through physical control. We don’t want to ban testing of these vehicles.

Yes, teams can test regular cars and then move their systems down to the deliverbots. This bars the deliverbots from coming first, even though they are easier, and allows only the developers of passenger vehicles to get in the game.

So let’s modify these regulations to either exempt vehicles which can’t safely carry a person, or which are fully drive-by-wire, and just demand a highly reliable DBW system the safety driver can use.

Can they make a better black box pinger?

I wrote earlier on how we might make it easier to find a lost jet and this included the proposal that the pingers in the black boxes follow a schedule of slowing down their pings to make their batteries last much longer.

In most cases, we’ll know where the jet went down and even see debris, and so getting a ping every second is useful. But if it’s been a week, something is clearly wrong, and having the pinger last much longer becomes important. It should slow down, eventually dropping to intervals as long as one minute, or even an hour, to keep it going for a year or more.

But it would be even more valuable if the pinger was precise about when it pinged. It’s easy to get very accurate clocks these days, either sourced from GPS chips (which cost $5) or just synced on occasion from other sources. Unlike GPS transmitter clocks, which must sync to the nanosecond, here even a second of drift is tolerable.

The key is that the receiver who hears a ping must be able to figure out when it was sent, because if they can do that they can get the range, and even a very rough range is magic when it comes to finding the box. Just 2 received pings from different places with range will probably find the box.

I presume the audio signal is full of noise and you can’t encode data into it very well, but you can vary the interval between pings. For example, while a pinger might bleep every second, every 30 seconds it could ping twice in a second. Any listener who hears 30 seconds of pings would then know the pinger’s clock and when each ping was sent. There could be other variations in the intervals to help pin the time down even better, but it’s probably not needed. In 30 seconds, sound travels 28 miles underwater, and it’s unlikely you would hear the ping from that far away.

When the ping slows down as battery gets lower, you don’t need the variation any more, because you will know that pings are sent at precise seconds. If pings are down to one a minute, you might hear just one, but knowing it was sent at exactly the top of the minute, you will know its range, at least if you are within 50 miles.

Of course things can interfere here — I don’t know if sound travels with such reliable speed in water, and of course, waves bounce off the sea floor and other things. It is possible the multipath problem for sound is much worse than I imagine, making this impossible. Perhaps that’s why it hasn’t been done. This also adds some complexity to the pinger which they may wish to avoid. But anything that made the pings distinctive would also allow two ships tracking the pings to know they had both heard the same particular ping and thus solve for the location of the pinger. Simple designs are possible.

Two way pinger

If you want to get complex of course you could make the pinger smart, and listening for commands from outside. Listening takes much less power, and a smart pinger could know not to bother pinging if it can’t hear the ship searching for it. Ships can ping with much more volume, and be sure to be heard. While there is a risk a pinger with a broken microphone might not understand it has a broken microphone, otherwise, a pinger should sit silent until it hears request pings from ships, and answer those. It could answer them with much more power and thus more range, because it would only ping when commanded to. It could sit under the sea for years until it heard a request from a passing ship or robot. (Like the robots made by my friends at Liquid Robotics, which cruise unmanned at 2 knots using wave power and could spend years searching an area.)

The search for MH370 has cost hundreds of millions of dollars, so this is something worth investigating.

Other more radical ideas might be a pinger able to release small quantities of radioactive material after waiting a few weeks without being found. Or anything else that can be detected in extremely minute concentrations. Spotting those chemicals could be done sampling the sea, and if found soon enough — we would know exactly when they would be released — could help narrow the search area.

Track the waves

I will repeat a new idea I added to the end of the older post. As soon as the search zone is identified, a search aircraft should drop small floating devices with small radio transmitters good to find them again at modest range. Drop them as densely as you can, which might mean every 10 miles or every 100 miles but try to get coverage on the area.

Then, if you find debris from the plane, do a radio hunt for the nearest such beacon. When you find it, or others, you can note their serial number, know where they were dropped, and thus get an idea of where the debris might have come from. Make them fancier, broadcasting their GPS location or remembering it for a dump when re-collected, and you could build a model of motion on the surface of the sea, and thus have a clue of how to track debris back to the crash site. In this case, it would have been a long time before the search zone was located, but in other cases it will be known sooner.

Conspiracy theory!

Reporting has not been clear, but it appears that the ships which heard the pings did so in the very first place they looked. With a range of only a few miles, that seems close to impossibly good luck. If it turns out they did hear the last gasp of the black boxes, this suggests an interesting theory.

The theory would be that some advanced intelligence agencies have always known where the plane went down, but could not reveal that because they did not want reveal their capabilities. A common technique in intelligence, when you learn something important by secret means, is to then engineer another way to learn that information, so that it appears it was learned through non-secret means or luck. In the war, for example, spies who broke enemy codes and learned about troop movements would then have a “lucky” recon plane “just happen” to fly over the area, to explain how you knew where they were. Too much good luck and they might get suspicious, and might learn you have broken their crypto.

In this case the luck is astounding. Yes, it is the central area predicted by the one ping found by Inmarsat, but that was never so precise. In this case, though, all we might discern — if we believe this theory at all — is that maybe, just maybe, some intelligence agency among the countries searching has some hidden ways to track aircraft. Not really all that surprising as a bit of news, though.

Let’s hope they do find what’s left — but if they do, it seems likely to me it happened because the spies know things they aren’t telling us.

Robocar Prize in India, New Vislab car

I read a lot of feeds, and there are now scores of stories about robocars every week. Almost every day a new publication gives a summary of things. Here, I want to focus on things that are truly new, rather than being comprehensive.

Mahindra “Rise” Prize

The large Indian company Mahindra has announced a $700,000 Rise prize for robocar development for India’s rather special driving challenges. Prizes have been a tremendous boost to robocar development and DARPA’s contests changed the landscape entirely. Yet after the urban challenge, DARPA declared their work was done and stopped, and in spite of various efforts to build a different prize at the X-Prize foundation, the right prize has never been clear. China has annual prizes and has done so for several years, but they get little coverage outside of China.

An Indian prize has merit because driving in India is very much different, and vastly more chaotic than most of the west. As such, western and east Asian companies are unlikely to spend a lot of effort trying to solve the special Indian problems first. It makes sense to spur Indian development, and of course there is no shortage of technical skill in India.

Many people imagine that India’s roads are so chaotic that a computer could never drive on them. There is great chaos, but it’s important to note that it’s slow chaos, not fast chaos. Being slow makes it much easier to be safe. Safety is the hard part of the problem. Figuring out just what is happening, playing subtle games of chicken — these are not trivial, but they can be solved, if the law allows it.

I say if the law allows it because Indians often pay little heed to the traffic law. A vehicle programmed to strictly obey the law will probably fail there without major changes. But the law might be rewritten to allow a robot to drive the way humans drive there, and be on an open footing. The main challenge is games of chicken. In the end, a robot will yield in a game of chicken and humans will know that and exploit it. If this makes it impossible for the robot to advance, it might be programmed to “yield without injury” in a game of chicken. This would mean randomly claiming territory from time to time, and if somebody else refuses to yield, letting them hit you, gently. The robot would use its knowledge of physics to keep the impact low enough speed to cause minor fender damage but not harm people. If at fault, the maker of the robot would have to pay, but this price in damage to property may be worthwhile if it makes the technology workable.

The reason it would make things workable is that once drivers understood that, at random, the robot will not yield (especially if it has the right-of-way) and you’re going to hit it. Yes, they might pay for the damage (if you had the right of way) but frankly that’s a big pain for most people to deal with. People might attempt insurance fraud and deliberately be hit, but they will be recorded in 3D, so they had better be sure they do it right, and don’t do it more than once.

Of course, the cars will have to yield to pedestrians, cylists and in India, cows. But so does everybody else. And if you just jump in front of a car to make it hit the brakes, it will be recording video of you, so smile.

New Vislab Car

I’ve written before about Vislab at the University of Parma. Vislab are champions of using computer vision to solve the driving problem, though their current vehicles also make use of LIDAR, and in fact they generally agree with the trade-offs I describe in my article contrasting LIDAR and cameras.

They have a new vehicle called DEEVA which features 20 cameras and 4 lasers. Like so many “not Google” projects, they have made a focus on embedding the sensors to make them not stand out from the vehicle. This continues to surprise me, because I have very high confidence that the first customers of robocars will be very keen that they not look like ordinary cars. They will want the car to stand out and tell everybody, “Hey, look, I have a robocar!” The shape of the Prius helped its sales, as well as its drag coefficient.

This is not to say there aren’t people who, when asked, will say they don’t want the car to look too strange, or who say, looking at various sensor-adorned cars, that these are clearly just lab efforts and not something coming soon to roads near you. But the real answer is neither ugly sensors nor hidden sensors, but distinctive sensors with a design flair.

More interesting is what they can do with all those cameras, and what performance levels they can reach.

I will also note that car uses QNX as its OS. QNX was created by friend I went to school with in Waterloo, and they’re now a unit of RIM/Blackberry (also created by classmates of mine.) Go UW!

Getting rid of lines at airport security

Why are there lines at airport security? I mean, we know why the lines form, when passenger load exceeds the capacity, with the bottleneck usually being the X-ray machines. The question is why this imbalance is allowed to happen?

The variable wait at airport security levies a high cost, because passengers must assume it will be long, just in case it is. That means every passenger gets there 15 or more minutes earlier than they would need to, even if there is no wait. Web sites listing wait times can help, but they can change quickly.

For these passengers, especially business passengers, their time is valuable, and almost surely a lot more costly than that of TSA screeners. If there are extra screeners, it costs more money to keep them idle when loads are low, but the passengers would be more than willing to pay that cost to get assuredly short airport lines.

(There are some alternatives, as Orwellian programs like Clear and TSA-PRE allow you to bypass the line if you will be fingerprinted and get a background check. But this should not be the answer.)

In some cases, the limit is the size of the screening area. After 9/11, screening got more intensive, and they needed more room for machines and more table space for people to prepare their bags for all the rules about shoes, laptops, liquids and anything in their pockets.

Here are some solutions:

Appointments at security

The TSA has considered this but it is not widely in use. Rather than a time of departure, what you care about is when you need to get to the airport. You want an appointment at security, so if you show up at that time, you get screened immediately and are on your way to the gate in time. Airlines or passengers could pay for appointments, though in theory they should be free and all should get them, with the premium passengers just paying for appointments that are closer to departure time.

Double-decker X-ray machines

There may not be enough floor space, but X-ray machines could be made double decker, with two conveyor belts. No hand luggage is allowed to be more than a foot high, though you need a little more headroom to arrange your things. Taller people could be asked to use the upper belt, though by lowering the lower belt a little you can get enough room for all and easy access to the upper belt for all but children and very short folks.

A double width deck is also possible, if people are able to reach over, or use the other side to load. (See below.)

This might be overkill, as I doubt the existing X-ray machines run at half their capacity. It is the screener’s deliberation that takes the time, and thus the next step is key…

Remote X-ray screeners

The X-ray screener’s job is to look at the X-ray image and flag suspect items. There is no need for them to be at the security station. There is no need for them to even be in the airport or the city, come to that. With redundant, reliable bandwidth, screeners could work in central screening stations, and be sent virtually to whatever security station has the highest load.

Each airport would have some local screeners, though they could work in a central facility so they can virtually move from station to station as needed, and even go there physically in the event of some major equipment failure. They would be enough to handle the airport’s base-load, but peak loads would call in screeners from other locations in the city, state or country.

Using truly remote screeners creates a risk that a network outage could greatly slow processing. This would mean delayed flights until text messages can go out to all passengers to expect longer lines and temporary workers can come in — or the outage can be repaired. To avoid this, you want reliable, redundant bandwidth, multiple screener centers and the ability to even use LTE cell phones as a backup. And, perhaps, an ability to quickly move screeners from airport to airport to handle downtimes at a particular airport. (Fortunately, there happens to be a handy technology for moving people from airport to airport!)

Screeners need not be working a specific line. Screeners could be allocated by item. Ie. one bag is looked at by screener 12 and the next bag is looked at by screener 24, just giving each item or set of items to the next available screener, which means an X-ray could actually constantly run at full speed if there are available staff. Each screener would, if they saw an issue, get to look at the other bags of the same passenger, and any bag flagged as suspect could immediately be presented to one or more other screeners for re-evaluation. In addition, as capacity is available, a random subset of bags could be looked at by 2 or more screeners.

It can also make sense to just skip having a human look at some bags at random to reduce wait and cost. It might even make sense to let some bags go unviewed in order to have other bags be viewed by 2 screeners. Software triage of how many screeners should look at a bag (0, 1, 2, etc.) is also possible though random might be better because attackers might figure out how to fool the software. With the screeners being remote and the belts operating at a fixed speed, passengers won’t learn who was randomly selected for inspection or not.

Some screeners need to be there — the one who swabs your bag, or does an extra search on it, the one who does the overly-intimate patdown and the one with the gun who tries to stop you if you try to run. But the ones who just give advice can be remote, and the one who inspects your boarding pass can be remote for passengers able to hold those things up to the scanners. I suspect remote inspection of ID is also possible though I can see people resisting that. The scanner who looks at your nude photo can certainly be remote — currently they are out of view so you don’t feel as bothered.

This remote approach, instead of costing more, might actually save money, especially on the national level. That’s because the different time zones have different peak times, and remote workers can quickly move to follow the traffic loads.

It’s also easier with remote screeners for passengers to use both sides of the belt to load and get their stuff. Agents would have to go in among them to pull bags for special inspection, though.

Of course it could be even better

Don’t misunderstand — the whole system should be scrapped and replaced with something that is more flyer-friendly as well as more capable of catching actual hijacker techniques. But if it’s going to exist, it should be possible to remove the line for everybody, not just those who go through background checks and fingerprinting just to travel.

After 2001, a company developed bomb proof luggage containers and now there is a new bag approach which would reduce the need to x-ray and delay checked luggage as much as they do. They were never widely deployed, because they cost more and weigh more.

I have 3 things I carry on planes:

  1. The things I need on the plane (like my computer, books and other items.)
  2. The vital and fragile things which I insist not leave my control, such as my camera gear and medicines.
  3. When I am not checking a bag, everything else for short trips.

I’m open to having all but #1 being put into a bomb-proof container by me and removed by me in a manner similar to gate check, so I can assure it’s always on the plane with me. Of course if I’m to do that then security (for just me and the items of type one) must be close to the plane — which it is for many international flights to the USA. That would speed up that security a lot. The use of remote screeners could make it easier to have security at the gate, too.

Personally, once the problem of taking over the cockpit was solved by new cockpit doors and access policies, I think there was an argument that you need not screen passengers at all. Sure, they could bring on guns, but would be no longer able to hijack the aircraft, so it’s no different from a bus or a train. Kept to small items, they would not be able to cause as much damage as they could do with a suitcase sized bomb in the security line. The security line is, by definition, unsecured, and anybody can bring a large uninspected roll-aboard up to it, amidst a very large crowd — similar to what happened in Moscow in 2011.

Instead, you would have gates where a portal in the wall would have a bomb-proof luggage container into which you could put your personal bags and coats. Most people would then just get on, but a random sampling would be directed to extra security. Those wishing to bring larger things on-board (medical gear, super-fragiles, mega-laptops) would need to arrive earlier and go through security too. A forklift would quickly move the bombproof container into the hold and the plane would take off.

Making sea crashes easier to find

We’ve all learned a lot about what can and can’t be done from the tragic story of MH 370, as well as the Air France flight lost over the Atlantic. Of course, nobody expected the real transponders to be disconnected or fail, and so it may be silly to speculate about how to avoid this situation when there already is supposed to be a system that stops aircraft from getting lost. Even so, here are some things to consider:

In the next few years, Iridium plans to launch a new generation of satellites with 1 megabit of bandwidth, replacing the pitiful 2400 bps they have now. In addition, with luck, Google Loon may get launched and do even more. With that much bandwidth, you can augment the “black box” with a live stream of the most important data. In particular, you would want a box to transmit as much as it could in the event of catastrophic shock, loss of signal from the aircraft and any unplanned descent, including of course getting close to the ground away from the target airport set at takeoff. Even the high cost of Iridium is no barrier for rare use, and you actually have a lot of seconds in the case of planes lost while flying at high altitude. Not enough to send much cockpit voice, but the ability to send all major alerts, odd-readings and cockpit inputs.

You could send more to geosync satellites but I will assume in a crisis it’s hard to keep aimed.

Another place you could stream live data would be to other aircraft. Turns out that up high as they are, aircraft are often able to transmit to other aircraft line of sight. Yes, the deep south Indian ocean may not be one of those places, but in general the range would be 500 miles, and longer if you used any wavelength that could travel beyond the horizon. Out there over the ocean, there’s nobody to interfere with, and closer to land, you can talk to the land. Near land, the live stream would go to terrestrial receivers, even cell towers. Live data gives you information even if the black box is destroyed or lost. If you are sure that can never happen, the black box is enough.

It also could make sense to have the black box be on the outside of the aircraft, meant to break away on impact with ground or water, and of course, it should float. The Emergency Locator Transmitter should be set up this way as well. You want another box pinging that sinks with the plane, though. The floating ELT/black box could even eject itself from the plane on its own if it detected an imminent crash in any remote area, including the ocean. With a GPS, it will know its altitude and location. It could even have a parachute on it.

Speaking of pinging, one issue right now is the boxes only have power for 2 weeks. Obviously there is a limit on power, and you want a strong signal, but it is possible to slow down your ping rate as your battery gets low, to the point that you are perhaps only pinging a few times a day. The trick is you would ping at very specific and predictable times, so people would know precisely when to listen — even years later if they get a new idea about where to look. Computers can go to sleep on these sorts of batteries and last for years if they only have to use power once a day.

If all you want to know is where an aircraft is, we’ve seen from this that it doesn’t take too much. A slightly more frequent accurately timed ping of any kind picked up by 2 satellites (LEO or geosync) is enough to get a pretty good idea where a plane is. The cheapest and simplest solution might be a radio that can’t be disabled that does this basic ping either all the time, or any time it doesn’t get the signal that others systems like ACARS are not doing their job.

Like many, I was surprised that the cell phones on board the aircraft that were left on — and every flight has many phones left on — didn’t help at all. Aircraft fly too high for most cell phones to actually associate with cell towers on the ground, so you would not see any connections made, but it seems likely that as the plane returned over inhabited areas on its way south, some of those phones probably transmitted something to those ground stations, something the ground stations ignored because they could not complete the handshake. If those stations kept lower level logs, there might be information there, but they probably don’t keep them. Because metal plane skins block signals, they might have been very weak. If the passengers were conscious, they probably would have been trying to hold their phones near the window, even though they could not connect at their altitude.

Another thing I have not understood is why we have only seen the results of one ping detected by the Inmarsat over the Indian. From that ping, they were able to calculate the distance of the aircraft to the satellite, and thus draw that giant arc we’ve all seen on the maps. It’s not clear to me why there was only one ping. Another ping would have drawn another arc, and so on, but that would have given us much more data to narrow down the course of the aircraft, as it’s a fair presumption it was flying straight. The reason they know know the one ping came from the southern hemisphere is the satellite itself is not perfectly centered and so moves up and down, giving a different doppler for north vs. south.

We may not learn their fate. I must admit, I’m probably an unusual passenger. I am an astronomer, and so will notice if a plane has made such a big course correction, though I have to admit in the southern hemisphere I would get confused. But then I would pull out my phone and ask its GPS where we are. I do this all the time, and I often notice when the aircraft I am in does something odd like divert or circle. But I guess there are not so many people of this stripe on a typical plane. (Though I have flown in and out of KL on Malaysian Airlines myself, but long ago.)

While hope for the people aboard is gone, I do hope we learn the cause of the tragedy, to see if anything we can think that is not too expensive would prevent it from happening again. The cost need not be that low. The cost of this search and the Air France search both added up to a lot.

Update: A New Idea — as soon as the search zone is identified, a search aircraft should drop small floating devices with small radio transmitters good to find them again at modest range. Drop them as densely as you can, which might mean every 10 miles or every 100 miles but try to get coverage on the area.

Then, if you find debris from the plane, do a radio hunt for the nearest such beacon. When you find it, or others, you can note their serial number, know where they were dropped, and thus get an idea of where the debris might have come from. Make them fancier, broadcasting their GPS location or remembering it for a dump when re-collected, and you could build a model of motion on the surface of the sea, and thus have a clue of how to track debris back to the crash site. In this case, it would have been a long time before the search zone was located, but in other cases it will be known sooner.

The world goes gaga for cool concept prototypes

One sign of how interest is building is the large reaction to some recent concept prototypes for robocars, two of which were shown in physical form at the Geneva auto show.

The most attention came to the Swiss auto research company Ringspeed’s XchangE concept which they based on a Tesla. They including a steering wheel which could move from side to side (and more to the point, go to the middle, where it could be out of the way of the two front seats,) along with seats that could recline to sleeping positions or for watching a big-screen TV, and which could reverse for face-to-face seating.

Also attracting attention was the Link and Go, an electric shuttle. In this article it is shown on the floor with the face to face configuration.

This followed on buzz late last year over the announcement of Zoox and their Boz concept, which features a car that has no steering wheel, and is symmetrical front to back (so of course seating is face to face.) The Zoox model takes this down to the low level, with 4 independent wheel motors. I’ve met a few times with Zoox’s leader, Tim Kentley-Klay of Melbourne, and the graphics skills of he and his team, along with some dynamic vision, also generated great buzz.

All this buzz came even though none of these companies had anything to say about the self-driving technology itself, which remains 99% of the problem. And there have been a number of designers who have put out graphic concepts like these for many years, and many writers (your unhumble blogger included) who have written about them for years.

The Zoox design is fairly radical — a vehicle with no windshield and no steering wheel — it can never be manually driven and a full robocar. Depending on future technologies like cheap carbon fibre and cost-effective 3-D printing for medium volumes, it’s a more expensive vehicle that you could make, but there may be a certain logic to that. Tesla has shown us that there are many people who will happily pay a lot more to get a car that is unlike any other, and clearly the best. They will pay more than can be rationally justified.

Speaking of Tesla, a lot of the excitement around the Rinspeed concept was that it was based on a Tesla. That appears to have been a wise choice for Rinspeed as people got more excited about it than any other concept I’ve seen. The image of people reclining, watching a movie, brought home an image that has been said many times in print but not shown physically to the world in the same way.

It’s easy for me (and perhaps for many readers of this blog) to feel that these concepts are so obvious that everybody just gets them, but it’s clearly not true. This revolution is going to take many people by surprise.

Commentary on California's robocar regulations workshop

Tuesday, the California DMV held a workshop on how they will write regulations for the operation of robocars in California. They already have done meetings on testing, but the real meat of things will be in the operation. It was in Sacramento, so I decided to just watch the video feed. (Sadly, remote participants got almost no opportunity to provide feedback to the workshop, so it looks like it’s 5 hours of driving if you want to really be heard, at least in this context.)

The event was led by Brian Soublet, assistant chief counsel, and next to him was Bernard Soriano, the deputy director. I think Mr. Soublet did a very good job of understanding many of the issues and leading the discussion. I am also impressed at the efforts Mr. Soriano has made to engage the online community to participate. Because Sacramento is a trek for most interested parties, it means the room will be dominated by those paid to go, and online engagement is a good way to broaden the input received.

As I wrote in my article on advice to governments I believe the best course is to have a light hand today while the technology is still in flux. While it isn’t easy to write regulations, it’s harder to undo them. There are many problems to be solved, but we really should see first whether the engineers who are working day-in and day-out to solve them can do that job before asking policymakers to force a solution. It’s not the role of the government to forbid theoretical risks in advance, but rather to correct demonstrated harms and demonstrated unacceptable risks once it’s clear they can’t be solved on the ground.

With that in mind, here’s some commentary on matters that came up during the session.

How do the police pull over a car?

Well, the law already requires that vehicles pull over when told to by police, as well as pull to the right when any emergency vehicle is passing. With no further action, all car developers will work out ways to notice this — microphones which know the sound of the sirens, cameras which can see the flashing lights.

Developers might ask for a way to make this problem easier. Perhaps a special sound the police car could make (by holding a smartphone up to their PA microphone for example.) Perhaps the police just reading the licence plate to dispatch and dispatch using an interface provided by the car vendor. Perhaps a radio protocol that can be loaded into an officer’s phone. Or something else — this is not yet the time to solve it.

It should be noted that this should be an extremely unlikely event. The officer is not going to pull over the car to have a chat. Rather, they would only want the car to stop because it is driving in an unsafe manner and putting people at risk. This is not impossible, but teams will work so hard on testing their cars that the probability that a police officer would be the first to discover a bug which makes the car drive illegally is very, very low. In fact, not to diminish the police or represent the developers as perfect, but the odds are much greater that the officer is in error. Still, the ability should be there.  read more »

Syndicate content