3 ms·
Subtracting your own velocity from what? I've been talking about individual sensor reporting with conflicting information and the complexity of decision making
by mdorazio 9y ago
Subtracting your own velocity from what? I've been talking about individual sensor reporting with conflicting information and the complexity of decision making that results. 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. Reference frame and velocity relative to the ground is up to your software algorithms to determine, not the sensors, and I've been trying to explain why that's non-trivial and "stationary" is always relative to something. You seem to be treating the entire system as an always-in-consensus whole, which it isn't.
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.
- Dylan16807 9y ago> Subtracting your own velocity from what? 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.
- mdorazio 9y agoMaybe I'm not being clear on my core argument. sensors give conflicting information in different scenarios. One sensor might read an obstacle to be avoided while another shows a clear path. Deciding what to do in these conflict situations is difficult. Saying it's easy is effectively saying that the hundreds of very intelligent engineers working on these systems are idiots because it looks like it should be a piece of cake. You're using similar logic to non-technical people who get angry when a developer can't give an accurate estimate of time needed to implement a new feature - (s)he has the code and requirements right there, it should be easy, right? 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.
- Dylan16807 9y ago> Saying it's easy is effectively saying that the hundreds of very intelligent engineers working on these systems are idiots because it looks like it should be a piece of cake. 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!