Starship On-orbit refueling - Options and Discussion

[oldAtlas_Eguy]

I was thinking about some additional sensors to be used for refining the GNC to be able to make the second SS fly very precisely along with the primary SS. And that is nothing more than a bunch of strain gauges that report 3 axis load values at the hard point or even semi-soft point connections between the 2 SS. By trying to maintain as low of a 3 axis loads through these connection points the secondary SS adjusts its actions to basically fly precisely along with the primary SS. NOTE is that as prop flows from one to the other this method inherently can provide accurate feedback to maintain flight and stability.

[TheRadicalModerate]

I was thinking about some additional sensors to be used for refining the GNC to be able to make the second SS fly very precisely along with the primary SS. And that is nothing more than a bunch of strain gauges that report 3 axis load values at the hard point or even semi-soft point connections between the 2 SS. By trying to maintain as low of a 3 axis loads through these connection points the secondary SS adjusts its actions to basically fly precisely along with the primary SS. NOTE is that as prop flows from one to the other this method inherently can provide accurate feedback to maintain flight and stability.

You'd need torsional or bending loads as well as tension/compression.  I still think you're probably better with IMUs and/or visual trackers, and centralized control of both ships as a single system.  The number of degrees of freedom needed to manage them as a two-body system that needs to maintain translational and rotational coherence gets out of hand pretty quickly.

[edzieba]

I was thinking about some additional sensors to be used for refining the GNC to be able to make the second SS fly very precisely along with the primary SS. And that is nothing more than a bunch of strain gauges that report 3 axis load values at the hard point or even semi-soft point connections between the 2 SS. By trying to maintain as low of a 3 axis loads through these connection points the secondary SS adjusts its actions to basically fly precisely along with the primary SS. NOTE is that as prop flows from one to the other this method inherently can provide accurate feedback to maintain flight and stability.

You'd need torsional or bending loads as well as tension/compression.

6 strain gauges (plus redundancy), then.

I still think you're probably better with IMUs and/or visual trackers, and centralized control of both ships as a single system.  The number of degrees of freedom needed to manage them as a two-body system that needs to maintain translational and rotational coherence gets out of hand pretty quickly.

6 DoF, not excessive. And since the goal is to minimise mechanical loads on the coupler, then directly measuring mechanical loads on the coupler is the gold standard compared to IMUs/RADAR/LIDAR/etc.

[TheRadicalModerate]

6 DoF, not excessive. And since the goal is to minimise mechanical loads on the coupler, then directly measuring mechanical loads on the coupler is the gold standard compared to IMUs/RADAR/LIDAR/etc.

Hmm, I seem to have lost my response to this.  Trying again:

You need at least nine degrees of freedom:

1) 3 for translation.
2) 3 for vehicle #1 rotation.
3) 3 for vehicle #2 rotation.

I don't think figuring everything via strain gauges will work.  Consider two cases:

a) Two ships drifting apart along the y-axis (x = fore/aft, y=left/right, z=up/down).
b) Two ships rotating about a common axis of inertia that happens to be parallel with the x-axis.

These should have identical strains, but they certainly don't have identical control actions to null the rates.

[OTV Booster]

In a more serious vein, the data environment before and after lash up are very different. Pre lash up, ISTM that keeping one ship passive while the other maneuvers keeps the risk low. Passive in this case doesn't mean dead. It means holding attitude but not otherwise maneuvering.

After lash up the rules change. Both ships need to (probably) work together for ullage settling and attitude control. But...

If the depot has CMG's and can thrust off axis with TVC on the settling engine, it should be able to handle everything. And, once they're lashed up they can have a physical low noise data connection. As you suggested, the second ships sensors would become an extension of the depot. Control systems could be tied in too if necessary.

Some questions:
- What are the chances the sensors and controls on SS are a data buss sharing network?
- Can off axis thrust be made a virtue during transfer? It imposes a certain type of order on slosh.

The data bus is likely 1000BaseT ethernet.  I assume that it's switched, because everything is these days.  So it should be quite easy to make one network out of two Starships.

