Hacker News Reader

Comment by HPsquared | Hacker News Reader

Space shuttle main engines (RS-25) had a very complicated startup process, deviations from this could cause all sorts of different things to fail catastrophically.

http://large.stanford.edu/courses/2011/ph240/nguyen1/docs/SS...

Slide 94 (pdf page 100)

View on HN

I feel like this is a subtle jab pretty much nobody outside of serious aerospace enthusiasts is going to get. For those who don't know, right now there's sort of a competition for the 'next big thing' in rockets. Congress/Boeing/Lockheed have been working on the SLS or Space Launch System since 2011. It was expected to launch in 2016. It had its first trial launch in 2022, and is tens of billions of dollars over budget.

It's also expected to cost billions of dollars per launch. Its more common nickname is the Senate Launch System, since it's largely just a really big pork project. It's already not especially competitive against the Falcon Heavy, and is being built at the same time SpaceX Starship is also being built. That project began in 2017, is being completely privately funded, and expected to revolutionize spaceflight once again - with costs potentially as low as $1 million per launch.

Anyhow, the SLS is reusing a bunch of old technology from the Space Shuttle. This includes the RS-25 engines...

[1] - https://en.wikipedia.org/wiki/Space_Launch_System

The SLS is mediocre but there are a few things to keep in mind:

1) NASA needs to keep in house rocketry expertise and the US government cannot rely on private companies 100% just for like NatSec reasons.

2) If NASA doesn't structure programs as pork barrel projects that make it difficult for small time senators to kill, they will constantly be nickle and dimed and have their budget slashed until their entire job is just to make memorabilia to sell.

3) Elon is not trustworthy. Our country should not rely on him. Starship hasn't launched yet, while SLS has now. I am excited for starship to launch, hopefully soon, but it's still not a functional rocket.

1) The US government does rely on private companies 100%, SLS is built by Boeing, a private company. Being a private American company has very little issue when it comes to national security, just means you have them meet various requirements (eg only allowing US persons to work there and security clearance requirements).

2) Unfortunate that our system is so corrupt, but agreed. Fortunately there is also the Artemis approach of tying in so many international partners that it becomes a matter of national prestige.

3) I suggest looking up "The Falcon 9 Heavy may some day come about. It's on the drawing board right now. SLS is real.".

> NASA needs to keep in house rocketry expertise and the US government cannot rely on private companies 100% just for like NatSec reasons

Do they? Most national security work in space is under NRO and USSF, not NASA; neither of them build their own rockets but instead rely on commercial vendors.

The Army doesn't build its own rifles or tanks, the Air Force doesn't build their own fighters and bombers, and the Navy doesn't build their own ships. Operations is different from designing equipment; the only time it makes sense for the same organization to do both is when that organization is so far out on the cutting edge of innovation that they have to do both. (Ironically it's SpaceX that is in this position with regard to Starlink.)

NASA was in this position during the Apollo era. They aren't in this position anymore. It should have been a hint as early as the Shuttle era when they went and designed the Shuttle as (among other things) a satellite launch platform, only for commercial vendors to provide unmanned rockets as satellite launch platforms instead. As it stands now, NASA carries out a lot of scientific missions that don't have an immediate commercial application, which is a good thing for them to do but doesn't require them to design their own rockets.

Furthermore, it's not even fair to describe SLS as "in-house", since it's built by Boeing and Boeing is bidding the system for their own commercial contracts now. At that point it's just a question of which private company the government can rely on.

All the imperial units in this PDF hurt my head. I'm an American, so I'm used to them, but seeing them in the context of precision aerospace hardware is so jarring. As a student it seemed like math re: chemistry and physics was so much easier (read: less error-prone) with metric units than with imperial. Mars Climate Orbiter indeed.

I mean, sure, converting grams to kilograms is easier (for a human) than converting ounces to pounds, but how often do we have to do that in our heads? Computers, on the other hand, do not care (and they "prefer" the binary system anyway).

Converting grams to kilograms not so much, but mm to m, mL to L, even g to mL and L to kg (of water) — all the time, and of course in our heads — it's so easy you barely need to think about it.

