Space Shuttle Ultra development thread

[SiameseCat]

I'm working on R2 now.

 

[spacman]

The MS2 or flight eng. sits directly between the CDR/PLT ,MS1 sits directly behind the PLT that seat on some flts astronauts will trade seats . MS2 position does not change for Ascent or Entry

 

[DaveS]

There is a 120 LED C&W matrix for displaying all hardware C&W.

OK, but you can't see it in the ACES during ascent/entry as the helmet blocks the view and the helmet cannot rotate.

For the Seat 3 occupant, panel R13 is directly behind him/her. The Seat 3 occupant also has the responsibility of video-documenting the entry and landing using a handheld video-camera.

 

[Urwumpe]

OK, but you can't see it in the ACES during ascent/entry as the helmet blocks the view and the helmet cannot rotate.

For the Seat 3 occupant, panel R13 is directly behind him/her. The Seat 3 occupant also has the responsibility of video-documenting the entry and landing using a handheld video-camera.

Well, at least it exists.

I just looked at the dimensions of the MFD screens. 256x256 in VC mode. Looks like I need to make really small letters for the DEU font... 5 x 10.

Isn't there a way to increase the MFD size to 512 x 512? Thats would make the letters much easier readable.

 

[Donamy]

Or you could press the Z key.

 

[Urwumpe]

Or you could press the Z key.

No, the problem is not zoom, I just can't draw the mathematical symbols in 5 x 10. 10 x 18 would be nicer to work with.

Anyway, lets scrub that DEU font plan for the moment. Maybe I can get back to the drawing of the CRTs later (For the CAU update of the shuttle or the Orion CEV which uses the same technology, 1024x1024 MFDs would be required - otherwise you can't draw the large amount of graphics).

Also I noticed that the MFD buttons do not work yet, this should be fixed too.

Back to switches, discrete lines and the other stuff. Became all a bit more complex now, for connecting switches with hardware without having direct connections to the switch. This makes event handling simpler - now a MDM or a GPC could just query if a bit in a memory word got set, which is a scenario, we will have more often than direct connections to the hardware.

(I found this concept in the telemetry information of the MCIU inside a payload processing manual - it contains information about which variables the MCIO or RMS handles and how rotary switches for example are stored inside a 16 bit telemetry word)

With this structure the function of the switches could now made depending on the power supply of the panels - no power, no discrete signals. Don't loose all fuel cells!

 

[Donamy]

Are there animations for the data probes and startracker doors yet ? Also, can we get the flames to burn longer on the SRB's ?

 

[Urwumpe]

Are there animations for the data probes and startracker doors yet ? Also, can we get the flames to burn longer on the SRB's ?

Probes are animated and deploy properly. No news on the Star tracker doors yet.

And what do you mean on the SRB flames? That they run out of fuel before they should? I already looked at fixing it, basically it is just rounding down the thrust for the final 40 seconds a bit.

 

[DaveS]

Are there animations for the data probes and startracker doors yet ? Also, can we get the flames to burn longer on the SRB's ?

Startrackers: no
Airdata probes: yes

 

[Urwumpe]

Startrackers: no

For making the star trackers, it would be nice to have Panel O6 ready. It has not only the many GPC and MDM switches, but also the switches for the star trackers.

 

[Donamy]

Then we would need O7 and O8 to make it look balenced, wouldn't we ?

 

[Urwumpe]

Then we would need O7 and O8 to make it look balenced, wouldn't we ?

*cough* Balance? What is that?

(And what switches are on panel O7 and O8? Wasn't that RCS...*look up in manual*)

Unless we can really speed up panel development, we will never get O6 implemented before version 1.08... :sorry: Even with the new code I prepared, it will still take a lot of time for getting the required reference data. But at least the copy and paste factor will get reduced.

I think I know now which graphic we need. An overview of the panels locations of the Shuttle. Maybe a reason for me to pick Inkscape, I have a pdf from NASA with the locations, but in very very poor (hand drawn) quality.

 

[Donamy]

The SCOM .pdf has all the panels, and they can be blown up quite nicely.

 

[Urwumpe]

The SCOM .pdf has all the panels, and they can be blown up quite nicely.

I know, I just tried to trace one of the panels into Inkscape, so I can make a compact pdf with the labels from it. But I think just writing down the system how I would like the labels in the mesh files would be better.

What I currently draw is a "map" of the flight deck. Which panel is where and what can you find on the panels. Most Shuttle experts might know this better than I do, but I feel better, when I have a small "memory aid".

Suggestion: We should implement a preliminary version of the GLS sooner as planned (if planned at all) in the next full release (1.08 or 1.20 because of the new scale). This way, we can ensure newbies which test SSU don't report bugs, which are actually lack of reading the manual. When the conditions for launch are not fulfilled, the shuttle does not launch and we display a message on the screen, what happened ("GLS aborted launch sequence.").

 

[DaveS]

Suggestion: We should implement a preliminary version of the GLS sooner as planned (if planned at all) in the next full release (1.08 or 1.20 because of the new scale). This way, we can ensure newbies which test SSU don't report bugs, which are actually lack of reading the manual. When the conditions for launch are not fulfilled, the shuttle does not launch and we display a message on the screen, what happened ("GLS aborted launch sequence.").

I would be in favour of this. The more correct way would be: "Countdown clock will hold at <next GLS milestone> due to a failure."

<next GLS milestone> would be T-7:30, T-5:00, T-4:00, T-2:50, T-1:57, T-0:31.

SiameseCat: I just wanted to check with you that if it is OK for me to work on fixing up the RMS joints animations.

So far I have both the shoulder joints lined up and working and almost have the elbow joint lined up.

Donamy: There's seems to be some sort of mesh blocking the Canada logo on the RMS. Could you fix it please? Also, the outboard Canada logo is missing.

 

[DaveS]

Update: Elbow joint lined up and working nicely. Now to tackle the wrist joints.

 

[SiameseCat]

DaveS: It'll be nice if you can fix the RMS animations.

 

[DaveS]

DaveS: It'll be nice if you can fix the RMS animations.

Wrist pitch joint updated and working.¨

2335 UTC Edit:
Wrist yaw joint updated and working. Just the end effector roll left to do.

 

[DaveS]

Just checked in the RMS fixes. For some reason the new coordinates for the wrist roll joint won't work.

Maybe someone could take a look at it?

 

[Urwumpe]

Just checked in the RMS fixes. For some reason the new coordinates for the wrist roll joint won't work.

Maybe someone could take a look at it?

Looks like the Offset in Y direction is too extreme, it is 20 cm higher as the yaw/pitch joins. Also I think we could make the animation code a bit less complex by making the tip vector calculations a child of the yaw actuator, instead of adding a unused rotation...