I obviously don't know the exact architecture of the network.  Never stops me from guessing, though.  For long runs (e.g. across the prop tanks), I'd use redundant wiring, with switches at either end.  From those switches, which no doubt have all sorts of vibration and noise hardening, you'd have fairly short runs to other distribution switches, which would feed individual engine controllers, gimbals, thrusters, heaters, coolers, IMUs, CMGs, etc.

The trick would be to minimize mass.  A switch almost certainly weighs less than two 20m Cat 6 cables, but it probably doesn't weigh less than 3 pairs of 2m cables.  No doubt somebody spent a lot of time of topology.  But once you get everything wired up, it's... just another LAN.  Give each Starship its own private subnet and they'll happily talk to one another.  Then it's just a question of how you allocated the computational resources.

I don't think off-axis thrust is ever a virtue.  But with full access to all the ullage thrusters, it's not difficult to keep things from rotating.  Even if the depot has CMGs, I don't think you want to load them as much as they'd have to be loaded to balance a 30-60 minute ullage burn during transfer.

BTW, here's the wikipedia article on time-triggered ethernet.  It's not really synchronous, but it's effectively isochronous for certain traffic types.  Kinda clever.  This is supposed to be what's used in the Gateway Docking System Specification, which is pressure- and latch-compatible with IDSS, but has different electrical and fluid connectors.

Yeah, off axis is not the best of things. Just wondering if there's any way of making lemonade.

In another post you set a goal of minimizing load through the lash up mechanism and followed it up with an expansion from 6 to 9 DoF to reach that goal.

Not too much mass gives a lot of structural strength. If a couple hundred kilos of mass potentially simplifies control it shouldn't be dismissed out of hand. A lot depends on control latency and adverse feedback loops between ships and the actual forces needed in the worst case.

Worst case for off axis settling thrust would be a near empty depot topping off a near full receiving ship. And whatever there is from slosh, which IIRC, is still an open question. Off axis guarantees slosh but it makes direction, if not magnitude, predictable. This is where a way to make lemonade might be handy.


Edit: added 'off axis'

[TheRadicalModerate]

Not too much mass gives a lot of structural strength. If a couple hundred kilos of mass potentially simplifies control it shouldn't be dismissed out of hand. A lot depends on control latency and adverse feedback loops between ships and the actual forces needed in the worst case.

Worst case for off axis settling thrust would be a near empty depot topping off a near full receiving ship. And whatever there is from slosh, which IIRC, is still an open question. Off axis guarantees slosh but it makes direction, if not magnitude, predictable. This is where a way to make lemonade might be handy.

I don't think this is particularly hard with a centralized processor and a distributed control bus (i.e., a LAN that can talk to everything on both ships).  It's only hard if you insist on treating it as a distributed control problem.  It doesn't have to be--other than designating a master and a failover, which is a solved problem.

[talltim007]

I may have missed it earlier in this thread, but why not use baffles or diffusers to deal with sloshing in the receiving tank?

[OTV Booster]

I may have missed it earlier in this thread, but why not use baffles or diffusers to deal with sloshing in the receiving tank?

IANARS, but what I think I see is that other than speculation, we can't characterize the slosh. There are too many options on how things will be done and no firm ground on which to base informed speculation.


IIU slosh correctly, baffles can be general purpose or specific to an angle and velocity. Might as well throw in fluid depth. Speculation: general purpose masses more and overall dampens less than task specific.


One thing that sets NSF apart from many sites is we sometimes recognize when the speculation is getting too rarified, and we shy away. Unfortunately, these speculations often get ruled out instead of getting a 'hold that thought' label.

[edzieba]

I may have missed it earlier in this thread, but why not use baffles or diffusers to deal with sloshing in the receiving tank?

Baffles and diffusers are already present to manage sloshing under thrust. The problem is that baffles and diffusers do not do much for propellant movement in microgravity; that's the realm of Propellant Management Devices. Baffles are also less effective as the tank drains, as that is when the surface-area/volume grows rapidly, the number of baffles immersed in the propellant drops, and the distance the surface neds to move in order to uncover the inlet reaches a minimum.