I don't even consider those to be "conversions" at all; in the same way that "two dozen metres" and "twenty four metres" and are both just some number of metres (not a conversion from a separate "dozen-metre" unit).

Technically, the SI standard does consider millimetres, centimentres, kilometres, etc. to be separate ("derived") units from the base unit of "metre". That matters when we have multiple interacting multiples, e.g. "one cubic centimetre" is not the same as "one centi cubic metre"; but of course, that's avoided if we stick to base units like cubic metre. (see http://www.chriswarbo.net/projects/units/improving_our_units... )

The biggest lessons learned on the Mars Climate Orbiter wasn't exactly that everything should be metric. It was the unit conversion is dangerous and needs to be handled very carefully. Just saying everything will be metric doesn't avoid unit conversion. You might have one thing measuring fuel burn rate in grams/second and another in kg/second. That conversion can still lead to issues if not handled correctly. In the context of the space shuttle it was all designed in imperial units starting in the 70s so it would be very risky to convert everything to metric.

I mean what issues would power of 10 fractions have in floating point after all?

If I have data going out on a data bus in grams/second, but someone reading that data in a different sub system reads it and thinks it is kilograms/second because that is the default unit they use then you have an issue. The actual conversion of the bits isn't the issue it is that certain systems might use different units internally and making sure those conversions are done correctly. It is much more an engineering design/human interaction issue than a computation issue.

Yes, I understood that. However repeated conversions can lead to rounding errors such as catastrophic cancellation. This is even more esoteric than “grams here kilograms there” and thus easier to fall prey to. Depending on how precise your measurements are you could easily drop significant digits or add random noise, especially if you do large scale changes.

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

Yeah we tended to utilize fixed point for many of our variables and documented the precision for each one. Then an analysis was done verifying that we were maintaining precision through the calculations from input from a sensor to output.

The problem is almost nothing today accelerates fixed point and everything supports floating point accelerations, which will speed up your ability to calculate the wrong number by many orders of magnitude.

Yeah that makes sense. In aerospace they will fall on the side of accuracy even at the expense of speed. But they also tend to utilize FPGAs that can be designed to handle fixed point calculations quickly but with that comes a lot of cost and specialty hardware.

Another place it makes issues is financial modeling, particularly for complex derivatives where the model might be extremely complex and small errors can accumulate into meaningful errors in risk calculations. Fixed point is sometimes used in finance but performance is also a real concern. There’s a lot you can do to reduce fp errors if your numerical libraries are carefully constructed. But it has often made me wonder why there aren’t processor lines with high performance fixed point since the math is extremely easy - even by just shifting the mantissa and working in integer space then shifting it back.

Pretty sure GP was making a sarcastic comment referencing how floating point is notorious for subtle rounding issues when handling values that have an exact representation in base 10 but a repeating pattern in binary.

Yeah. Given we’ve moved from counting on our fingers to counting on our computers we need a new base 2 metric.

> You might have one thing measuring fuel burn rate in grams/second and another in kg/second

This sort of redundancy is a big problem with metric (e.g. hours, litres, tonnes, etc.); and why it's better to stick to the SI subset. http://www.chriswarbo.net/projects/units/improving_our_units...

In particular, SI is "coherent" https://en.wikipedia.org/wiki/Coherence_(units_of_measuremen...

