Question Undocking Imparted Delta V

[kuddel]

Thanks Dave,
that was my knowledge so far. But still I am wondering how much rotational component that introduced.
As the shuttle is in free drift, no RCS is used (the shouldn't so close to the station, anyhow).
Let me research whether the shuttle had flywheels for attitude control, I'm not sure but I don't think they had.
That would be a "plume free" option

 

[Urwumpe]

But still I am wondering how much rotational component that introduced.

Not that much - its 700 lb(f) by all springs, on a heavy orbiter and the ODS is much closer to the COG than the RCS. Also not sure how long the spring force acts on both spacecraft.

 

[kuddel]

I found something for an "automatic undocking without crew etc."

Here they seem to use the up-firing RCS tail jets:

---------- Post added at 20:01 ---------- Previous post was at 19:21 ----------

and the ODS is much closer to the COG than the RCS

Yes the ODS being positioned in the payload bay moves it closer to the CG (of the Shuttle), but still what about situations where there's a payload (e.g. MLPM) in the bay at undocking.

That surely also adds a lot of inertia, so rotation would not be "so fast".:hmm:

[1] The MLPM on STS-131 for example had a down-mass of 9242 kg!

 

[DaveS]

Not that much - its 700 lb(f) by all springs, on a heavy orbiter and the ODS is much closer to the COG than the RCS. Also not sure how long the spring force acts on both spacecraft.

According to the APAS Reference Guide, the springs provide a force between 551 lbf and 595 lbf.

 

[Urwumpe]

@DaveS: SCOM says 700 lb in sum of all springs.

I found something for an "automatic undocking without crew etc."

Yes, also note the undocking attitude of ISS and Shuttle to understand what happens.

 

[DaveS]

Yes the ODS being positioned in the payload bay moves it closer to the CG (of the Shuttle), but still what about situations where there's a payload (e.g. MLPM) in the bay at undocking.

[1] The MLPM on STS-131 for example had a down-mass of 9242 kg!

That doesn't change the c.g much. The orbiter is designed to have the c.g well aft even without a payload, thanks to lead ballasting. That's why the heaviest payloads are always mounted in the aft-most sections of the payload bay, to control the c.g.

 

[fred18]

This might be a very stupid comment but what about deleting the docking port, apply the force and then after a bit of time recreating it? Using DelDock should cause no deltaV at all between the vehicles.
I don t know if you can have issues deleting docking ports with vessels docked to it, but I think I tested it a while ago for other purposes and it worked.

 

[kuddel]

This might be a very stupid comment but what about deleting the docking port, apply the force and then after a bit of time recreating it? Using DelDock should cause no deltaV at all between the vehicles.
I don t know if you can have issues deleting docking ports with vessels docked to it, but I think I tested it a while ago for other purposes and it worked.

I was thinking about that too, but then I read the documentation on Vessel::Undock()

/**
 * \brief Delete a previously defined docking port.
 * \param hDock dock handle
 * \return \e false indicates failure (invalid dock handle)
 * \note [B]Any object docked at the port will be undocked before the
 *   docking port is deleted.[/B]
 * \sa CreateDock, ClearDockDefinitions, DockCount, Dock, Undock
 */
bool DelDock (DOCKHANDLE hDock) const;

If "will be undocked" means "the usual way", this might not help.
But one can try and see what happens :thumbup:

---------- Post added 17-08-18 at 15:12 ---------- Previous post was 16-08-18 at 21:49 ----------

It seems that Vessel::Undock() will not apply any further forces! :thumbup:

v = vessel.get_focusinterface()
dh = v:get_dockhandle(0)
v::del_dock(dh)

This keeps the two vessels at their position without applying any further forces.


So something like this (untested) might be another thin to try

v = vessel.get_focusinterface()
dh = v:get_dockhandle(0)
-- Get docking parameter (for apply force and later re-enabling)
pos,dir,rot = v:get_dockparams(dh)

-- Delete the docking port and apply some force where it used to be...
v::del_dock(dh)
v::add_force(dir,pos) -- this needs to be checked/changed/calculated ;)

-- Re create the docking port
-- This should be done after some time and/or distance...
proc.wait_simdt(7)
newdh = V:create_dock(pos,dir,rot)

---------- Post added at 18:10 ---------- Previous post was at 15:12 ----------

Note: That script is not realistic! As it only applies a force to one vessel (self)
To make it better one needs to get the parameters of the other vessel as well and apply forces into both docking ports in opposite directions.
The possibly different accelerations of the two vessels (due to possible different masses, CG etc...) should then be handled by Orbiter core, I guess.

 

[kuddel]

Lua Script Undock Test Scenario

I couldn't resist doing a little proof of concept script here.
I had to push the shuttle with 200 kN however...is the dir vector really a unit-vector?

Doing the simple (not realistic as mentioned before) thing was quite easy in Lua I must admit. :dry:

Edit: Attachment removed (see Post#31)

 

[rcflyinghokie]

Regarding Orbiter itself, from experimenting it looks like it defaults to adding 2m/s at undocking, and this is divided among the spacecraft based on mass. Not a super realistic approach but of course it prevents undocking.

I think what we can do in NASSP is just simply compensate for this known docking velocity in our code and add what we want as the velocity. Since it is constant, it should be able to be removed constantly. Does this theory sound like a safe work around?

EDIT: Units

 

[kuddel]

Updated script
- Now both vessels get "a push"
- Scenario doesn't deactivate Shuttle RCS, now

 

[kuddel]

Regarding Orbiter itself, from experimenting it looks like it defaults to adding 2m/s at undocking, and this is divided among the spacecraft based on mass. Not a super realistic approach but of course it prevents undocking.

I think what we can do in NASSP is just simply compensate for this known docking velocity in our code and add what we want as the velocity. Since it is constant, it should be able to be removed constantly. Does this theory sound like a safe work around?

I don't think this works, as Orbiter (core) would immediately re-dock when you reduce the separation velocity.
If you however (temporarily) delete the docking port, you can apply whatever forces you like to both vessels.
You then just have to decide at what point you will re-create the docking port again[1].
See my (2nd) Lua example for the general procedure.

[1] Once the distance is bigger than Orbiter (core) threshold value, you can re-create the port again.

 

[rcflyinghokie]

I don't think this works, as Orbiter (core) would immediately re-dock when you reduce the separation velocity.

Are you saying that anything less than 0.2 m/s would automatically redock? Most of my cases impart more this this after compensating.removing this velocity, however I do have a case where the velocity would be closer to 0.08 m/s, would this be too small to avoid a redock? Keep in mind every case would impart a separation velocity of some magnitude.

---------- Post added at 12:18 ---------- Previous post was at 11:45 ----------

If you however (temporarily) delete the docking port, you can apply whatever forces you like to both vessels.
You then just have to decide at what point you will re-create the docking port again[1].
See my (2nd) Lua example for the general procedure.

[1] Once the distance is bigger than Orbiter (core) threshold value, you can re-create the port again.

So this got me thinking that there is an appropriate time to do this that is realistic, for a normal undocking, The CMP holds the docking probe switch in extend/release, at which time the capture latches are disengaged and effectively preventing recapture. This would be an appropriate simulation of deleting the docking port as long as the switch is held in extend/release (>5 seconds from the AOH)

For a LM Jettison, both docking ports should be deleted anyways as the vehicles no longer would physically be able to dock, so this small velocity here would make little difference.

I think this, coupled with the deleting of the orbiter velocity internally, is an appropriate path assuming we code it right

 

[DaveS]

Are you saying that anything less than 0.2 m/s would automatically redock? Most of my cases impart more this this after compensating.removing this velocity, however I do have a case where the velocity would be closer to 0.08 m/s, would this be too small to avoid a redock? Keep in mind every case would impart a separation velocity of some magnitude.

AFAIK, Orbiter doesn't care about the relative attitude or velocity. All it cares about is the proximity of the two docking ports to each other. As long as the proximity of the docking ports is less than 0.1(?)m, you get contact and capture.

 

[rcflyinghokie]

AFAIK, Orbiter doesn't care about the relative attitude or velocity. All it cares about is the proximity of the two docking ports to each other. As long as the proximity of the docking ports is less than 0.1(?)m, you get contact and capture.

That makes a lot more sense than the velocity, so it wants x meters of separation after a timestep or it will reconnect?

 

[DaveS]

That makes a lot more sense than the velocity, so it wants x meters of separation after a timestep or it will reconnect?

Not about timesteps. Only distance. Orbiter checks the distance and if it inside that hardcoded distance, you'll get a harddock. Think of it like magnets. Once inside the attraction range, the magnet will snap to the attracted surface.

 

[Urwumpe]

Not about timesteps. Only distance. Orbiter checks the distance and if it inside that hardcoded distance, you'll get a harddock.

Yes, and its a lot of distance for a docking, AFAIR, we had the problem that we had been unable to capture the attachment of the ODS ring in SSU before it snapped on the docking port.

 

[DaveS]

Yes, and its a lot of distance for a docking, AFAIR, we had the problem that we had been unable to capture the attachment of the ODS ring in SSU before it snapped on the docking port.

That's where the attachment system shines over the docking port system as it allows the developer to specify the capture distance (we already do this for the RMS). It also allows the developer to specify the separation velocity (once again we do this for the RMS (0) and our upper stages).

 

[GLS]

That's where the attachment system shines over the docking port system as it allows the developer to specify the capture distance (we already do this for the RMS). It also allows the developer to specify the separation velocity (once again we do this for the RMS (0) and our upper stages).

... but then in the attachment system, a child vessel can't "thrust" the parent vessel, only the other way around. :shrug:
For SSU that means the "SRB thrusters" can't be in the SRBs, but for NASSP it would mean no DPS burns while docked... so no happy ending for Apollo 13... :uhh:

 

[rcflyinghokie]

... but then in the attachment system, a child vessel can't "thrust" the parent vessel, only the other way around. :shrug:
For SSU that means the "SRB thrusters" can't be in the SRBs, but for NASSP it would mean no DPS burns while docked... so no happy ending for Apollo 13... :uhh:

Haha yeah the docked DPS burns work so well right now too! However we use both attachment and docked, attached is "soft dock" and docked is "hard docked" so we utilize both. Attaching does cause us some headaches as it is though when say docking with the SIVB/LM. Because it's attached, the forces arent right and the SIVB starts rolling left and right oscillating and just getting confused until the vessels are hard docked.