Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
 
« previous next »
Pages: 1 ... 43 44 [45] 46 47 Print
Author Topic: LM Landing questions/report  (Read 47218 times)
Coussini
Project Team Member
Hero Member
****
Posts: 686


View Profile
« Reply #660 on: November 12, 2005, 02:52:57 PM »

CURIOUS THING... i found this in MIT, and it's a apollo landing sequence storyboard... check that... it's interresting to read  Cool. I found this in Google... and the link is break... i force the contain using HTML.... and i'm curious to see the original frame. The link is

http://web.mit.edu/aeroastro/www/labs/halab/media/Apollo-Landing1.ppt

Apollo Landing Sequence Storyboard

This is a storyboard of the Apollo Lunar landings.  

DOI
PDI
Undocking
Separation
LM Descent Orbit
(60 N.M x 50,000 ft)

CSM Orbit
(62 x 58 N.M)

APOLLO

Post-DOI

Prior-PDI

Landing

Approach

Braking

P64
 


PDI
 
P63

P65

Optional Modes:

P66

P67

Landing Site

High Gate

Low Gate

Landing

260 N.M.
50,000 ft
~3000 ft

Post-DOI

Check residuals (X,Y,Z)
All 0 if DOI burn was perfect
Null X & Z with hand controller
Purpose: avoid landing long/short of target
Compare PGNS and AGS Residuals
PGNS data comes from inertial platform
AGS data comes from body-mounted accelerometers
Re-initialize AGS to match PGNS for descent
Program P00 puts computer in “idle” state so that no other processing might change values sent up by Houston
Use rendezvous radar to track CSM to see that it is working properly and estimate altitude at PDI
Use VHF ranging (dopler measurement) to determine radial velocity relative to CSM

Prior-PDI

Determine LM current altitude (~15 mins till PDI)
Scribe marks on MC’s window used to determine how quickly objects on ground move along scale altitude
Crudely, LM alt = (360*rmoon)/(PLM*ratesurface feature move along scale)
rmoon= 5,700,000 ft, PLM = 7200 sec
Crew has chart in cabin that compares tracking rates with expected values @ various positions along orbit
Difference between observation & expected estimate of altitude of perilune & time that will reach it

2nd method of computing altitude = relative motion from CSM

Superimpose 2 methods on graph to get idea of altitude and time history
Verb 47 – command to initialize AGS using PGNS data
Send state vector from one computer to another
Visual altitude check
v=rw
r = altitude that want to know, w = omega, avg rate determined by watching points on the ground, v = velocity (already known)
Alternate altitude check to ensure close to intended starting altitude – important to make sure that landing guidance converges

Change rate scale from 5 deg/sec to 25 deg/sec
Verb 77 – setting attitude control modes for DAP
Pitching & Yawing to gain radio contact
Set up camera
“Master Arm” switch – enable descent engine to fire & explosive bolts in case of descent abort
Check health of circuits that will detonate explosive charges for abort (2 lights)
Check DSKY time against stopwatch time & AGS
Perform manual backup if auto “ullage” to force propellant towards valves does not work
Power up landing radar
Yaw for high-gain aim
Check oxidizer levels
Cycle breaker to reset Propellant Quantity Measurement Device (PQMD) for good readings
Activate RCS system
Activate Digital Event Time (DET)
Press “PRO” on DSKY to accept desired attitude for PDI burn and allow computer to make adjustments to attitude

PDI (Powered Descent Initiation)

Landmark Tracking to confirm trajectory prior & right after ignition
Yaw s/c to windows-up orientation (180 deg yaw)
So that when s/c pitches toward upright orientation for landing, will be looking out window at Landing Site (LS)
So that radar could see surface
Radar wasn’t reliable > ~ 30,000 ft
Radar info used to help guidance equation converge
10% thrust until guidance made distance correction to proper geometric position and then went full thrust
Done with hand controller

