SSU Workbench development

[GLS]

All crashes point to line 138 in SSU.Workbench.Model.Mission of Mission.cs. The error is System.IndexOutOfRangeException, 0x80131508.

It is almost certainly related to some vessel file which is probably empty, and when trying to read the mass and attachment count = kaput.
I disabled that code as it isn't used (see my big post above). Didn't compile it (didn't even open VS :lol but it should work now.

 

[DaveS]

It is almost certainly related to some vessel file which is probably empty, and when trying to read the mass and attachment count = kaput.
I disabled that code as it isn't used (see my big post above). Didn't compile it (didn't even open VS :lol but it should work now.

No more crashes here, everything is working fine. Just one thing though, would it be possible to specify OMS/RCS propellant loads directly in mass rather than percent? All the NASA sources always list the propellant loads in mass rather than actual propellant tank capacity.

---------- Post added at 03:32 AM ---------- Previous post was at 03:04 AM ----------

Another thing is that for launch the RMS elbow camera PTU should be set to 90/90 respectively. I believe that this is for ascent loads, it handles it better with the camera pointing up and the pan is to clear the radiator panels.

 

[GLS]

No more crashes here, everything is working fine. Just one thing though, would it be possible to specify OMS/RCS propellant loads directly in mass rather than percent? All the NASA sources always list the propellant loads in mass rather than actual propellant tank capacity.

The current OMS/RCS controls are not "plugged in", as they are for future RCS implementation where there are RCS tanks separate from the OMS tanks. Currently the prop is fixed.... not sure if worth adding controls and mission file parameters for it now... I have to think about it.

Another thing is that for launch the RMS elbow camera PTU should be set to 90/90 respectively. I believe that this is for ascent loads, it handles it better with the camera pointing up and the pan is to clear the radiator panels.

Done.

 

[DaveS]

I just noticed something critical is missing which is the ability to add other vessels, such as potential rendezvous targets (like ISS, Mir and HST).

 

[GLS]

I just noticed something critical is missing which is the ability to add other vessels, such as potential rendezvous targets (like ISS, Mir and HST).

Yes, and it's missing for the same reason that it doesn't do on-orbit scenarios: how to specify the orbit? What degree of automation should it have?
For a landing scenario we can place the vehicle based on a "default" position in relation to the runway, and thus scenarios can be (+/-) easily generated for any runway at any time of the day, but for orbit it's not so easy.

On top of that, the data must be saved in the mission file, which currently isn't structured, so that would mean (more) "lost parameters". I've been playing with a JSON format for the mission file, and although it still needs more thinking, it seems much more "organized". Here is a sketch I made a few days ago:

{
	"Name": "STS-26R",
	"Description": "place for stuff and such....",
	"Orbiter":
	{
		"Name": "Discovery",
		"Texture": "Discovery_original",
		"RMS": false,
		"KUBand": true,
		"STBDMPM": false,
		"ODS": false,
		"ExtAL": false,
		"TAA": false,
		"AftTAA": false,
		"BulkheadFloodlights": true,
		"DragChute": false,
		"PLBLiner": true,
		"SILTS": false,
		"Crew": 7,
		"LaunchParameters":
		{
			"T0": 51683.4244212963,
			"TargetInc": 28.500000,
			"TargetLAN": 0.000000,
			"MECOAlt": 109268.000000,
			"MECOVel": 7848.801,
			"MECOFPA": 1.202536,
			"PerformRollToHeadsUp": false,
			"OMSAssistEnable": true,
			"OMSAssistDuration": 59.000000,
			"MaxSSMEThrust": 104.0
		},
		"Payload":
		[
		{
			"Vessel": "OASIS",
			"PL_ID": 142
		},
		{
			"Vessel": "GAS",
			"PL_ID": 257
		}
		]
	},
	"ExternalTank":
	{
		"Type": "LWT"
	},
	"SolidRocketBoosters":
	{
		"SRM": "RSRM"
	},
	"LaunchSite":
	{
		"Site": "KSC",
		"Pad": "LC-39B",
		"PadType": "1988",
		"MLP": 2
	},
	"CentaurG": null,
	"CentaurGPrime": null,
	"IUS":
	{
		"PayloadVessel": "TDRS-C",
		"AdapterMesh": "SSU\\IUS\\IUS_DemoSat_adapter",
		"AdapterOffset": 1.1833,
		"AdapterMass": 300.000000,
		"LoadStage1": 1.0,
		"LoadStage2": 1.0,
		"RCSTanks": 2,
		"4Antennas": false
	}
}

The ideal place for transition/add support for this would be SSU 6.0, along with the more precise payload bay attachment definition I put forward here (in JSON, not it the current format I posted there).

 

[DaveS]

Well, for now I think it could be specified using the "Target" drop down menu on the FLT NO tab.

 

[GLS]

Well, for now I think it could be specified using the "Target" drop down menu on the FLT NO tab.

OK, it takes like 30 seconds to have that combo box show the vessel list (like the payloads), then what gets written in the scenario? :shrug:

 

[DaveS]

OK, it takes like 30 seconds to have that combo box show the vessel list (like the payloads), then what gets written in the scenario? :shrug:

SPEC 34 ORBIT TGT requires a specific vessel name to work properly namely TARGET_VESSEL in StateVectorSoftware. That's what needs to be written specifically in the scenario regarding rendezvous target(s). The Ku rendezvous radar is a bit more flexible as can lock on to the closest vessel without any scenario input.

---------- Post added at 02:12 AM ---------- Previous post was at 01:36 AM ----------

I think this is a fault related to the workbench: The AFD ORBIT DAP PBIs aren't lit up. The C3 ORBIT DAP PBIs are working fine.

 

[GLS]

SPEC 34 ORBIT TGT requires a specific vessel name to work properly namely TARGET_VESSEL in StateVectorSoftware. That's what needs to be written specifically in the scenario regarding rendezvous target(s). The Ku rendezvous radar is a bit more flexible as can lock on to the closest vessel without any scenario input.

Even adding that output, the user still has to manually put that vessel in the scenario... why not add that line as well for now?

---------- Post added at 01:58 AM ---------- Previous post was at 01:53 AM ----------

I think this is a fault related to the workbench: The AFD ORBIT DAP PBIs aren't lit up. The C3 ORBIT DAP PBIs are working fine.

There is no fault, I just corrected the switch positions for launch, so the aft ACAs are off for launch. They are powered by a switch on panel A6U (the associated CBs are not working).

---------- Post added 12-23-19 at 01:24 AM ---------- Previous post was 12-22-19 at 01:58 AM ----------

Added basic crash checks to (hopefully) allow some info to be displayed to the user. Also added the license header to the files, in a similar way to what exists in the C++ source files. The initial logic for the SimpleGPCSoftware scenario blocks was also added (and just realized I have the ATVC value wrong... :facepalm: will fix after this post). On the user side, replaced the "ok" msgbox with a message in the new status bar. It's a simple indication to the user that the load/save/whatever has finished, and it should show up almost immediately.

One thing that still needs thinking is the "MECO Tool". (Once again) there is no issue with the math in there, but I'm not sure the parameters are saved in the mission file are the most adequate: MECO parameters, versus what the user wants, e.g., a circular orbit at 273Km. Maybe the post-OMS2 burn orbit should be specified (don't ask how yet), and then the MECO parameters should be calculated (for use by the Ascent Guidance sw) and placed in the I-LOADs file.
Which raises another question: could/should the I-LOADs file be a field in the future structured mission file?

 

[DaveS]

msgbox with a message in the new status bar. It's a simple indication to the user that the load/save/whatever has finished, and it should show up almost immediately.

One thing that still needs thinking is the "MECO Tool". (Once again) there is no issue with the math in there, but I'm not sure the parameters are saved in the mission file are the most adequate: MECO parameters, versus what the user wants, e.g., a circular orbit at 273Km. Maybe the post-OMS2 burn orbit should be specified (don't ask how yet), and then the MECO parameters should be calculated (for use by the Ascent Guidance sw) and placed in the I-LOADs file

