Meadville Space Center

Project Apollo - NASSP => Programming => Topic started by: chode on December 13, 2006, 02:19:00 AM



Title: AGC++ reentry help
Post by: chode on December 13, 2006, 02:19:00 AM
I've been able to get some free time (finally!) to get back to some programming for Project Apollo.

So far, I've been able to incorporate C++ code that emulates the programs P61 through P67 into the existing code (in CSMcomputer.cpp and apolloguidance.cpp). The problem I have is that my old code for autopilot control of the RCS jets on the CM doesn't work anymore. I was using "SetAttitudeRotLevel" in my old code. Could someone point me in the right direction as to how to control the CM RCS system in the new code?

Regards


Title: Re: AGC++ reentry help
Post by: dseagrav on December 13, 2006, 02:34:23 AM
Just set and clear the bits in IO channels 5 and 6 to fire and stop thrusters.
Pitch and yaw jets are on channel 5, roll jets on 6.

To do this:
SetOutputChannelBit(0ch, xx, y);  ch = channel (The leading 0 is important), xx = bit number, y = value

Jet table (I think this is correct, I didn't look it up, this is just copipe)

Code:
CM# SM# INDEX# SWITCH GROUP ROT AXIS
CH 5
1 1 C3 1 PITCH +PITCH
2 2 A4 2 PITCH -PITCH
3 3 A3 3 PITCH +PITCH
4 4 C4 4 PITCH -PITCH
5 5 D3 5 YAW +YAW
6 6 B4 6 YAW -YAW
7 7 B3 7 YAW +YAW
8 8 D4 8 YAW -YAW
CH 6
1 9 B1 9 ROLL B/D +ROLL
2 10 D2 10 ROLL B/D -ROLL
3 11 D1 11 ROLL B/D +ROLL
4 12 B2 12 ROLL B/D -ROLL
5 xx A1 13 ROLL A/C +ROLL
6 xx A2 14 ROLL A/C -ROLL
7 xx C1 15 ROLL A/C +ROLL
8 xx C2 16 ROLL A/C -ROLL


Title: Re: AGC++ reentry help
Post by: chode on December 13, 2006, 02:54:39 AM
Thanks, I'll give it a go.

That jet table is actually very readable once I copied and pasted it into Notepad.

Regards


Title: Re: AGC++ reentry help
Post by: Swatch on December 13, 2006, 08:33:16 AM
that is a very strange glitch....

Good to see ya back chode!


Title: Re: AGC++ reentry help
Post by: movieman on December 13, 2006, 08:40:07 AM
BTW, if that doesn't work, check that the SetOutputChannelBit() call goes through the correct path to process the RCS bits. The function that the Virtual AGC calls certainly does, but I'm not 100% sure that they all do and don't have access to the code at the moment.


Title: Re: AGC++ reentry help
Post by: dseagrav on December 13, 2006, 08:41:14 AM
BTW, if that doesn't work, check that the SetOutputChannelBit() call goes through the correct path to process the RCS bits. The function that the Virtual AGC calls certainly does, but I'm not 100% sure that they all do and don't have access to the code at the moment.


I checked before I posted. It does pass through the channel processing code.


Title: Re: AGC++ reentry help
Post by: chode on December 19, 2006, 08:34:15 PM
I tried using SetOutputChannelBit, but no success. I've tried to follow the path that call would take, and it looks like CSMComputer::SetOutputChannelBit calls ApolloGuidance::SetOutputChannelBit which calls ProcessChannel15. My rusty C++ may be showing here, but does this call ApolloGuidance::ProcessChannel15 or CSMComputer::ProcessChannel15? ApolloGuidance::ProcessChannel15 doesn't do anything, while CSMComputer::ProcessChannel15 looks like it fires the jets.

Any help or suggestions are greatly appreciated.

Regards


Title: Re: AGC++ reentry help
Post by: movieman on December 19, 2006, 09:07:41 PM
Quote
My rusty C++ may be showing here, but does this call ApolloGuidance::ProcessChannel15 or CSMComputer::ProcessChannel15?

It's virtual, so it goes into the CSMComputer version.

Is the CM RCS activated?


Title: Re: AGC++ reentry help
Post by: chode on December 19, 2006, 09:12:35 PM
I can control the CM RCS manually with the numpad, so I am assuming that it is activated. Also, manual control acts a little wierd, for example the KILLROT doesn't work right. Maybe that indicates that the autopilot is constantly setting all thrusters to zero?

Regards


Title: Re: AGC++ reentry help
Post by: dseagrav on December 20, 2006, 12:02:16 AM
Did you have the guidance mode set to CMC?

Also check that the RCS AUTO power is on to a live bus (left panel).

If the SCS has control it will probably override you, or if the RJEC lockout conditions are true (RHC is commanding DIRECT, etc) that will override either SCS or CMC.






Title: Re: AGC++ reentry help
Post by: chode on December 20, 2006, 03:10:28 PM
Thanks for the help, it looks like I didn't have the RCS power connected up. I am now getting RCS action from P63, now I just have to get it to control properly, and not not send me into an uncotrollable tumble.

Regards


Title: Re: AGC++ reentry help
Post by: dseagrav on December 20, 2006, 03:16:52 PM
That's good, I was worried for a second that I had missed or forgotten something ^_^


Title: Re: AGC++ reentry help
Post by: chode on December 21, 2006, 12:43:00 PM
OK, new problem. It looks like the thrust vectors for the CM RCS jets are incorrect. For example, the pitch-up and pitch-down jets are all pointed in the -y direction, so the net effect is to push the CM in the -y direction when these jets fire, changing the orbit of the CM. I'm not sure what the correct vectors should be, other than my intuitive feeling that they should be perpendicular to the vector from the jet to the CM center of mass to maximize torque and minimize net thrust (although there will still be some net thrust). Does anyone have any source for this info? Otherwise, I'm going to try the perpendicular approach and see how that works.

Regards


Title: Re: AGC++ reentry help
Post by: dseagrav on December 21, 2006, 05:10:43 PM
I'll dig through my reference material when I get home (about an hour) - I know there was some net thrust because the AGC expects it, and it's mentioned in the source code. If you eliminate the net thrust (or change it too much) you'll break the vAGC.



Title: Re: AGC++ reentry help
Post by: dseagrav on December 21, 2006, 06:44:43 PM
CSM 104 SYSTEMS HANDBOOOK pages 472 and later show how the engines are mounted. They should point straight out through their holes. Honestly, I can't remember if I aimed them or not.

It looks like the ones on the sloped sections of wall (roll, plus pitch, yaw) point directly out their holes flush with the wall, and the minus pitch engines point straight up (page 474).



Title: Re: AGC++ reentry help
Post by: Tschachim 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


Title: Re: AGC++ reentry help
Post by: chode 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


Title: Re: AGC++ reentry help
Post by: chode 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 8) 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


