Most sensors can be implemented in a way that enables self-calibration.
I'm oversimplifying it here, but the macro process is taking some known attributes and mapping them to what you are observing. For example, if you can detect people, and you know the average height of a person, you can compute where your horizon is, and where you should (or shouldn't) expect to see people in the FOV. You can do this with cameras, lidar, etc. When you have multiple sensors you can do a lot more to have them all sample an object in their own ways and converge on agreement of where they are relative to each other and the object.
I’m not sure this has much to do with vision as opposed to fancy self-calibration software. At least a few years ago, Tesla cars would be in self-calibration mode for a while after delivery while they calibrated their cameras. I think the idea is that it’s cheaper to figure out in software where everything is than to calibrate the camera mounts and lenses at the factory.
I see no reason that LiDAR couldn’t participate in a similar algorithm.
A bigger issue would be knowing the shape of the car to avoid clipping an obstacle.
It probably could, but I imagine a LIDAR system would need a similar (large) amount of training data to enable effective self-calibration across a wide variety of situations.
At some point, with enough sensor suites, we might be able to generalize better and have effective lower(?)-shot training for self-calibration of sensor suites.
Isn’t the model needed rather similar to what’s needed for sensor fusion in general? If you can extract features from each sensor that you expect to match to features from a different sensor, then you can collect a bunch of samples of this sort of data and then use it to fit the transformation between one sensor’s world space and another sensor’s world space.
There is actually a photo of a Model 3 in factory line doing that precise positioned target stuff, so they do that precise positioned target stuff at the factory. It's also instant compared to a 10-minute drive.
I think the real reason why Tesla is known to require 10-minute calibration drive is, they shipped APHW2 long before the software matured, so they needed means to do it after the cars were shipped "blank". Other manufacturers only ship finalized hardware and software, and so they don't need a scalable tool-free calibration method.
Anyways, my point is that, Tesla cars need calibrations like anything else. This is same for any multi sensor SLAM systems, whether it uses sets of color cameras or laser spinny thingy or laser flash cameras or laser flash color camera thingy or combinations thereof.
Python has nothing on the sprawl of nodejs packages.
It is a fair criticism and some languages do fare better than others. Python is kind of in the middle there in my opinion. It's pretty easy to keep a relatively simple dependency graph with a little bit of discipline.
Yeah, and this is a good one. Blacklist is less likely to be ignored by parents. Both have risks of corps doing CYA strats, but less so with the blacklist. Whitelist has the advantage of being more feasible without an actual law, and also better matching how parenting works. Generally kids are given whitelists irl.
React gets blamed for this because the error handling is bad and the UX is confusing. But the issue with GitHub’s frontend is that the backend is dropping requests. When you click a button on GitHub and the loader gets stuck that’s because there no timeout/error handling in the JavaScript but there also no reply from the server. I feel like React is getting a bad rap because it’s visible when the issue is clearly their backend.
> React gets blamed for this because the error handling is bad and the UX is confusing
Yes, it does.
> React is getting a bad rap because it’s visible when the issue is clearly their backend.
Two things can be bad! Except that in this case one of them is unnecessarily bad, because nobody forced them to use a front end system which defaults to terrible failure handling.
It's also not tautological that React apps have bad error handling. You can do proper error handling and retry logic in React, and I can't for the life of me understand why GitHub engineers making several hundred thousand a year in cash and at least that much in stock simply... don't?
It's no wonder my jobs feed is flooded with senior engineering positions at GitHub (one wonders if they're growing, or jettisoning dead weight) but I can't imagine it's a good look for the resume to put GitHub on it at this point.
What's hilarious about that script is that the solution is so simple: use a less-than comparison instead of an equals. That's really, really all it would have taken to fix the issue. And yet https://github.com/actions/runner/pull/3157 was opened on 2024-02-17 and was merged on 2025-08-21, a full 18 months (plus a few days) later! It took literally 18 months for them to merge a bugfix that is trivially obvious to see is correct.
Yeah, the problems at GitHub ran (and still run) deep.
P.S. Yes, there are busy-wait issues in that code, which should have been addressed by bringing back the check for the `sleep` command and using it if available, falling back on the CPU-burning busy-wait only if `sleep` was unavailable. But the most revealing thing is the 18 months to merge a trivial-to-verify PR. That, more than the bad busy-wait loop, is the fundamental indicator of brokenness at GitHub under Microsoft's ownership.
This is surprising to me, I would have bet money that all the people who actively engage in this type of language/framework war discourse were all drawing Social Security by now.
There's a big difference between a war between two somewhat equivalent things that make different choices (editor wars, language wars, etc.) vs pointing out that certain things are really fundamentally ... not good. IMO we all need to be much louder and clearer about how bad things are, and how much better they could be.
This is, in fact, on topic: github actions seemed to me like a bad idea from the start, to me, but I let my co-workers and "network effects" convince me that I was being grumpy and that it was fine, and so we've adopted it. And now ... here we are. It was exactly as bad I thought it was, and it reflected a broken engineering culture.
It is certainly possible that you are brilliant and your co-workers and the industry writ large are all morons. That you were right all along, and chickens roosting and all that, though it seems at least equally as likely that this is not the case.
If you think it requires "brilliance" to figure out that Github Actions is really bad, and/or that "the industry writ large" always makes good decisions, you might be the problem!
You really need a large volume of repeated results by different groups doing the experiment/research so you get the proper regression to the mean. Individual papers are more important at saying "here is something interesting that others should also check out".
reply