Okay, Barry, I guess it'sd because I thought I had covered all the points when I said that V2I doesn't have to be limited to RF. So here goes, your points about why you don't need V2I:
1. "Precise 3D maps." That's a form of V2I, although often too stale to be of any tactical use. The car can't get these maps with just internal sensors. A human creates those, and this is clearly infrastructure-related information sent to the vehicle one way or another.
2. "Stop lights." Reading stop lights optically is a form of V2I. The stop lights are human-generated information provided by the infrastructure.
3. "Read road signs." Same thing as stop lights. It's V2I. Whether those signs are permanent or temporary, they are infrastructure-related information that someone outside the car has to create and transfer to the vehicle.
4. "Maps updated quickly." That too is V2I. The infrastructure has to provide those maps, and btw, realistically, they have to be transferred via some RF link. How else would these real-time maps be made available?
Then you list examples where a car's own sensors can't handle the situation at this time, which we can more or less agree on. Although weather consitions should fall among those that a car's own sensors should be able to manage eventually, since after all, human drivers have to do that autonomously now. (E.g., cars can measure outside temp and humidity, and optically scan the road ahead, which will give a darned good indication of the risk of black ice, for instance.)
You did reply to my comment about the speed limit signs, and I appreciate it, but you listed many things that you said made v2x necessary, to which I offered ways that self-driving cars might handle them without it, and I was hoping for your comments on all of them; instead you offered more. Whack-a-Mole's not much fun.
If even one of them prevents self-driving cars from operating safely, well, then v2i is necessary, and that would be a shame, because self-driving vehicles would take a lot longer to arrive and would cost a lot more. So I tried to respond to all of your points and wanted to know what you thought.
Regarding the simple exercise: all street signs are standard images that the car can store and match with the image it sees. That image can be associated in the car's database with whatever information you think a car should receive via a v2i system.
While the principles behind auto pilot in flying an airplane is based on "taking human decisions out of the equation," I think it will take a long time for drivers to get used to that "auto pilot" concept.
We would all like to belive that human beings are fully capable of making sound decisions at the moment's notice --- but let's face it, that's not always the case in many accidents we see on the road.
But at the same time, what's yet not clear to many of today's drivers like ourselves is how cars of the future could consistently make better decisions than what we do while driving.
Not sure where that came from, Barry, since I was agreeing with the post where you mentioned electronically reading the speed limit signs.
My disagreement with you, and with the title of the article, was the implied notion that self driving cars don't need V2I comms. Just because some regulators aren't coincentrating on V2I at the moment, or because the existing Google car doesn't use much V2I (it does use some, even if the information is potentially stale).
Electronically scanning road signs or pavement markings constitutes V2I. Perhaps you missed where I suggested that these V2I and V2V comms may not be RF-based at all.
1) LTE is just an air interface, so if they are deciding to run LTE car-to-car, that may be great. But, I for one will not pay the extortionate fee the carriers want just to get LTE data for my car. I have grandfathered unlimited data on the smartphone, but I can't see people with these ridiculously low data caps the carriers favor these days wanting their car using up all their data either.
2) Privacy implications (not LTE speciifc but a problem with anything beyond communications with surrounding vehicles). There should be something like key rotation on car restart or the like, to make sure there's enough info to determine when there's traffic jams and so on, but not enough to track a specific car as it moves around. The authorities have shown their willingness to perform illegal and unconstitutional actions on a continuing basis, violating privacy rights. Because of this these systems will be a hard sell unless anonymity is assured.
Just saying, this is a big technical problem, but a working technical solution will still not be accepted if it doesn't keep track of some practical matters.
p_g, when you say, "Also even one bad person can lead to accident, however there is always a smartmind behind wheel which can adapt to situation and reacts. In automation world we will be under controll of machines and they are not adaptive and smart enough," is ther not perhaps an implied "yet" in there?
I've worked on or with automatic control systems for most of my career. It seems to me that the trend, for a very long time, has been that the more sophisticated a system becomes, the more the human operator MUST be taken out of the loop. It's usually a case where progress becomes impossible until some existing key human operator function is replaced with automation. Reason being, algorithms running on computers can be faster, more consistent, more precise, and more predictable, than that "smart" human.
Driving a car is a complex task, so althopugh a large number of manual controls have already been automated, the basic throttle, steering, and brakes are *mostly* still under human control. But even there, hard to deny that the trends to automation are obvious.
"As you mention, the Google car stores speed limits, but it can handle stop lights. It doesn't seem hard to me to teach it to read speed limit signs."
We are in violent agreement! As I suggested previously, a better questionm to ask might be, will, or should, V2I and V2V comms be assumed to be RF only, or might they not be optical? If optical, then in principle, the EXISTING solutions, i.e. road signs and markings on the pavement, traffic lights, and the existing lighting and signaling schemes in other cars, could be drectly adapted for self-driving V2I and V2V comms. Just as a human determines the intentions of other drivers by the lighting cues, so can an algorithm in the slef-driving car.
The police can alreadu scan license plates electrnically. Surely, similar tech can be adopted to read all manner of road signs.
Here's a simple exercise. Take one of those manuals that teaches the meaning of road signs and markings. Then run through each one and ask how a self-driving vehicle would get that same info, or conversely, why a self driving vehicle would not need that information. For example, a self-driving vehicle may not need a "deer crossing" warning sign, presumably because it's radar and lidar are always alert. But a self driving vehicle would need lane merging indications, speed limits, traffic lights, lane markers, road edge markers, bridge height limita info, and a whole slew of other info.
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.