Title: Re: AGC++ reentry help
Post by: Christophe 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!
 :)
Thanks.


Title: Re: AGC++ reentry help
Post by: chode 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


Title: Re: AGC++ reentry help
Post by: dseagrav 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...)


Title: Re: AGC++ reentry help
Post by: chode 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


Title: Re: AGC++ reentry help
Post by: dseagrav 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?)



Title: Re: AGC++ reentry help
Post by: chode 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


Title: Re: AGC++ reentry help
Post by: dseagrav 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. ^_^




Title: Re: AGC++ reentry help
Post by: chode 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


Title: Re: AGC++ reentry help
Post by: Swatch 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


Title: Re: AGC++ reentry help
Post by: irnenginer 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


Title: Re: AGC++ reentry help
Post by: movieman on January 04, 2007, 04:57:07 AM
Delco manual has some information too, and you could check the Colossus source code as well.


Title: Re: AGC++ reentry help
Post by: chode 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


Title: Re: AGC++ reentry help
Post by: chode on January 04, 2007, 02:33:33 PM
Aha, I just found an edited trajectory table which looks like it was used for Colossus 3. I'll try it out and see if works any better.

Regards


Title: Re: AGC++ reentry help
Post by: chode on January 09, 2007, 01:16:27 AM
Thanks in large part to everyone's help, I'm very close to committing the AGC++ reentry autopilot code.
The last thing I need to do is refine the atmospheric jet control to be more realistic. Right now, it's barely good enough to do the job. I think I have sufficient documentation on how it's supposed to work, so it shouldn't be long. Even with a clunky jet control algorithm, the autopilot typically lands within 5 kilometers of the target.

Regards


Title: Re: AGC++ reentry help
Post by: Tschachim on January 09, 2007, 08:55:49 AM
Cool, great news, I can't wait to try!  :ThumbsUp432:  :)

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: chode on January 11, 2007, 04:33:25 AM
I've committed the reentry guidance programs.

The simplest way to engage guidance is to enter:

V37E61E

then hit PRO 5 times, and P63 should take over,
guiding you to a safe landing (as long as you hit water, and your entry angle is within limits).

In more detail, here is what you should see:

Enter V37E61E:

Flashing V06N61
         XXX.XX   Impact Latitude
         XXX.XX   Impact Longitude
          +/-1    RollCode

These values are calculated based on a nominal reentry down-range (historical), and zero
cross-range. They can all be changed through V21-25.

Enter PRO:

Flashing V06N60
         XXX.XX     Predicted maximum G force
         XXXXX m/s  Predicted velocity at entry interface
         XXX.XX     Entry angle

