Meadville Space Center
Welcome, Guest. Please login or register.
August 03, 2020, 07:48:07 AM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
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)
| | | |-+  LM status...
« previous next »
Pages: 1 [2] 3 4 ... 67 Print
Author Topic: LM status...  (Read 157077 times)
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #15 on: April 14, 2006, 10:39:36 AM »

It's OK. I just don't want to promise I can fix it because I haven't even looked at it, so I have no idea if it's too confusing for me or whatever. Except for the CM SCS I've never dealt with any sort of working autopilot before. None of mine ever worked properly.
Logged
LazyD
Project Admin
Sr. Member
*****
Posts: 412


View Profile Email
« Reply #16 on: April 14, 2006, 06:19:45 PM »

Hi dseagrav,

Currently, the AGC++ for anything I wrote for the Apollo CSM or LM controls attitude independently of anything dependent on the VAGC.  It basicly feels up the RCS torques and vessel PMI, and uses Orbiter API to control RCS thrust.  If the vessel RCS changes, it should be able to deal with it.

Currently, it's difficult for me to test the old AGC++ stuff I wrote last year.  Due to scenario format changes and who knows what else, none of my stuff seems to work any more.  I have gladly watched the progress of the CSM VAGC and figured the LM would soon be running Luminary, which is very cool, IMHO.  I'm happy to cooperate, but I think this project has moved beyond what I am able to do.

If you can bring the LM to life using the VAGC, I think that's fantastic!

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



View Profile
« Reply #17 on: April 14, 2006, 07:03:38 PM »

Quote
Currently, it's difficult for me to test the old AGC++ stuff I wrote last year. Due to scenario format changes and who knows what else, none of my stuff seems to work any more.


Hopefully these changes will pretty much fix the scenario format and allow us to get the LEM up and running with the control panel again before long.
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #18 on: April 17, 2006, 12:59:34 AM »

LazyD, as nifty as running Luminary is, it still locks up on scenario loads semi-randomly and doesn't work above 10x time acceleration. We still need the AGC++ for awhile until those problems are solved. There's also a philosophical divide between the AGC++ and the AGC - The AGC++ is cheat-able and easier to manipulate for newbies, it uses "proper metric measurements instead of the ugly American measurements", and so on; It will take us quite awhile to get the AGC working reliably enough for the Average Joe, and even then it can never be made user-friendly; Only the AGC++ can do that.

Once I get the systems mess worked out the LM will be back to business as usual, and you can hack away. It's just being a pain in the butt in the meantime.

Speaking of, here's the latest scoop - I got the IMU alive and talking to the LGC, and I can start the LGC DAP and get it to fire jets. The RHC works and fires jets in the proper axes.  HOWEVER, someone installed the IMU sideways, or possibly backwards and sideways, so the computer gets very confused when it tries to navigate. I have to sort that out and get one of the FDAI alive, and then I should be able to call this working enough to let some other people share the fun.

Additional quirks that I haven't investigated yet include Luminary being very confused about something; It randomly falls over and dies, and requires a restart every so often. I think being "on" during the launch may have confused it. Most notably, even in P00, using V48 will mess up something such that V49 gets a OPR ERR lamp afterwards and requires a fresh-start to continue. Hopefully this is related to the IMU being wrong and will go away.

I don't plan to try fixing Luminary except as required to get the IMU, FDAI and RCS hardover working, so as to keep people who don't want to use vAGC from waiting on vAGC work.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #19 on: April 17, 2006, 06:25:59 AM »

Are you loading a sensible state vector?

If you go to the Virtual AGC site, other people seem to have Luminary running, so clearly it's possible to get it to work. We must have either screwed something up when wiring it into Orbiter or not loaded enough data to make it happy.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #20 on: April 17, 2006, 01:11:54 PM »

Quote from: dseagrav
HOWEVER, someone installed the IMU sideways, or possibly backwards and sideways, so the computer gets very confused when it tries to navigate. I have to sort that out.

