SSU V1.25 Release

[SiameseCat]

Here's my suggestion: when the ODS ring is extended, have a docking port at the appropriate location. When SSU actually docks, try to attach the two vessels (and delete the SSU-side docking port).

 

[Donamy]

No way to get it to retract slowly I suppose.

 

[DaveS]

No way to get it to retract slowly I suppose.

There is. It's the reason why why use an attachment point: docking ports can't be modified like with an animation so we use the attachment system.

Upon contact and capture, the ISS is attached to the ODS attachment point like a payload to SRMS end effector. This allows use to modify the position of ISS the way we want, IE retract it along with the ODS ring. Once the ring is the ins "final position"(fully retracted into the ODS) harddocking is done throug the normal means of a docking port.

So to summarize:

Soft docking: Attachment system so we can retract the ring along with the captured ISS

Harddocking: Normal docking port system since we don't need any fancy stuff with ISS.

 

[SiameseCat]

Well, after docking you'd delete the docking port and use attachments for retraction. Once the ODS ring is completely retracted, you could use docking ports again.

 

[Urwumpe]

Well, after docking you'd delete the docking port and use attachments for retraction. Once the ODS ring is completely retracted, you could use docking ports again.

I think that is possible - but also pretty annoying. We would have a fixed connection (docking) even before retraction. We would have to undock, delete and capture the ISS even for just animating a damping oscillation of the ring. of course, with the speed of the ISS already reset to zero before we mess with it.

I think this docking port solution creates more trouble as it solves. Currently, the big problem is just that the loop for scanning for docking rings can take a lot of time in a time step, if the ISS would consist of multiple modules with many attachment points. Even if we already know that a vessel is not interesting for us.

EDIT: I fixed the orientation of the centerline camera, it might now be helpful to correct the sense switch effects for the inverted orientation

 

[DaveS]

Currently, the big problem is just that the loop for scanning for docking rings can take a lot of time in a time step, if the ISS would consist of multiple modules with many attachment points. Even if we already know that a vessel is not interesting for us.

Well, currently we do have a FPS impact, unknown where it comes from at high time acceleration. It's even noticeable at 1x as a slight hick-up every 1 second when looking around in the flight deck view.

If we could track down this bug and eliminate it, I think we could live it with a slight performance impact.

 

[tblaxland]

I think this docking port solution creates more trouble as it solves. Currently, the big problem is just that the loop for scanning for docking rings can take a lot of time in a time step, if the ISS would consist of multiple modules with many attachment points. Even if we already know that a vessel is not interesting for us.

Since for any given shuttle mission you know where you are going to dock, couldn't the target vessel and the docking port of interest be nominated in the scenario file?

If there is also an APASxx attachment point at that docking port, you can use your ODS animation, otherwise just use a standard Orbiter docking (or alternatively create the attachment point you need and still use your ODS animation).

If you use the scenario file settings to set the base/port variables in VESSELSTATUS, you can then use the Docking MFD to change the target docking port in flight, if the mission requires it. The downside is that this potentially involves using a non-shuttle MFD in flight and is therefore less "realistic" but I don't see that as a big issue given the relative infrequency.

 

[SiameseCat]

I think that is possible - but also pretty annoying. We would have a fixed connection (docking) even before retraction. We would have to undock, delete and capture the ISS even for just animating a damping oscillation of the ring. of course, with the speed of the ISS already reset to zero before we mess with it.

I think this docking port solution creates more trouble as it solves. Currently, the big problem is just that the loop for scanning for docking rings can take a lot of time in a time step, if the ISS would consist of multiple modules with many attachment points. Even if we already know that a vessel is not interesting for us.

EDIT: I fixed the orientation of the centerline camera, it might now be helpful to correct the sense switch effects for the inverted orientation

I'm not sure if you're doing this already, but at the start of the sim you could get a list of all vessels with APAS9 attachment points, and only check those vessels at each step.
The sense switch was coded for the correct centerline camera orientation, so it shouldn't need updating.
EDIT: I take that back. Sense switch needs updating.


-----Post Added-----


Sense switch fixed now.

 

[Urwumpe]

Have the detection code implemented, looks now like it is worth the money.

I notice that Orbiter already docks the vessels when the ISS barely touches the capture ring - maybe we need some cheating there to make sure we can get capture at all.


Does somebody know, which sensors indications are used for activating the "initial contact" signal? I have descriptions of the capture indication, but not for initial contact.

 

[DaveS]

