API Question Getting the position of another vessel during the first clbkPreStep

[GLS]

Like the title says, is there a way to find the global or relative position of another vessel during the first run of clbkPreStep? The usual means don't work: v->GetGlobalPos() gives (0,0,0), and v->GetRelativePos() uses (0,0,0) as the other vessel's position... is this a bug, or a feature?

 

[Urwumpe]

Is it an attached vessel?

(I think those values should already be established at clbkPostCreation, but I am not sure)

 

[Face]

Like the title says, is there a way to find the global or relative position of another vessel during the first run of clbkPreStep? The usual means don't work: v->GetGlobalPos() gives (0,0,0), and v->GetRelativePos() uses (0,0,0) as the other vessel's position... is this a bug, or a feature?

I could imagine that the info is simply not there yet, because Orbiter's engine did not load/decode/calculate the position information for all vessels at this point of time. Then it might be a feature to return at least zero instead of NaN or somesuch.

But according to Martin's diagram, this is not the case:


There it is made clear that the initial world state ([math]S_0[/math]) should be established before the first clbkPreStep goes out, so a function taking positions of other vessels into account should return the proper values. Therefore, I'd say it is a bug.

 

[GLS]

Is it an attached vessel?

(I think those values should already be established at clbkPostCreation, but I am not sure)

Yep, so we know where SSU's payloads are.

I could imagine that the info is simply not there yet, because Orbiter's engine did not load/decode/calculate the position information for all vessels at this point of time. Then it might be a feature to return at least zero instead of NaN or somesuch.

But according to Martin's diagram, this is not the case:
View attachment 14984

There it is made clear that the initial world state ([math]S_0[/math]) should be established before the first clbkPreStep goes out, so a function taking positions of other vessels into account should return the proper values. Therefore, I'd say it is a bug.

The (own) vessel's position is available, so some calculations occur.
Changing the order of the vessels in the scenario file changes nothing. I'll try to get the position of vessel A from vessel B and vice-versa in the first step to see what happens.

 

[Urwumpe]

Yep, so we know where SSU's payloads are.

Shouldn't work in the first time step because of the ordering of the vessels in Orbiter... during the first time step, they are not fully attached, but attach during the first propagation of them. They float around somewhere else and then jump to the right places during the first timestep. (You can observe it when you start paused)

Of course, we actually know where the payloads are, because they are attached. But Orbiter doesn't tell the truth then.

 

[GLS]

I'll try to get the position of vessel A from vessel B and vice-versa in the first step to see what happens.

Here are the interesting results I got when calling GetGlobalPos() for the own vessel and for another (vessels are attached, vessel B has no RPOS, etc):

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel B
A {-76975518214.058441, -7176475.6313778162, -129628502440.62596}
B {-76975518215.850647, -7176472.5618840335, -129628502442.09454}

Switching the order of the vessels in the scenario gives this:

vessel B
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

...and no, there is no mistake on the second run, vessel B really gets (0,0,0) for it's own position.... :shifty:
The order in which the 2 GetGlobalPos() calls are made doesn't change the results.

Separating the vessels (and adding RPOS, etc to vessel B) gives this:

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

vessel B
A {-76975518213.739502, -7176476.3046060400, -129628502440.38686}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

(switch order)
vessel B
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

This indicates the issue is only for attached vessels.
Re-attaching the vessels, keeping the state vector in vessel B's scenario block, give this:

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel B
A {-76975518214.058441, -7176475.6313778162, -129628502440.62596}
B {-76975518215.850647, -7176472.5618840335, -129628502442.09454}

(switch order)
vessel B
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

.. the same as the if vessel B has no RPOS, etc, so it seems like something is slipping thru the cracks somewhere...


BTW: only vessel B had the ATTACHED scenario entry, I didn't test playing with that.

---------- Post added at 12:50 PM ---------- Previous post was at 12:47 PM ----------

Shouldn't work in the first time step because of the ordering of the vessels in Orbiter... during the first time step, they are not fully attached, but attach during the first propagation of them. They float around somewhere else and then jump to the right places during the first timestep. (You can observe it when you start paused)

Of course, we actually know where the payloads are, because they are attached. But Orbiter doesn't tell the truth then.

That's what I'm trying to fix, hence my doubt about this Orbiter behaviour.

 

[martins]

I'll look into it. Attached vessels don't go through a full update phase, but simply wait to be updated by their parent vessel. This may mean that they skip some initialisation step and only update once the parent has gone though its own first update. I'll try to initialise the attachment before clbkPostCreation.

Incidentally, I was wondering if it is time to retire the attachment interface altogether. It may be more trouble than it's worth, and now that the docking interface is a bit more robust (works for landed vessels) there may be no more need for attachments. Attachments cause major problems when they are mixed with docking connections, since this breaks the clear parent-child relationships, causing all hell to break loose when it comes to the update pipeline.

Is anybody particularly attached to attachments?

 

[DaveS]