Timing when pass landmarks
Cross-range position difficult to tell b/c of skewed yaw attitude needed to maintain comm
Yaw vehicle to face-up, feet-forward position (~ 5 mins till P64 Pitchover)
Receive radar data from lunar surface
A11, radar showed 2900’ lower than PGNS altitude
Pitch @ ~77deg
90 deg would be backs parallel to lunar surface & feet forward, 0 deg pitch @ landing, 56 deg @ just prior to P64

Verb16Noun68 – displays range to LS & time remaining in braking phase

Monitor fuel
LMP compares PGNS & AGS
MC checking PGNS values with predicted values
Chart of delta-H as a function of time into burn compared with computer readout of radar data gives confidence in radar data
Update the AGS based on radar data
Use star to check accuracy of LPD

Enter Noun 69 for landing site position update

Compare velocities and attitude with chart showing desired values
Check voltage on descent batteries
Descent Engine Command Overide – allowed astronaut to overide computer’s commanded thrust level.  
Altitude and velocity lights go out when computer gets acceptable data from landing radar
Computer uses 5 segment model of mountainous terrain. Delta-H-dot is the difference between the altitude from the landing radar and altitude according to this model (model of approach path terrain 1st included in A-14)

Monitor altitude, h-dot, fuel
Check manual control to ensure that it’s working properly

Call up Noun 68 to check time of P64 occurrence
Enter Verb 57 on DSKY to tell computer to begin accepting radar data

Tapemeter display showed radar data. Pair of tapes with #s on them which moved up and down behind a needle

Approach (P64 Pitchover)

Relay info to determine where computer thinks LM will land
LM pilot reads #s to MC to look @ scribed window
1st look @ LS!
Retarget LM using hand controller & LPD
Forward move target downrange, etc
1 “blip” = 1 deg movement

Use of LPD is difficult to begin with, but vehicle is in constant slow pitch ever since P64, so LPD # are up to 2 sec old

Options for redesignation = L,R,down(short), or go over
Call up LPD display by pressing “PRO” on DSKY
MC immediately looks out window
Monitor fuel
Press PRPLNT_QTY MON switch to see fuel & oxidizer % remaining
LM pitches into more upright position
MC looks through scribe marks on window and uses info from PGNS that LMP is giving him to determine where computer thinks the LM will land
MC uses handcontroller to tell computer to redesignate landing site (NOT manual control)

LMP consulting descent profile chart – shows desired descent rate as a function of altitude

Landing (P66 Manual Control)

Finish pitching LM over to 0 deg pitch
If take over manual control, vertical velocity is maintained (i.e. no control)

“BINGO” fuel call – “land in 20 sec or abort”
< 100 ft = dust disturbances obscured visibility
Difficult to determine downrange velocities (translational velocities)

Engine shut off @ < 10 ft = acceptable to landing gear

Probes from foot pads touch surface @ 67’
 
Kill rate of descent to hover and look around
Monitor fuel, speed, altitude
Use “8-ball” (inertial attitude gyro) to determine attitude and if level or not because of dust
MC has controls and is looking out window.  In manual control model, MC actually controls pitch, roll, and yaw
Use Rate of Descent (ROD) switch to go in to P66 mode = primary means of controlling vertical velocity
Monitoring rate of descent now (not angles) because no more LPD mode
“cross-pointers” check – horizontal & lateral velocities on attitude gyro  (2 needles like an instrument landing system give rate laterally, forward, & aft in fps – want to be 0 when land)

Mode Descriptions

P63 = “Braking Phase Guidance”
Ignition algorithms (when to ignite DPS for PDI)
Basic guidance logic to steer to desired conditions for beginning approach phase

P64 = “Approach Phase Guidance”
Same basic guidance logic, but new set of targets
Provides window point logic for LPD Operation (LP will be maintained along LPD grid)

P65 = “Velocity Nulling Guidance”
Nulls all components of velocity to pre-selected values
Used for automatic vertical descent if desired
No position control

