Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

Are you sure the wings are too low and not that the model has maybe a small rotation around X that makes it wrong?

 

[DaveS]

Are you sure the wings are too low and not that the model has maybe a small rotation around X that makes it wrong?

The rest is A-OK based on the side schematics:

 

[Urwumpe]

The rest is A-OK based on the side schematics:

Well, some small tiny differences are also there. I am not sure of this is really a showstopper here or if we can try to include it in the current release if it is done, or delay it one release, if it isn't done.

Same with a MECOCalc successor, a better solution would be nice for the next release, but it is not priority... will try starting such a project tonight in Java, because I had been programming in C++ at work for 90 hours in the past two weeks and really need to see another programming language.

EDIT: About the path for the MECOCalc successor - Any suggestions better than "./OrbiterSDK/src/UltraToolbox"? Instead of many small independent tools, I want to make a single modular toolbox application, that eventually covers everything from vehicle configuration, over ascent and mission planning to scenario file creation. Tools for programming the DPS systems or decoding telemetry streams will also go there eventually. Thanks to modularity, not everything needs to be considered now in the planning.

 

[SiameseCat]

Well, some small tiny differences are also there. I am not sure of this is really a showstopper here or if we can try to include it in the current release if it is done, or delay it one release, if it isn't done.

Same with a MECOCalc successor, a better solution would be nice for the next release, but it is not priority... will try starting such a project tonight in Java, because I had been programming in C++ at work for 90 hours in the past two weeks and really need to see another programming language.

EDIT: About the path for the MECOCalc successor - Any suggestions better than "./OrbiterSDK/src/UltraToolbox"? Instead of many small independent tools, I want to make a single modular toolbox application, that eventually covers everything from vehicle configuration, over ascent and mission planning to scenario file creation. Tools for programming the DPS systems or decoding telemetry streams will also go there eventually. Thanks to modularity, not everything needs to be considered now in the planning.

The code is currently in "Orbitersdk/Space Shuttle Ultra" and "Orbitersdk/libUltra", so "Orbitersdk/UltraToolbox" would be better than "Orbitersdk/src/UltraToolbox", I think.

 

[Urwumpe]

The code is currently in "Orbitersdk/Space Shuttle Ultra" and "Orbitersdk/libUltra", so "Orbitersdk/UltraToolbox" would be better than "Orbitersdk/src/UltraToolbox", I think.

Yes... but thinking more about it, it would maybe be better to have a structure "./UltraToolbox/src" since it isn't directly related to OrbiterSDK. It only depends on SSU and Orbiter Installations.

 

[SiameseCat]

I'd prefer to leave it in Orbitersdk so we don't clutter the main Orbiter directory with an additional folder (which will only be needed by SSU developers). Also, even if it doesn't use Orbiter. it is still code, and I think it's better to have all the SSU-related code in a single folder.

Also, at some point we need to start developing a MCC simulation for SSU, which will run in Orbiter. We should probably think carefully about what goes in the MCC simulation and what goes in the UltraToolbox.

 

[Urwumpe]

I'd prefer to leave it in Orbitersdk so we don't clutter the main Orbiter directory with an additional folder (which will only be needed by SSU developers). Also, even if it doesn't use Orbiter. it is still code, and I think it's better to have all the SSU-related code in a single folder.

Yes... but it clutters anyway.

Also, at some point we need to start developing a MCC simulation for SSU, which will run in Orbiter. We should probably think carefully about what goes in the MCC simulation and what goes in the UltraToolbox.

Well, the toolbox could also act as MCC simulation, but I would say that the user interface might get too overloaded then. The toolbox should act mostly as mission planning and mission analysis tool, and as such, mostly play offline. But including a tool to capture a telemetry stream from SSU would fit into it.

 

[DaveS]

Yes... but it clutters anyway.



Well, the toolbox could also act as MCC simulation, but I would say that the user interface might get too overloaded then. The toolbox should act mostly as mission planning and mission analysis tool, and as such, mostly play offline. But including a tool to capture a telemetry stream from SSU would fit into it.

