A great example of this is the GigE Vision/GenICam standards that are used by basically all machine vision cameras, which were accessible to non-licensees but not usefully implementable (these standards explicitly prohibited their use in implementing any open source implementation of the standards). So essentially all they could be used for were (1) as a licensee producing closed-source software for their own cameras, or (2) you as customer trying to complain to your camera/software vendor that they failed to implement some part of the standard correctly.

I think you've gotten hung up on the idea that making robots is the essential part of the problem. I'm not going to go as far as much of the ML community and say that making hardware is secondary, but the software side is where most of the latest and greatest work is happening. Better hardware is not going to magically solve all the outstanding problems of manipulation. Better software might solve them entirely independent of hardware so long as the hardware is "good enough". I think there is a general sense that the field that robotics is approaching the equivalent on the mid 2000's with respect to computing architectures - there are still first-party RISC UNIX workstations on the market (e.g. Apple, IBM, Sun) but the incoming tide of commodity x86 platforms is clear for all to see. There are still some gains to be had by designing everything in-house, but the marginal gains versus off-the-shelf components or even full systems are steadily narrowing. There is every reason to believe that COTS hardware capabilities will continue to mature and become more commoditized.

Of course, the purchase here that actually mattered happened several years ago; this headline is just the final piece. BD and Hyundai have been working fairly closely on Altas applications to auto manufacturing for some time, never mind the additional research being done at BDAII/RAII.

If you had any auto industry experience, you would know that the people responsible for the design and build of the physical car and the people responsible for the user-facing software are very separate (in fact, the user-facing software might be entirely contracted out).

> What... positive experience do you have to assume that one of the lowest-tech industries in existence is somehow giving experience with some of the most advanced tech in the world?

You do realize how laughable this position is, commenting on an article about one of the largest automakers in the world buying out the remaining stake in the robotics development company that they already effectively owned. Do you really think that somewhow between owning BD and their partnership with GDM that no-one in the entire corporate structure of Hyundai is aware of the state of the art in robotics?

I actually don't think any of the big automakers have ever really, in-depth considered the ROI of "traditional" assembly automation (i.e. anything SoTA pre-2020), with experts in all parts of the process in same room. It's easy to assume that these companies must make careful measured decisions based on evidence, but in practice big decisions are made by small groups within the C-suite, often pretty divorced from the reality on the ground.

For example, many of the big asian automakers seem to have completely ignored the well-understood effects of their demographic crises (i.e. significantly aging population) on the future of their workforce (i.e. they are having trouble retaining and hiring new workers as the older generation retires) and this totally changes the economics of automation! Now they are all having to play catch-up, having realized that they must automate, at whatever the cost, because the issue is not "robots must be cheaper than human labor" it is "we might not be able to afford human labor at all".

> I can’t imagine this would bring much actual experience with this new generation of robotics.

Luckily for you, my job has always been within the robotics research side of the company, so I am very much aware of the strengths and weaknesses of the current technology.

The auto industry is notorious for making incredibly myopic choices to save money/make money in the near term versus long-term investments. The relationship between automakers and their suppliers/vendors is basically a century-plus of the automakers trying to (1) outsource anything they can for a quick buck, and (2) grind the supplier/vendor margins down to nothing. (This is part of why the newer Chinese automakers with much greater vertical integration are such a threat to the traditional automakers; vertical integration has a high up-front investment but the payoff in flexibility and speed is significant).

This is over the last decade at one of the largest automakers in the world. Naturally there is significant variation between individual lines and plants; some are newer and more automated, some are older and much less automated. Are some cars being built on more automated lines? Yes. But a great many, probably the vast majority, are being built with fairly low assembly* automation.

* There is a significant split in automation between "body weld" stages and "assembly" stages. Body weld is very heavily automated basically everywhere (although there are some surprising exceptions in places), while assembly is much less automated.

