Space Shuttle Ultra 1.25 Revision B development

[Poscik]

Just started working on simple MM801. Of course I'm implementing it the same way as AerojetDAP, OrbitDAP etc. At first it will have ability to do FCS C/O, as Dave requested. Will be ready in next few days.

 

[Poscik]

Basic MM801 code has been checked in. If I did something wrong, just let me know. Active items are 10 and 11. 10 starts the motion, 11 parks elevons.

Known issues:
- No movement indication on SPI display
- No MM801 display yet

I'm gonna fix them soon.

:tiphat:

 

[DaveS]

Only problem identified is that the elevons stop when they hit their hardstops when they should reverse the motion with no delay.

 

[Poscik]

Ah, yes. Also they can be moved without APU enabled yet. But everything gonna be repaired.

 

[Urwumpe]

Ah, yes. Also they can be moved without APU enabled yet. But everything gonna be repaired.

We should send all control surface commands by the GPC to the ASAs, and let the ASA only operate, if hydraulic pressure is available. Should make the behavior more transparent.

Wouldn't really work for the user inputs.

 

[SiameseCat]

We should send all control surface commands by the GPC to the ASAs, and let the ASA only operate, if hydraulic pressure is available. Should make the behavior more transparent.

Wouldn't really work for the user inputs.

We don't have ASAs simulated yet, but the code already does something like this (the aerosurface positions are set in Atlantis::clbkPreStep, and only at least one APU is on).

 

[Donamy]

SSME stow would be nice.

 

[Urwumpe]

SSME stow would be nice.

Let me get my new notebook, and I will stow them where the plasma does not shine. :ninja:

(Had ordered it yesterday, after seeing that my bank account is free of any fiscal cliffs in the future, I plan for delivery in week ten)

------------------------------------------------------------

I think we should define ASA and ATVC, since they do a lot of important work regarding most hydraulic actuators.

About the development for the DPS modes: How about having a basic framework for such applications, that is based on the HAL/S grammar macros... the macros are defined and known to us (ALT Software specs). They define the event handling and user interface behavior, and should be pretty accurate for defining the keyboard events etc.

Should permit more commonality in the development.

While shortcuts and direct access to the Orbiter animations etc. are faster implemented they mean a lot more work when we later have to refactor them - it would really be better if communication from GPC software to the actual subsystem would be via the network nodes.

EDIT: And we should have some kind of "Working Agreement" for SSU, mandatory at least for those who have commit rights for the repository. Examples of what is defined in a Working Agreement is for example how many tasks are active at a time during development in a team, how communication should be, language used for documentation and source code or when things should be committed.

Currently all appears to be a bit too liberal, especially regarding that the lack of a mandatory coding style guide leads to a complete lack of source code documentation - we are open source and want to reach a distant goal one day, not closed source and fail early.

 

[DaveS]

I'm almost done with updated orbiter mesh, just have to finish up the contemporary textures. One thing though: Anyone know if it is possible to realistically animate things like flex hoses?

 

[Urwumpe]

I'm almost done with updated orbiter mesh, just have to finish up the contemporary textures. One thing though: Anyone know if it is possible to realistically animate things like flex hoses?

Realistically - Not with a constrained CPU performance. There you have quite a lot of calculations.

Pseudo-realistic: No problem for simple hoses. A large long hose isn't really nice to simulate even with many simplifications.

Pseudo-pseudo: No deal, there are solutions for this. We could just assume a spline from the beginning vector to the end vector, maybe with some constraining middle points.

The animation would be most realistic by mapping the vertex data on a hose model. Can be done, is pretty simple if the hose is initially a straight tube: note the distance of each vertex to the center line and store the 2D coordinates of the plane perpendicular to the center line. During animation, calculate the new vertex coordinates by projecting the 2D coordinates relative to the bend center line.

I can write a class for this stuff. Would be a bit more processor and GPU heavy to use. I think the state of the art solution would be a geometry shader, but I can't do this and Orbiter does not support it.

 

[DaveS]

The reason I'm asking is because I was thinking about adding the radiator retract flex hoses. There's a total of four flex hoses, two per side (forward and aft).

---------- Post added at 07:48 PM ---------- Previous post was at 06:13 PM ----------

The port forward radiator retract flex hose can be seen in this photo: http://spaceflight.nasa.gov/gallery/images/shuttle/sts-116/hires/s116e07004.jpg
It attaches to the aft end of the white TCS covered tube on runs along the upper edge radiator panels.

 

[Poscik]

What is line voltage for elevons fully "up" and "down"? They are set to 0.1 and -0.1 now, but it's too much I think.

 

[SiameseCat]

The AerojetDAP code has -1.0 to +1.0. I don't think the actual value matters much, and this way the elevon command is nicely scaled.

 

[Urwumpe]

What is line voltage for elevons fully "up" and "down"? They are set to 0.1 and -0.1 now, but it's too much I think.

I can maybe research this. (Never tried it, but my Galaxy S3 should be capable of accessing my external HDD as USB Host, if I can find the right cable)

I suspect it is 0 to 5V, using a simple Analog-Low I/O card on a MDM. Need to find out, what the ASA does with that input. The data for the SPI should arrive the other way around, getting sampled from an analog line into a 10 bit digital readout and scaled in the GPC to the proper value.

 

[Poscik]

Well... elevons reach their "down" and "up" positions at about -0.1 and 0.1 volts. Then they stand freeze. I move them in clbkPreStep in Atlantis.cpp, line 4398. Looks like animation scaling is wrong.

[EDIT]
I fixed it by the way.

---------- Post added at 10:24 PM ---------- Previous post was at 08:11 PM ----------

New MM801 code has been checked in. FCS C/O now work as it should. I will add proper display soon.

---------- Post added 03-02-13 at 04:35 PM ---------- Previous post was 03-01-13 at 10:24 PM ----------

I also added complete display for MM801, but with limited functionality to items 10 and 11. Only things left to do is body flap movement and load/save state.

 

[DaveS]

Just for reference here's the post-landing SSME REPO sequence:

1: BODY FLAP to TRAIL (34.2%)
2: SSME 1 to FULL UP
3: SSME 2 to FULL LEFT
4: SSME 3 to FULL RIGHT
5: BODY FLAP to FULL DOWN(100%)
6: SSME 1 to FULL DOWN
7: SSME 2 to FULL DOWN, then CENTER YAW
8: SSME 3 to FULL DOWN, then CENTER YAW

---------- Post added 03-03-13 at 01:01 AM ---------- Previous post was 03-02-13 at 05:54 PM ----------

Question: The SSME refs in Atlantis_defs.h, are those where the center of the MCCs of each engine are located on the mesh?

 

[SiameseCat]

I think so. The SSME refs are used for the SSME gimballing animations and as the thrust reference point when defining the SSME thrusters.

 

[DaveS]

Which new tile texture do you like the best? I think texture 2 looks the best, with the borders between the individual tiles showing nicely, but I'm looking for other opinions.

 

[Donamy]

Would be better to see a wider shot also.

 

[DaveS]

Would be better to see a wider shot also.

Here you go:

Tile tex 1:

Tile tex 2: