Space Shuttle - Development

[GinGin]

NASA made a royal mess of the whole thing in my opinion... if you're used to just doing math, it's really weird what they define and plot.

Yep, it is hard to follow sometimes with all the frame conventions that change here and there :=

Like you said, Spec 34 offsets and the Rendez vous canvas were following the same convention. That is the most important




Nasa use some plots and spec 34 offsets focused on LVLH centered on ISS, so the other way around.
Negative X would get us behind ISS and Positive Z would get us below ( so the other way around)




But that is just a question of convention, now that I understand that positive X is downrange, let's fire the Shuttle

[wlbragg]

Just a little distraction here. After bugman's post about using the NASA ISS 3d model reminded me I don't need to reinvent the wheel, I managed to acquire and scale the needed pieces for a Hubble mission in about a half hour. A little texturing, a bit of coding and we will end up with Hubble deployment and servicing missions.
There is even one of the servicing mission models we can leverage.



There is a more detailed one available as well.

[GinGin]

Impressive Wayne
The more detailled one looks beautifull
Did you find my doc usefull?

I found others, I will send you

[Thorsten]

A decent ISS model would be cool as well - though we do need to find a way to *not* load it is part of the Shuttle model for the docked version...

In other matters, I've just had a quick test of an rbar approach, and it worked well, I got the expected braking effect quite nicely.

So I'll give some love to proximity ops during the next days, there's plenty that's still amiss in that area.

[wlbragg]

we do need to find a way to *not* load it is part of the Shuttle model for the docked version...

We should be able to use the nasal place_model function to introduce it "on demand".

I was wondering if we continue to grow with different payloads if we might need to load them with nasal "on demand" as well.
Downside of course being then we have to manage real time motion or translations. We could make a standardized helper class to handle the majority of them I suppose.

We already have a massive mesh overhead and we essentially keep adding to it.
I don't suppose "sub models" are really any different overhead wise in this context?

[GinGin]

I've just had a quick test of an rbar approach, and it worked well, I got the expected braking effect quite nicely.

Nice !!
Pro of R bar

So I'll give some love to proximity ops during the next days, there's plenty that's still amiss in that area.

Even nicer
On what will you work in particular?



I found something interesting with the present in game Spec 33
While data of range ,R dot etc are not fed when we are too far from ISS ( values appeared for me quite close to the station), I have the feeling that filtesr work and "Filter minus Prop" values are fed with delta Position/Velocity.

Is it actually working ? And recalibriting the shuttle state vector with item 8 FLTR to PROP ?

[wlbragg]

Did you find my doc usefull?

Which ones? Every time I turn around you've documented or demonstrated a procedure or technique to be able to fly the Shuttle, so yes to all.
If you referring to the Hubble stuff, yes, it certainly will once I get into designing missions.

[GinGin]

@Wayne: yes Hubble xD

[Thorsten]

Is it actually working ?

Sort of... not as well as area navigation filters, but in principle using RR gives you better precision than inertial on its own.

[eatdirt]

managed to acquire and scale the needed pieces for a Hubble mission in about a half hour

YYYYYYYEEEEEEEESSSSSS!!!!!!!!! Holy cows, so beautiful!!!


Ah ah, no way I am gonna put that in a 4k orbit, the OMS-kit is not fitting anymore Time to go back to nominal missions!

[GinGin]

Sort of... not as well as area navigation filters, but in principle using RR gives you better precision than inertial on its own.

Ahh very nice, I will update it then

Do you think it would be possible to have inertial and RR informations earlier than 15 kfeet into the spec 33 ? ( RR should give some datas around 140 km)



Quick sum up of the last things I noticed during my test sessions


I made many tests with your scenario parameters. It is really working great after a few attempts. Rendez vous canvas informations are very usefull.

I still have a hard time to determine a solid time of rendez vous.
The Alpha/min value is fluctuating a lot sometimes





I saw you implemented Target ID 1 for BPV, very nice.
I tested it, it seems to work well .

I think that body vector ID 1 and 2 are inverted for ISS track
BPV 1 points tail instead of nose towards ISS
BPV2 points nose instead of tail

For other targets ( at least earth and sun), it works like intended ( BPV 1 +X and BPV 2 - X)

[eatdirt]

@Thorsten, I am syncing the fgspaceshuttle once a day, just wanted to mention that I am not able to do "save" since a while, but "resume" from already existing sessions is fine. I do start from --aircrarft=SpaceShuttle-orbit.

[Thorsten]

( RR should give some datas around 140 km)

Really? The Rendezvous workbook says 'up to 27 nm' for a passive target (and I don't think the active target mode has ever been used).

The Alpha/min value is fluctuating a lot sometimes

Well, first it's the instantaneous value, and second it unfortunately has some numerical jitter of unknown origin still. So while it gives a hint, it can't be used 'as is' for a calculation.

I think that body vector ID 1 and 2 are inverted for ISS track

Interesting... Of course I only tested body vector 3 (usually that's the one that's not working...)

just wanted to mention that I am not able to do "save" since a while, but "resume" from already existing sessions is fine.

Yeah... Expect plenty of breakage to continue for a while, there are unfortunately a few more internal changes required.

[GinGin]

eally? The Rendezvous workbook says 'up to 27 nm' for a passive target

Indeed, typo error with the unit. 140 kfeet I meant.
That is the beginning of radar navigation phase and acquisition, with lock establish at latest around 60 kfeet.

So far ( for me), data come alive below 15 kfeet ( for inertial one also). But state vector is still receiving some filters update once item 1 and 2 are enabled

Interesting... Of course I only tested body vector 3 (usually that's the one that's not working...)

I will give it another try to be sure

[Thorsten]

I advise anyone who wants to play with ISS at close range (or at all) not to be too quick to update today - I'm re-factoring the ISS code into something more organized, and there will be things broken all over the place once I push this.