SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.
So, finished typing the side aero data and plugged it in.... and the FCS is still having to put in aileron to maintain a bank. :facepalm: Further digging shows that the vehicle has some sideslip during banks that causes a roll moment in the opposite direction, and that is what the aileron is fighting. The sideslip should be taken out by the rudder, but it isn't really reacting enough to null the sideslip. :uhh:
As the yaw logic is driven by NY (lateral acceleration), and the logic that calculates it never really gave me a good feeling, that becomes candidate number 1 for further investigation. Does anyone know how to calculate lateral acceleration?
 
I had the same problem with SC3 vessels. The rudder was giving opposite side slip when just the ailerons were commanded.
 
Before I file an official ticket, does anyone else experience regular changes to the Orbit TGT Ha/Hp numbers? I have disabled everything that could affect the orbit calculations (Nonspherical gravity sources, radiation pressure, gravity-gradient torque). I have even placed the DAP in FREE to prevent any RCS firings.

This is something that makes calculating the correct burn data hard.
 
Before I file an official ticket, does anyone else experience regular changes to the Orbit TGT Ha/Hp numbers? I have disabled everything that could affect the orbit calculations (Nonspherical gravity sources, radiation pressure, gravity-gradient torque). I have even placed the DAP in FREE to prevent any RCS firings.

This is something that makes calculating the correct burn data hard.

I do. After loading the OMS targets the HA/HP show and then after 20/30” the values suddenly change...
 
Before I file an official ticket, does anyone else experience regular changes to the Orbit TGT Ha/Hp numbers? I have disabled everything that could affect the orbit calculations (Nonspherical gravity sources, radiation pressure, gravity-gradient torque). I have even placed the DAP in FREE to prevent any RCS firings.

This is something that makes calculating the correct burn data hard.

Yes, they change... think it could be the timestep length/frame rate, as I noticed that it shows one set of numbers at 1x, and another at 10x. Anyway, the OrbitDAP needs work (RCS, OMS, pointing to a surface or celestial location... and navigation).
File the ticket, at least as a reminder that things need to be done.

BTW: you closed the MECO scale ticket, but I still haven't worked it... :facepalm:
Actually I was going to start tonight. As there is no confirmation that the scale is now (i.e., post OI-32) dynamic, I'm going to reproduce the functionality of the (old) BFS display. I'll set the left hand side at MECO-700fps, and the right side at MECO+300fps (the MECO mark is at about 70% of the 1000fps scale). In the future when the I-LOADs are more mature, and the MECO targets are better specified, those 2 values will become the I-LOADs that they are, instead of being calculated "on the fly".
...and if someone is thinking "but that is more complex than it has to be", yes you are correct, but that's the way the shuttle was, so... :shrug:

---------- Post added at 10:29 PM ---------- Previous post was at 08:08 PM ----------

The MECO scale should now work for HST missions.
 
I think that the animation for the payload bay doors are wrong, more specifically rotation direction of the push/pull rods. They're supposed to end more-or-less vertical with the doors fully open. But right now they're at this weird angle and pointing inwards. I've also noticed that during the animation they almost go pure horizontal pointing towards the outer edges of the payload bay. This is a clear indication that something is off.

This is graphic from the Mechanical Systems Workbook which shows the entire mechanism both in the fully closed configuration (solid outlines) and the fully open configuration (dashed outline): https://www.dropbox.com/s/luyqcb1hklj7g39/PLBD drive system overview 2.jpg?dl=0
Our push/pull rods in the fully open configuration are at an similar angle to the the clamp in the closed configuration.
 
I think that the animation for the payload bay doors are wrong, more specifically rotation direction of the push/pull rods. They're supposed to end more-or-less vertical with the doors fully open. But right now they're at this weird angle and pointing inwards. I've also noticed that during the animation they almost go pure horizontal pointing towards the outer edges of the payload bay. This is a clear indication that something is off.

This is graphic from the Mechanical Systems Workbook which shows the entire mechanism both in the fully closed configuration (solid outlines) and the fully open configuration (dashed outline): https://www.dropbox.com/s/luyqcb1hklj7g39/PLBD drive system overview 2.jpg?dl=0
Our push/pull rods in the fully open configuration are at an similar angle to the the clamp in the closed configuration.

Oh, I know it's wrong, because I don't have the coordinates of the motor or the lengths of some parts... :shrug:
 
Oh, I know it's wrong, because I don't have the coordinates of the motor or the lengths of some parts... :shrug:
What lengths are you looking for? As for the coordinates of the motor, does the torque shaft position qualify?
 