Enter PRO:

Flashing V16N63
         XXXX.X     predicted range from 0.05G to splash
         XXXXX m/s  predicted Velocity at 0.05G
         XX  XX     min  sec   until 0.05G

Enter PRO:

Program advances to P62

Flashing V50N25
         00041      Checklist Code (perform CM/SM separation)

Enter PRO:

Flashing V06N61
         XXX.XX   Impact Latitude
         XXX.XX   Impact Longitude
          +/-1    RollCode

Last chance to change the landing point (V21-25).

Enter PRO:

P63 takes over, display shows:

Flashing V16N64N
         XXX.XX     Drag Acceleration
         XXXXX m/s  Inertial velocity
         XXXX.X km  Range to splash

Attitude hold is engaged to orient correctly for entry interface.

When Drag acceleration reaches 0.05G, program automatically advances to P64.

P64 (nominal)

If entering from Earth orbit (with entry angle around 2 to 3 degrees),
should proceed to program 67.

If entering from trans-lunar orbit (with entry angle around 6 to 7 degrees),
should stay in P64, attempting a constant drag level until sufficient energy is lost,
then enter P67.

P67:

Flashing V16N66
         XXX.XX deg   Commanded Bank Angle
         XXXX.X km    Downrange Error
         XXXX.X km    Crossrange Error

When your velocity drops low enough, P67 shuts off the control jets and displays:

Flashing V16N67
         XXXX.X km    Range to target splash
         XXX.XX deg   Present Latitude
         XXX.XX deg   Present Longitude

Notes: P65 and P66 are also implemented, but will only be used if you re-target to a
 landing point far down-range of the nominal target. Historically, they were only used on
 test flights.

Questions, comments welcome.

Regards



Title: Re: AGC++ reentry help
Post by: Tschachim on January 11, 2007, 06:51:55 AM
Great! :)

I didn't try yet, but I have a question: You changed the "CoeffFunc" function in Saturn1b.cpp, should the "CoeffFunc" function in Saturn5 also be changed, because it's the same CM?

... and a request of the lazy ones like me :wink:: Could you post/attach a test scenario (by using the "Additional Options" feature of the reply screen), which one can start, enter V37E61E and watch the entry? That would be great!

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: chode on January 11, 2007, 02:10:46 PM
You are correct that the CoeffFunc in Saturn V should be changed as well. I'll go ahead and do that.

As for scenarios, I'll see if I can attach two I have been using for testing.

One is from orbit, Apollo 7. The CM is still attached, so you have to separate.

The other is reentry from a trans-lunar sized orbit.

Regards


Title: Re: AGC++ reentry help
Post by: movieman on January 11, 2007, 08:37:47 PM
Haven't had a chance to try it, but I fixed the warnings and made it build on VC2005.

Note that you shouldn't define loop counter variables in for loops, because that causes incompatibiilties between VC6 and VC2005.


Title: Re: AGC++ reentry help
Post by: Coussini on January 12, 2007, 05:37:28 AM
Thanks Chode... i'll try this.

Great job. Hapy new year to everybody.


Title: Re: AGC++ reentry help
Post by: mikaelanderlund on January 13, 2007, 05:20:58 AM
Cool :ThumbsUp432:. Great :Excited432:

Mikael


Title: Re: AGC++ reentry help
Post by: Swatch on January 13, 2007, 10:47:29 AM
Now about that EMS.... :-)

Can't wait to try this!

It's good to be back guys! :-D


Title: Re: AGC++ reentry help
Post by: Tschachim on January 15, 2007, 01:35:50 PM
Hi chode,

I didn't do comprehensive tests yet, but I noticed that with the AGC++ autopilot the CM rolls a lot and sometimes flys complete rolls, especially at higher g loads. Since I have almost no knowledge about entry, is that normal/intended?

Also the VAGC seems to react differently, probably because of the modified CM RCS thrusters, but I don't know if it's more or less realistic now. Perhaps you could elaborate a litte bit how the CM should fly?

Quote
Now about that EMS...

Yeah, it looks like I need the EMS dV mode soon for the SPS, chode, do you have any plans to do the EMS or parts of it (or anybody else)?

Thanks and Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: dseagrav on January 15, 2007, 02:00:16 PM
I can do the EMS if nobody else already started - I was putting together my notes earlier today for just that. By the way, does anyone have any original Apollo 7 checklists? I can't find any.

