Meadville Space Center
Welcome, Guest. Please login or register.
October 24, 2020, 09:40:25 PM

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
  Show Posts
Pages: 1 ... 13 14 [15]
211  Project Apollo - NASSP / Planning / FDAI marker error on: January 25, 2006, 09:52:49 AM
Quote from: Tschachim

 This isn't historically correct, but fixing the NASSP AGC would be a lot of work and the Virtual AGC is already working...


Yes, it makes no sense to put much work into the NASSP AGC when the VAGC does already work (and is getting better and better all the time).
This is why I suggest concentrating on the elements that are missing.

Quote from: Tschachim

In earth orbit or later you can't realign the IMU at the moment (in Virtual AGC mode V41/42 is working, but that's all) and there's no ORDEAL, so the FDAIs will show the attitude with respect to the prelaunch alignment the whole mission (except you cage the IMU), so here the realism ends at the moment.


ORDEAL does not change the IMU reference in any way, it simply drives the pitch of the FDAI . ORDEAL was used in most flights soon after orbit was reached,  inertial referencer was the launch pad REFSMAT.

Quote from: Tschachim

For the LM I suggest to use the FDAI and IMU classes from the CSM, AFAIR thanks to movieman the IMU is already there, and similar to the "quick hack" at launch we could set the IMU to the correct "lunar landing alignment" at beginning of the powered descent until we have more of the GNC stuff or the LM Virtual AGC working?


Sounds like a plan. The VAGC IMU and FDAI seems excellent. It would work well incorporated into the CSM. All that would really be needed immediatly after that would be BMAGS and some kind of GDC functionallity . This would provide vehicle rates for the FDAI.
The error needles were driven from either the PGNCS error or the SCS error so deciding which way to get it working first will be the thing.
212  Project Apollo - NASSP / Planning / FDAI marker error on: January 25, 2006, 02:48:55 AM
Hi!

My suggestions are mainly in order to prevent duplicated work and systems from being implemented in a way which won't mesh in the future with things that will be coming along strong like VAGC.

To get a proper FDAI going you need to have some mechanism in place to first set some kind of inertial reference. It does not really matter if this is the ASCP to give a reference to the GCD or if you set gimbal angles and go through Verb 41 and 42.

Then the FDAI can display this information.

I will prepare some sort of chart to try and illustrate what is needed.
213  Project Apollo - NASSP / Planning / FDAI marker error on: January 24, 2006, 07:45:49 AM
Quote from: LazyD
Hi again, kneecaps,

There is no other way to initialize orientation except for Orbiter API calls.  After an initial state vector, we can predict future pos/vel and so forth, but the universe we live in is Orbiter.  

.


Hi,
  Try to remember for a moment just how the PGNCS knows its orientation. The IMU gimbal angles. The IMU gimbal angles do not have to relate to anything in the real world. Orientation of the inertial reference should not be taken from calls to the orbiter API. The inertial reference of the spacevehicle (LM or CSM) must be CHOSEN and the appropriate gimbal angles torqued into the IMU. The same can be said for the SCS GDC unit, it has to be told the space crafts angles.

Quote from: LazyD

As far as trying to be compatible with future VAGC interfaces, I will rely on the the gods, movieman and Tschachim, to give me direction on how to proceed.  
D.


This is why for compatbillity with VAGC interfaces I would recommend working on the FDAI and some kind of simulated GDC and BMAG code (and other SCS elements), you would also need to simulate the CDU if you intend to make your FDAI work with both the SCS and the PGNCS (IMU).

 This would give you a fully working control system which could interface with the PGNCS elements at a later date. If the VAGC development proves to proceed too slowly you can then write your own interim IMU and AGC code to talk to the FDAI.

If you want I could put together some kind of high level logical diagram of whats already impemented and what is needed to have a proper spacecraft GNC in place.
214  Project Apollo - NASSP / Programming / Electrial system on: January 23, 2006, 07:36:38 PM
Quote from: Moonwalker
By the way, I noted that the 3 green lines and the 3 "verb", "prog" and "noun" lights of the DSKY are illuminated when entering the CSM. But the circuit breakers are pulled out before reviewing the checklists. So the DSKY should be off completely and look like shown on the background bitmap of the CSM main panel Wink


CBs for the DSKY lighting are on panel 226 (which we don't yet have I think?). Dimmers for MDC dsky are  Interior Flood - Integral, Numeric and the LEB dsky dimmers are on panel panel 100 (which we don't have?).
215  Project Apollo - NASSP / Planning / FDAI marker error on: January 23, 2006, 06:34:36 PM
Quote from: LazyD


That makes sense, and agrees with what I've read in A15Delco.  And I understand the IMU needed to be aligned with stars.



Roger that, i would add some kind of interim measure if possible so that the LM alignment for lunar landing does just not 'happen'. Prehaps a key shortcut or some ficticious computer verb? Just until the rest of the GNC stuff is in place?


Quote from: LazyD

It is easy for me to get unit X, Y and Z vectors for the IMU, and also to transform them to the local vessel axes.


Do these come from calls into the orbiter api, or from some NASSP IMU code?

