There's just something about a machine controlling *my* car and not the others, or even portions of my car and not any others that's really squicky.
It may have something to do with that question I ask that usually makes would-be engineers very annoyed at me: What is it's most likely failure mode?
This is a no-win scenario. You desire to install a machine that has the ability to apply your car's brakes (not supplement, not augment, but to actually apply them) What happens if it suddenly fails to work? Is that failure mode now to *stop or slow down your vehicle* or to *NOT stop or slow down your vehicle*?
Common sense indicates that the driver should automatically override any autopiloting mechanism. This application is elegant enough that it would be necessary to install not just the ability for the driver to "play thru" whatever the CC is doing, but for the CC to actually *sense* what the driver is doing as well. What happens if the CC is doing something and fails to sense driver input? By the time you've gone and designed something whose ONLY default failure mode is to return complete manual control to the driver, you've added a whole lot of other pieces to the chain, ALL of which will have their own failure mode.
I have a suspicion that the driving that you describe is a whole order of magnitude more complex and chaotic than you're envisioning and that the amount of things you are not aware that you are doing has a very high "rude awakening" potential, especially when it comes to deciding what HAS to happen should your device fail to work, and what *could* happen if you fail to anticipate something. I have a sneaking suspicion that the engineering problems you'll need to solve involve a viewpoint that far transcends picturing the car only from the driver's POV.
I like having the option of complete control over my machine, but I'm comfortable with that being an option instead of the Only Way. Despite that preference, I somehow manage to drive a car with an automatic transmission (as long as I haven't just gotten out of a car with a stick shift) and fuel injection. And I've gotten used to inertial locking seat belts and am slowly coming around to the idea of air bags (though I still dislike the "attack belts" that I have to put up with). Each of those, along with conventional cruise control, involves surrendering some of my control. Even on a car with a carburator, when was the last time you saw a manual control for the choke?
Okay, so with the exception of conventional cruise control, none of those work the accelerator for me. And with the exception of ABS (which I don't think my car has), none touch the brake. So yeah, I get the (rather significant) difference. My point is that I'm already used to letting machines control parts of my car for me, so while the difference is meaningful, it is not absolute.
One design principle I'd argue for is: where feasible, allow the driver to override the automation. We have this completely in a conventional cruise control, in a very limited form in an automatic transmission, and not at all in an automatic choke. I very strongly agree with your statement that the system must allow the driver to "play thru", as you put it. I don't think that's an unsolvable problem, though it's a little more complicated than with conventional cruise control.
"that question I ask that usually makes would-be engineers very annoyed at me: What is it's most likely failure mode?"
And you've probably already noticed that real engineers don't get annoyed at that because they're trained to have already asked it. While I'm only in the would-be category myself, I do know enough that the moment I take an idea for something that controls my automobile past the "idle daydream" stage, paying close attention to failure modes becomes crucial.
"I have a sneaking suspicion that the engineering problems you'll need to solve involve a viewpoint that far transcends picturing the car only from the driver's POV."
Why should it, if I'm already capable of performing the same task manually with only the driver's POV? I can see how it might turn out to require greater (or different kinds of) intelligence than we're able to build into machines, but I don't see where a need for information not available from car-based sensors would come in.
>but I don't see where a need for information not available from car-based >sensors would come in.
That's because you're not realising the total complexity of the task that you are performing when you think you're *simply* following the car in front of you. You're operating as a portion of a VERY BIG PICTURE.
ORDERS OF MAGNITUDE more complex is what the engineers who HAD the money, HAD the tools, HAD the mandate, found and had to give up.
You're not just acting on the data from the car in front/back/sides etc. When you're in traffic, you're analysing (hopefully) data that's coming in from all directions and at a range and complexity that is going to completely dwarf what some motion/distance/light sensors will give you. Just in the visual light spectrum, along with noting positions, motions, etc, you're analysing data that is being communicated in several colors (tail lights, reverse lights(!), brake lights, turn signals, traffic lights, cop lights, tow truck lights, signage, on and on and on) and this IS data that you're using when you're simply following stop and go traffic. AND you're gathering it from WAY out front, from behind, and from the sides, and all at ranges that are beyond the immediate neighbor cars.
Then there's the data that you're gathering from the distance and apparent motions of cars, front, back, side, and AT A DISTANCE far beyond the neighboring cars. You're analysing trends, events, modifications to trends, histories, and comparing it all to HUGE databases of past history and cross indexing it all on what ever cartological and geographical data you possess. And YES YOU ARE DOING THIS IN STOP AND GO TRAFFIC, and YES IT DOES COME INTO PLAY- FOR EVERYONE.
And you may not realise it, but you're also observing the behaviour of the other drivers and trying to piece their behaviour into "profiles" that you then use to predict what they are likely to in certain circumstances, and do so that your response times to their behaviour can be decreased and that your responses to them are more, not less productive to your game goal. This requires a certain amount of empathy, and when that process breaks down via a particularly narcissistic or randomly influenced driver, then the whole supersystem begins to disintigrate real fast. And this is what I meant when I said that in order for a traffic autopilot (even for the brakes) to work effectively, you're eventually going to need data that transcends the POV of the individual driver. For better or for worse, drivers SYNTHESISE those other POVs on the fly in real time, and respond to them. The drivers who can better empathise with the other drivers and the drivers who can better communicate their needs and intentions at a distance are the drivers who fare better.
You're attempting to posit what is essentially an AI protocol to take over a task for you, and I'm warning you that the reason others could not succeed on time and within budget is NOT because they aren't eftychia, but because what looks to be a very straightforward task is actually orders of magnitude more complex than we ever imagined.
Welcome to AI research. Surprise! Get used to that phrase!
You've pointed out that the problem (actually, a somewhat different problem than the one we started off with) is much more complex than it appears at first glance, but you still haven't shown that it requires information not attainable from car-mounted sensors. In fact, my ability to safely and smoothly operate a car in traffic without listening to advice radioed from a spotter or looking at a display showing the view from other locations refutes your assertion that the task requires information not available from the driver's POV. (Not that the additional inputs couldn't be useful; just that they're not required.)
Furthermore, I'm not talking about an autopilot; I'm talking about an assist for an alert and attentive driver. This may not make the problem trivial, no, but it does make it a different size of problem than what the folks trying to design automated driving systems were trying to solve.
Penultimately, I didn't envision this for stop and go traffic (though I was not explicit about that); more for "too heavy to just set a speed and go, but moving well" situations.
And finally, please note that I labelled the entry "driving daydream" and said, "I'd like to have"; not "why isn't there...?" or "it should be trivial to design" or "I think I'll go build".
>In fact, my ability to safely and smoothly operate a car in traffic >without listening to advice radioed from a spotter or looking at a >display showing the view from other locations refutes your assertion that >the task requires information not available from the driver's POV.
I wouldn't claim a refutation touchdown just yet. There *is* the small matter of a five yard penalty for logical fallacy ("Extension", I believe).
My claim had nothing to do with needing "spotters" to drive. That is a rather nonsensical extension of what I actually said. I actually spoke of empathetic synthesis of these other drivers' future decisions performed at a distance on the part of the driver, based on behaviour and signals that they percieve at a distance. I claim and still claim that these mental simulations of other drivers are an essential part of traffic behaviour and the data that is gathered to generate these simulations is not only HUGE, but is beyond the range and scope of anything one can mount on a car today. FI: There are NOT sensors current that can analyse an entire LINE of cars ahead of you for patterns in the info being given to you by the brake lights. I'll bet that there are not sensors available that can correctly read traffic lights while a vehicle is in motion. And that's just a minute FRACTION of the data that one uses to drive, even in a "just follow everyone else" scenario. The amount of data one uses just for that is astonishingly complex, no matter how much you protest otherwise.
Tell you what tho, design for me a sensor and a program that can either:
- correctly collect and analyse brake light behaviour patterns - OR read a traffic light in daylight from an automobile in motion
at 1 kilometer ahead of you. Do that, and you can claim to refute me and I'll not only agree publickly that I've been refuted, but also perform the "Glenn Was Right" dance with wardrobe and music of YOUR choice!
In the meantime, I stand by my claim that this kind of assist, on the scale that you originally proposed proved to be impractical because the engineers involved had not anticipated how mind-bogglingly big and complex the data set they needed for implementation actually is.
You could also attempt a rather feeble cop-out and try to claim that this info is not needed for a safe and accurate driver assist. But that is going to be an even harder sell, because you'd have to convince me that YOU don't use this info in traffic to make or streamline your braking decisions.
(no subject)
There's just something about a machine controlling *my* car and not the others, or even portions of my car and not any others that's really squicky.
It may have something to do with that question I ask that usually makes would-be engineers very annoyed at me:
What is it's most likely failure mode?
This is a no-win scenario. You desire to install a machine that has the ability to apply your car's brakes (not supplement, not augment, but to actually apply them) What happens if it suddenly fails to work? Is that failure mode now to *stop or slow down your vehicle* or to *NOT stop or slow down your vehicle*?
Common sense indicates that the driver should automatically override any autopiloting mechanism. This application is elegant enough that it would be necessary to install not just the ability for the driver to "play thru" whatever the CC is doing, but for the CC to actually *sense* what the driver is doing as well. What happens if the CC is doing something and fails to sense driver input? By the time you've gone and designed something whose ONLY default failure mode is to return complete manual control to the driver, you've added a whole lot of other pieces to the chain, ALL of which will have their own failure mode.
I have a suspicion that the driving that you describe is a whole order of magnitude more complex and chaotic than you're envisioning and that the amount of things you are not aware that you are doing has a very high "rude awakening" potential, especially when it comes to deciding what HAS to happen should your device fail to work, and what *could* happen if you fail to anticipate something. I have a sneaking suspicion that the engineering problems you'll need to solve involve a viewpoint that far transcends picturing the car only from the driver's POV.
(no subject)
Okay, so with the exception of conventional cruise control, none of those work the accelerator for me. And with the exception of ABS (which I don't think my car has), none touch the brake. So yeah, I get the (rather significant) difference. My point is that I'm already used to letting machines control parts of my car for me, so while the difference is meaningful, it is not absolute.
One design principle I'd argue for is: where feasible, allow the driver to override the automation. We have this completely in a conventional cruise control, in a very limited form in an automatic transmission, and not at all in an automatic choke. I very strongly agree with your statement that the system must allow the driver to "play thru", as you put it. I don't think that's an unsolvable problem, though it's a little more complicated than with conventional cruise control.
"that question I ask that usually makes would-be engineers very annoyed at me: What is it's most likely failure mode?"
And you've probably already noticed that real engineers don't get annoyed at that because they're trained to have already asked it. While I'm only in the would-be category myself, I do know enough that the moment I take an idea for something that controls my automobile past the "idle daydream" stage, paying close attention to failure modes becomes crucial.
"I have a sneaking suspicion that the engineering problems you'll need to solve involve a viewpoint that far transcends picturing the car only from the driver's POV."
Why should it, if I'm already capable of performing the same task manually with only the driver's POV? I can see how it might turn out to require greater (or different kinds of) intelligence than we're able to build into machines, but I don't see where a need for information not available from car-based sensors would come in.
(no subject)
>sensors would come in.
That's because you're not realising the total complexity of the task that you are performing when you think you're *simply* following the car in front of you. You're operating as a portion of a VERY BIG PICTURE.
ORDERS OF MAGNITUDE more complex is what the engineers who HAD the money, HAD the tools, HAD the mandate, found and had to give up.
You're not just acting on the data from the car in front/back/sides etc.
When you're in traffic, you're analysing (hopefully) data that's coming in from all directions and at a range and complexity that is going to completely dwarf what some motion/distance/light sensors will give you. Just in the visual light spectrum, along with noting positions, motions, etc, you're analysing data that is being communicated in several colors (tail lights, reverse lights(!), brake lights, turn signals, traffic lights, cop lights, tow truck lights, signage, on and on and on) and this IS data that you're using when you're simply following stop and go traffic. AND you're gathering it from WAY out front, from behind, and from the sides, and all at ranges that are beyond the immediate neighbor cars.
Then there's the data that you're gathering from the distance and apparent motions of cars, front, back, side, and AT A DISTANCE far beyond the neighboring cars. You're analysing trends, events, modifications to trends, histories, and comparing it all to HUGE databases of past history and cross indexing it all on what ever cartological and geographical data you possess. And YES YOU ARE DOING THIS IN STOP AND GO TRAFFIC, and YES IT DOES COME INTO PLAY- FOR EVERYONE.
And you may not realise it, but you're also observing the behaviour of the other drivers and trying to piece their behaviour into "profiles" that you then use to predict what they are likely to in certain circumstances, and do so that your response times to their behaviour can be decreased and that your responses to them are more, not less productive to your game goal. This requires a certain amount of empathy, and when that process breaks down via a particularly narcissistic or randomly influenced driver, then the whole supersystem begins to disintigrate real fast. And this is what I meant when I said that in order for a traffic autopilot (even for the brakes) to work effectively, you're eventually going to need data that transcends the POV of the individual driver. For better or for worse, drivers SYNTHESISE those other POVs on the fly in real time, and respond to them. The drivers who can better empathise with the other drivers and the drivers who can better communicate their needs and intentions at a distance are the drivers who fare better.
You're attempting to posit what is essentially an AI protocol to take over a task for you, and I'm warning you that the reason others could not succeed on time and within budget is NOT because they aren't
Welcome to AI research. Surprise! Get used to that phrase!
(no subject)
Furthermore, I'm not talking about an autopilot; I'm talking about an assist for an alert and attentive driver. This may not make the problem trivial, no, but it does make it a different size of problem than what the folks trying to design automated driving systems were trying to solve.
Penultimately, I didn't envision this for stop and go traffic (though I was not explicit about that); more for "too heavy to just set a speed and go, but moving well" situations.
And finally, please note that I labelled the entry "driving daydream" and said, "I'd like to have"; not "why isn't there...?" or "it should be trivial to design" or "I think I'll go build".
(no subject)
>without listening to advice radioed from a spotter or looking at a
>display showing the view from other locations refutes your assertion that
>the task requires information not available from the driver's POV.
I wouldn't claim a refutation touchdown just yet. There *is* the small matter of a five yard penalty for logical fallacy ("Extension", I believe).
My claim had nothing to do with needing "spotters" to drive. That is a rather nonsensical extension of what I actually said. I actually spoke of empathetic synthesis of these other drivers' future decisions performed at a distance on the part of the driver, based on behaviour and signals that they percieve at a distance.
I claim and still claim that these mental simulations of other drivers are an essential part of traffic behaviour and the data that is gathered to generate these simulations is not only HUGE, but is beyond the range and scope of anything one can mount on a car today.
FI: There are NOT sensors current that can analyse an entire LINE of cars ahead of you for patterns in the info being given to you by the brake lights. I'll bet that there are not sensors available that can correctly read traffic lights while a vehicle is in motion. And that's just a minute FRACTION of the data that one uses to drive, even in a "just follow everyone else" scenario. The amount of data one uses just for that is astonishingly complex, no matter how much you protest otherwise.
Tell you what tho, design for me a sensor and a program that can either:
- correctly collect and analyse brake light behaviour patterns
- OR read a traffic light in daylight from an automobile in motion
at 1 kilometer ahead of you. Do that, and you can claim to refute me and I'll not only agree publickly that I've been refuted, but also perform the "Glenn Was Right" dance with wardrobe and music of YOUR choice!
In the meantime, I stand by my claim that this kind of assist, on the scale that you originally proposed proved to be impractical because the engineers involved had not anticipated how mind-bogglingly big and complex the data set they needed for implementation actually is.
You could also attempt a rather feeble cop-out and try to claim that this info is not needed for a safe and accurate driver assist. But that is going to be an even harder sell, because you'd have to convince me that YOU don't use this info in traffic to make or streamline your braking decisions.