As far as the rolling, I know that the CM primarily rolls during re-entry, but causes some yawing because there is an SCS re-entry mode that modifies the yaw data to eliminate yaw caused by rolling about the "aerodynamic stability axis". (I don't understand how to simulate this behavior.) The rolling is how it does the "Fly up" and "Fly down" commands that the EMS will be generating. During a manual entry, the crew is supposed to roll the CM to match the EMS commands. During automatic entry the CMC and EMS are independent, and usually generate the same commands by separate means.



Title: Re: AGC++ reentry help
Post by: Tschachim on January 15, 2007, 02:25:28 PM
I can do the EMS if nobody else already started - I was putting together my notes earlier today for just that.

I did nothing yet, I don't know if chode started, for my part you can go ahead!  :)


Title: Re: AGC++ reentry help
Post by: chode on January 15, 2007, 04:17:13 PM
The reentry data I've seen shows a lot of rolling, this is the expected behavior. In reentry from the moon, the initial pull-up (to limit the G forces to 7 Gs) is followed by a 180 degree roll to prevent the CM from skipping back out of the atmosphere. During this early part, the guidance is trying to keep the G forces around 4 Gs. After it starts back down again, it need to roll back 180 degrees to minimize the Gs on the "second bounce". After that it is seeking to follow a reference trajectory, while maintaining a resonable cross-range error. This requires a lot off rolling as well, with at least a few rolls from right to left and back (much like the Space Shuttle).

The jet directions have been changed significantly, and I did my best to make them more historically accurate. The original directions were definitely incorrect, and there was a lot of cross-feed of roll commands into yaw and vice-versa.

I should note that my approach was to model everything as close to the documentation as possible (aerodynamics, jets, guidance equations, DAP), and then see if it actually worked the way it was supposed to. The only things that I changed were two constants in the reference trajectory (P67), and I know that these were tweaked a few times from flight to flight in reality anyway.

I'll try to fly reentries with the VAGC to see if the new jet directions are worse or better than the old ones (as far as VAGC control is concerned).

The only part of the reentry that behaves a little differently compared to the actual reentry data is the final phase, where the combined innacuracies of the aerodynamics and atmospheric properties cause the autopilot to roll around a little more trying to seek out the reference trajectory, which would have been based on more accurate models for these properties.
Even so, the guidance does a good job getting to the target, since I'm sure it was designed with built-in tolerance to uncertainties in the flight dynamics.

I had intended to start working on the EMS system, starting with the .05 G light, then the roll indicator, the corridor lights, and the scrolling chart.

I wouldn't mind if someone wanted to start on some of these, since I don't know how quickly I might progress on these.

One initial question: Should the scrolling chart use m/sec or ft/sec, or leave the option to do either?

Regards




Title: Re: AGC++ reentry help
Post by: Swatch on January 15, 2007, 04:51:42 PM
If nobody has started on it yet, may I suggest that dseagrav works on the EMS implementation while chode continues checking the accuracy of the reentries?  Moonwalker or myself (preferably him to keep things consistant) can start on some reentry scrolls....I'll see what I can dig up if you want to post the stuff you have on them.  Tschachim, you know the vAGC quite well, so maybe you can help chode check the modifications to thrusters along with any reconciliation between the vAGC and the AGC++ in performance.

Anyway, that might get all of our skills working on this at once, and that's my  :twocents22: worth.   What do you guys think?

PS. I'm a bit worried about the thursters because of our past problems, but it may be because I'm not extremely knowlegable on their orbiter implementation.  My first question is, were the CM thrusters checked or was it just the SM thrusters that dseagrav worked on?  Secondly, are the new thrusters compatable with where the vAGC wants them?


Title: Re: AGC++ reentry help
Post by: movieman on January 15, 2007, 05:25:19 PM
Do the SM thrusters point in the right direction now? I know when I first moved them to match the new mesh they were pointing a few degrees out from where they should have been... I don't know whether anyone ever fixed that.


Title: Re: AGC++ reentry help
Post by: dseagrav on January 15, 2007, 07:21:59 PM
I worked on both the CM and SM (and the LM), because I'm the one who originally split and repositioned the CM RCS. I never did AIM them in the right direction though. They're wired through the RJ/EC, but if I remember right tschachim has a hack that shuts off part of the RJ/EC logic for the AGC++.

For whoever makes the scrolling tape images, please use US units first, so we can confirm operation with the NASA documents and vAGC, and then make metric versions later. The logic shouldn't change at all, just the scroll tape images.

I would like for someone else to please look at the SCS 0.5G switch, or tell me how to do it. The doc says it "modifies the roll-rate gyro output by the tangent 21 degrees and sums with the yaw rate". I don't know what this means. The idea is to make the yaw rate zero when the CM is rolled about the stability axis. (I never went past algebra in school, I spent more time in electronics and computer stuffs! ^_^)


Title: Re: AGC++ reentry help
Post by: Tschachim on January 16, 2007, 07:30:15 AM
About the EMS: Chode, you did a great job with the AGC++ entry autopilot, I think you should continue with the EMS. Please use the historical (US) units, except some AGC++ outputs all displays and controls use the historically correct units and I would like to stay with that. Are you also going to do the dV/range display and the dV mode we need for the SPS SCS dV mode? If not, perhaps Dseagrav could take a look at that part of the EMS? :)