P66 = “Rate of Descent”
Crew controls s/c attitude & computer commands DPS throttle to maintain desired altitude rate (altitude rate can be adjusted with manual inputs from crew)

Normally entered late in P64 operation prior to P65 switching for manual control

P67 = “Manual Guidance”
Maintains navigation and display operations for complete manual control of throttle and attitude

Not used unless P66 is inoperative

Landing Modes

Landing Phases

Manual Control

Low Gate

Landing  

Crew Visibility

High Gate

Approach

Min Prop Usage

PDI

Braking

DESIGN CRITERIA

INITIAL EVENT

PHASE

Landing Figures

POST-LANDING ACTIVITIES

Post-Landing


413 Command – contains variables that indicate LM has landed

So any abort will be from the surface

Therefore AGS saves attitude data from gyros

Prepare for immediate lift-off

If footpad starts sinking and lose stability or propellant tank pressure problem, etc.

LPD

Acronyms

AGS: Abort Guidance System
PGNA: Primary Guidance & Navigation System
DAP: Digital Autopilot
DPS: Descent Propulsion System
RCS: Reaction Control System
LR: Landing Radar
LPD: Landing Point Designator
DSKY: Display & Keyboard Assembly
NOUN = Data
VERB = Actions
X-axis: Thrust axis (+ = up – away front engine toward rendezvous hatch)
Y-axis: L to R (+ = R side of s/c)
Z-axis: fore & aft (+ = out windows)
LS: landing site
LP: Landing point
 

That it's .... funny  :!:
Logged

Have a nice day
DarthVader
Project Admin
Sr. Member
*****
Posts: 315



View Profile WWW
« Reply #661 on: November 12, 2005, 02:54:25 PM »

I'm getting "file not found" errors on that PPT file
Logged

Coussini
Project Team Member
Hero Member
****
Posts: 686


View Profile
« Reply #662 on: November 12, 2005, 02:56:28 PM »

Quote from: DarthVader
I'm getting "file not found" errors on that PPT file


Yes... i know that.... i said that in my memo... but i force the contain using google HTML method.
Logged

Have a nice day
DarthVader
Project Admin
Sr. Member
*****
Posts: 315



View Profile WWW
« Reply #663 on: November 12, 2005, 02:59:56 PM »

oops Embarassed
Logged

LazyD
Project Admin
Sr. Member
*****
Posts: 412


View Profile Email
« Reply #664 on: November 22, 2005, 07:01:47 PM »

Hello,

I've downloaded and rebuilt all the new stuff as of today.  I am really pleased about the new LM mesh sitting properly on the lunar surface - whoever did that, thanks!!

I want to fix a few things and update the other Historical Apollo scenarios, but need a bit of advice:

Do we want to include scenarios for missions other than Apollo 11, or not?  Although it probably makes sense not to have all the NEP stuff in the release, the other landing sites are pretty nice.

I read in another thread that movieman renamed the LM/CSM - how do I deal with that in the code and scenarios?  I'm happy to work on it, just don't know what to do.

I have another project I'm working on, but want to make sure the next Project Apollo release (at least my stuff) works solidly, and I'll have some time to work on it in the near future.

D.
Logged
movieman
Moderator
Hero Member
****
Posts: 1697



View Profile
« Reply #665 on: November 22, 2005, 07:21:51 PM »

Quote
I read in another thread that movieman renamed the LM/CSM - how do I deal with that in the code and scenarios? I'm happy to work on it, just don't know what to do.


The AGC knows the other vessel name: you just ensure it's set up in the scenario, then your code should all work. It's ONAME in the AGC, and LEMN in the Saturn V.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3307


nassp.sf.net


View Profile WWW
« Reply #666 on: November 23, 2005, 04:52:44 AM »

Quote from: LazyD
Do we want to include scenarios for missions other than Apollo 11, or not?  Although it probably makes sense not to have all the NEP stuff in the release, the other landing sites are pretty nice.

