Pushing the limits of the hoverslam landing

[Gliderflyer]

Only three engines have plumbing for TEA/TEB reignition, and all three receive a reignition pulse regardless of which ones are lit.

Was this ever confirmed? I remember some speculation on it, but I don't recall if there was ever a source for it. In the Orbcomm 2 landing video there is only one green flash during the landing burn startup. If the igniter was firing in three engines, I would think the green flash would be visible in the other 2 engines as well as the center one.
https://www.youtube.com/watch?v=ANv5UfZsvZQ#t=2m35s

[Kabloona]

Only three engines have plumbing for TEA/TEB reignition, and all three receive a reignition pulse regardless of which ones are lit.

Was this ever confirmed? I remember some speculation on it, but I don't recall if there was ever a source for it. In the Orbcomm 2 landing video there is only one green flash during the landing burn startup. If the igniter was firing in three engines, I would think the green flash would be visible in the other 2 engines as well as the center one.
https://www.youtube.com/watch?v=ANv5UfZsvZQ#t=2m35s

That was stated as fact on reddit by someone who seemed to know (u/EchoLogic). And I haven't looked again at the OG2 landing video, but maybe all 3 engines were on line-of-sight to the camera, so the viewer would see only one flash.

As it happens, the OG2 stage is the one where we noticed the white TEA/TEB residue on the 2 outer engines and made the conjecture about how the TEA/TEB was plumbed. So it's virtually impossible that there *weren't* three flashes on OG2. Later I noticed what seemed to be authoritative confirmation of the plumbing configuration on reddit by EchoLogic. Hopefully he wasn't just repeating what he read here. 

[abaddon]

That was stated as fact on reddit by someone who seemed to know (u/EchoLogic). And I haven't looked again at the OG2 landing video, but maybe all 3 engines were on line-of-sight to the camera, so the viewer would see only one flash.

As it happens, the OG2 stage is the one where we noticed the white TEA/TEB residue on the 2 outer engines and made the conjecture about how the TEA/TEB was plumbed. So it's virtually impossible that there *weren't* three flashes on OG2. Later I noticed what seemed to be authoritative confirmation of the plumbing configuration on reddit by EchoLogic. Hopefully he wasn't just repeating what he read here. 

EchoLogic is the (an?) r/SpaceX moderator.  So any information should be considered secondary in nature (not saying it is bad).

ISTR there was a poster who seemed to be likely to be from SpaceX directly posting here around the time, who was indicating the same.

In general, we have a lot of sources pointing to the same thing, and nothing I am aware of contradicting it, so it seems like we should consider it as factual until otherwise proven different.

[launchwatcher]

That all sounds great in theory, but does anyone know precisely what they'd be basing those mass figures on?  To know how fast it's burning propellant, does it use mass flowmeters - or something else?  If they use mighty-accurate mass flowmeters, can anyone hazard a guess at a make/model??

I'd imagine that some combination of turbopump RPMs plus temperature and pressure readings at various points would give you a good idea about mass flow.

[John Alan]

I think you all are overthinking how this works... 

I will quote myself from a different thread yesterday...

It's likely a carefully crafted sequence developed thru many simulations then just played back and run thru...
There is likely code to adjust some things in real time... but mostly just to adjust the timeline playing out...

Example... compares timeline expected radar altitude to actual reading...
Jumps back or forward in timeline to make equal and continues to monitor...

Example... I'm falling faster then I should be at this point on timeline...
Applies small plus offset to thrust commands in timeline to attempt to compensate...

Point is with a good timeline sequence laid out and then played out... it works...
Just has enough wiggle room built in to adjust for the actual deck height before it gets there...

The above is very simplified and just my opinion... 

To add to the above... my opinion... 
SpaceX runs their simulations preflight and builds a launch (and landing) program sequence for the stage S1 main controller...
While it likely has built in correction calculation loops to make small adjustments to output values on the fly...
...It's very committed to assuming reality matches the assumed values made when programming the simulation...

It also (and this is key) logs in real time what it signaled out and what all input values were... and saves it.
Every stage landed and log file downloaded helps correct for modeling errors in the simulator...

