Space Shuttle Ultra development thread

[Donamy]

Ehh, I'm not seeing how POS in degrees relates to the size of the shuttle in meters.

I lined up the concrete hardstands with their correct locations on the default KSC surface tiles as per Urwumpe's suggestion here:





Understand now?

Not really, No.

 

[DaveS]

Not really, No.

Could you then explain *exactly* what problem you have with my concrete hardstand and the default KSC tiles?

The concrete hardstand is exactly(well more or less) sized like the real ones, so they're not scaled wrong or anything. Same thing with the MLP.

So is this the problem? That it is too big because of the default KSC tiles? I can assure you that it is not.

 

[Urwumpe]

Also, the difference between the tiles was on the scale of 800 meters.

 

[Donamy]

Going to all the trouble scaling everything down to fit your ET, but the correct location of the launch pad doesn't matter ? I'm confused.

 

[DaveS]

Going to all the trouble scaling everything down to fit your ET, but the correct location of the launch pad doesn't matter ? I'm confused.

Read my post again. The concrete hardstands have the correct dimensions! It isn't too small or too large. It is of the correct size.

Same thing with the MLP. We're going to have a compromise in accurate LAT/LONG position as long as we're using the default KSC tiles, this can only be helped if we use Kukanotas high-res KSC tiles.

So there's nothing wrong with the physical size of the concrete hardstand meshes. We just have a compromise the position of the hardstands.

 

[Urwumpe]

Going to all the trouble scaling everything down to fit your ET, but the correct location of the launch pad doesn't matter ? I'm confused.

The correct location is not known - that is one of the problems. Do you know the exact coordinates of LC-39B? You have to remember that Orbiter uses geocentric coordinates, by the look at it whole Google Earth and others use geographic coordinates. Between both are about 800m distance in space, because of the shape of Earth.

If Orbiter uses geocentric coordinates, we have to put the pad at the correct geocentric coordinates - otherwise our orbit is off by a few arc minutes.

Also, the scaling was not only done because of the ET - it was also done for making the other stuff fit. Payloads, mechanics, launch structures, transporters, space stations.

BTW... the orbiter scale difference was 2.75%, the pad error in the worst case 0.00229%

 

[Donamy]

My question was if the position was correct, if it is the closest we can get, fine. I was under the impression, it didn't matter. I get it now.

Urwumpe,

I believe this shows a few of the buttons lit, not much difference. Probably a much bigger difference in darkness I would assume.

 

[Urwumpe]

Are you sure this is lit? The panel is not powered according to the switches...

 

[Donamy]

I don't think it has to be for the status lights.

Can someone get a comformation from L2 ?

 

[Urwumpe]

I don't think it has to be for the status lights.

According to the ODS reference, it has to - the panel electronics have no power-on limit like the mechanics circuits of the ODS, but you still have to provide power to the panel over the three circuit breaker switches at the top left corner.

But I don't know if this is a real panel or a mock-up. If the panel is real, it could also mean that the lights have different colors.

 

[DaveS]

But I don't know if this is a real panel or a mock-up. If the panel is real, it could also mean that the lights have different colors.

Could be a flight unit as these photos of it during STS-116 shows the same colors and config of the panel: http://spaceflight.nasa.gov/gallery/images/shuttle/sts-116/hires/s116e05368.jpg

http://spaceflight.nasa.gov/gallery/images/shuttle/sts-116/hires/s116e05565.jpg

http://spaceflight.nasa.gov/gallery/images/shuttle/sts-116/hires/s116e05556.jpg

http://spaceflight.nasa.gov/gallery/images/shuttle/sts-116/hires/s116e05933.jpg

 

[Donamy]

I don't think they're cyan.

 

[DaveS]

Donamy: once you're done with what you're doing right now, could take a look on getting a good animation of the FSS OWP panels?

 

[Urwumpe]

For implementing the ODS panels, I would prefer the following concept: We make the panel interfaces used by the ODS general purpose payload panels and make it possible to use different behavior when something else gets installed there.

That means, we can't expect that a ODS panel is installed there, when something is installed there at all. But we could also for example just install a blank panel with Velcro hooks in place of the ODS panels, which has no switches or lights at all. I have seen such a panel at the location in one of my spaceflight photo books.

Now to something completely different:

Does somebody really know how to fill a listbox dialog element with data and operate with it? I have never done such a thing without MFC or wxWidgets, but would like to make one such dialog for debugging the cable connections.

I want to make a really simple dialog - it just lists all registered cable bundles inside the software and the state of the lines inside each bundle.

One such bundle would for example be "C2_TO_IDP1", and connect the panel C2 with IDP1. A discrete cable bundle is in the software just an array of float values, which I defined for making message passing between subsystems and VC components robust. Such cable bundles can be used for on/off signals or analog measurement signals (not for power supply, this would become too general purpose and require serious math)


I currently test these bundles with log outputs and oapidebugstring, but I think when it comes to ODS or payload panels, a full dialog for controlling signals would be very good. My current idea is to take the FlightData custom function source code and start from that point.

 

[Donamy]

So you want a back panel, completely empty ? Do you need me to eliminate the rest of the panels and have them added seperately ?

 

[Urwumpe]

So you want a back panel, completely empty ? Do you need me to eliminate the rest of the panels and have them added seperately ?

A flat surface like we have now would also go, but maybe you can repaint the texture of the area a bit to be ultramarine blue with square velcro strips (I search for the photo in NASAs DB, I don't yet know the mission, but the astronaut shown is Terrence Wilcutt). The blank panel would then be just a idle class, which does nothing, but has all needed interfaces.

We could get rendering problems with the extra panels added because of Z-Buffer problems, then we would need to remove this flat surface. But as long as we don't know, I don't want to cause extra work for you.

 

[Donamy]

The panels are all made, so it's not a question of work, it's just which ones need to be eliminated for the clean panel. I don't think they flew the RMS panel for STS 107 mission, I'll have to check on that.

 

[Urwumpe]

I think this image tells it all:

http://spaceflight.nasa.gov/gallery/images/shuttle/sts-107/hires/s107e05002.jpg

No such panel on STS-107.

 

[Donamy]

No controllers either.

I have a new VC I can send you without the RMS panels and controls, however you may have to look at the order of things and see if the animation still works. I also added a label to the aft MDU.

 

[Urwumpe]

No controllers either.

I have a new VC I can send you without the RMS panels and controls, however you may have to look at the order of things and see if the animation still works. I also added a label to the aft MDU.

Can check this pretty easy, we have meshc for that in the tool chain. But the RMS panel animation will get broken anyway until for a moment, so you should talk to SiameseCat first about that move. Maybe it is better to leave this change to the next version.