[InterestedEngineer]

I don't think the orbital fuel transfer system will work by acceleration.

It'll work by tricks with surface tension:

[Robotbeat]

I bet it will.

[BT52]

I bet it will.

Sorry to bother but in witch sense. I think acceleration is most straight forward way to generate similar situation as knowledge from second stage tank simulation can be taking into account.

[Robotbeat]

I bet it will.

Sorry to bother but in witch sense. I think acceleration is most straight forward way to generate similar situation as knowledge from second stage tank simulation can be taking into account.

Yeah. I meant that I think gentle acceleration will be used.

[OTV Booster]

It looks like crew SS and (presumably) the depot are doing full length contact. Of course the perennial question arises of the art departments veracity. My guess is they show what the current engineering thoughts are with some license but no contradictions.

[Twark_Main]

6 DoF, not excessive. And since the goal is to minimise mechanical loads on the coupler, then directly measuring mechanical loads on the coupler is the gold standard compared to IMUs/RADAR/LIDAR/etc.

...You need at least nine degrees of freedom:

1) 3 for translation.
2) 3 for vehicle #1 rotation.
3) 3 for vehicle #2 rotation.

The system has 9 DoF, but the stresses on the connector still only have 6 DoF (3-axis linear force + 3 axis torques). Therefore it only requires 6 strain gauge channels, plus redundancy if needed.

I don't think figuring everything via strain gauges will work.

Who does?

Has anyone proposed getting rid of gyroscopes, accelerometers, star trackers, and GPS and using only the strain gauges? I haven't seen such a proposal.

[TheRadicalModerate]

Has anyone proposed getting rid of gyroscopes, accelerometers, star trackers, and GPS and using only the strain gauges? I haven't seen such a proposal.

No, nobody was proposing gutting the GN&C sensor suite.  But the argument was whether you could implement distributed control using just the strain gauges.  This all fell out from a discussion about distributed vs. centralized control for the docked (or loosely-coupled) system.

I'm in the centralized control camp, because gluing the two avionics networks together via an ethernet (xBaseT) connection is easy, and master/slave determination (oops, sorry--leader/follower determination) is a solved problem.

[Twark_Main]

Has anyone proposed getting rid of gyroscopes, accelerometers, star trackers, and GPS and using only the strain gauges? I haven't seen such a proposal.

No, nobody was proposing gutting the GN&C sensor suite.  But the argument was whether you could implement distributed control using just the strain gauges.

I think you're just misreading.

The first post to mention strain gauges says:

I was thinking about some additional sensors to be used for refining the GNC to be able to make the second SS fly very precisely along with the primary SS. And that is nothing more than a bunch of strain gauges that report 3 axis [sic] load values at the... connections

I think you read "nothing more" and misinterpreted it as discarding all the other sensors, despite the bold text. But Atlas just meant that those are the only additional sensors and nothing more beyond that.

Agreed, centralized control is the way.

[TheRadicalModerate]

Hey, has anybody looked carefully at the refueling animation on the SpaceX Starship page?  S24 has two raceways on its dorsal surface, but they don't look exactly like the ones in the animation.  Are there any details to be gleaned on docking refueling connectors from the animation?

It's possible, maybe even likely, that the animation is notional or fanciful, but there might be some hints in there.

[Twark_Main]

As seen on TV:



Looks like a pair of twin "standpipes" on the dorsal midline, going from the top of the fuel tank to the bottom of the LOX tank. Features are also seen at the top of the LOX tank, so we may be looking at 3-4 external pipes not just 2.

Refilling fluid connections between ships are made at the top and bottom of the standpipes. Minimal design.

Above the standpipes looks like a combined zero-thrust fuel vent + pair of RCS thrusters.

Below, it looks like the Stage 0 umbilical port. I don't see anything on either side that would connect over, so it looks like it's unused during refilling.

[TheRadicalModerate]

As seen on TV:

Thanks, that's better than the web page.

The first thing to note is that it's a double raceway in the refueling scene and a single raceway in the scene immediately following it.  That would seem to require one to increase one's "fanciful" priors.