What lengths are you looking for? As for the coordinates of the motor, does the torque shaft position qualify?


Should do it - but the mesh coordinates, not the real coordinates... I am sure we even have them somewhere.
 
Should do it - but the mesh coordinates, not the real coordinates... I am sure we even have them somewhere.
Based on the above posted graphic, the torque tube center is located approx. 5.63" (0.143 m) below the payload bay sill. The length of the push/pull rod is 0.283 m (11.14").
 
What lengths are you looking for? As for the coordinates of the motor, does the torque shaft position qualify?

All the axis (points where 2 parts meet) in the mechanism.

---------- Post added at 10:37 PM ---------- Previous post was at 10:35 PM ----------

Should do it - but the mesh coordinates, not the real coordinates... I am sure we even have them somewhere.

Real coordinates will do, as we can convert between both systems... I even made a spreadsheet for it. It should be in the Utils folder.
 
Torque tube-push/pull rod length: 0.10563 m
Push/pull rod-clamp length: 0.28287 m
Clamp-door rod length: 0.27606 m
Door rod-PLBD length: 0.15841 m
 
Based on the above posted graphic, the torque tube center is located approx. 5.63" (0.143 m) below the payload bay sill. The length of the push/pull rod is 0.283 m (11.14").


Or in Shuttle Systems Handbook, Volume 2, Drawing 14.1 (page 220 and following). Those might be much better because the 14.1 drawings also contain a sequence of drawings how the mechanism looks like at different stages of opening the doors (in the EVA section)



14.3 might also be interesting because it contains some dimensions on the latches as well.
 
Torque tube-push/pull rod length: 0.10563 m
Push/pull rod-clamp length: 0.28287 m
Clamp-door rod length: 0.27606 m
Door rod-PLBD length: 0.15841 m

The math takes in coordinates... so those measurements are only helpful in checking the math. With angles, which can also be used for checking, we could join both sets of numbers and calculate coordinates.

---------- Post added at 12:01 PM ---------- Previous post was at 11:59 AM ----------

Or in Shuttle Systems Handbook, Volume 2, Drawing 14.1 (page 220 and following). Those might be much better because the 14.1 drawings also contain a sequence of drawings how the mechanism looks like at different stages of opening the doors (in the EVA section)



14.3 might also be interesting because it contains some dimensions on the latches as well.
I'll recheck when I get home, but I think the coordinates we need aren't in those diagrams.
 
I'll recheck when I get home, but I think the coordinates we need aren't in those diagrams.

Many actually are, but not all, that's right. But having station numbers and some YZ coordinates is still better than none.
 
As I pretty much fried my brains with the aero stuff, I'd like to do some hidden triangle mesh work (it's boring as hell, but more easy on the head).
Looking at ticket 179 there is lots to do, but some I don't dare touch as I don't know what should be deleted. Of what I can do, I don't know if DaveS changed the meshes and hasn't committed them yet... :shrug:
To start, are these meshes unchanged?
EDO_pallet.msh
DFI_pallet.msh
Centaur_Mission_Kit_plumbing.msh
 
I am back after exams!

I'll re-start my work from the latest trunk commit. But I have a problem. The attitude ball is in the wrong position. It should be fixed (GLS did) but that isn't my case.
 
As I pretty much fried my brains with the aero stuff, I'd like to do some hidden triangle mesh work (it's boring as hell, but more easy on the head).
Looking at ticket 179 there is lots to do, but some I don't dare touch as I don't know what should be deleted. Of what I can do, I don't know if DaveS changed the meshes and hasn't committed them yet... :shrug:
To start, are these meshes unchanged?
EDO_pallet.msh
DFI_pallet.msh
Centaur_Mission_Kit_plumbing.msh
I'm working my way through the meshes. Could you confirm that as far as hidden triangles go, the current RSRM meshes are good? Those were checked in after you filed that ticket, so I just want confirmation that those are good.
 
I'm working my way through the meshes. Could you confirm that as far as hidden triangles go, the current RSRM meshes are good? Those were checked in after you filed that ticket, so I just want confirmation that those are good.

Looking at a center segment, the part of the cable tray that is inside the segment could be deleted, which would gain 8 triangles. Another 96 could be gained with similar work in the cable tray "belts". This seems like pennies, but it would be about 10% of that mesh.
One thing I noticed is that the propellant top and bottom disks are not concentric (or mishaped) and are visible on the outside.
Do I work this?
 
Status
Not open for further replies.
Back
Top