Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Something has changed, MPS performance-wise. I have used the STS-107 launch scenario twice now with the same result: Not hitting the proper MECO targets and therefore not the proper post-MECO trajectory. The actual achieved post-MECO trajectory has the perigee in the negatives and the apogee barely above MECO altitude.

 

[SiameseCat]

When was the last time you ran the STS-107 launch scenario? You might want to try Rev. 1359 (just before I changed the ascent guidance code) and Rev. 1391 (just before GLS changed the SSME code) and see when the problem appears.

 

[DaveS]

When was the last time you ran the STS-107 launch scenario? You might want to try Rev. 1359 (just before I changed the ascent guidance code) and Rev. 1391 (just before GLS changed the SSME code) and see when the problem appears.

The last time I ran the scenario was just before I checked in the new updated scenario and mission file and that was revision 1412.

 

[SiameseCat]

I just ran the STS-107 launch scenario at Rev. 1412 and the apogee at MECO is 137 km and the perigee is -62 km.

 

[DaveS]

I just ran the STS-107 launch scenario at Rev. 1412 and the apogee at MECO is 137 km and the perigee is -62 km.

That's what I get as well. The MECO trajectory numbers I used were generated by the MECOTool utility. Is it wrong maybe?

 

[SiameseCat]

I ran the launch scenario for Rev. 1409, and the apogee at MECO was 346 km and perigee was 74 km.

As far as I can tell, the only thing that changed between Rev. 1409 and Rev. 1412 is that the payload configuration changed a bit, and I suspect the weight of the payloads changed. I also noticed that in Rev. 1412, a Low Level Cutoff occurs. Are you sure the payload weight is correct?

 

[DaveS]

I ran the launch scenario for Rev. 1409, and the apogee at MECO was 346 km and perigee was 74 km.

As far as I can tell, the only thing that changed between Rev. 1409 and Rev. 1412 is that the payload configuration changed a bit, and I suspect the weight of the payloads changed. I also noticed that in Rev. 1412, a Low Level Cutoff occurs. Are you sure the payload weight is correct?

After further research and checking, it seems like I got the total payload mass wrong. Original total mass was 17458.75. The new total mass is listed below.

Masses for the SpaceHAB RDM and FREESTAR were taken from CAIB Final Report Vol II, Appendix D.6.
The mass for the EDO cryo kit were taken from the SCOM.

Payload Mass breakdown:
SpaceHAB RDM: 9112.05 kg
FREESTAR: 1992.15 kg
EDO cryo kit, dry: 1575 kg
EDO cryo kit, cryo mass: 1571.4 kg

Total loaded mass: 14250.6 kg
Payload mass delta from original: 3208.15 kg

---------- Post added at 04:52 AM ---------- Previous post was at 04:42 AM ----------

I did a test launch with the corrected payload mass and got the 346x74 orbit. Apogee at MECO should be 278 km, so the MECOTool utility needs to be revised.

 

[DaveS]

There seems to be a problem with revision 1438 which prevents the RMS for translating in the X axis. It seems like the "correction" to the joint speed limit is the cause. I reverted back to revision 1436 and everything worked fine again.

 

[SiameseCat]

The problem is that the joint speed required for translation exceeds the speed limit (before this change, the speed limits were ignored). Do you know what the correct joint speed limits are? Otherwise, I can increase the joint speed limits so the arm always translates.

 

[DaveS]

The problem is that the joint speed required for translation exceeds the speed limit (before this change, the speed limits were ignored). Do you know what the correct joint speed limits are? Otherwise, I can increase the joint speed limits so the arm always translates.

Maximum unloaded translational speed is 2.0 fps. And it is my understanding that exceeding the speed will not stop the arm dead in its tracks but simply not allow it to go faster.

Here's a document from the JSC Space Shuttle Technical Conference in 1983 on the RMS: An overview of the Shuttle Remote Manipulator System

 

[SiameseCat]

What I need is the maximum rotational speed of each joint, not the translation speed. I've found a lot of documents giving the rotation speed limit for the Single Joint mode, but nothing for the IK modes.

I'll just increase the joint speed limits so everything works, and we can change the numbers if we can actually get realistic values.

 

[Urwumpe]

Shouldn't the arm translate slower, but along the correct direction, if the maximum joint speed is reached for one joint?

 

[SiameseCat]

