Hacker News Reader

Comment by mattlondon | Hacker News Reader

Interesting that they are doing updates at only 10 and 50Hz. I had kinda assumed they'd be looking at much higher frequencies for telemetry especially for things like the rocket motor metrics

View on HN

I thought that too initially, but if you think about the physics it makes sense.. the larger the mass the more stable the object, the lower the frequency of acceleration needed to adjust it's trajectory. Also even though it's dynamic, it's not articulated or anything like dynamic robots.

Take the opposite, a little quad copter, very low mass, will need very high frequencies. I used to manually fly miniature remote control helicopters before all of the automatic control stuff came in, they were extremely, inherently unstable, very tricky to control.

> the larger the mass the more stable the object

Not really. Only when scaling mass, margin of error, and forgetting thrust/gravity.

And even if you scaled mass, thrust, and margin of error proportionally, you'd still have an object exactly as stable as before (force X applied to the small object gives you the same acceleration as proportionally scaled force Xs applied to a larger object). Gravity accelerates all things the same, and so do proportionally stronger thrusters.

But being off by one meter can destroy a small drone just as well as a large spacecraft, so you don't have the luxury of scaling your margin of error by significant amounts.

The only reason larger objects appear more stable to humans is because we, and the environment[1], tend to apply relatively weaker forces to them, and also you don't tend to notice they're already moving at 5m/s because of their size.

[1]Larger objects will better compensate for "truly random" forces, if their size causes them to encounter more of them, canceling them out and/or they're generally small.

A spacecraft may need to be super accurate at docking, but outside of that precision is far less important.

Docking is also done extremely slowly.

Not mass, size.

You can still have a small but massive flying device and would end up with the same acceleration and jerk because need more thrust to zero the gravity out.

The bigger your thing is the relatively smaller the 9.8 m/s^2 is.

Keep in mind that this is _reaction time_. As in, if something happens to an engine how fast do I need to react to safe it before it spreads to other things. Turns out that 20ms response time is plenty appropriate.

Are there any processes in combustion dynamics faster than 20ms? You bet there are, and when the engine is being tested they are instrumented with high speed probes, because during development/testing you want to _understand_ what’s going. When you are flying you want to stay in control first and foremost.

Of course, it would be awesome to have everything on high speed data acquisition channels. But there is a very limited telemetry budget and everyone is fighting for it. So compromises have to be made.

There probably are high speed probes on the rocket, such as strain gages. And if an engineer thinks that having a high speed engine metric would be _critical_ to do postmortems then it will most likely be included.

So, I would say that assigning telemetry budgets it’s a holistic process where multiple teams fight/cooperate to share that budget and prioritize absolutely critical data channels.

Rocket engines have built-in computers, like ECUs in cars, that likely operate at a much finer update cycle than 50hz. Flight computers are not concerned with every aspect of timing when it comes to the engines, they just need to tell the engine's controller when to fire.

50Hz is pretty damn fast for anything happening at rocket ship scale (i.e. gimbaling of engines). 10Hz seems fine for a more strategic roll-up of all subsystems wherein you would have to do more complex logic each round. The physics are pretty stable at any rate considering the masses involved. If we were talking about controlling a 10g nanodrone (hypothetically), 50hz would probably be cause for concern.

For a SpaceX mission, there isn't a lot that can go wrong in 2 hundredths of a second that you could have magically resolved if you saw it 1 hundredth of a second earlier (i.e. at a 100hz rate).

> 50Hz is pretty damn fast for anything happening at rocket ship scale

I was thinking whether this is OK for dragon in-flight abort system. Well, probably is. Or that may use some system on Dragon itself as the rocket may be no more...

FTS/crewed abort is likely a special exception to these control loops. Last I read there are some lengths of wire that run down the rockets which, when broken, would allow for an instantaneous reaction to some catastrophic event.

I don't know what I'm talking about, but I believe in optimal control a rocket's orientation changes very slowly and the rocket is designed for aerodynamic stability. 50Hz is also probably much faster than the engine can gimbal or throttle. So if a 50Hz tick is too slow to respond to some stimulus, something has gone horribly wrong.

> So if a 50Hz tick is too slow to respond to some stimulus, something has gone horribly wrong.

Which is why the abort system probably doesn't need to wait for that tick.

Telemetry can be packaged up and sent out at higher than the control loop rate (if needed). There's nothing keeping you from having a buffer that stores up higher frequency data that gets read off and sent off as a blob each control loop.

There's probably no point in going much faster for most control systems of physical devices of the sizes we're talking about. The actual response time of actuators and time to see the results of changes on sensors is much longer. Think the time required to actually adjust the throttle or gimbal a huge rocket engine, and then the time required to see an acceleration change as a result of that.

They probably use higher rates for stuff like measuring combustion dynamics during ground tests of the engines in development. If anything is wrong there, they'll probably seek to correct it via mechanical or fluid dynamics adjustments of the system itself, since active control systems could probably never react fast enough anyways.

I would assume something like an engine controller or some other control loops might run internally at a much higher frequency. But the main control loop which orchestrates all components is able to run at lower frequency.

I found this also interesting. I can see how it simplifies the mathematics to use a fixed time interval.

Can anyone experienced comment if 10Hz is very different or the same as vehicle control systems such as a modern car?

Also, are these systems fixed or floating point? Fixed time intervals would help keep numerical instability of floats in check (however I'd really hope this is more formally understood for such a safety-critical system.)

I've been working on the engine control unit for trucks. I think the fastest control loops were 100Hz (but that was only a few), fixed time intervals. Then, of course, you have the fuel injection that is controlled by its own processor, independent of the ECU scheduling.

Nowadays I work with satellite SW. Most of the control loops are pretty slow. The fastest ones are those controlling gyros and reaction wheels that run in 5 or 10Hz

PID control loops on brushless motor controllers typically operate in the 5kHz-50kHz range.

These are almost certainly global control loops that are orchestrating hundreds or thousands of subordinate control systems that have completely independent dynamics and refresh rates.

Reply on news.ycombinator.com