In industry, this is how you automate high speed machinery...
You break it down to sequences and correction factors...
A) Sequences assume the laws of physics will not change and the machine is in working order...
B) Correction factors allow for things that can and will vary, to be allowed and adjusted for in real time...

In the end... the S1 controller just 'drives'... (like you drive a car)
It does not have to do heavy math... calculate all these things in real time and keep up...

Just my opinion on topic... 

[envy887]

Can someone with insight comment on how SpaceX is actually measuring or calculating thrust in flight?

[John Alan]

Can someone with insight comment on how SpaceX is actually measuring or calculating thrust in flight?

Likely off chamber pressure sensors and assuming the engine is in working order...
Would not surprise me if each engine controller is not reporting back a value on the controller network for all controllers to see...
If chamber pressure is X and altitude is Y then thrust equals Z...
Uses a lookup table... real common way of doing such a thing in the embedded controller world...
Turbine speed is indirectly an indication of power output... Chamber pressure is more direct...
BUT... that is all just my opinion... 

[Herb Schaltegger]

Can someone with insight comment on how SpaceX is actually measuring or calculating thrust in flight?

They don't need to. They can infer it from stage acceleration at any given time, which they can adjust within given parameters to modulate.

And that said, I think a lot of people posting should do some reading on closed-loop control system logic and design. You're making things way more complicated than they need to be from a "vehicle smarts" standpoint. 

[Kabloona]

Can someone with insight comment on how SpaceX is actually measuring or calculating thrust in flight?

Not claiming insight into SpaceX specifically, but other LV's I have worked on (Pegasus, Taurus, which admittedly are different beasts as solids) don't measure or calculate thrust per se. The IMU just measures vehicle acceleration, etc.

For liquid vehicles, the only difference is throttleability, and the thrust characteristics of the engines at given throttle settings are determined in static test firings. Once you have the engine thrust vs. throttle setting curves established through testing, you can program the autopilot accordingly. It can then command a given throttle setting expecting a certain thrust level, and the result is a given acceleration sensed by the IMU.

If fine control of acceleration (and therefore thrust) is required, eg in the case of F9 landing burn, the IMU can adjust throttle up or down as needed to obtain the desired acceleration, because of course the vehicle mass is always decreasing. So the IMU ends up "closing the loop" on desired acceleration by adjusting throttle accordingly. But it doesn't need to measure (or calculate) thrust per se, only acceleration.

[the_other_Doug]

Can someone with insight comment on how SpaceX is actually measuring or calculating thrust in flight?

Not claiming insight into SpaceX specifically, but other LV's I have worked on (Pegasus, Taurus, which admittedly are different beasts as solids) don't measure or calculate thrust per se. The IMU just measures vehicle acceleration, etc.

For liquid vehicles, the only difference is throttleability, and the thrust characteristics of the engines at given throttle settings are determined in static test firings. Once you have the engine thrust vs. throttle setting curves established through testing, you can program the autopilot accordingly. It can then command a given throttle setting expecting a certain thrust level, and the result is a given acceleration sensed by the IMU.

If fine control of acceleration (and therefore thrust) is required, eg in the case of F9 landing burn, the IMU can adjust throttle up or down as needed to obtain the desired acceleration, because of course the vehicle mass is always decreasing. So the IMU ends up "closing the loop" on desired acceleration by adjusting throttle accordingly. But it doesn't need to measure (or calculate) thrust per se, only acceleration.

I'm pretty certain that the Falcon stage 1 control and guidance system knows exactly where it should be, and how fast it should be going, at every point along its pre-defined trajectory.  It uses its controls (grid fins, engine gimbals and engine throttling) to maintain itself as close as possible against the pre-defined trajectory.

It doesn't need to know exact thrust or exact weight of the stage at any given time, it just knows what kinds of inputs to put into its controls to keep it on the right path.  If adding a little downrange velocity is called for, the system will do so until it is on profile.  It doesn't need to know it's fighting winds, what the wind speed is, etc.  It just needs to know where it's supposed to be and where it is.  It will then apply control inputs to get there.

This keeps the variables it needs to solve for down to a bare minimum, and based on the successful targeting we've seen, it seems to work pretty darned well...

[Robotbeat]