About the CM/entry: Thanks for explaining! It seems to look like the VAGC is working better with the new CM RCS thruster positions/directions, but I (we) need to do more tests, I'll post if I have some results.

About the SM RCS: Dseagrav, I think you did the last modifications of the SM RCS thrusters a few months ago? I don't know if they are really correct, but they seem to work fine with the VAGC and the SCS. Anyway, perhaps you or chode could take a look at that just to have "that issue closed"? Swatch, I don't know the RCS thrusters very well, I plan to stick to the SPS until that's ready.

The hack I introduced is the CSMcomputer::SetAttitudeRotLevel(VECTOR3 level) function, which sets the RCS thrusters with Orbiter's SetAttitudeRotLevel function and disables the RJ/EC for 2s (AGC++ control loop is 2s). But this is only used by some of LazyD's AGC++ programs (mainly LOI and the rendezvous programs) and not by the VAGC or the SCS and should be modified sooner or later to use the I/O channels.

Cheers
Tschachim

EDIT: I modified this post a couple of times, I hope it's finished now (and not to weird)... :)


Title: Re: AGC++ reentry help
Post by: Swatch on January 16, 2007, 08:51:35 AM
alrighty, sounds cool  :cool7777:

Hey Chode, do you think you can get me everything you have on the scrolls?  I'll look into replicating them.


Title: Re: AGC++ reentry help
Post by: dseagrav on January 16, 2007, 09:35:57 AM
I'll go along with that as well; chode can do the EMS. I can re-check the CM RCS if you like, probably this afternoon. I'll probably go back to my primary project after that, about which another thread will be posted in a few minutes. (The AC inverter stuff was a diversion from that project, just because I stumbled across the efficiency data while doing some spelunking at NTRS ^_^)





Title: Re: AGC++ reentry help
Post by: Tschachim on January 16, 2007, 09:41:26 AM
I can re-check the CM RCS if you like, probably this afternoon.

Cool, perhaps you could also check the SM RCS as movieman requested? The CM RCS seems to be better since chodes modifications, but re-checking can't hurt... :)


Title: Re: AGC++ reentry help
Post by: dseagrav on January 16, 2007, 10:12:39 AM
Meh, that was a thinko. I meant SM.


Title: Re: AGC++ reentry help
Post by: chode on January 16, 2007, 11:54:35 AM
As it stands now, the only thing that I would suggest correcting in the CM RCS system is to have the thruster positions coincide with the mesh. The pitch and yaw thrusters look to be only an inch or two off, but the roll thrusters look to be off by a larger amount. This re-positioning shouldn't have much effect on the performance.

The reason for the rate gyro summing during the entry is because the CM is not rolling along the z axis of the spacecraft, the angle of rotation is off by about 21-25 degrees. What you really want to measure is the roll angle relative to the rotation axis, so you need to geometrically sum the roll and yaw rates to arrive at the "true" roll angle. I'll see if I can come up with a more mathematical explanation that would be useful in practice.

The AGC in P61 - P67 presently uses metric units in all the displays. It sounds like people prefer English (historical) units, so I'll look at making English the standard and leave the option to show metric. Would the best thing be to have a line in the scenario file, something like UNITS METRIC/ENGLISH?

The Delta V display is not at the top of my list of things to work on, so feel free to work on it.

Swatch, I'm away from home for the next week at least, and that is where most of my Apollo data resides. I'll see if I can find links to the documentation with pictures of the EMS scroll.

Regards




Title: Re: AGC++ reentry help
Post by: Tschachim on January 16, 2007, 12:00:21 PM
Would the best thing be to have a line in the scenario file, something like UNITS METRIC/ENGLISH?

A setting like this already exists (at least partially), please check ApolloGuidance::DisplayUnits.


Title: Re: AGC++ reentry help
Post by: dseagrav on January 16, 2007, 12:21:35 PM
It sounds like people prefer English (historical) units, so I'll look at making English the standard and leave the option to show metric.

It's actually the opposite - We have to use US measurements initially, so we can check against NASA's documentation, but Orbiter and the majority of the people want metric measurements.

As I understand it, this is primarily a European project, Americans are a minority here.