Hah! Hardly. I say this as someone whose first "real job" was in applying robotics research to automotive assembly - there are still a ton of assembly tasks that could be performed by a fixed-base robot arm, or a robot arm on a linear rail/fixed gantry. Wheeled mobile manipulators are only needed in a few cases, and humanoid form-factor is only "necessary" in very few cases (and I don't think the current crop of humanoids is particularly suited to these tasks).

In my opinion/experience, the impediments are that (1) the system integrators that are usually responsible for assembly-line robotics are too stupid to figure out how to apply robots to the problem, (2) the automakers themselves are often too short-sighted/stupid/unwilling to invest in increased automation (and particularly in building the in-house competency that they really need), (3) the hostile/exploitative relationship between (most) automakers and their main suppliers means that low-hanging improvements to parts/assemblies are a non-starter, and (4) the automaker C-suite (and investors) are too drawn to silver-bullet solutions (e.g. humanoids) than practical automation improvements.

All of this is up to the implementation in practice. The codebases I work on generally follow the pattern that exceptions may be thrown but may not be caught*, and thus they practically serve as terminate. And we absolutely get stack traces in our core dumps (Linux, both GCC and clang), and basically all of the complex debugging I do starts with a coredump stacktrace.

* We follow this pattern for a few reasons, (1) it is generally safer for us to assume that libraries we consume (STL included) will behave as expected with exceptions enabled, (2) "don't catch exceptions" (or if you must, catch the as close-to-throw as possible) is a simple way to avoid exceptions-for-nonexceptional-cases control flow, and (3) most of the C++ codebase is exposed through bindings in Python, and propagating errors as exceptions is the only Python-friendly way to handle it.

> I’m thinking kerosene or even methane. UDMH is a toxic mess.

Methane is absolutely out because of pressures/temperatures involved in keeping it liquid for any useful length of time. It would require both significant on-site gas storage as well as a gas compression plant to produce liquid methane on demand, both considerable additional targets (and very fragile ones at that). Kerosene + additives (e.g. RP-1 and JP-8) is the only really viable storable "friendly" hydrocarbon.

In practice, Hydrazine/UDMH + N2O4 is going to be much easier to handle safely than you think (Hydrazine itself is probably safer to handle than Ammonia, and there's a lot of Ammonia handled out there). You fill and seal the tanks at assembly, and outside of rare leaks the handling is fairly benign. Most notably, basically every major military has, as some point in the 20th century, done so - including aboard USN carriers, famously a very skeptical customer from a handling standpoint. Even today, every single F-16 (about 2000 in active service with about 25 operators around the globe) carries Hydrazine in the onboard EPU, and those operators are prepared to service (and handle leaks) safely.

While they aren't pleasant chemicals by any stretch, Hydrazine/UDMH + N2O4, by virtue of its immediate hypergolic behavior, is actually quite well-behaved from a fire/explosion safety standpoint, which is practically a larger concern than toxic fumes (consider how many other things in and around a combat environment can produce toxic gasses). Hydrazine/UDMH + N2O4 ignite promptly on mixing, and thus don't accumulate in an explosive mixture to be ignited later like alternative fuels and oxidizers.

The only real cases a non-storable SAM/ABM is viable are where the target being protected is so small and so known that (1) all missile infrastructure on/near the target is vulnerable and (2) sufficient advance warning is available to handle liquid fuels as needed. There is really only one case of this: Guam. I think there is a case that a dedicated unique-to-Guam liquid-fueled SAM/ABM farm would go a long way to addressing stockpile and magazine depth concerns.

> That's just another way of saying what I said: they can't operate at close range and must instead use stand off weapons instead of, say, gravity bombs.

It really isn't. Outside of rare cases where mid-air refueling is unavailable, standoff weapons are used to reduce exposure to enemy air defense, not to increase range. Your airwing uses exactly the same gravity bombs to strike a target 10 miles from the carrier as they do at 50 miles or 100 miles or 200 miles.

> Our ships are designed to operate in the Pacific or North Atlantic, not the Persian Gulf.

Nearly every type of ship in the USN has spent considerable deployment time in the Persian Gulf. They are absolutely "designed" for deployment there. What "prevents" their deployment there is that it does not make tactical or strategic sense to put highly capable warships during a war in a tiny waterway when said warship is capable and effective at operating from outside said tiny waterway. Put a CBG in the Persian Gulf and it becomes just about as expensive to defend as an air base on land (much more so, given the logistics involved). That same CBG operating in the Indian Ocean against the same targets has tens of thousands of square miles in which to operate and avoid detection and attack, and never need to fire a missile in self-defense.

> It’s saying we can do that faster than we can get another AP production facility online

Oh boy, have you seen how long SAM/ABM development takes? The critical munitions that actually need to be designed here would be liquid-fueled equivalents to THAAD, PAC-3, SM-2, SM-3, and SM-6. Not yet-another-cruise-missile which is already liquid-fueled.

Solids are better from a storage and deployment standpoint in almost all cases; anyone making a sincere case for liquid fuels should be making it on the basis of munitions that are best designed around them (notably, of course, most of the long range cruise missiles that have received the most hand-wringing about stockpile depletion are already air-breathing jet-fueled). The actual stockpile issues wrt solid rocket fuel are high-performance SAM/ABM interceptors, and those would require complete redesigns to make liquid-fueled equivalents.

The last 40 or so years haven't really moved the needle on theoretical complexity, but we have developed new methods and improved existing methods (and also computers have gotten massively better) such that a much larger subset of the problem space is actually practically solvable. Even still, it is almost trivially easy to go from a practically-solvable problem to a practically-unsolvable one, and much of the confusion that exists in the popular understanding of robot capabilities is the result of the solvable/unsolvable line being so close and subtle.

On the topic of bipedal (and quadrupedal) locomotion, I think you could actually argue that we very much do not understand how to solve the problem, and exhibit #1 is that basically everyone (Boston Dynamics included) is giving up on MPC-based control and adopting RL-based controllers which seem to work better but are much less comprehensible from a theory standpoint.