- There is only one unit for each dimension. In your example, "grams/second" would not be a valid unit; SI only has kilograms/second (yes, it's annoying that the unit of mass has a name beginning "kilo" :( )

- The conversion factor between different dimensions is exactly 1 (by definition). In your example, the rate R is related to mass M and time T via M = TR (i.e. kilograms = seconds × kilograms/second). There are no conversion factors, since the unit of rate is derived from the units of time and mass (unlike, say, measuring energy as calories OR pound-feet OR coulomb-volts OR ounce-miles OR slug-acres-per-squared-hour OR ...)

When designing new systems it is best to clearly define the expected units for everything clearly at the start. SI units are great but sometimes they are not great for the specific use case. When measuring high power systems like power plants or EVs kW/MW/GW are a more appropriate unit versus Watts. In embedded systems you have limited bandwidth having to have large variables just to store values in SI units is a waste versus using an appropriately scaled unit and saving bandwidth.

Overall the conversion of the unit isn't the root of the issue. Clearly defining the data types and units of everything is the key issue. This makes sure any conversion is done when necessary and allows people to design systems so that they can avoid conversion if possible.

INT_MAX is usually 2147483648, which means a "power" figure in Watt can handle anything from a laptop CPU to a Chernobyl power plant. FLT_MAX and _MIN are e+38 and e-38 so couple digits over and under(within 32bit precision).

Have you actually had that kind of unit confusion in metric, or inferring from your experience with Imperial system? It kind of just seems to reinforce suggestion that Imperial system having bunch of redundant or weird units IS the problem.

(for your defense: try [METRIC_UNIT]/h and /s. e.g. km/h often used for display in slow vehicles and m/s used for calculation motions of fast objects are kind of confusing.)

INT_MAX is assuming every variable is using a 32 bit integer which is not always the case. In my experience with flight control systems controls systems were focused on using the smallest variable necessary for a given variable. We had many variables that were only 8 or 16 bits. The processing overhead wasn't really the driving factor for smaller variables it was typically interface bandwidth which can be very limited while maintaining required safety margins on aircraft.

We had a pretty massive ICD that defined every message going in between sub systems down to the bit level which is what was necessary to avoid unit confusion when dealing with system creates by sub contractors and such. Your example of velocity is pretty common thing that you would have to reference the ICD for. Is this velocity signal in KM/h or m/s, as well as MPH, fps, and Mach number.

Sure you could say all velocities need to be in m/s, but then if all your control laws for higher speeds which have been fined tuned through 10s of years of work utilize Mach Number in the calculations is it safer to update all the controls laws or just do a conversion?

> Sure you could say all velocities need to be in m/s, but if all your control laws for higher speeds which have been fined tuned through 10s of years of work utilize Mach Number in the calculations is it safer to update all the controls laws or just do a conversion?

Mach Number is a dimensionless ratio; I don't understand what that could have to do with velocity units? (Any units used in its calculation have cancelled-out by that point)

So 32767 m/s is like not much short of twice the Solar system escape velocity…

> SI units are great but sometimes they are not great for the specific use case. When measuring high power systems like power plants or EVs kW/MW/GW are a more appropriate unit versus Watts.

Those are all SI units. In fact, they're all the same unit: the Watt (almost http://www.chriswarbo.net/projects/units/metric_red_herring.... )

A non-SI example would be e.g. kilowatthours (kWH); since 'hour' is not an SI unit. The SI equivalent would be 3.6 MegaJoules.

> In embedded systems you have limited bandwidth having to have large variables just to store values in SI units is a waste versus using an appropriately scaled unit and saving bandwidth.

This seems like a non-issue to me:

- Integer arithmetic can be "appropriately scaled"; we call it https://en.wikipedia.org/wiki/Fixed-point_arithmetic

- Floats are designed to be scaled, by adjusting their exponents. In the happy case, our algorithms don't care; so why not stick with standard units? In the unhappy case (imprecision, numeric instability) we may need a mixture of entirely bespoke representations, even within a single algorithm. Ideally we'd still use standard units at the "boundaries".

> You might have one thing measuring fuel burn rate in grams/second and another in kg/second.

One of my jobs is reporting on packaging weights[1] in the UK and it's not uncommon to have this problem when I request data.

For example we request in Kgs, but one manufacturer sent back the report table of numbers in grams. That meant the thin plastic sleeve a tube of paper coffee cups comes in was reported at 30Kgs rather than 30g.

These components are all taxed / levied at various stages in the supply chain so being out by a factor of 1,000 can make a significant difference - we sanity check all our data, but a surprising number of people don't. It's not life threatening, but expensive!

[1] It's for the UK packaging waste regulations and packaging taxes. For a case of paper coffee cups we report on the weight and materials of every component such as the cardboard outer box, labels, parcel tape, inner sleeve bags, paper in the cups and the plastic lining in the cups.

Reply on news.ycombinator.com