Indeed. There is some value to knowing those things to some extent, but a control loop can be pretty dumb and still work just fine getting you to where you need to go.

[envy887]

My question about thrust was more about the data sent home than anything used real-time for control.

Isn't engine thrust a metric examined in post mission analysis?

[the_other_Doug]

My question about thrust was more about the data sent home than anything used real-time for control.

Isn't engine thrust a metric examined in post mission analysis?

Not really.  "Thrust" is an ever-changing number and has as much to do with the air pressure as it does with the engine.  What is measured are things chamber pressure and acceleration.  From these kinds of measurements, one can compute thrust at a given moment.

In the old line about how, for example, the Saturn V would sit during engine start-up and not ask to be released until the engines had "come up to full thrust," the measurements that were actually used to determine the thrust level of the engines were chamber pressure measurements.  There was nothing that measured the actual thrust being produced, just what the chamber pressure was.  Per the physics of the engine design, at a given chamber pressure, the engine must be generating a given amount of thrust...

[Herb Schaltegger]

My question about thrust was more about the data sent home than anything used real-time for control.

Isn't engine thrust a metric examined in post mission analysis?

As I posted earlier, "thrust" can be determined by measuring acceleration of the vehicle in response to control inputs. During post-mission analysis, the mass of the stage at any given time can be determined to a reasonable degree of certainty by integrating along the flight profile. SpaceX knows the empty mass of the vehicle; they know the mass of the payload; the know the mass of propellants loaded; they know the mass flow-rate curves for the engine along the throttle points for the M1D engine.  From those starting values, they know all they need to.

EDIT: Yeah, what the_other_Doug said.

[MP99]

My question about thrust was more about the data sent home than anything used real-time for control.

Isn't engine thrust a metric examined in post mission analysis?

As I posted earlier, "thrust" can be determined by measuring acceleration of the vehicle in response to control inputs. During post-mission analysis, the mass of the stage at any given time can be determined to a reasonable degree of certainty by integrating along the flight profile. SpaceX knows the empty mass of the vehicle; they know the mass of the payload; the know the mass of propellants loaded; they know the mass flow-rate curves for the engine along the throttle points for the M1D engine.  From those starting values, they know all they need to.

EDIT: Yeah, what the_other_Doug said.

Plus, also deriving air resistance from altitude and descent rate?

Edit: also attack angle and grid fin settings?

Cheers, Martin

[MP99]

But the flight computer probably just flies the mission assuming it has enough propellant to land safely. And you wouldn't want it to know if it didn't. 

I would not expect MECO to occur until S1 has met its performance targets.

If there is insufficient prop left for a landing, I'm not sure if it would go ahead with a doomed landing attempt, or switch to expendable mode and abandon recovery?

One last tweak - if prop is tighter than expected, perhaps a single engine landing would be switched to three engines? (But not sure if single engine landings will ever be planned again.)

Cheers, Martin

Sent from my Nexus 6 using Tapatalk

[Saabstory88]

(But not sure if single engine landings will ever be planned again.)

Wont that depend on the state #24? If the first thing they did upon reaching the droneship was to pull off the engine covers, it may be a little more harsh of a technique than is good for reusability.

[gadgetmind]

Isn't it the short re-entry burn that's harsh rather than the three engine landing burn?

[llanitedave]

Indeed. There is some value to knowing those things to some extent, but a control loop can be pretty dumb and still work just fine getting you to where you need to go.

I think the question wasn't so much about staying on track, but in cases where fuel reserves are at a bare minimum, knowing whether or not there will be enough fuel remaining to complete the landing.

[Herb Schaltegger]

Indeed. There is some value to knowing those things to some extent, but a control loop can be pretty dumb and still work just fine getting you to where you need to go.

I think the question wasn't so much about staying on track, but in cases where fuel reserves are at a bare minimum, knowing whether or not there will be enough fuel remaining to complete the landing.

Why does the stage guidance system need to know that? Either there is, and the landing presumably succeeds, or there isn't, and it fails one way or another. Telemetry lets the ground later figure out why it failed (e.g., due to lack of fuel) and they adjust things to hopefully improve odds of success the next time. Or decide landing isn't feasible with that payload and they don't even try further for a payload/mission of that type in the future.