Does somebody know, which sensors indications are used for activating the "initial contact" signal? I have descriptions of the capture indication, but not for initial contact.

According to an APAS Reference Guide I have, the INITIAL CONTACT light is triggered by the active ring ball screws physically move.

That's all I have on the subject though.

 

[Urwumpe]

According to an APAS Reference Guide I have, the INITIAL CONTACT light is triggered by the active ring ball screws physically move.

OK, that is what I somehow expected, but I was not sure if any indication of the capture contacts is also used.

------------------------------------

Offtopic: Just watching "Space Cowboys"... they really seem to have filmed it in the JSC and the SMS, but they sure changed the CRT displays for better looks... usually the CRT 3 shows the BFS system summary.

 

[DaveS]

Just tested the latest check-in and everything works great, except for that annoying unexplained FPS-drain at time-acceleration levels. The SSU module picks up the APAS9 attachment point on ISS just nicely.

 

[Urwumpe]

Just tested the latest check-in and everything works great, except for that annoying unexplained FPS-drain at time-acceleration levels. The SSU module picks up the APAS9 attachment point on ISS just nicely.

Can be related to the subsampling I included for the DPS simulation. It's rate is currently still about 80 times higher as needed in reality, I had chosen a higher number for security during testing, so it has to subsample often enough per timestep to test the code. We usually won't get more than 2 minor cycles (each 40 ms long) of the PASS software per time step at 50 fps.

EDIT: Reduced the rate by 80 - but still exactly the same effect. It was already unlikely because the GPCs don't execute any software, but it was not needed anyway. Something else makes the frame rate drop at time acceleration.

 

[DaveS]

EDIT: Reduced the rate by 80 - but still exactly the same effect. It was already unlikely because the GPCs don't execute any software, but it was not needed anyway. Something else makes the frame rate drop at time acceleration.

If it helps narrowing down the list of possible culprits, the drain only shows up when the vehicle is in motion. When sitting idle on the pad or on the runway post-landing the drain doesn't show up.

Is there any systems that relies on the vehicle being in motion that that could explain the drain? The only one that comes to mind is the Orbit DAP and the timers(F7, O3 and A4).

 

[Urwumpe]

If it helps narrowing down the list of possible culprits, the drain only shows up when the vehicle is in motion. When sitting idle on the pad or on the runway post-landing the drain doesn't show up.

Is there any systems that relies on the vehicle being in motion that that could explain the drain? The only one that comes to mind is the Orbit DAP and the timers(F7, O3 and A4).

I wanted to rewrite the timers anyway for integrating them into the object oriented panel code, but I also doubt that they will be the cause. Their repaint should be triggered every second in sim time, but also only if they are running. We have only two mission timers that are always running and updating during flight.

Slowing the repaint down to every second real time could improve the frame rates, but I would not expect more than 5% increase of the frame rates at x10 time warp.

 

[DaveS]

Going back a few pages, I found that this problem had been mentioned before: http://orbiter-forum.com/showpost.php?p=58407&postcount=185

 

[tblaxland]

If it helps narrowing down the list of possible culprits, the drain only shows up when the vehicle is in motion. When sitting idle on the pad or on the runway post-landing the drain doesn't show up.

Is there any systems that relies on the vehicle being in motion that that could explain the drain? The only one that comes to mind is the Orbit DAP and the timers(F7, O3 and A4).

Could it be a issue with GetElements? According to the API Ref this is computationally expensive, however I think that Orbiter would not bother calculating elements when a vessel is "landed". Perhaps you have a function that is calling GetElements every second of sim time instead of every second of real time?

 

[SiameseCat]

Could it be a issue with GetElements? According to the API Ref this is computationally expensive, however I think that Orbiter would not bother calculating elements when a vessel is "landed". Perhaps you have a function that is calling GetElements every second of sim time instead of every second of real time?

There was a problem with GetElements earlier, but this was fixed. I think it has something to do with one of the subsystems; commenting out the psubsystems->OnPostStep call fixes the problem.


-----Post Added-----


It seems to be the MasterTimingUnit::OnPropagate function that's causing the problem. Adding a return statement to the start of the function prevents the framerate drop.

 

[DaveS]

It seems to be the MasterTimingUnit::OnPropagate function that's causing the problem. Adding a return statement to the start of the function prevents the framerate drop.

Can you check in the code?

 

[Urwumpe]

It seems to be the MasterTimingUnit::OnPropagate function that's causing the problem. Adding a return statement to the start of the function prevents the framerate drop.

Sure it will. It stops the timers from being redrawn.