Question Undocking Imparted Delta V

[rcflyinghokie]

I am wondering is the dV generated by undocking in Orbiter fixed in the Orbiter code or is it something can be edited in an add on? I ask because I am computing the math for imparted dV for NASSP undocking based on vessel mass, jettison pyros, docking probe extension, and tunnel pressure remaining.

Ideally I want to set the default orbiter undock dV to zero and use the NASSP code to control this velocity. Any insight would be greatly appreciated!

 

[ADSWNJ]

You could easily write the code to detect the sim-step when you undock, and then time an AP to trim your dV to what you need. You could even cheat by adding back in the fuel for the RCS you burn to reset the dV to what you need (e.g. alter the tank level up by 20kg of fuel). Not hard at all.

 

[GLS]

You could easily write the code to detect the sim-step when you undock, and then time an AP to trim your dV to what you need. You could even cheat by adding back in the fuel for the RCS you burn to reset the dV to what you need (e.g. alter the tank level up by 20kg of fuel). Not hard at all.

Forget the RCS and just change the state vector of the vessels as needed.

 

[Urwumpe]

The best way: Use the clbkDockEvent callback to detect the undocking and AddForce to simulate the spring force.

 

[rcflyinghokie]

Forget the RCS and just change the state vector of the vessels as needed.

Changing the vessel SV unfortunately negates one of the purposes of this idea, and that is to produce the effects of unaccounted for dV on the Apollo 11 SV causing a long landing.

But I think my point may have been missed, I want to know how to disable the imparted dV by orbiter, or know how it is calculated so I can add a calculated dV in addition for NASSP.

 

[GLS]

Changing the vessel SV unfortunately negates one of the purposes of this idea, and that is to produce the effects of unaccounted for dV on the Apollo 11 SV causing a long landing.

I was not talking about the state vector "inside" NASSP, but the "real" one that Orbiter uses.

But I think my point may have been missed, I want to know how to disable the imparted dV by orbiter, or know how it is calculated so I can add a calculated dV in addition for NASSP.

You probably can't disable that... what you can probably do is:
1) right after undocking calculate the "middle" state vector of both vessels (averaging probably won't work as the masses of each vessel affect how much dV each gets... but I don't know what Orbiter does on undocking so that needs research);
2) do whatever math you need (tunnel pressure, probe springs, etc) and calculate the dV or the force;
3a) if you calculate a dV, add dV to the average SV and put that in one vessel, and subtract dV from the average SV and put that in the other vessel;
3b) if you calculate a force, put the average SV on both vessels, and then call AddForce() and apply the force to each vessel.

IMO the force option is better as you don't have to worry about the current vessel masses.

BTW: you need to take into account the docking port position when setting the SV, otherwise you end up with the vessels ovelapping. :facepalm:

BTW2: you might have to disable one of the docking ports right after undocking, as if the vessels don't move apart enough, they will dock again.

 

[Urwumpe]

Yeah, I think BTW2 is a really important factor then, especially at high FPS.

Generally, the real docking ports should be unable to dock for a moment after undocking because of the released latches anyway, so its not unrealistic. Just a small hassle to code.

 

[rcflyinghokie]

I was not talking about the state vector "inside" NASSP, but the "real" one that Orbiter uses.


You probably can't disable that... what you can probably do is:
1) right after undocking calculate the "middle" state vector of both vessels (averaging probably won't work as the masses of each vessel affect how much dV each gets... but I don't know what Orbiter does on undocking so that needs research);
2) do whatever math you need (tunnel pressure, probe springs, etc) and calculate the dV or the force;
3a) if you calculate a dV, add dV to the average SV and put that in one vessel, and subtract dV from the average SV and put that in the other vessel;
3b) if you calculate a force, put the average SV on both vessels, and then call AddForce() and apply the force to each vessel.

IMO the force option is better as you don't have to worry about the current vessel masses.

BTW: you need to take into account the docking port position when setting the SV, otherwise you end up with the vessels ovelapping. :facepalm:

BTW2: you might have to disable one of the docking ports right after undocking, as if the vessels don't move apart enough, they will dock again.

Ahh I am completely with you now regarding the SV, I was thinking too linearly and NASSP'y, not enough coffee this morning

I have the equations and the math done for these situations based on vessel mass, so that work is already complete, it just would need to be added to the vehicles.

The BTW2 comment could potentially be an issue for a two stage undock in which the CSM extends the probe with capture latches still engaged and then releases the latches to minimize dV the LM receives. But I will look into the actual changes before dealing with this situation For a normal undock the dV should be enough to clear the docking ports I hope (usually 0.5 fps total from the probe extension)

 

[Urwumpe]

(usually 0.5 fps total from the probe extension)

Remember: simulation frames in Orbiter can be much shorter than the extension time of the probe. It might be accurate at 10 fps (0.1s), but at 100 fps (not impossible), the 0.5 fps velocity change happen in 0.01s, 50 ft/s² or 15 m/s²

Just adding velocity can give you a pretty strong jolt then.

 

[jedidia]