I'll look into it. Attached vessels don't go through a full update phase, but simply wait to be updated by their parent vessel. This may mean that they skip some initialisation step and only update once the parent has gone though its own first update. I'll try to initialise the attachment before clbkPostCreation.

Incidentally, I was wondering if it is time to retire the attachment interface altogether. It may be more trouble than it's worth, and now that the docking interface is a bit more robust (works for landed vessels) there may be no more need for attachments. Attachments cause major problems when they are mixed with docking connections, since this breaks the clear parent-child relationships, causing all hell to break loose when it comes to the update pipeline.

Is anybody particularly attached to attachments?

The main problem with docking connections currently are that they can't be moved dynamically like attachment points can (current uses of the attachment points are mainly for RMS End Effectors which can be changed in position as well as direction dynamically). Docking ports currently can't undergo this.

This is what lead me to create this issue back in 2015: http://www.orbiter-forum.com/project.php?issueid=1204

 

[Face]

Anybody nostalgic about attachments?

Not nostalgic, but I wonder if modelling things like Shuttle stacks with docking points is really the way to go. The term "attachment" already is a better fit.

If attachments go away, the only other option to model these vehicles (vs. docking it together) is the "classic" way of having a monolithic vessel that hides meshes and spawns vessels at jettison of elements.

Then again I always liked that later approach much more, even if it's just for the cleaner vessel list that doesn't get polluted by things like blabla_Booster or whatsit_Bay (no offense, Doug ).

 

[gattispilot]

Attachments, YES!!!. You can move a attachment point but not a dock point. They can be used for cranes,....

 

[indy91]

Not nostalgic, but I wonder if modelling things like Shuttle stacks with docking points is really the way to go. The term "attachment" already is a better fit.

If attachments go away, the only other option to model these vehicles (vs. docking it together) is the "classic" way of having a monolithic vessel that hides meshes and spawns vessels at jettison of elements.

This exactly was the plan for the first Orbiter 2016 compatible version of NASSP.

Simulating the Saturn, CSM and LM separately already on the launch pad and not as one vehicle, as it works right now, will be a huuuge simplification and will allow much more flexible launch scenarios.

As long as there is a good method to stack vessels like this I don't care if it is called docking or attachment.

 

[Face]

Simulating the Saturn, CSM and LM separately already on the launch pad and not as one vehicle, as it works right now, will be a huuuge simplification and will allow much more flexible launch scenarios.

Wouldn't that also mean that the whole code for all involved parts already needs to be run right from start? I.e. Pad, Stages, CSM, LM, perhaps even rovers and such must be loaded at launch scenarios, and their callback routines are run although the elements are effectively inactive at first. Could that influence performance in contrast to the previous approach?

 

[indy91]

Wouldn't that also mean that the whole code for all involved parts already needs to be run right from start? I.e. Pad, Stages, CSM, LM, perhaps even rovers and such must be loaded at launch scenarios, and their callback routines are run although the elements are effectively inactive at first. Could that influence performance in contrast to the previous approach?

Yes it will influence performance, but hopefully not too much. For the LM mostly a bunch of standby heaters and the rover should be completely off. Powered down systems shouldn't be very performance heavy.

The problem is, right now the CSM is fully integrated with the Saturn class. It's not a separate entity in the code. Recently the AGC version (Sunburst 120) flown on Apollo 5 became available for the Virtual AGC project. But there currently is no way to run it, because only the CSM and the Saturn are doing anything on the pad. The LM only starts existing upon separation from the Saturn stage.

Also, our simulation of the LVDC should be running in the S-IVB stage after CSM separation, to hold attitude for TD&E and to perform a maneuver to get away from the CSM/LM. That is also not really easily possible right now.

We already have an interface in place for transferring power from the CSM to the LM etc. We will be able to use that to transfer information from e.g. the IU to the Flight Control Computer of the S-IC.

So, it is certainly possible to do all this in the monolithic vehicle on the pad, but a lot of extra code will be necessary to integrate both the CSM and LM with the Saturn. I think it is the cleaner solution to separate them.

 

[Face]

I think it is the cleaner solution to separate them.

I see. But do you think it is good to stack those elements together with the docking option (in contrast to attachments)? AFAIK, docked vessels still get influenced by gravity, bring in their mass, possibly unbalance the stack, get their aerodynamics updated and so forth. It sure will simulate reality closer, but is the added development complexity worth the effects?

I think for such things attachments are better suited. If they are gone, the classic implementation model will be easier to do. In your case, if you cleanly separate the classes, it should be not too hard to keep a monolithic vessel. I've done that with AscensionUltra already... each base elements (hangars, cranes, radars, etc.) were modeled as classes in such a way that the monolithic "super" class (the base as a whole) relayed the necessary callbacks to its "sub" classes. This architecture allowed a quick extraction of e.g. the radar-tracker dish functionality into its own vessel representation.

IF the attachments are gone... I'd keep them, if you ask me.

 

[indy91]

I see. But do you think it is good to stack those elements together with the docking option (in contrast to attachments)? AFAIK, docked vessels still get influenced by gravity, bring in their mass, possibly unbalance the stack, get their aerodynamics updated and so forth. It sure will simulate reality closer, but is the added development complexity worth the effects?

How are attachments different in that regard? Is there no Superstructure CG calculated with attachments? I don't really know how that works, luckily it most likely won't be my job to work on this anyway. But if we still have to define parameters for the whole vehicle, if we attach instead of dock the stages together, then attachments might not be the right way.

Our Saturns use the same implementation of the Thrust Vector Control as the real rockets. Same equations, same gains, etc. So having a more realistically behaving rocket should make control better, hopefully, not worse.

I think for such things attachments are better suited. If they are gone, the classic implementation model will be easier to do. In your case, if you cleanly separate the classes, it should be not too hard to keep a monolithic vessel. I've done that with AscensionUltra already... each base elements (hangars, cranes, radars, etc.) were modeled as classes in such a way that the monolithic "super" class (the base as a whole) relayed the necessary callbacks to its "sub" classes. This architecture allowed a quick extraction of e.g. the radar-tracker dish functionality into its own vessel representation.

IF the attachments are gone... I'd keep them, if you ask me.

Also a problem, you can't switch between CSM cockpit and LM cockpit. What if we want a T-22h launch scenario with the LM Closeout procedures one day? Ok, ok, not all that big of an issue. :lol:

 

[Face]

How are attachments different in that regard? Is there no Superstructure CG calculated with attachments?

Excerpt from API_Reference.pdf, chapter 7:

Docking ports allow individual vessel objects to connect with each other, forming a superstructure. Orbiter automatically calculates the physical properties of the superstructure from the properties of the individual constituents. In particular, the following properties are managed by Orbiter:
• total mass: The mass of the superstructure is the sum of masses of the individual vessels
• centre of mass. The centre of mass of the superstructure is calculated from the individual vessel masses and their relative position
• inertia tensor: A simplified rigid-body model is applied to calculate an inertia tensor for the superstructure.
• effects of forces: any forces acting on individual vessels (thrust, drag, lift, etc.) are transformed into the superstructure frame and applied.



Similar to docking ports, attachment points allow to connect two or more vessel objects. There are a few important differences:
• Docking ports establish peer connections, attachments establish parent-child hierarchies: A parent vessel can have multiple attached children, but each child can only be attached to a single parent.
• Attachments use a simplified physics engine: the root parent alone defines the object's trajectory (both for freespace and atmospheric flight). The children are assumed to have no influence on flight behaviour.
• Orbiter establishes docking connections automatically if the docking ports of two vessels are brought close to each other. Attachment connections are only established by API calls.

Also a problem, you can't switch between CSM cockpit and LM cockpit. What if we want a T-22h launch scenario with the LM Closeout procedures one day? Ok, ok, not all that big of an issue. :lol:

In AU, I've also worked with virtual "cockpits" inside the monolithic vessel. It was possible to switch views between all of the command-rooms of the base, e.g. hangars and towers. I think it is not that big of an issue to implement this in a modular way. But YMMV, of course.

 

[indy91]

Excerpt from API_Reference.pdf, chapter 7:

Thanks for the excerpt. Attachments might not be the way to go then. But I'm sure @dseagrav has already has an idea how he wants to do it. If we have enough control over the docking method for stage separations, then having the stages "docked" will work pretty well, I think.

In AU, I've also worked with virtual "cockpits" inside the monolithic vessel. It was possible to switch views between all of the command-rooms of the base, e.g. hangars and towers. I think it is not that big of an issue to implement this in a modular way. But YMMV, of course.

I understand. However, the difference is that we have different stages, separated in a certain sequence and they should still be functional in some way after staging. Right now upon separation there is a lot of code dealing with creating a new vessel, giving it some of the properties of the combined stage etc. Another example would be the Launch Escape Tower. If you don't jettison it during the ascent, then it messes with the staging sequence. The mesh used to just vanish when the S-II stage is separated. The physical properties aren't right etc.

All this code making sure everything works despite the LET being attached could be eliminated. That's why I think it is an improvement and simplification to have the stages separated from the beginning. Of course this only applies to NASSP.

 

[Face]

Thanks for the excerpt. Attachments might not be the way to go then. But I'm sure @dseagrav has already has an idea how he wants to do it. If we have enough control over the docking method for stage separations, then having the stages "docked" will work pretty well, I think.

Keep in mind that you'll have to tell Orbiter to ignore the aerodynamic properties of the LM and some stages while they are docked together, because it doesn't take into account (AFAIK) that the stages are behind each other and the LM is within the structure. I guess your drag functions will need to be docking-aware.

That's why I think it is an improvement and simplification to have the stages separated from the beginning. Of course this only applies to NASSP.

I understand your reasoning, but I disagree. How you invest your time is non of my business, though, so - in order to not further go off-topic - I guess we can leave it at that.