Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm pretty sure that they "fixed" the dancing cars problem by applying a low pass filter to the data before sending it to the visualization, just so people would stop complaining about it. I think there's still a lot of jitter in the underlying data.


Seems like it would make more sense to model the inertia. Cars don't randomly accelerate at 100,000m/s/s in some direction they aren't pointed. Though they should have a model for detecting obstacles in the view regardless of inertia, because sometimes something really does appear in front of you in a thirteenth of a second.

You could probably model inertia with n prior frames of probability fields.


> Cars don't randomly accelerate at 100,000m/s/s in some direction they aren't pointed

What if they are hit by a truck? Maybe not 100,000 m/s^2 but if you assume that cars can't accelerate in directions they aren't pointed, you will be wrong at the worst possible time.


That's why I elaborate, and why I chose that number. The only way something actually accelerates like that is an error, or it's an error.


A threshold that high will be useless as it will miss most errors. A threshold low enough to catch most errors will reject some valid data. A naive approach like that will not work.

A better approach would be to include temporal data in the inputs to the neural net so it can learn how to do the prediction and filtering itself using all the context available in the input imagery, instead of processing each frame completely independently and feeding low-dimensional symbolic results into some other system. But you'd need a very large dataset and a very large neural net.


Would you not be implicitly assuming that the prior position was more accurate than the current one? If you have a sequence of consistent prior positions, then perhaps something like a Kalman filter would be appropriate, but I would guess that with something suddenly being revealed by a change in either party's position or that of a third party, you don't always have that.


Modelling inertia seems like a special case of a low pass filter? A very useful and physically plausible special case, of course.


That's a good fix, but they should apply the filter to the data used in the driving logic also.


If the filter adds significant latency that could go poorly


To elaborate, the filter also may not improve the accuracy, just the perceived accuracy.

To be correct but one second late is to be completely inaccurate. The system is trying to estimate the current position of the car, but also predict future positions.

So a little bit of imprecision is fine since it improves accuracy related to predicting the future positions of the cars. A slight move in one direction may indicate a lane change, so it is always useful to be aware of that so as not to accelerate past a car whose measurement appears to be more inaccurate, since they actually might be moving. If you did the same thing with a human's "sixth sense" perception of the positions of the cars, you'd definitely find that they move a lot compared to their actual positions when the head is turned since our ability to merge our vision and our inertial sense is not very good for the most part.

The same issues arises with AR/VR, it's useless to know a more accurate position of the user if it's not the present position, because then that will definitely lead to motion sickness.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: