>> "Can you draw a parallel between a pilot flying an airplane on autopilot and a driver in a self-driving car?"
Considering that you can have a maximum of say 8 passengers, I do not see the reason why we need people in these self-driving cars. If the thesis is to drive someone to the mall, when people are seated, why not make one of the people have a driving license. But if the idea is to send the car to pick things in the mall without people in it, then it makes a lot of sense. While you can be in a car and be reading expecting it to drive itself, it does not offer a lot of productivity when compared to airplanes.
I think the point of V2I communication is manifold. Beyond reporting speeds, it should enable hazard warning, accident reporting, approaching emergency vehicle warning and even traffic lights violation warning.
You want V2I to work so that any info picked up by cars on the road will be automatically reported to the infrastructure, and as a result, that information is shared with other cars.
V2I is there essentially to give you look-ahead info your cars can't see (even if your cars are loaded with sensors. And for this V2I communication to work, you need standardized way of communication -- and ideally, every car on the road has the ability to speak that language.
It would be interesting to understand what the Google car algorithms would do if it prompted for the driver to take control and he/she did not?
Exactly. That's the crux of the issue. And that's the question Mr. Safety at Google did not want to give direct answer. His response was, as I wrote in the story, that we simply don't know how drivers react to such situation. Therefore, we don't know how a self-driving car should respond to that.
Wireless links are an inherent risk presently because virtually all these links use low power processors such as the ARM 7 which lack an MMU and other security features to make them immune to hacking -- Even if processors use an MMU like the intel i7 series then every bit of code in the wireless link must be written to use the MMU (built into all the applications and the RTOS/OS) -- Hardware based security is even more complex and design intensive to implement, however given the huge numbers of these chips sold each year a secure design would be a winner in the market.
@Tiger Joe. The government own the roads/freeways today and it's not a huge problem.
I meant to convey that the government were responsible (since I'd suggest they should own the automation computer control and sensor infrastructure for autonomous driving) for stopping a vehicle before it leaves the controlled road section if a driver does not respond to the prompt to take back manual control.
It would be interesting to understand what the Google car algorithms would do if it prompted for the driver to take control and he/she did not? Since it does not prompt the driver until after some event that triggered the need to change status, and one assumes that the changeover time would be several seconds at least, then at 60mph it would seem unworkable.
..is the prompt because a sensor failed? ...or is it outside it's range of response capability? ..Would it simply stop? ..or slow down? ..how suddenly? ..would it try to clear the traffic lanes to stop?
I totally agree with you that implementation should begin with freeways and controlled road sections. This reduces the the problem from it's current "boil the ocean size". If we can't make that work, then we are in trouble.
". If the infrastructure prompts the driver to take manual control again and they cannot; (asleep, drunk, ill, or simply inattentive) then the system moves the car off the highway and parks. This puts the onus on the government I know, but I think that is where the responsibility for control should rest."
That sends a strong message. There's no freaking way I'm going to hand over control of my vehicle to the government. Can you imagine, some 'incident' gets some bureaucrat to push a button, causing all traffic on the freeway to come to a standstill? We are stuck in gridlock until the situation is resolved. Given the two week shutdown we just got out of, I don't trust any quick resolution in the matter.
IMHO, the whole idea of self-driving vehicles is a 'walk before you run' problem. If we can't solve the problem to confine use on limited access highways only, forget it. By 'solve' I mean graduating it to common consumer acceptance. We would hand control of our car as soon as we get onto the freeway as readily as we do when stepping on a bus, train or plane. And we would get that control back in our hands, when taking the off-ramp.
And the problem of driving on city streets where reading signs, obstacles in traffic, lights and more, is intractible by comparison.
Whilst actually driving, many drivers today seem willing to make telephone calls, send or receive texts, put on make-up and so on.
With self driving cars, they'll be finishing that report, having a meeting over a video link, having breakfast, or maybe a motor-home driver in the toilet. It'll happen (well, I guess the latter might not if it causes the vehicle to pull off the road because the driver has 'vanished').
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.