Yes, we want them (or at least I would like to have them Wink, but I think I'm not alone). Just add them to the "Historical Apollo" directory or the proper subdirectory, I think we'll move all historical scenarios to that directory structure soon. The surface bases also exist in "standard" Project Apollo, only the surface meshes are in the NEP, so the scenarios should also work with "standard" Project Apollo.

Cheers
Tschachim
Logged

movieman
Moderator
Hero Member
****
Posts: 1697



View Profile
« Reply #667 on: November 23, 2005, 06:06:57 AM »

I guess we should move the main config files before creating a lot of scenarios, to save having to re-edit them again later. I was wondering last night, for example, which solar system we should be running in: currently the scenarios still use Sol_NASSP5, with the old KSC.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3307


nassp.sf.net


View Profile WWW
« Reply #668 on: November 23, 2005, 06:29:47 AM »

Yes, only the first 3 scenarios in Project Apollo - NASSP\Historical Apollo\Apollo 11 use the new ProjectApollo\Sol just because the new KSC is not ready yet and I didn't want to break the other scenarios. But if the new KSC is now "good enough" for you Wink feel free to switch now (the ML and the LUT are not finished).

Ahh, and the Virtual AGC scenarios use their own ProjectApollo\Sol_VirtualAGC because of the different size of "their" earth.

Cheers
Tschachim
Logged

movieman
Moderator
Hero Member
****
Posts: 1697



View Profile
« Reply #669 on: November 23, 2005, 06:58:02 AM »

Even if the new KSC isn't finished, I think it makes sense to have a working set of scenarios rather than have to re-edit all of them later. It's easier to update the KSC config file than update fifty or more scenario files (and any saved scenarios).

I'll move the Saturn and LEM config files tonight and update the current scenarios.

One thing I was wondering was whether to 'CVS remove' the old files? We should really aim to have no files outside the ProjectApollo directories in the release version, but I'm not sure whether we went to delete the moved files in CVS... I started doing that last night then thought that I should check here first Happy. If we don't delete them then we'll get bugs when people use old paths and the code works because an old copy of the file happens to still be there.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3307


nassp.sf.net


View Profile WWW
« Reply #670 on: November 23, 2005, 07:07:34 AM »

OK, then I'll use the new ProjectApollo\Sol for new scenarios, too.
Logged

Coussini
Project Team Member
Hero Member
****
Posts: 686


View Profile
« Reply #671 on: November 23, 2005, 08:43:03 AM »

Hi LazyD,

Are you already did a launch from the eath, a TLI and an LOI using a DSKY....

I use the Apollo TLI - Free-return Tutorial 17.10.2005 from Jarmo Nikkanen (IMFD)

Are you using this....

Thanks to reply... i'm just curious to know you procedure Wink
Logged

Have a nice day
LazyD
Project Admin
Sr. Member
*****
Posts: 412


View Profile Email
« Reply #672 on: November 24, 2005, 08:26:24 AM »

Hi Coussini,

I haven't flown an entire Apollo mission since starting on the AGC code, but I used to use TransX with good results.  I tried a much older version of IMFD, but it used to require an in-plane transfer.  I haven't tried it recently.

D.
Logged
Coussini
Project Team Member
Hero Member
****
Posts: 686


View Profile
« Reply #673 on: November 24, 2005, 12:16:30 PM »

I did.... and it's very nice....

Thanks very much to reply dear Master  Cool
Logged

Have a nice day
Toadtal
Full Member
***
Posts: 67


View Profile
« Reply #674 on: January 12, 2006, 01:03:16 PM »

Today i was doing PDI using the DSKY and i realized something. I realized that every single approach is straight down the line and puts you down in exactly the same spot. And I was wondering if it would be possible to make the approach a little more realistic by making less acurate.
Logged
Pages: 1 ... 43 44 [45] 46 47 Print 
« previous next »
Jump to:  




Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC
Enterprise design by Bloc