Something related to this is that the math doesn't work out in some cases. This is something you can check for yourself. A good example is STS-109 which had a MECO apogee of 310.4 nmi. Convert that to km and we get 574.8608 so we plug that into either the MECO tab or MECO Tool itself and we get the following parameters:

TargetInc=28.450000
TargetLAN=0.000000
MECOAlt=109268.000000
MECOVel=7962.684124
MECOFPA=1.355849

But using those parameters leads to 305 nmi MECO apogee, which is below the specified MECO apogee. By trial and error the I've found out that there's an underspeed of 3 m/s. Maybe it doesn't seem like much but, HST missions were known for their propellant usages. They always loaded the OMS tanks pretty much full (98.8% for STS-109) and never did an OMS assist (not even on STS-125).

 

[GLS]

Something related to this is that the math doesn't work out in some cases. This is something you can check for yourself. A good example is STS-109 which had a MECO apogee of 310.4 nmi. Convert that to km and we get 574.8608 so we plug that into either the MECO tab or MECO Tool itself and we get the following parameters:

TargetInc=28.450000
TargetLAN=0.000000
MECOAlt=109268.000000
MECOVel=7962.684124
MECOFPA=1.355849

But using those parameters leads to 305 nmi MECO apogee, which is below the specified MECO apogee. By trial and error the I've found out that there's an underspeed of 3 m/s. Maybe it doesn't seem like much but, HST missions were known for their propellant usages. They always loaded the OMS tanks pretty much full (98.8% for STS-109) and never did an OMS assist (not even on STS-125).

