While the traditional, "open road" cruise control continues to be useful, long drives this past weekend got me thinking about how much I'd like to have an "in traffic" cruise control.
That is, in addition to "maintain this speed", which is only useful if there's either nobody in front of you or there's plenty of room for smooth lane changes as needed to avoid crawling up someone else's tailpipe, I'd like to be able to tell the car, "maintain a following distance of [minimum safe distance + user-specified comfort buffer] seconds from whatever's in front of me".
Such a cruise control would probably need to be linked to the brakes, not just the throttle, and even with the ability to brake it might be good to have a warning tone sound when the car in front decelerates at an unusual rate. (And just as with traditional cruise control, the idea would be simply to make driving a wee bit easier, not to lull the driver into no longer Paying Attention, since what I'm describing is still short of an autopilot.) Additional tweaks to the algorithm would include setting a maximum speed, which would double as the speed setting for reverting to traditional cruise control when there's no vehicle in sensor range, and detecting lane changes (as momentary override plus acquisition of a new sensor target).
This is the front-bumper parallel to what I've wanted on the back of my car for a while now: a rangefinder coupled to my spedometer which would light up a "You Are Too Close" sign whenever someone tailgates me.
(no subject)
(no subject)
OTOH, it means someone else is doing the engineering for me.
(no subject)
(no subject)
(no subject)
(no subject)
On moderate hills I like the fact that the cruise control keeps my speed steady. It's only on larger/steeper ones that I start wishing it'd start playing with gravity instead of against it, but at that point I'm usually in WV on hills so steep that the cruise control gives up and switches itself off going uphill. (OTOH, if it allowed gravity to speed it up on the downslopes, it might make it a bit farther along the upslopes.) Of course, it also depends on the reason I've turned on cruise control. Sometimes it's because I've got a hunch a speed trap is coming, and specifically don't want it to speed up on the downslopes.
It'd be interesting to have a cruise control that a) wasn't just a really basic feedback loop with a whole bunch of "turn yourself off" conditions, and b) exposed enough of its programming that I could tinker with the algorithms. I could burn a lot of time (and gasoline) playing with that.
(no subject)
(no subject)
(no subject)
The test drivers hated it because it was not beeping but actually braking. This made for a car the kept slowing down based on sensing braking on the part of the car in front of it. There was no corresponding mechanism to speed back up, only a setting to maintain X distance from the car in front.
Eventually, the car was dropping below 25 mph based on sensing the slowing on the car ahead and being set to maintain a minimum distance. The description also sounded like a jerkier ride than I'd find comfortable.
(no subject)
It was to do with something akin to shock-waves travelling through the traffic when something slowed down ahead, and IIRC this turned out to be the cause of many pile-ups and areas of congestion and so on.
I'm not a driver (why am I reading this entry in fact? :D ), so there's probably others who know and can explain this thing a lot better than I, but I still found it pretty interesting so it stuck in my mind somewhat.
(no subject)
Another interesting bit from the article is that density waves travel backward and forward from an incident. I've recognized this once I learned to look for it; people think they're out of the woods and try to speed up to cruising speed, but things haven't quite cleared out enough, so it jams up again. It can be pretty mysterious if you get onto the road after the incident, though; you keep hitting slowdowns, but never pass anything that has caused them.
(no subject)
*chuckle* You might, I don't listen to 'em ;) (see "not a driver" disclaimer above)
*blink* Now that seems rather surprising! I wish you'd kept a copy even more now! :D
(no subject)
(no subject)
(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.
(no subject)
(no subject)
The benefit, at least the way I use it, is not that one can continue driving when tired, but that one can drive longer before becoming tired. And I agree that it's important never to become uninvolved in the act of driving -- I'm still paying attention to my speed, as well as everything else; I'm just relieved of the burden of constantly tweaking it until I observe a situation that requires my intervention.
As for the grocery bag scenario, I'd want to do a whole lot of testing on any design+algorithm I came up with, to be sure problems like that had been solved, and it'd still have to have instant manual override the moment the driver touched a control.
(no subject)
(no subject)
Was that one of the systems that required the roadway itself to be "smart" as well? I know someone tested a design that was entirely car-contained and autonomous, but I think that was more recent and only prototyped in a single vehicle.
(no subject)