I don't have the documentation handy right now, but if I remember correctly, can't you pass a DV vector when you undock a vessel programmatically?

 

[Urwumpe]

I don't have the documentation handy right now, but if I remember correctly, can't you pass a DV vector when you undock a vessel programmatically?

You can at least provide a DV scalar for attachments. Not sure about docking ports right now, I can look into the Orbiter SDK when I am back home.

 

[GLS]

I don't think you can specify dV for docking ports.

 

[rcflyinghokie]

So I guess the solution is probably modifying the SV after undocking and then adding a calculated force through NASSP code?

 

[martins]

One of the reason Orbiter adds a separation velocity upon undocking is to avoid unintentional immediate redocking. Currently, docking occurs if the docking reference points are below a threshold distance, and the separation is closing.

This could be avoided by adding the notion of "arming" docking ports before docking can occur, but so far this is not implemented. It might also add an element of tedium if you realise that you are flying through your docking target, because you forgot to arm the docking port ...

Note that for attachments (as opposed to docking connections), connections are never established automatically on proximity, so there is a provision for user-defined separation velocity.

Edit: I guess I could add an extended undocking function that allows to specify the separation velocity, but this would always have to be (sufficiently) positive.

 

[Urwumpe]

Well, right now, the best way to implement realistic soft docking is by creating or deleting a docking port depending on docking state and use attachments for handling the motion.

There are just some minor realism issues because conservation of impulse has to be implemented by the add-on in both docking and undocking.

 

[rcflyinghokie]

One of the reason Orbiter adds a separation velocity upon undocking is to avoid unintentional immediate redocking. Currently, docking occurs if the docking reference points are below a threshold distance, and the separation is closing.

Makes total sense. I just wonder if it would be simple to allow an addon to control this velocity exclusively.

For NASSP there would never be a zero velocity undocking (save for the "soft undock" in which the vehicles would revert from hard dock to "attached" I believe which could pose problems of it's own)

Note that for attachments (as opposed to docking connections), connections are never established automatically on proximity, so there is a provision for user-defined separation velocity.

Yeah we use this (I believe) for our soft dock condition.

I guess I could add an extended undocking function that allows to specify the separation velocity, but this would always have to be (sufficiently) positive.

This could potentially be useful. What would be a "sufficient" velocity? For a hard dock to undock, I was looking at no smaller than 0.5 feet/sec (probe extension imparted velocity and zero tunnel pressure)

EDIT: I could also ignore reattaching I believe under certain conditions, that would be more realistic on our end (ie only re attaching if the capture latches were engaged)

 

[DaveS]

I guess this feature request from 2015 is relevant to this thread: https://www.orbiter-forum.com/project.php?issueid=1204

 

[kuddel]

A little side question here:

As a read through this thread I tend to think of a Force parameter that could be optionally added to the Vessel::Undock() call.

I then thought of the Space Shuttle undocking and wondered, how did the real Shuttle handle the problem with the offset center of gravity (of the shuttle) during undocking?
If the springs would just apply a force straight into the docking direction I would assume that a little rotational component would be incorporated in that action (as the force vector does not go strait through the COG...)

Anyone having infos on that?

 

[rcflyinghokie]

A little side question here:

As a read through this thread I tend to think of a Force parameter that could be optionally added to the Vessel::Undock() call.

I then thought of the Space Shuttle undocking and wondered, how did the real Shuttle handle the problem with the offset center of gravity (of the shuttle) during undocking?
If the springs would just apply a force straight into the docking direction I would assume that a little rotational component would be incorporated in that action (as the force vector does not go strait through the COG...)

Anyone having infos on that?

The AddForce is what we plan on using for this, actually. We are crunching the numbers to add it to the undocking code. And through some experimenting, it seems that Orbiter always imparts 0.2fps, divided between the spacecraft proportional to the masses.

And I honestly don't know how the shuttle worked with this, but it could be similar to the Apollo soft undock I mentioned earlier, where it undocks to a point where it doesnt impart a velocity, so the RCS can take care of separation? You have me curious now too! Research time!

 

[DaveS]

And I honestly don't know how the shuttle worked with this, but it could be similar to the Apollo soft undock I mentioned earlier, where it undocks to a point where it doesnt impart a velocity, so the RCS can take care of separation? You have me curious now too! Research time!

The ODS/PMA was held together by a series of hooks (ODS) and latches (PMA). When the Undock button was pushed the hooks and latches would begin to drive open, a process that took around 2½ minutes. Once the hooks and latches were fully open a set of compressed springs in the ODS would gently push the two vehicles apart. These springs had been compressed since hard-dock occurred. Soft-dock was contact and capture of the PMA with the extended ODS docking ring.

The attitude control systems on both spacecraft were inhibited for the undocking leaving both in free drift to prevent any recontacts. Once the orbiter had passed the 50' mark, the orbiter RCS was re-enabled.

---------- Post added at 08:50 PM ---------- Previous post was at 08:38 PM ----------

This schematic shows the layout of the ODS: https://www.dropbox.com/s/7oiabunx6nsorbk/APDS_layout.jpg?dl=0