Meadville Space Center
Welcome, Guest. Please login or register.
July 08, 2020, 06:45:49 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  AGC++ reentry help
« previous next »
Pages: 1 [2] 3 4 ... 6 Print
Author Topic: AGC++ reentry help  (Read 22301 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #15 on: December 21, 2006, 07:25:05 PM »

Also from the CSM system handbook (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730060780_1973060780.pdf), page 458. The systems handbook is great, there are detailed diagrams of all systems, though the AOH (http://history.nasa.gov/afj/aohindex.htm) is almost more important, but I didn't check the CM RCS there...

Cheers
Tschachim


* CM RCS.jpg (17.79 KB, 303x401 - viewed 248 times.)
Logged

chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #16 on: December 21, 2006, 07:55:15 PM »

Thanks again for the help. That diagram illustrates the problem. It shows the +pitch jets pointed towards the nose of the CM instead of "outward", as is the case for the current definitions. Pointed "outwards", the jets would be nearly in line with the center of mass, giving mostly translation rather than rotation, which explains what I am seeing when I fire the +pitch jets. I'll dig around those references to see if there might be a more definitive indication as to the direction of the jets.

Regards
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #17 on: December 22, 2006, 01:29:31 AM »

After looking over the schematics, and trying out some ideas, I've come up with a proposal for what the thrust vectors should be for the CM RCS jets. The position of the jets looks to be correct. I'd like to get some agreement for these thrust vector values, because I need to re-write some of the AGC++ autopilot, and if someone comes along and changes these vectors at a later date, the whole autopilot falls apart (again). The observations that have gone into these values are:

1) the +pitch thrusters (jets #1 & 3) point perpendicular to the CM skin, which has an angle of about 36 degrees to vertical.
2) the -pitch thrusters (jets #2 & 4) look like they point in the +y direction, and not perpendicular to the skin.
3) the + and - yaw thrusters (jets #5 to Cool look like they point perpendicular to the CM skin.
4) the roll thrusters, which are located at + and - 45 degrees to the +y direction look like they are not exactly pointing strictly along the x or y axies, but are tilted slightly towards the center of mass, maybe to lessen the lateral acceleration.

So, here are my proposed thrust vectors:

th_att_cm     Jet #           vector             control
       0                1        (0, -0.81, -0.59)       pitch up
       1                3            same                  pitch up
       2                2        (0, -1, 0)                pitch down
       3                4            same                  pitch down
       4                5        (-0.81, 0, -0.59)      yaw rt
       5                7            same                  yaw rt
       6                6        (0.81, 0, -0.59)        yaw left
       7                8            same                  yaw left
       8                9         (0.17, -0.98, 0)       roll rt
       9               11        (0.98, 0.17, 0)         roll rt
      10              10        (-0.17, -0.98, 0)       roll left
      11              12        (-0.98, 0.17, 0)        roll left

Regards
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #18 on: December 22, 2006, 11:30:53 AM »

Quote
If you eliminate the net thrust (or change it too much) you'll break the vAGC.

CAUTION!
Allthough I have nothing to do in this topic I would like to point out that we have so much difficulties to make the vAGC working in normal situation, so please please, DON't BREAK IT!
 Happy
Thanks.
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #19 on: December 24, 2006, 03:11:51 AM »

Don't worry, I won't do anything that can't be undone.

I have a question and some observations.

Question: is the vAGC working at any level to control the CM? (e.g. re-entry autopilot)

Observation: My thinking is that if the RCS jets on the CM are located and oriented correctly (according to the best information available), then the vAGC should work better because of the improved accuracy of the jets.

Observation (2): The thrust vectors for the roll jets I've proposed above have some issues. When I roll, these values cause a pitch-up in addition to a roll. According to the the best drawings I have of these jets, they look like they point slightly toward the -z direction. This makes sense, as this would tend to cancel the pitch-up effect when rollling. I'm trying some new thrust vectors for the roll jets to eliminate the pitch-up while rolling.

Regards
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #20 on: December 24, 2006, 03:21:22 AM »

Yes, the vAGC works with the CM, and can fly re-entries. You can also just start DAP and jettison the SM, and play around.
Correct is *ALWAYS* better, even if it breaks the vAGC. We can always fix the vAGC -toward- correct, since that's how it was originally operating anyway, but it's hard to fix -away from- correct. (I'm not sure if I worded that right...)
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #21 on: December 27, 2006, 02:14:28 AM »

I am seeing a very wierd bug with the CM RCS system. If I fire the roll or yaw thrusters, the opposite direction thrusters also come on after about a second. If I stop firing, then fire the same thruster again, they all (both directions) come on together. It does not happen with the pitch thrusters. I tried a clean install and build of the current CVS repository, and still see it. The best way to clearly see this is to look at the CM with an external view, zoomed in to see the thrusters, then manually roll or yaw for more than one second. Is anyone else getting this bug? Any suggestions as to what could cause such strange behaviour?

Regards
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #22 on: December 27, 2006, 06:19:35 AM »

First guess, SCS is active and in rate-limit mode, and is trying to untumble you.
Do you have a joystick? (Or better still, do you have two?)

Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #23 on: December 27, 2006, 03:04:30 PM »

Thanks again. You were correct, the SCS was switched in. The autopilot works correctly when I switch to CMC control (someday I learn how to fly this thing the right way). Manually, it works if I switch the manual to acell. I don't have a joystick connected, just using keyboard commands.

Regards
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #24 on: December 27, 2006, 04:35:30 PM »

You really should get one (or two) - Just the $20 four-axis (X/Y/Rudder/Throttle) joysticks they sell at Walmart work well.

Using the keypad just causes Orbiter to fire thrusters in whatever direction, completely outside the CMC/SCS. The CMC/SCS sees this as an uncommanded thruster firing and try to counteract it. I wanted to capture the keypad and assign it to THC/RHC axes, but this would cause problems for AGC++ users (until the AGC++ gets a DAP) and confuse people who are used to Orbiter's controls (killrot and the like). If you get joysticks, you can have a proper THC and RHC.

We'll *HAVE* to deal with this problem with the LM, because the LM RCS is sufficiently complex that Orbiter cannot use it properly. We can burn that bridge when we get there. I'd prefer to force people to be smart enough to fly realistically and leave the cheating to the other projects, but I'm outnumbered. ^_^


Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #25 on: January 03, 2007, 10:16:27 PM »

I've come up against a potential stumbling block for the reentry autopilot. The only publications I've found with detailed descriptions of the algorithms for the autopilot seem to be written specifically for AS-202. AS-202, for those of you who may not remember, was the second test flight of the Saturn 1b, and it carried a Block 1 command module. The reentry velocity for the flight was about 25,500 fps; more than orbital velocity, but still less than lunar return velocity.

In general, the autopilot was written with both Earth-orbit and lunar-return entries in mind, with one exception. There is a final guidance stage that requires a reference trajectory that it tries to fly to. The problem is that the reentry that was planned for AS-202 is somewhat unique in that the entry velocity is intermediate between orbit and trans-lunar and they flew a long downrange entry, with a big "skip" phase. As a consequence, the final stage starts out "high and slow" rather than "low and fast" as is the case for the reentries flown for lunar flights. After some experimentation, it looks to me like this reference trajectory is too far off to be used for control of historically correct lunar reentry. What happens is that the autopilot is trying to match a "high and slow" trajectory starting off "low and fast" and ends up overshooting the target to a point where it can't recover (although it tries, pulling about 10 Gs in the process).

Does anyone know of possible sources of additional information on the specifics of the reentry autopilot?

I have some info on the actual reentry profiles flown by Apollo 7 and 8, so my fall-back plan is to make my own final guidance "references" and see if that works.

Thanks for all your help.

Regards
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #26 on: January 04, 2007, 01:18:50 AM »

hope this can be of help....

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072398_1979072398.pdf
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #27 on: January 04, 2007, 01:24:54 AM »

Take a look for the following:

R-577 Section 3 on Entry DAP
19740072934_1974072934   a NASA archive doc on the entry procedures for near earth de orbit
You might also take a look at the mission reports which may also hold some info on reentry

Also see
http://aiaa-houston.org/cy0506/event-19may06/pres/pres151.ppt
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #28 on: January 04, 2007, 04:57:07 AM »

Delco manual has some information too, and you could check the Colossus source code as well.
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #29 on: January 04, 2007, 01:39:51 PM »

Thanks for the suggestions.

I've checked out those sources, and the three documents that give the reference trajectory data needed for the final entry guidance are the R-577 doc, Sect 5 (which is what I was using as the primary reference for the autopilot) , the Bellcom "Descriptlon of Apollo Entry Guidance for AS-202" document, and the source code for Colossus. Unfortunately, they all contain the same data. In the Colossus code, the data is commented "used for suborbital entry", and the reference trajectory looks like the profile actually flown by AS-202. If there was a source code listing for some later version of the AGC software, that could confirm that the reference trajectory was changed in later versions, but I haven't been able to find any of these.

I may go ahead and construct a reference trajectory from the Apollo 8 mission report which shows a "planned" trajectory and see how that works.

Regards
Logged
Pages: 1 [2] 3 4 ... 6 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!