Title: Re: AGC++ reentry help
Post by: Tschachim on January 16, 2007, 12:33:01 PM
Well, despite the fact that I'm used to metric units (and an European, but I would characterize Project Apollo - NASSP more an international project :)), I would prefer to have the historically correct (i.e. imperial) units, just because this is the way it was. But of course I've no problem to show metric units optionally for user's convenience.

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: dseagrav on January 16, 2007, 12:57:28 PM
Well, in other projects I've been involved in, I usually catch some flak for being too Americentric, so I'm trying to be more considerate this time around. Not everyone is a big fan of Americans, and on the prior Apollo project I even was asked by a potential user if it would be possible to remove the NASA and USA marks from the equipment so the user could pretend that another "more civilized" nation had done the landing instead. I ignored the request, did not forward it to the others in the project, and quite frankly was insulted by it. In retrospect, that's incredibly close-minded, to be insulted by the idea that someone else should have done something rather than you. I'm trying to do better this time.


Title: Re: AGC++ reentry help
Post by: movieman on January 16, 2007, 01:34:40 PM
Given that all the MFDs output metric units, it's almost certainly better for the AGC default to be metric :).

Also, while the flag exists to distinguish between imperial and metric units, most of the code ignores it, so making it work will take a fair amount of work. At one point in the distant past all the altitude, velocity, etc displays did use the correct macros to convert values appropriately but many values have been added since which don't.


Title: Re: AGC++ reentry help
Post by: chode on January 16, 2007, 07:20:01 PM
I'll take a look at making the metric/english flag work for the AGC display, and maybe then we can move on from there.

Swatch,

Here are links to a few of the best drawings and descriptions of the EMS scroll I've come across:

Graphics of scrolls:

Apollo Operations Handbook, Stabilization and Control System (12.8 MB) at
http://history.nasa.gov/afj/aohindex.htm
 pp. 58-64

Apollo 7 scroll, post-flight:

Apollo 7 Mission Report at 
http://www.hq.nasa.gov/alsj/alsj-mrs.html
p. 201

Shows the G scale on the left of the scroll:

Command/Service Module Systems Handbook at http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730060780_1973060780.pdf
p. 41

The main problem would seem to be that the numbers and letters on the scroll are going to be awfully small, and it will be difficult to make them readable.

Regards


Title: Re: AGC++ reentry help
Post by: Swatch on January 17, 2007, 02:01:04 AM
alright, I definately have a good handle on what was on the scroll now, as well as the dimensions....if I make one big realistic scroll the bitmap will be upwards of 6100 x 150 or so pixels  if memory serves me.  That's pretty big, but I'm going to look into what it would take to make it work with smaller ones.  I might make a big one first though, and then just chop from there.


I also think I understand the usage and what exactly its showing if there are any questions...


Title: Re: AGC++ reentry help
Post by: Tschachim on January 17, 2007, 06:14:50 AM
I'll take a look at making the metric/english flag work for the AGC display, and maybe then we can move on from there.

Yeah, looks like I'm a little bit too perfectionistic here. :wink: When we have that config file/scenario flag we can make it available in the Launchpad Configurator (http://nassp.sourceforge.net/wiki/Launchpad_Configuration_Options) and use metric as default, I think that would be a good solution.