For the IK modes, if one joint is rotating too slowly, the arm will move in the wrong direction (it'll be close to the correct direction, but not quite). It's theoretically possible to limit the translation speed so the joint speeds are within limits, but I don't think its worth the bother.

I'm not completely sure if there is a strict speed limit on the joints, or if it's just based on how much force the motors can apply and how much mass is on the end of the arm. I think the simplest solution is just to increase the speed limits so the IK works. I think the IK translation/rotation speeds are low enough that the joint speed limits aren't an issue in real life.

 

[Urwumpe]

For the IK modes, if one joint is rotating too slowly, the arm will move in the wrong direction (it'll be close to the correct direction, but not quite). It's theoretically possible to limit the translation speed so the joint speeds are within limits, but I don't think its worth the bother.

I'm not completely sure if there is a strict speed limit on the joints, or if it's just based on how much force the motors can apply and how much mass is on the end of the arm. I think the simplest solution is just to increase the speed limits so the IK works. I think the IK translation/rotation speeds are low enough that the joint speed limits aren't an issue in real life.

Near singularities, you could have out of range joint speeds for a slow translation, even if you usually have no such limitations to fear. The maximum joint speed also depends on the electronics and the kind of motor, if you move too fast, you can get step errors and thus wrong positioning.

For most robots I know, the solution is to use lower motion speeds, which is no problem since the algorithm for calculating translations uses subdivision anyway.

 

[Donamy]

Er... this is a sim after all, no need to make it like watching grass grow.

 

[SiameseCat]

Near singularities, you could have out of range joint speeds for a slow translation, even if you usually have no such limitations to fear. The maximum joint speed also depends on the electronics and the kind of motor, if you move too fast, you can get step errors and thus wrong positioning.

For most robots I know, the solution is to use lower motion speeds, which is no problem since the algorithm for calculating translations uses subdivision anyway.

The RMS doesn't have many singularities (the only significant one is if the wrist yaw joint gets too close to 90 degrees). My guess is that the RMS speed limits are set so there aren't any problems with individual joints except around the singularities.

 

[Urwumpe]

The RMS doesn't have many singularities (the only significant one is if the wrist yaw joint gets too close to 90 degrees). My guess is that the RMS speed limits are set so there aren't any problems with individual joints except around the singularities.

I'll check this in the ODB, this should contain the rates with some more accuracy than the SCOM.

---------- Post added at 09:09 PM ---------- Previous post was at 08:40 PM ----------

Ok, found some data on the topic:

There are three singularities, all handled by the control system in both manual and automatic modes. "Trajectory may deviate from commanded when passing a singularity".

Also this table with the motor data, there is also a lot of data in the ODB about things that happen much deeper below the surface, but I think this data is enough for us.

 

[DaveS]

Checked in some changed stuff.

Here's the change-log:

• New original Atlantis texture sporting new wing textures by xmariox
• New LW ET texture with bump map
• Tweaked the position of the SSUPad Water Tower strobe light
• Changed the GOX vent stream from "EMISSIVE" to "DIFFUSE" in both SSUPad and Atlantis.
  For best appearance using D3D9Client, in the Particle.fx file, change outVS.light = saturate(dot(-gSun.direction, vrt.nrmL)) + 0.2f; to read outVS.light = saturate(dot(-gSun.direction, vrt.nrmL)) + 0.6f;
• Tweaked xenon light settings
• Tweaked SRB offsets to the accurate 6.3 m

 

[DaveS]

I think I have come up with some good settings for D3D9Client.

Save the following as SpaceShuttleUltra.cfg in the Config\GC folder:

#default
; -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
MESH 1
; ---------------------------------------------
MATERIAL 7 ; Radiator panels
REFLECT 0.247059 0.000000
DISSOLVE Disl_Lines.png 12.000000 0.174902
; -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
MESH 4
; ---------------------------------------------
MATERIAL 0 ; Ku band DEA
REFLECT 0.564706 1.066667
DISSOLVE Disl_Lines.png 12.000000 0.025490
; -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
MESH 6
; ---------------------------------------------
MATERIAL 2 ; ODS hooks and latches
REFLECT 1.000000 0.000000
; ---------------------------------------------
MATERIAL 3 ; ODS docking ring
REFLECT 1.000000 0.000000
#end

 

[DaveS]

I'm working on an updated orbiter mesh and I now need a way to test the aerosurfaces. We used to be able to move them on-orbit by firing up an APU but that capability has since been removed. So could this be put back in or be replaced by the appropriate ITEMs (10/11 in MM801) in the DPS?