That's not tricky. You never ignore it. A stationary object means that you will have to either stop or turn. You don't know which one yet, but you definitely know you'll have to take an action. If you haven't decided by some close point, you just pick one.
There's no reason to ever ignore it.
Combine that with the normal event of a garage wall or building directly in front of you while parking and we have three different "stationary object in front" situations that all have to be handled differently. In all three, the radar and camera are saying "stationary object ahead". But in the left-turn-with-wall situation you need to turn instead of stop. In the following-another-car situation you do nothing, and in the parking situation you need to stop instead of turn. And that's all without even starting to account for things like rain (opaque to some LIDAR and cameras = "we're literally crashing right now!" while radar reports nothing amiss). In order to decide what to do you have to pull in additional environment information, but then that's going to have similar caveats and conflicting reports to account for, so you need additional rules and information, etc. and now you've snowballed into a highly complex model with corner cases and potential bugs everywhere.
If it was easy we would have had self-driving cars a decade ago.
Vehicles in front moving at the same speed aren't stationary in the external reference frame. They're stationary in the vehicle's reference frame. If one stops, though, it becomes stationary in the external reference frame, and has closing velocity in the vehicle's reference frame.
Sorry to be pedantic.
> Combine that with the normal event of a garage wall or building directly in front of you while parking and we have three different "stationary object in front" situations that all have to be handled differently. In all three, the radar and camera are saying "stationary object ahead". But in the left-turn-with-wall situation you need to turn instead of stop. In the following-another-car situation you do nothing, and in the parking situation you need to stop instead of turn.
If the object is stationary, you turn-or-stop. If it's another car, it's really easy to measure that it's not stationary. If your sensors can't figure out the distance or velocity for multiple seconds in a row, your equipment should not be allowed to drive.
> highly complex model with corner cases and potential bugs everywhere
That's all in object detection, though. And none of that noise looks at all like a solid object at a specific location.
> If it was easy we would have had self-driving cars a decade ago.
I disagree. Even if you have a system that competently avoids stationary-object collisions, you're nowhere near a full self-driving car.
And while the overall problem of avoiding collisions has hard parts, none of the hard parts are in the "What do we do about a stationary object?" logic.
I feel like we're just going in circles here. I could keep giving you examples of cases where sensors will report conflicting information that makes decisions like turn or stop difficult or false-positive prone, and you'll keep insisting that it's just object recognition and you should always know to turn or stop. I'll stop here and stand by my original point - sensor limitations and immature algorithms are the reason for issues like the ones Autopilot has; completely preventing these issues is not straight forward.
You said the camera/radar would be reading another car as "stationary", which is a velocity number of zero. Add/subtract your speed and you get the real speed.
A non-defective sensor suite is going to give you either distance or velocity, and you can use distance measurements to calculate velocity really easily.
> A radar return from a rear bumper at relative zero miles an hour is exactly the same whether the car is actually in motion or not.
Doppler effect.
> "stationary" is always relative to something
Once you have a velocity number, no matter what it's relative to, it's trivial to convert it to any reference frame you want.
> I feel like we're just going in circles here. I could keep giving you examples of cases where sensors will report conflicting information
That's because such things are irrelevant to my argument. I'm only talking about how algorithms should handle objects that have already been found.
> I'll stop here and stand by my original point - sensor limitations and immature algorithms are the reason for issues like the ones Autopilot has; completely preventing these issues is not straight forward.
I fundamentally disagree that the navigation algorithms are difficult here. Sensor issues are huge, but your original scenario was based on the sensors working and navigation failing. That specific kind of navigation failure is utterly inexcusable. It is actually easy to force a car to either slow down or turn to avoid a known obstacle. That specific part should never ever ever fail. It doesn't matter how hard other parts are.
I'm quite familiar with how vector math works. Your comments above seem to still be missing that I am talking about situations from the perspective of individual sensors, which have no ability to make judgments about different frames of reference. That only applies at the level of the full driving system. For example, to a radar sensor alone, there is no difference between a car parked 10ft in front of you while you are motionless relative to the ground and a car 10ft in front of you while you are both moving at 60mph relative to the ground. Both are "stationary" as far as the return signature is concerned. There will be no doppler shift in either case. The driving system has to combine this with other sources of information for it to be useful, and that's where problems creep in.
> That's because such things are irrelevant to my argument. I'm only talking about how algorithms should handle objects that have already been found.
We're arguing two perspectives of the same higher-level opinion (algorithms are insufficiently developed to be safe enough for autonomous driving). What I'm trying to say is that there are a number of fuzzy steps to get from sensor readings to actual object detected, and then from actual object detected to "known obstacle" classification, as you put it. I don't think I'm going to be able to argue this case clearly enough in the comments here, so I'm going to add this to my longer article writing list. Thank you for the constructive debate on this.
Saying one very very specific thing is easy is not the same as calling engineers idiots. It's bad to conflate "the system is hard" with "every single piece of the system is hard"
> The driving system has to combine this with other sources of information for it to be useful, and that's where problems creep in.
There are many places where integrating information can let errors creep in.
The car adding its own ground velocity in is just... not one of them.
> What I'm trying to say is that there are a number of fuzzy steps to get from sensor readings to actual object detected, and then from actual object detected to "known obstacle" classification, as you put it.
Agreed. But while some steps are fuzzy, some are easy. The chain from start to finish is fragile and difficult. But some of the individual links are rock-solid.
> I'm going to add this to my longer article writing list. Thank you for the constructive debate on this.
I'm not sure if we really got anywhere productive here, but good luck!
Tesla seems to have figured that, It is better to kill some of your customers then pissing every single one of them off...
The dichotomy between ignore and stop is a false one.