The IMU assumes the CSM Orbiter and Apollo coordinates systems when calculating attitudes and probably this is wrong for the LM, so it looks like you should make the IMU configurable for both CSM and LM coordinates.

Cheers
Tschachim
Logged

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


View Profile Email
« Reply #21 on: April 20, 2006, 05:03:44 PM »

hi dseagrav, Movieman or everybody else
I've found this while surfing:
http://klabs.org/mapld04/papers/p/p202_portillo_p.pdf
Don't know if there is something useable for you
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #22 on: April 20, 2006, 05:25:44 PM »

I found that earlier last week ^_^
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #23 on: April 23, 2006, 11:36:19 PM »

Quite a while ago, Moonwalker suggested I look into getting the vertical acceleration/velocity and, namely, the X-Pointer instruments working in the LEM...I did some more looking at it and I was having trouble determineing the best way it could be implemented in Orbiter.   (like Optics...I have ideas, but I'm working out the kinks)  I was wondering what the IMU was capable of...
What all values can I get out of it? (velocities? positions? accelerations? relative to what axis? etc...)
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)
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #24 on: April 24, 2006, 03:59:26 PM »

I figured everything out....but I'm still interested in what the IMU is capable of for curiousity sake.

I got the X-Ptrs working on the Main Panel, and they've been commited....I hope that didn't mess with anything you're doing dseagrav.  Now I'm going to get to work on the Range Altitude, the T/W, and the Range Rate/Alt Rate meters
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)
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #25 on: April 24, 2006, 04:19:10 PM »

IMU provides attitude and velocity-change in three axes, and that's it. I don't think anything is connected to it other than the LGC and FDAI. The velocity data is definetely only available to the LGC because of how it works - via an integrating accelerometer the computer periodically resets. The AGS uses a different system entirely.

Oh, and if you want to do the voltmeters and such on the right panel, that would be grand.
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #26 on: April 25, 2006, 03:19:55 AM »

I committed what I have - The IMU is alive and works, but the computer is still unhappy about something. Most likely it has a bizarre state vector. We need to come up with a way to do an alignment for the LM, or otherwise fake it. For the crazy types, The RHC works, but the computer generates way too high rate commands and ends up bell-ringing out of control (or just plain tumbling). I didn't bother wiring the translation controller until the LGC situation is sorted out and it can orient itself.

Someone else can look at the LGC while I finish out the descent ECS. It generates high rates for any maneuver and ends up tumbling pretty quickly.

Also, the IMU doesn't save state right now. I'll fix this unless someone beats me to it.
Logged
shotto
Jr. Member
**
Posts: 3


View Profile
« Reply #27 on: May 05, 2006, 03:39:59 AM »

First I like to introduce myself.
Last year I did some hacking  Wink  to create that TCL/TK based LM Simulator distributed with Ron Burkey's yaagc package http://www.ibiblio.org/apollo/index.html

Right now I'm stuck with the development because the DAP does not work correctly, even after providing the whole set of Apollo 13 launch pad values for the Luminary code base.
The DAP behavior is more or less an oscillation with increasing amplitude around the target attitude values. Because of your working CSM DAP, I would assume that yaagc is fine but probably an initialization value is missing.
As a pre condition IMU is aligned, the V48 initialization has been performed and even the V49 crew defined maneuver routine works with the above mentioned behavior.

It would be great if you can give me some hints why the DAP does not lock on the target attitude values even by simulating the correct moment of inertia.

Thanks in advance.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #28 on: May 05, 2006, 05:32:00 AM »

Hi Stephan,

nice to see you here at Meadville!  Happy
I hope dseagrav can help you, he already did a lot of great stuff in the CSM.

Cheers
Tschachim
Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #29 on: May 05, 2006, 06:24:59 AM »

Quote
For the crazy types, The RHC works, but the computer generates way too high rate commands and ends up bell-ringing out of control (or just plain tumbling).


Are you sure the LEM RCS has the correct thrust? The CSM RCS was way overpowered before, so the LEM may be too.
Logged
Pages: 1 [2] 3 4 ... 67 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!