... and something important:
 As you can see here (http://nassp.cvs.sourceforge.net/nassp/projectApolloSource/CSMcomputer.cpp?view=markup) in the revision history we've lost versions 1.68 to 1.72 of CSMcomputer.cpp, so the VAGC is broken in the latest CVS version.

So my appeal to all developers: Please make sure that you do a CVS update of the files before you commit changes. Do not copy files around nor copy and paste the complete content of a file. Before you commit changes it's useful to do a "CVS Diff" (context menu) to check the your changes against the latest CVS version to avoid unintentional changes. In order to do that in a comfortable way I suggest to install WinMerge (http://winmerge.org/), which has a TortoiseCVS integration.

I already prepared a fixed version I'm going to commit together with the SPS TVC stuff the next days, I just need to do a couple of tests, then everything should be working again. :)

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: chode on January 17, 2007, 11:56:26 AM
About the scroll, to keep the size manageable, I would suggest having two scrolls, one for LEO entry and one for trans-lunar and only include the part that the astronaut would actually see during the mission (only one of the charts). This should be the test header stuff and one re-entry chart, plus part of the header for the next chart, since from the Apollo 7 scroll it looks like the pen runs off the chart into the beginning of the next one.

Regards


Title: Re: AGC++ reentry help
Post by: dseagrav on January 17, 2007, 12:14:16 PM
On the other hand, the bitmap being long doesn't matter much when the bitmap is being scrolled, depending on how you scroll it. If you blt parts out, it doesn't matter how long it is, the unused parts will be swapped if they don't end up part of the current working page set. The unseen parts wouldn't (shouldn't) occupy video RAM. At the join point you would have to load both anyway.

Another idea, leaving it as one bitmap makes it possible to write a program or Photoshop filter or something that takes the scroll image and superimposes the trace from a post-landing scenario file, so we can read the scroll and see how well the entry went.


Title: Re: AGC++ reentry help
Post by: Swatch on January 17, 2007, 09:48:05 PM
Ok, we'll go with 1 or 2 large bitmaps to be messed with later...

Different Sections:

Leader: Used by the manufacturer, not important really and probably next to impossible to find.  ~34 in.
Ground Test Patterns: Not found as of yet, but would probably be useful.  Anyone who can find one of these, or even reference to what was on them, it'd be a great resource.  5 of these at ~3 in. a piece.
VHF/dV Ranging Instructions:  Alternated with In-Flight Test blocks on Lunar trips. More information on the VHF Ranging test is needed.
In-Flight Test:  Header before each reentry proceadure/chart.  About 3 in. a piece, various # and location it seems. 
Entry-Instructions:  2 inch section before each reentry chart containing instructions.  More information on what exactly this means is welcome.
Entry-Chart:  Many types, Non-Exit Orbital Entry Pattern (NOE),Non-Exit Lunar Entry Pattern (NLE), and 3500NM Lunar Return Exit Pattern (LRE).  4 Charts per scroll, but typically only 1 or two of the individual types.  18 in. a piece.

Now, what would you guys prefer?

Realistic:
|--Gnd Test (3-5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--LRE Pattern--|

Simple:
|--Gnd Test--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--NLE Pattern--|--LRE Pattern--|

Seperate (2 scrolls):
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--LRE Pattern--|     (Lunar Reentry)
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|   (Earth Reentry)

Historic (2 scrolls):
|--Gnd Test (25)--|--FltTst/VHF-dV Rng(4)--|--Entry Inst.--|--NLE Pattern--|--Entry Inst.--|--LRE Pattern--|--Entry Inst.--|--NLE Pattern--|--Entry Inst.--|--LRE Pattern--|    (Lunar Reentry - partially verified for Apollo 8)
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|    (Earth Reentry-verified for Apollo 7)

Oh and a full-sized Apollo 7 scroll at 120 inches in length would be about 6,144px in length and 144-150 px in height.


Title: Re: AGC++ reentry help
Post by: chode on January 19, 2007, 12:12:56 AM

Seperate (2 scrolls):
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--LRE Pattern--|     (Lunar Reentry)
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|   (Earth Reentry)


I would vote for this, except changed to:

Seperate (2 scrolls):
|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|     (Lunar Reentry)
|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|   (Earth Reentry)

The reasons being:

1) We don't know what the ground test patterns looked like, nor do we have any idea how they were used.

2) I have no idea what the purpose of the 3500 NM "exit" trace was, since no mission ever had a reentry range longer than 2000NM. Plus, if you look at one, the differences between it and the "no-exit" trace are very small.

Also, you only need part of the second entry trace, since the entire second chart would not be used in practice, it would be there only so the chart would continue to scroll if the EMS system were left running up to and beyond splashdown.

I like the idea of preserving a copy of the marked-up scroll in a file (.bmp?) so the user could look at it or print it out to see how they did.

Regards


Title: Re: AGC++ reentry help
Post by: Swatch on January 19, 2007, 12:52:49 AM
If I remember correctly, the reason for the second, third and forth charts were so if the astronauts scanned past the start of the first, they would just go the next chart.  The EMS scroll could only move forward, it couldn't back up.


Title: Re: AGC++ reentry help
Post by: chode on January 19, 2007, 01:09:47 AM
Yes, that is most likely the reason why there are so many charts. But, we can go back, and make it look like we went forward if we want to simulate that, since the scroll just repeats itself.

Regards


Title: Re: AGC++ reentry help
Post by: Coussini on January 19, 2007, 06:26:14 AM
Do you have a scenario include in the BETA files that i can use to test your stuf.

Thanks.

I want to test it ;)

It's a good job chode  :ThumbsUp432:


Title: Re: AGC++ reentry help
Post by: chode on January 19, 2007, 09:12:21 AM
On page 3 of this thread, about half way down, there are two scenarios attached.

Regards


Title: Re: AGC++ reentry help
Post by: dseagrav on January 19, 2007, 09:11:08 PM
I tweaked the SM RCS positions; They should be better.
Sorry it took so long, I had unexpected company staying over the last couple days, so I didn't get much time to work with.


Title: Re: AGC++ reentry help
Post by: chode on January 20, 2007, 02:16:53 PM
I think something got changed up in the directions of those jets, they don't work correctly now. I'll see if I can fix them.

Regards


Title: Re: AGC++ reentry help
Post by: Tschachim on January 20, 2007, 02:52:40 PM
I just checked dseagrav's new SM RCS thruster modification and it works fine here (in fact I didn't realize the difference).
Chode, what problems do you have?


Title: Re: AGC++ reentry help
Post by: Swatch on January 20, 2007, 04:17:26 PM
present for you all in the orbitersdk folder...