I'm thinking that it would probably be best to code the SCS system first and PGNCS later . Thinking about it there really isn't any other way to do it if you want to aim for 100% future integration with the AGC project. Otherwise the same ground will be covered. Implementing a full SCS system would also need to be done anyway.
216  Project Apollo - NASSP / Planning / FDAI marker error on: January 22, 2006, 01:12:26 PM
Quote from: LazyD
Hi,

I started writing an IMU orientation routine so we could make the FDAI indicate properly but never got all the orientations finished.  For the lunar operations up to landing, the IMU is aligned so:



Remember this needs to be set, and not magically happen for realism. The astronauts would have followed procedures to get the IMU setup in this way.

Your statements regarding IMU alignment and spacecraft axis are correct for the LM

Quote from: LazyD

What I don't know is if the FDAI ball is directly slaved to IMU orientation or whether it gets modified by the current REFSSMAT.  In any case, R-695 makes it clear that at the instant of landing, the spacecraft axes are parallel to the IMU platform axes.


THE FDAIs display total attitude directly from the IMU by way of the CDU or the Euler angles from the GDC. REFSSMAT only exists logically in the AGC programming as a concept for reference.

Hope this helps
217  Project Apollo - NASSP / Planning / Re: Defining FDAI on: January 22, 2006, 12:01:18 PM
Hi all! First post here as i'm enjoying beta testing! Just want to clear up a few issues on this FDAI issues.

Its so important to have the correct understanding of this and how the FDAI fits in the GN&C system.

I'm going to clear up some small points that Gymbal Lock made.

Quote from: Gymbal Lock
Hey Tschachim,
Interpreting from NASA lingo to plain English, its an instrument that displays the ATTITUDE RELATIVE TO THE FLIGHT TRAJECTORY DIRECTION!


Okay, to be specific here, the FDAI displays the spacecrafts ATTITUDE relative some fixed reference and NOT the spacecrafts trajectory.


Quote from: Gymbal Lock

 Thus pitch and yaw are relative to the trajectory direction and roll is relative to orbital plane.


No, pitch yaw and roll are all relative to some fixed reference, and not trajectory direction or orbital plane. In different situations this inertial reference may be aligned with the orbital plane but this was not always the case.

Quote from: Gymbal Lock

  Apollo used [near] circular orbits arround the earth and the Moon.  As you all know, in circular orbit the trajectory is parallel to the surface of the body being orbitted.  This allowed the Apollo crew to use the 8-ball as the artificial horizon.


Whats your source for this? The Apollo GNC for orientation is a Stellar Inertial system. However when it was desired to match the orbital rate the ORDEAL system was used. ORDEAL actually drove the FDAI at the orbital rate to maintain an 'ORB RATE' attitude. Much like Orbiters prograde function, however ORDEAL did not have to keep the X axis aligned with with local vertical.


Quote from: Gymbal Lock

From undocking and DOI to landing, the LM's FDAI does NOT change its functionality to artificial horizon :!:  


Correct in the sense of a normal artifical horizon. However since the inertial reference used for orientation could be anything required the IMU was orientated to provide a LVLH (local vertical, local horizontal) reference systems for the crew to use. However the pitch 0 MAY not have corresponded exactly with a pitch level LM flight condition. (it was supposed to be close however)

Quote from: Gymbal Lock

Because the navigation technology was not as advanced as it is now, it could not pin-point an exact landing on the moon down to a foot.  Therefore, the final 50' were achieved manually looking out the window.


The LM descent was designed and tested to take the spacecraft from undocking to landing with minimal human input. Its not that the LM couldn't land automatically, its just that no commander ever chose to let it do so.

Quote from: Gymbal Lock

 Since the Global Tracking System could not determine the spacecraft's attitude, in case of a GL the MCC-H could not help the spacecraft to orient itself.  The only option that the crew would have left is star tracking through COAS, which is time consuming and would require the crew numerous calculations in order to calculate their attitude relative to their trajectory (which is necessary to know in order to determine which thrusters to fire for a maneuver).  



Yes, however in the case of loss of PGNCS intertial reference the OSS (sextant) would have been used to make star sightings to re-establish the inertial reference.


Quote from: Gymbal Lock

In a dynamic turn of events (like in Apollo 13) losing the 8-ball would be disasterous because of the negative visibility of the star field.  I agree with those who say that flying Saturn V "Apollo style" is the best, which is why I'd like to see the 8-ball simulated :lol:


Yes, the FDAI is very important, but the FDAI is nothing without the rest of the SCS system to go with it and/or inputs from PGNCS. The FDAI is simply a display for human consumption.


Quote from: Gymbal Lock

Another feature that the FDAI posesses is the three needles pointing to the center, which indicated pitch rate (on the right of the 8-ball), yaw rate (on the bottom), and roll rate (on the top) in fps.


The FDAI needles are attitude ERROR needles not rate needles. The three black scales around the outside of the display are the rate. The error needles are able to display total attitude error and provide a fly to indication to null those attitude errors, very useful.

The key to getting a usable spacecraft pointing systems is to develop the most central functions first. elements of the PGNCS ans SCS need to be simulated first. IMU and/or GDC being the most important, along with the FDAI which is utilised by both systems.

Phew!
Pages: 1 ... 13 14 [15]
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!