To whatever extent SOX compliance makes it more complex to go public, it has no meaningful effect on legitimate successful companies - if you think going public will allow you to raise the most money, you'll go public; if ZIRP meant you could indefinitely raise private money, you'd stay private. Finance and startup bros want to blame companies staying private on SOX, but it has everything to do with either (1) the companies being deeply questionable from an accounting perspective, or (2) the companies being able to raise whatever investments they wanted in private without taking any of the costs of an IPO (e.g. the IPO pop, which could (simplisticaly) be thought of as money being made by the banks underwriting the IPO rather than by the existing owners/investors).

I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.

I suspect in time there will actually be safety consequences to the continued downsizing of airplane lavatories. There are already a number of serious incidents that have been caused by fluid leaks from galleys and lavatories (IIRC Quantas came pretty close to losing a 747-400 due to a kitchen leak leading to massive water intrusion into the main electrical/avionics bay - once you end up pouring large quantities of water on your avionics all bets are off about the systems failures that will happen and you are well beyond any backup/redundancy that has been designed in, and during the 60s and 70s the USAF experienced serious corrosion of flight control cables on C-130s due to urine "leakage"). Too-small lavatories basically guarantee that water and urine are going to end up in undesirable locations and at best they will cause expensive interior corrosion and at worst they will cause serious corrosion to the airframe or critical equipment.

At this point, the designers of narrow-body interiors should be actively shamed for how hostile they have made lavatory designs. In a world in which every major flying population is aging and more overweight, yet every generation of airplane lavatories is even narrower and less accessible for everyone.

Well, actually, the Argentinians had no trouble delivering high explosives to UK vessels, but they did have a great deal of trouble getting those explosives to sink those vessels ... mostly because their bomb fuzes were incorrectly set or inappropriate for the delivery profile.

But on a more serious note, none of the ships sunk by air attack in the Falklands were large military vessels. The largest vessel sunk was the Atlantic Conveyor, and that was (1) a civilian cargo ship built to civilian levels of durability, and (2) it was carrying a large quantity of ammunition essentially unprotected (unlike how a large warship would carry it). Even then, the missile strike and fire did not sink the ship immediately. For the largest military vessels sunk by air attack, the two Type 42s Sheffield and Coventry were relatively small destroyers (less than half the displacement of either their USN contemporaries the Spruance/Kidd or a modern Arleigh Burke) and again there the Exocet strike and resulting fire did not sink Sheffield immediately either. The smaller Type 21 frigates lost, Antelope and Ardent, were never really meant to survive meaningful damage and yet both remained afloat overnight before sinking. For comparison, the roughly contemporary USN frigates, the Perry-class (larger in displacement than the Type 42s), survived both Exocet (Stark) and mine (Samuel B. Roberts) strikes.

(The General Belgrano was a larger military vessel lost to submarine attack with, but considering that it was a treaty-limited 44-year-old light cruiser operating unprepared for submarine attack, it is hard to draw too many conclusions about modern ship durability from its loss - and her sisters in the Brooklyn class generally survived quite a punishment in WWII.)

As other replies note, 4 is the simplest arrangement mechanically and control-wise, as the control math is quite simple (just rotor speeds/torque) and the only moving parts are the fixed-pitch rotors.

The minimum, as seen in real (and model) helicopters, is either two (approximately) constant-speed rotors with swashplate control, or one (approximately) constant-speed rotor with swashplate control and one tail rotor, either with (approximately) constant speed and variable pitch, or with variable speed. At the scale of real helicopters, two rotors may often be more powerful and efficient (e.g. CH-47, V-22) but the size and weight of the gearbox needed to transmit so much power is a significant contribution to the weight and cost of the helicopter, and thus having a single main gearbox is much lighter and cheaper. The notable difficulties of shaft drive between multi-rotor helicopters, particularly with distributed engines (see a number of V-22 issues) strongly discourages helicopters with more than 2 rotors.

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.