Space Shuttle Ultra 1.25 Revision B development

[DaveS]

While I am out of C++ development in the SSU project scale... what about making an SSU mission file editor in Java?

Will that fix the bug in the Standard Insertion calculations?

 

[SiameseCat]

Will that fix the bug in the Standard Insertion calculations?

What bug? I didn't know there was a problem with Standard Insertion (unless you're talking about the OMS PEG4 targets, which is a completely different issue). The MECO targets would have to be changed, but I wouldn't expect any problems with the autopilot.

 

[DaveS]

What bug? I didn't know there was a problem with Standard Insertion (unless you're talking about the OMS PEG4 targets, which is a completely different issue). The MECO targets would have to be changed, but I wouldn't expect any problems with the autopilot.

The problem is with the calculations that the current MECO Target calculator (MECOTool.exe) does for Standard Insertion.

We went through this a while ago, but I can't find the posts now.

 

[Urwumpe]

Will that fix the bug in the Standard Insertion calculations?

A different tool, but can be fixed. I just need better constants and assumptions for improving the targeting. The MFC tool was really done quickly.

I would want to include the following functions in it:

• Mission planning
  • Orbiter configuration
  • Payload configuration
  • STS stack configuration
  • Assembly options
  • Magnetic tape image preparation
• Flight planning
  • Launch window(s)
  • Ascent trajectory
  • Abort targets and abort windows
  • Flight plan
• Flight interaction (Less capable as Posciks tool, without 3D animations)
  • Create executive packages
  • Send executive packages to simulation
  • Communicate with simulation
• Flight analysis
  • Read telemetry streams or telemetry dumps
  • Visualize mission and mission events
• Export functions
  • Generate Checklists in PDF
  • Export flight plan to PDF or HTML
  • Export mission overview to PDF or HTML

Essentially, the swiss pocket knife for SSU, all as modular as possible, so I can finish things in small steps. I think I will create a new Sourceforge project for this, so the C++ development and the Java stuff will be separated.

 

[SiameseCat]

For standard insertion, I think you can just use a fixed set of values for the MECO targets. The document I have (Ascent Guidance & Flight Control Workbook) has the following values:
Inertial velocity: 25,725 fps
FPA: 0.675 deg
Altitude: 360 kft
The real targeting is done by the OMS-1 burn - once I fix the PEG4 parameters (which should be done soon), this should be really simple.

---------- Post added at 02:19 PM ---------- Previous post was at 02:10 PM ----------

A different tool, but can be fixed. I just need better constants and assumptions for improving the targeting. The MFC tool was really done quickly.

I would want to include the following functions in it:

• Mission planning
  • Orbiter configuration
  • Payload configuration
  • STS stack configuration
  • Assembly options
  • Magnetic tape image preparation
• Flight planning
  • Launch window(s)
  • Ascent trajectory
  • Abort targets and abort windows
  • Flight plan
• Flight interaction (Less capable as Posciks tool, without 3D animations)
  • Create executive packages
  • Send executive packages to simulation
  • Communicate with simulation
• Flight analysis
  • Read telemetry streams or telemetry dumps
  • Visualize mission and mission events
• Export functions
  • Generate Checklists in PDF
  • Export flight plan to PDF or HTML
  • Export mission overview to PDF or HTML

Essentially, the swiss pocket knife for SSU, all as modular as possible, so I can finish things in small steps. I think I will create a new Sourceforge project for this, so the C++ development and the Java stuff will be separated.

I think it would be better to use the existing SSU project. It's still all connected, so I don't see any need to keep the C++ and the Java stuff separate - just put the Java code in a different folder.

BTW, is there any particular reason for using Java? My own inclination would be to use C# (mainly because I'm much more familiar with it, but I do think it's a slightly better language).

 

[Urwumpe]

I think it must not be part of the same project, so why force it into the SSU processes and cause a bloated repository? Have a separate project and focus on the application processes.

BTW, is there any particular reason for using Java? My own inclination would be to use C# (mainly because I'm much more familiar with it, but I do think it's a slightly better language).

Same here, but pro-Java. :lol: I am full-time Java developer at work, thus the preference for Java.

And no, I don't think C# is the better language. While it has some concepts that Java still lacks (Lambda functions), it is mostly Java with additional keywords instead of letting one keyword serve multiple purposes depending on expression. But C# lacks strongly at the framework end.