Title: Re: AGC++ reentry help
Post by: chode on January 20, 2007, 07:01:16 PM
It's the CM jets. The direction of one of the roll jets is not right, I'll try to fix it tonight.

Regards


Title: Re: AGC++ reentry help
Post by: chode on January 20, 2007, 11:08:17 PM
Somehow, the direction of one of the roll jets on the CM got changed, causing the problem I reported (sorry, I didn't specify that the problem was with the CM and not the SM). I've reset it to the correct direction. I also tweaked the position of the CM jets to coincide more with the mesh. I did not tamper with the SM RCS thrusters at all. I've committed the changes, and hopefully everything is working as it should now.

Regards


Title: Re: AGC++ reentry help
Post by: Swatch on January 21, 2007, 01:00:02 AM
for whomever is developing the EMS scroll that I uploaded to CVS, these are the important numbers....

along the bottom scale, its 3 pixels from left to right means a reduction of 100 feet per second in velocity.
along the up/down scale, it's roughly 13.5 pixels from top to bottom for an increase of 1G

I'm working on the Lunar one, but it will be mostly the same stuff and use the same scale.

If anyone is wondering, the test section and entry instructions are pretty much slightly cleaned up scans of actual scrolls, but the actual reentry graph is freshly drawn to make the scale match up with pixels, this means it's slightly longer than a real copy of the same height.  It has been properly scaled however and this shouldn't be an issue.


Title: Re: AGC++ reentry help
Post by: Coussini on January 21, 2007, 10:24:29 AM
On page 3 of this thread, about half way down, there are two scenarios attached.

Regards

Thanks  :ThumbsUp432:


Title: Re: AGC++ reentry help
Post by: dseagrav on January 21, 2007, 05:46:45 PM
As you can see here (http://nassp.cvs.sourceforge.net/nassp/projectApolloSource/CSMcomputer.cpp?view=markup) in the revision history we've lost versions 1.68 to 1.72 of CSMcomputer.cpp, so the VAGC is broken in the latest CVS version.
...
Quote
I already prepared a fixed version I'm going to commit together with the SPS TVC stuff the next days, I just need to do a couple of tests, then everything should be working again. :)

Am I going to screw you up if I put back the changes to CSMcomputer, or at least the vAGC time acceleration fix? I need it.


Title: Re: AGC++ reentry help
Post by: Tschachim on January 21, 2007, 05:55:16 PM
Yeah, this really need to be fixed. Put back the time acceleration fix, I think I can live with the CVS conflicts and sort them out on my site. :)

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: dseagrav on January 21, 2007, 07:18:42 PM
I committed it back. Hope it doesn't cause you too much trouble.


Title: Re: AGC++ reentry help
Post by: Tschachim on January 22, 2007, 11:36:06 AM
No problems here, I committed my stuff, too, so all CMC (and CVS) issues should be fixed now!

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: Tschachim on January 30, 2007, 02:45:50 PM
Small test flight report using the "Apollo 7 final reentry" scenario (available on page 3 of this thread), just to praise Chode's great work :): Altogether the entry was much smoother (presumably because of the fixed CM jets), the CM banked several times and seemed to follow the commanded bank angles very well.

The numbers actual (predicted):
Latitude: 29.99N (30.02N)
Longitude: 59.11W (59.00W)
max. G: slightly over 4 on the meter at the "2nd peak" (4.38)

Range to target was 11.5km, which looks fine for me (though it's higher than the 5km Chode posted). Despite the fact I'm no entry expert I want to thank you, Chode, for your great job, it looks like I arrived back home alive and "unburnt".  :) :ThumbsUp432:

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: legion on February 26, 2007, 11:20:46 AM
err.. can i still make a reentry with the entry checklist from the doc-folder?
a little problem is that i didnt find 'BASE-SYNCHRO_MFD' with its 'ENC>closest passage function' anywhere.
even on imfd i didnt find this function.
i would try chodes way too but cant do a cvs update right now....(my nassp seems to be antique already)
help with the base sync mfd is as always welcome.

legion


Title: Re: AGC++ reentry help
Post by: Tschachim on February 26, 2007, 11:25:58 AM
Jarmo's BaseSyncMFD? Look here and scroll down: http://koti.mbnet.fi/jarmonik/Orbiter.html

Cheers
Tschachim


Title: Re: AGC++ reentry help
Post by: legion on February 26, 2007, 12:59:40 PM
hi tschachim,
and thanx again. the whole orbiter universe seems so big at present, and i searched so much sites....
but now im really looking foreward to do a proper reentry especially with your(?) checklist and the beautifull sm breakup. the pics looked fantastic.... :ThumbsUp432: >hope this is feature is availeble in vagc apollo7 mission. we'll see   :wink:

legion