Hacker News Reader

Comment by ChrisClark | Hacker News Reader

The dancing cars were fixed several months ago in an update. The computer used to just recognize cars, and then align them according to the lanes it sees. At a stoplight it when it had trouble seeing the lanes clearly the cars would rapidly change orientation.

Since they updated the neural net to also recognize the vehicle orientations the dancing has stopped.

I have seen a lane change cancel recently, a couple weeks ago though.

You can tell the car is a 'nervous' driver. It plays it way too safe, but I guess that's a good thing at this point.

View on HN

Model 3 owner here: the dance where cars spun around and landed on top of you is gone but detected cars are still quite jittery. I notice that when I'm stopped and also when I'm driving. This is quite noticeable in the transition between different regions in the car (presumably when the vehicle is handed over between different cameras or sensors). Even something relatively simple as the traffic aware cruise control will sometimes slow down for no apparently reason or simply turn itself off in the rain. Given the combination of the visualizations and the performance of cruise control and autopilot I think Tesla is very far away from fully autonomous driving under all conditions. But they'll probably keep getting better at the semi-autonomous/good conditions/freeway "self-driving"/"augmented driving"...

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.

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.

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.

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

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.

"The dancing cars were fixed several months ago in an update."

On the latest software and with HW 2.5, this is not true. It's still very much there.

Agreed, with HW3 it's the same, there's still lots of jitter and dancing cars. As of today, with software updated about three days ago.

Dancing isn’t completely gone - especially with large trucks.

I'm pretty sure the truck thing is because images aren't stitched yet. That's coming in an update.

Do you know if, when a vehicle disappears, the system assumes the vehicle continues moving as it was when last spotted?

I'm pretty sure that the visualization is only showing highly confident classifications (not sure about the SUV/Pickup thing). Under the hood the algorithm is locating all kinds of objects that could be but are not displayed on the screen as some kind of unknown box. Probably the reason Tesla isn't showing this is because the location and size of objects are uncertain and people would freak out if they saw all that traffic (some of it quite close) jumping around.

If it’s a debug visualisation, why would it not be displaying everything? Of course, it’s in a public release so it’s probably, er, ‘tidied up’ a bit.

Reply on news.ycombinator.com