Let's just focus on the mission planning for now, as I think MCC ops is quite far away as we don't even have any systems to keep an eye.

 

[SiameseCat]

The main thing that I'm concerned about is burn targeting, which is mostly done by the shuttle. We can have the offline tool compute basic transfers (i.e. change orbit height), but for something like rendezvous targeting it would be really helpful to have something built in to Orbiter.

 

[DaveS]

The main thing that I'm concerned about is burn targeting, which is mostly done by the shuttle. We can have the offline tool compute basic transfers (i.e. change orbit height), but for something like rendezvous targeting it would be really helpful to have something built in to Orbiter.

The quickest way would be to show the target Ha and Hp on MMs 104, 105, 106, 202, 301, 302 and 303. Currently they only show Current Ha and Hp.

 

[Donamy]

I think we should freeze the mesh as is. It will never be perfect, but it is better than any others out there, including the ones available from NASA.

 

[Urwumpe]

The main thing that I'm concerned about is burn targeting, which is mostly done by the shuttle. We can have the offline tool compute basic transfers (i.e. change orbit height), but for something like rendezvous targeting it would be really helpful to have something built in to Orbiter.

I don't want to make the planning for that all while also flying the Shuttle. While the exact precise calculation should better be done during Orbiter session, describing which kind of maneuver is planned to be executed in a mission file sounds like the more comfortable solution. If you need a realistic amount of time for doing operations inside the Shuttle, you can't be expected to also do all the mission planning on the fly. The player needs a flight plan and all what we can squeeze from a CPU for assisting the player. Including at one not too far future having pilot and MS to assist the player in his role as commander.

But for now, the goal is rather simple:

• Select orbiter and which other vehicles should be in a scenario.
  • Define reference orbit parameters of ISS or Hubble
• Plan a launch window
  • Use target orbit data or
  • manually enter launch date and time.
• Calculate ascent parameters
  • Direct
  • Standard
• Calculate I-Loaded OMS burns (even if we still don't have them I-loaded :dry.
• Write mission file and generate a set of scenarios.

I suggest using a special file format for the editor - this way I can include a lot of metadata into the planning that we can ignore happily in Orbiter (remarks, notes, alternative versions of the flight plan)


It would be no big deal to support also other vessels than the Space Shuttle in such a tool. If you can make plans for the Space Shuttle, you can nearly plan everything.

 

[STS]

• Select orbiter and which other vehicles should be in a scenario.
  • Define reference orbit parameters of ISS or Hubble

• 
  
  Would be possible to have custom vehicles/stations as reference orbit parameters?

 

[Urwumpe]

Would be possible to have custom vehicles/stations as reference orbit parameters?

Yes, it would be no problem, I just don't want to design for too much flexibility now. In this case, it would be just a new set of data with a different name added to a list of trajectory sources.

 

[DaveS]

Checked in all my changes to the Orbiter, RMS, OBSS, DFI pallet, External Airlock, ODS, Ku band DA and OBSS MPMs, both meshes and textures. Everything should work and compile. The only thing that's dogging me is the position of the ODS C/L camera view. I don't understand that code so it is currently in wrong location relative to the airlock/ODS.

I consider these updates the RC ones, so unless there' a major flaw discovered, no more updates will be made prior to release.

 

[Donamy]

A chorus of "Halleluyah" can be heard from the heavens.

 

[DaveS]

Where do we stand on getting the tickets listed on SourceForge closed?

 

[Urwumpe]

Where do we stand on getting the tickets listed on SourceForge closed?

I look at the ODS ticket... do you know the steepness of the spiral rails for the ODS extension arms?

 

[DaveS]

I look at the ODS ticket... do you know the steepness of the spiral rails for the ODS extension arms?

Measured it and it came out as 35.2°s.

 

[Urwumpe]

OK, I estimated it to be 30°, so not far away.

I could maybe also look at the animation for rotating the extension tubes when correcting this