I have checked the math myself (it's the same in the MECOTool.exe and in the MECO Tool tab of SSUW) and it's OK AFAIK. Feel free to check it yourself, but you are assuming that the MECO Tool is wrong and the Ascent Guidance and FCS are working well, which they aren't. There is an instability in the pitch axis, due to c.g. shift, that messes up the FPA targeting. Then, the final velocity is dependent on frame rate: higher frame rate will have a smaller overspeed (that always exists, assuming the SSME tailoff is correct, which shouldn't be off by much, although it doesn't take into account vehicle mass).

 

[GLS]

OMS and RCS tank loads are now definable, and saved in the mission files, and also output into scenario files (with the the OMS/ARCS being combined due to the current propellant resource architecture). Added the available OMS/RCS load data to mission files.

Also added logic to "force" mission files to be inside the "\Mission\SSU" folder, and the "link" in the scenario is now the mission file name instead of the mission name, so mission files can be saved with other names. Sub-folders are also supported, so addons have the possibility to group their own mission files, e.g., "\Mission\SSU\MIR Flights".

Added PRSD tank number selection, as well as EDO pallets (only 1 for now). The loads will have to wait until the new propellant resources are made.

In addition to only allow the EDO pallet on the OVs that supported it (102, 104 and 105), the Centaurs are now only allowed on 099 and 104.

 

[asdad]

Guys , I have problem with SSU Workbench when loading mission is error can you fix iit guys ?

 

[GLS]

Guys , I have problem with SSU Workbench when loading mission is error can you fix iit guys ?

I'm sorry but "there is an error" is not enough information to do anything. What happens exactly? Which mission file are you loading?

 

[asdad]

sts-1.cfg in Mission/SSU

 

[GLS]

sts-1.cfg in Mission/SSU

... and what error shows up?
Does it only happen with that mission?
If you create a new mission can you save it and re-load it?

 

[asdad]

 

[GLS]

I'll look at it later today, thanks for reporting the issue!

 

[asdad]

ok no problem

 

[GLS]

Should be fixed. To confirm, could you load a mission file (one of the default ones), save it, and then reload it, making sure the date is correct?
Also, afterwards try creating a scenario, and report if the scenario created has a dot or a comma in "Date MJD" number.