Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby GinGin » Sat Aug 10, 2019 10:22 am

Indeed for the xml.
Like in real , I guess we can adjust the nominal one following the profile will fly , like a I load mission specific :)

I just changed the max to 109 ( 106 before ) and abort to 106 ( 109 ) before .
It was flipped .



For the performance issue , i have good documentation’s With propellant remaining , etc
Need to find it now :)

For me 6 pour-cent seems legit .
A ful’ Eastward with no payload .
Shuttle would have been able for polar orbit and heavy payload .
So I guess there was margin for a full earth relative speed assistance launching due east compared to what was forecasted for polar orbit.

I am wondering , because empty but with the 40000 pounds equipment was like fully loaded orbiter for your empty payload test .
Basically without payload and with that 40 kpounds , it was like if Shuttle was already full . So added to that a payload , it was a way overweight Shuttle .
So bad results on abort with full payload might be linked to that . An extra 40000 pounds outside of the envelop

I will test that . But removing like we said those 40000 pounds will give us much more realistic results to compared with real data’s.


As for the flight path . It is te gamma value , angle between local horizontal and velocity vector at meco.
GinGin
 
Posts: 648
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby eatdirt » Sun Aug 11, 2019 2:04 pm

, I'd appreciate if the people running the development branch could test whether the normal rendezvous stuff


Woo, fantastic features implemented. I am off from a real computer for a while, but I'll test asap. Thank you for the work Thorsten!
eatdirt
 
Posts: 328
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby Thorsten » Sun Aug 11, 2019 2:07 pm

So bad results on abort with full payload might be linked to that . An extra 40000 pounds outside of the envelop


Actually the problems outside of contingency aborts had often to do with too much performance :(

***

So, over the last days, I've made the decision to start with a 'Scenario' concept. This will be a fairly general way to specify an xml file which can

a) place you at a specific state vector (e.g. for trying high or low energy entry)
b) spawn co-orbiting objects around you (for practicing capture, assembly or docking)
c) can cause specific failure modes
d) places the orbital target at a specific location to practice phasing/intercept

or a combination of all of them. Currently I have support for pre-defined scenarios, but I plan to also allow to pass a user-written scenario via the commandline. To avoid dumb outcomes, scenarios are linked to a specific mission phase, so unless you start with SpaceShuttle-entry you won't be able to access entry scenarios. In this way, this is complementary to what save/resume provides, in that you use save/resume for a complete mission, possibly over days, whereas scenarios give uou direct access to specific problems.

At least for me the advantage will be that testing some things (handover between near and far zone,...) will be faster.
Thorsten
 
Posts: 10693
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby GinGin » Sun Aug 11, 2019 8:22 pm

Actually the problems outside of contingency aborts had often to do with too much performance


Ah, alright :/

After a bit of readings, 1% of propellant was equal to 15000 pounds ( with the 6:1 LO2/LH2 ratio)
FPR ( Final Performance reserve) was around 4000 pounds to allow some margins, and usually at MECO , one % max was remaining in the ET plus the 5000 pounds into the feedlines/engines

Powered flight duration was around 500 s ( 8mn 30s), and Target Parameters at MECO for the closed loop stage 2 guidance was MECO altitude ( 52 Nm ), Flight Path Angle ( the gamma we talked about) and the Inertial velocity.

So, I will continue to dig as I am already closer to the real Nasa Ascent Path and try to see what is the Propellant left over to compare it to real datas.


So, over the last days, I've made the decision to start with a 'Scenario' concept. This will be a fairly general way to specify an xml file which can


Very nice and very useful, Thanks!
GinGin
 
Posts: 648
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby amalahama » Thu Aug 15, 2019 10:45 pm

Thorsten wrote in Sun Aug 11, 2019 2:07 pm:
So, over the last days, I've made the decision to start with a 'Scenario' concept. This will be a fairly general way to specify an xml file which can

a) place you at a specific state vector (e.g. for trying high or low energy entry)
b) spawn co-orbiting objects around you (for practicing capture, assembly or docking)
c) can cause specific failure modes
d) places the orbital target at a specific location to practice phasing/intercept

or a combination of all of them. Currently I have support for pre-defined scenarios, but I plan to also allow to pass a user-written scenario via the commandline. To avoid dumb outcomes, scenarios are linked to a specific mission phase, so unless you start with SpaceShuttle-entry you won't be able to access entry scenarios. In this way, this is complementary to what save/resume provides, in that you use save/resume for a complete mission, possibly over days, whereas scenarios give uou direct access to specific problems.

At least for me the advantage will be that testing some things (handover between near and far zone,...) will be faster.


That actually sounds very cool! You might consider to extend the scenario framework to support some sort of scripting engine, so people can set interactive missions based on real data, with MCC messaging, or interactive tutorials. LUA seems to be a quite popular scripting language, although I don't know if there is an API implemented in FG so it can read/write internal variables.
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle - Development

Postby Thorsten » Fri Aug 16, 2019 4:17 am

We have a scripting language in FG, it's called 'Nasal', and if you can code in it, you can read data files, do interactive scenarios, play messages via text to speech or interface with the Shuttle systems. That kind of thing is enabled without any effort in FG - effort is to structure things to look unscripted for the end user such that he can use an xml file :mrgreen:
Thorsten
 
Posts: 10693
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby amalahama » Fri Aug 16, 2019 11:50 pm

Oh I see. So something that could be quite useful to consider in further iterations is the "trigger" concept - so several hard-coded events such as mission steps complete, distance to target, successful docking, orbital parameters, mission time etc can invoke custom-made effects - text messages, system failures, AI reactions (chase aircraft?) etc, in a way that can be customized easily through XML files or similar. That addition would pretty much open the door to simulating real (and hypothetical) missions in a richer and more stimulating environment.
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle - Development

Postby Thorsten » Sat Aug 17, 2019 4:52 am

something that could be quite useful to consider in further iterations is the "trigger" concept - so several hard-coded events such as mission steps complete, distance to target, successful docking, orbital parameters, mission time etc can invoke custom-made effects - text messages, system failures, AI reactions (chase aircraft?) etc, in a way that can be customized easily through XML files or similar.


I don't think you realize how flexible FG is right out of the box in that department - if you consider scripting scenarios, you have access to the whole property tree, i.e. you can simply set a listener to anything and use that as trigger.

Likewise, you can interact with the whole property tree.

Once you consider xml, it's just rather complicated conceptually to define an 'event' - the tutorial system is there and tries to do that, but it's been expressed by several people who used it to code scenarios that sometimes it just doesn't get the obvious and persists in doing wrong things (you have no power in the cockpit because of an electric failure, but it advises you to switch on more an more avionics).

Which is why I don't use it, because scripting is more flexible.
Thorsten
 
Posts: 10693
Joined: Mon Nov 02, 2009 8:33 am

Previous

Return to Spaceflight

Who is online

Users browsing this forum: Applebot [Bot] and 1 guest