But what really makes me pro-Java in that context: I could use the Netbeans Rich Client Platform as foundation for building the application. There are no comparable Rich Client Platforms for C#, all developments in that field are based on Java actually.

 

[SiameseCat]

It seems to me that the tool will be part of SSU (and presumably released along with SSU), so I don't see any reason to keep it in a separate repository. I think most people working on SSU development would also be working on, or at least using, the mission file tool.

 

[Urwumpe]

It seems to me that the tool will be part of SSU (and presumably released along with SSU), so I don't see any reason to keep it in a separate repository. I think most people working on SSU development would also be working on, or at least using, the mission file tool.

Yes, and while it could in theory also support other add-ons, I doubt this will ever happen outside the Ultra gang. But still, I am not sure two different developments could fit into one SSU repository, from a management point of view. Wouldn't two projects be better to handle?

 

[SiameseCat]

I think two projects would be more work to handle, since you have to manage both projects. I don't see how creating a separate repository makes it easier to manage.

---------- Post added at 10:50 PM ---------- Previous post was at 05:14 PM ----------

Is there any reason why we have the MissionFileManagement.cpp file? At the moment it returns Mission class instances, but all it does is create the mission instance and store it in a std::map so each mission file is only read once. I really don't see the point in this, and it makes the code more confusing.

 

[Urwumpe]

I think two projects would be more work to handle, since you have to manage both projects. I don't see how creating a separate repository makes it easier to manage.

---------- Post added at 10:50 PM ---------- Previous post was at 05:14 PM ----------

Is there any reason why we have the MissionFileManagement.cpp file? At the moment it returns Mission class instances, but all it does is create the mission instance and store it in a std::map so each mission file is only read once. I really don't see the point in this, and it makes the code more confusing.

Was made that way to ensure that the mission file is only read once.

 

[SiameseCat]

Is there any reason for that? At the moment, we don't have any scenarios with multiple shuttles, and it's even less likely that they'll be sharing mission files. I'd prefer to simply let the Shuttle vessel create Mission class instances as required.

 

[Urwumpe]

Is there any reason for that? At the moment, we don't have any scenarios with multiple shuttles, and it's even less likely that they'll be sharing mission files. I'd prefer to simply let the Shuttle vessel create Mission class instances as required.

There is just one problem: There isn't one instance of the mission file per design. It is easily possible to have multiple instances of the same data, and if we would get more data in the mission files, this could easily cause delays.

One other design aspect there was to permit accessing the mission data from other vessels, while only loading it once during the orbiter session.

 

[DaveS]

The SSU orbiter reacts too slowly in pitch during final approach compared to the real orbiters. I have to really pull back on the joystick in order to get it to pitch up during the final flare.

 

[Donamy]

That would be correct for FBW.

 

[Cras]

but isnt the point of FBW to be tunable so it behaves in what ever manner it is programmed to? In that there is no such thing as a commonn "feel" for FBW?

For example, the B777 and the A320. Both FBW. Both have very different feels.

 

[Donamy]

And the shuttle would be different also, I assume.

 

[SiameseCat]

The SSU orbiter reacts too slowly in pitch during final approach compared to the real orbiters. I have to really pull back on the joystick in order to get it to pitch up during the final flare.

Checked in code with larger gains; hopefully this will fix the issue.

 

[DaveS]

Checked in code with larger gains; hopefully this will fix the issue.

It does. Much better response now.

---------- Post added at 09:00 PM ---------- Previous post was at 06:22 PM ----------

Urwumpe: Anything you can check in on the camera twist fix? Also, anything on the EE camera light?

 

[Urwumpe]

Urwumpe: Anything you can check in on the camera twist fix? Also, anything on the EE camera light?

Can't test anything on my current machine in terms of SSU, run out of memory and swap space - no development. The project is already too big for my 2004 hardware, replacement needs work.

 

[DaveS]

I think this table will come in handy. Unfortunately I can't share the document it came from but I think this one page is OK:

Shuttle orbiter Ku band gimbal conversion equations:

---------- Post added at 10:05 PM ---------- Previous post was at 04:18 AM ----------

Latest check in fails during compile as it can't find PIDControl.cpp/h. The file has been checked in so it has to be some project settings that are not right.