Space Shuttle Ultra 1.25 Revision B development

[Poscik]

New code checked in. It will display debug string with altitude error on the right and some other values in it. Added ReentryDragTable.cpp and .h. In AerojetDAP, lines 285-290 has been added. In Atlantis class, I obtained drag coefficient in PostStep, to pass it via STS() function to AerojetDAP. In AerojetDAP.cpp there is also another function in the end of the file, but it is useless at the moment. Calculations are made by ReentryDragTable.

 

[SiameseCat]

Thanks. I'll take a look at the code and see if I can figure out what's happening.

 

[DaveS]

Could SPEC050 Horiz Sit be implemented for HAC visualization? Currently the the only tool for this task is GPCMFD and it doesn't agree with SSU (at least the HUD).

 

[Poscik]

There was small error in code in Atlantis.cpp at line 5581. Now checked in corrected one.

 

[SiameseCat]

New code checked in. It will display debug string with altitude error on the right and some other values in it. Added ReentryDragTable.cpp and .h. In AerojetDAP, lines 285-290 has been added. In Atlantis class, I obtained drag coefficient in PostStep, to pass it via STS() function to AerojetDAP. In AerojetDAP.cpp there is also another function in the end of the file, but it is useless at the moment. Calculations are made by ReentryDragTable.

I found the problem; you're using the lookup table directly. I added the GetShuttleVerticalAeroCoefficients function to return the coefficients, and the idea was that this function could be called from AerojetDAP. The code you originally had got the coefficients for the basic shuttle, not the elevon/body flap components.

I've checked the fixed code in, along with two other small changes: in DragTable::TargetAltitude, I've replaced the hardcoded wing area value with the value defined in ParameterValues.h (this is the exact value used by Orbiter, and it will be easier to change the value if we get a more accurate number). Also, I added the ReentryDragTable files to the VS2010 Atlantis project.

 

[DaveS]

I found the problem; you're using the lookup table directly. I added the GetShuttleVerticalAeroCoefficients function to return the coefficients, and the idea was that this function could be called from AerojetDAP. The code you originally had got the coefficients for the basic shuttle, not the elevon/body flap components.

I've checked the fixed code in, along with two other small changes: in DragTable::TargetAltitude, I've replaced the hardcoded wing area value with the value defined in ParameterValues.h (this is the exact value used by Orbiter, and it will be easier to change the value if we get a more accurate number). Also, I added the ReentryDragTable files to the VS2010 Atlantis project.

So this means the Aerojet DAP is operational and tied to the PITCH and ROLL/YAW PBIs?

---------- Post added at 06:23 PM ---------- Previous post was at 04:44 PM ----------

After two failed tries, I have found that the Aerojet DAP seems to lose it when it is supposed to command the first roll reversal at DelAz = 10.5. The debug string goes all shaky and the roll reversal is never commanded and the entry ends in failure as the Gs build up beyond what the airframe was built to handle.

 

[Poscik]

I found the problem; you're using the lookup table directly. I added the GetShuttleVerticalAeroCoefficients function to return the coefficients, and the idea was that this function could be called from AerojetDAP. The code you originally had got the coefficients for the basic shuttle, not the elevon/body flap components.

I've checked the fixed code in, along with two other small changes: in DragTable::TargetAltitude, I've replaced the hardcoded wing area value with the value defined in ParameterValues.h (this is the exact value used by Orbiter, and it will be easier to change the value if we get a more accurate number). Also, I added the ReentryDragTable files to the VS2010 Atlantis project.

Thank you. I forgot to add ReentryDragTable to project :facepalm: But still it want us to drop more altitude than we need. There have to be problem with drag function. I'll try to do some test with it.

So this means the Aerojet DAP is operational and tied to the PITCH and ROLL/YAW PBIs?

---------- Post added at 06:23 PM ---------- Previous post was at 04:44 PM ----------

After two failed tries, I have found that the Aerojet DAP seems to lose it when it is supposed to command the first roll reversal at DelAz = 10.5. The debug string goes all shaky and the roll reversal is never commanded and the entry ends in failure as the Gs build up beyond what the airframe was built to handle.

That's for all:
AUTO mode doesn't do anything useful yet. Code has been checked in to track altitude error problem, which is still occuring. You can also reenter to KSC only, referring to target drag and actual drag values.

 

[SiameseCat]

If you compare the target and actual density (instead of altitude), the drag coefficient seems to be correct. So it looks like the problem is converting the target density to a target altitude.

 

[Poscik]

If you compare the target and actual density (instead of altitude), the drag coefficient seems to be correct. So it looks like the problem is converting the target density to a target altitude.

Ok, I'll take a look on it. So indeed there is the problem with drag function I've taken from columbia conspiracy site I think something is missing there...

[EDIT]
Ok, I'll review my altitude function also. I'll generate lookup table for it also.

 

[DaveS]

Ok, I'll take a look on it. So indeed there is the problem with drag function I've taken from columbia conspiracy site I think something is missing there...

You can blame that on me as I was the one who pointed you to that site, although I did caution you that everything on that site was suspect, including the equations.

 

[Poscik]

You can blame that on me as I was the one who pointed you to that site, although I did caution you that everything on that site was suspect, including the equations.

Actually equations match these from wikipedia, so they are rather less fake :lol:

 

[SiameseCat]

Could SPEC050 Horiz Sit be implemented for HAC visualization? Currently the the only tool for this task is GPCMFD and it doesn't agree with SSU (at least the HUD).

I'm working on this.

 

[Poscik]

Hey! I have some good news to announce. I generated atmoshpere density table by 500m step. Now it uses linterp() function to return target altitude, and it works very nice. One thing that have to be done before messing with good PID, is to operate on drag indicated by SurfaceMFD, not on returned from GetDrag(), because sometimes there is 1m/s*s error. Result? Made few reentries, and I was too high on energy in every try, because GetDrag() was returning higher drag than actually was. My idea is to calculate drag from GetForce(), store it in 100-element list and return average value. In each step remove value on top, and add new one on the bottom, then repeat procedure. Any ideas?

 

[SiameseCat]

Not sure is this is what's causing problems, but drag is defined as being parallel to the velocity vector. You probably only want the horizontal component.

 

[Poscik]

That can be. I did new measurements. For most time during reentry, difference between GetDrag() and ACC is within 0.1m/s*s. I doubt it can lead to "much too high energy" on TAEM. In fact, I'm mach 2.5 when entering the HAC. This should occur 60nm earlier, so I'll shorten range and see what happens.

 

[DaveS]

Could SPEC050 Horiz Sit be implemented for HAC visualization? Currently the the only tool for this task is GPCMFD and it doesn't agree with SSU (at least the HUD).

I'm working on this.

How is this coming?

 

[SiameseCat]

Pretty much complete. I'm hoping to check the code in tomorrow.

 

[Poscik]

Also I just trying to draw runway on HUD, yet without any effects. I'm stopped at measuring rwy threshold position in local coordinates. Reentry calculations are work pretty fine. Following altitude error you can land precisely 2.5 mach at 60nm range. Now we need good PID and de-orbit planner.

 

[SiameseCat]

I'll see if I can do the HUD drawing - it might be fairly similar to the HORIZ SIT drawing code I've been working on.

 

[Poscik]

I just figured out one end of the runway, using already implemented function. But IMO would be better if I could calculate relative position of each runway end. Then some trigonometry would do the trick