Well, it also apparently can't detect stationary semi trailers or fire trucks. So expecting it to detect a little gore point is iffy.
But why can't it?
But why can't it?
If you think about a sharp left turn with a wall on the right side of the road, there is a "stationary object" (the wall) in front of the vehicle throughout the turn that will be detected by radar and cameras. In order to navigate a situation like this, an autonomous vehicle has to have additional decision-making in place to effectively override "stationary object in front of me = stop" logic. But once you do that, it gets tricky to determine when you should ignore the "stationary object" and when you shouldn't.
On top of this, Tesla opted not to include LIDAR as a sensor in its vehicles, so it does not get a 3D point cloud to help identify what an object is and what to do with it. Instead, there's a high reliance on the cameras and radar, but these have some limitations. For example, it's difficult for a camera to distinguish between two objects of similar brightness and color, so for example if there's a white semi-trailer in front of a white wall 100ft away, the camera might not "see" the trailer. This can create situations where sensors are reporting conflicting data, which is bad - for example in the trailer situation, the camera would be saying "there's nothing in front of me until a wall 100ft away", but the radar would be saying "no there's something right in front of me". Or the radar might not "see" an obstacle that is a few feet off the ground while the camera is saying "there's something in front of me". Resolving these conflicts is hard.
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.
> 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!
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.
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.
On Teslas theoretically the camera is there to prevent stuff like this but vision AI isn't all there yet.
Other companies use lidar which gives pretty accurate distance and direction but not object speed. Pretty useful for avoiding obstacles but current automotive grade lidars are very expensive. Much cheaper solid state lidars seem to be imminent.
The hardware that may be actually required to make this work well may still cost tens of thousands of dollars, which means car makers will avoid using it and will use cheaper options like cameras and radar.
While on the software side, we may be 80% of the road there, but the other 20% and solving every single edge case out of potentially millions will take another decade or more.
And that's without even mentioning software bugs that could make the whole system crash. I think someone mentioned recently that there are on average 15 bugs every 1,000 lines or code or something. Either way, we should expect a lot of bugs to be in this software. Remember Toyota's "spaghetti code"? And now we're just going to assume that Toyota's self-driving cars are going to drive us safely within 3 years?
And of course nobody wants to talk about how these cars will be hacked remotely.