Meadville Space Center
Welcome, Guest. Please login or register.
June 20, 2013, 05:25:58 AM

Login with username, password and session length
Search:     Advanced search
20011 Posts in 1930 Topics by 2250 Members
Latest Member: mikegk
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  New Forum Member, developing a UMMU Apollo
« previous next »
Pages: [1] Print
Author Topic: New Forum Member, developing a UMMU Apollo  (Read 1439 times)
Hlynkacg
Full Member
***
Posts: 18


View Profile Email
« on: September 07, 2012, 04:01:17 PM »

Greetings all!

My name's Greg and I'm an aspiring rocket scientist (AKA engineering student)

I've wiled away more hours than I care to count messing around in orbiter with both NASSP and AMSO, but have always been a little frustrated by their lack of flexibility and compatability with other addons. Lets face it, you can't just go into the scenario editor, spawn a LEM at Brighton Beach, and take it for a spin. 

I was also annoyed by the scarcity of realistic, airless-body, landers with UMMU support, as such I decided to build my own.

For the last 4 months or so I've been working on "Spider" an Apollo derived Lunar Lander with UMMU support. My intent is to try and balance a historically accurate (actual Apollo) performance envelope with accessibility and ease of play.

I contacted Tschachim on O-F and created my account here in the hopes of exchanging information and other resources. My primary design sources have been the LM Familiarization Manual (LM-10 - 14), the Apollo Extension Systems LEM final report, and my general geekery for scale models.

As it stands Spider is fully flyable in Orbiter but I'm having a lot of trouble intigrating the autopilots and various other subsystems such as thermal control and life support.

I was hoping I could swap meshes and other resources for assistance (or atleast pointers) on the coding end.
 
anyway this is what I've got so far...



Lunar Excursion Module in orbit. Ascent and Descent stage meshes are my own.



Lunar Module Interior. It may be a work in progress (till working on the textures) but the VC is fully interactive. I've done my best to match all panels to their historical counterparts though obviously there have been some concessions made. The biggest change was replaceing of the Commander's ADI and X-Pointer with an Orbiter standard MFD. The intent is for the vessel to be completely controllable from within the VC with all buttons, switchs, valves etc.. in their appropriate places.

(Orbiter-Forum developement thread)   


Respectfully,
Greg Hlynka
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #1 on: September 11, 2012, 03:14:16 PM »

Hi Greg,

welcome to the forum!  Happy

Quote
I was hoping I could swap meshes and other resources for assistance (or atleast pointers) on the coding end.

Sounds great! Being the resident CSM guy I don't know the LM in detail, but I hope one of the LM guys will pick you up. Feel free to ask concrete questions so people know what you need.
Your LM VC looks really stunning. I don't know if your add-on is open source / GPL, but if yes, you can use our 2D panel bitmaps as a whole or in parts as textures, you'll find then in CVS (or the CVS snapshot download).

Cheers
Tschachim
Logged

Hlynkacg
Full Member
***
Posts: 18


View Profile Email
« Reply #2 on: September 12, 2012, 11:43:25 PM »

Quote
Sounds great! Being the resident CSM guy I don't know the LM in detail, but I hope one of the LM guys will pick you up. Feel free to ask concrete questions so people know what you need.
Your LM VC looks really stunning. I don't know if your add-on is open source / GPL, but if yes, you can use our 2D panel bitmaps as a whole or in parts as textures, you'll find then in CVS (or the CVS snapshot download).

Is there anyone in particualar that you'd reccomend getting in touch with?

I hadn't made up my mind yet on whether to go full open source or not but I do include copies of my addons' source files as SDK samples just on general principal. I learned much of my orbiter-fu by tearing the stock atlantis apart line by line and it seems rude to deny that kind of resourse to others Wink.

At the moment my biggest headaches are thermal control and the landing autopilot.

I have a bunch of temprature and pressure guages that work but have no values to display, and my AP freaks out any time pitch gets close to +/-90 degrees
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #3 on: September 18, 2012, 10:23:19 AM »

Is there anyone in particualar that you'd reccomend getting in touch with?

The guys in this thread: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=491.0, especially dseagrav.

... and it seems rude to deny that kind of resourse to others Wink.

Sounds good!  Happy

At the moment my biggest headaches are thermal control and the landing autopilot.
I have a bunch of temprature and pressure guages that work but have no values to display, and my AP freaks out any time pitch gets close to +/-90 degrees

Both are complicated topics. For pressures and temperatures of the ECS/EPS in the CSM we use Radu's Systems (and Panel) SDK, a coarse overview is here: http://nassp.sourceforge.net/wiki/Command/Service_Module#Internal_systems_simulation. For the thrusters we use more simple, hardcoded rules. What pressures/temperatures are you looking for?

About the AP, our LM has a self-coded (non-VAGC) AP in Quickstart Mode (by the late LazyD), the stuff is in lemautoland.cpp/lemautoascent.cpp here: http://nassp.cvs.sourceforge.net/viewvc/nassp/projectApolloSource/src_lm/, perhaps this helps...

Cheers
Tschachim
Logged

Hlynkacg
Full Member
***
Posts: 18


View Profile Email
« Reply #4 on: September 19, 2012, 01:12:51 PM »

Quote
Both are complicated topics. For pressures and temperatures of the ECS/EPS in the CSM we use Radu's Systems (and Panel) SDK, a coarse overview is here: http://nassp.sourceforge.net/wiki/Command/Service_Module#Internal_systems_simulation. For the thrusters we use more simple, hardcoded rules. What pressures/temperatures are you looking for?


First priority is calculating cabin pressure, and temp so I can keep my UMMU's alive.

after that It's thruster and fuel-tank pressure/temps so I can do failure modeling and give my tape gauges something to display.

As far as the autopilot is concerned I'll take a look but thus far most of my problems have spawned from issues with attitude control. High angles of attack, such as at the beginning of the descent/landing or at the end of the ascent program, causes a high degree of instability in my pitch and roll pograms. Basically its an issue with Trig functions, Arc Sines & Cosines start coming back undefined and the AP doesn't know what to do.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #5 on: September 28, 2012, 11:44:30 AM »

First priority is calculating cabin pressure, and temp so I can keep my UMMU's alive.

Well, for those we use the forementioned "System & Panels SDK", the schematics on the wiki page is a depiction of the config file here: http://nassp.cvs.sourceforge.net/viewvc/nassp/projectApolloConfig/ProjectApollo/SaturnSystems.cfg?revision=1.26&content-type=text%2Fplain. In case you go open-source this might be an option, but it's a lot of work (and still needs a lot of coding) to get it right, so you might consider something more simple, i.e. a state driven system (pressured / unpressured cabin for example) leading to hardcoded values (we use that for RCS helium and fuel pressure).

As far as the autopilot is concerned I'll take a look but thus far most of my problems have spawned from issues with attitude control. High angles of attack, such as at the beginning of the descent/landing or at the end of the ascent program, causes a high degree of instability in my pitch and roll pograms. Basically its an issue with Trig functions, Arc Sines & Cosines start coming back undefined and the AP doesn't know what to do.

To be a smart-ass you could use Quaternions: http://en.wikipedia.org/wiki/Quaternion...  Wink

But you could also do it like the real thing and change your Euler angle convention, the real navigation system has its singularities at +/- 90° yaw, not +/-90° pitch. Mathematically it's just another convention, but 90° yaw doesn't happen normally during flight.  Happy

Cheers
Tschachim
Logged

Hlynkacg
Full Member
***
Posts: 18


View Profile Email
« Reply #6 on: September 29, 2012, 02:08:11 PM »

Quote
you might consider something more simple, i.e. a state driven system (pressured / unpressured cabin for example) leading to hardcoded values (we use that for RCS helium and fuel pressure).

Could you pont me towards those He and Fuel pressure functions? Both are items on my to-do list.

 
Quote
But you could also do it like the real thing and change your Euler angle convention, the real navigation system has its singularities at +/- 90° yaw, not +/-90° pitch. Mathematically it's just another convention, but 90° yaw doesn't happen normally during flight. 

Hmm...

Hadn't thought of that. Thank you.

It does raise some interesting question though, In every image of the FADI ball I've been able to find it appears to have full a 360 range of movement around the Y axis which I assumed Translated to 360* of yaw.

As such I applied the same matrix to my guidance programs as (in my vessel at least) they're reading thier inputs from the same function.

Speaking of ADIs I could really use some help here.

Thank's Again

Greg
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #7 on: October 02, 2012, 04:31:57 PM »

Could you pont me towards those He and Fuel pressure functions? Both are items on my to-do list.

Look here: http://nassp.cvs.sourceforge.net/viewvc/nassp/projectApolloSource/src_csm/csmrcs.cpp?view=markup at the SMRCSPropellantSource::Timestep function for an example. There is a SMRCSPropellantSource instance per CSM RCS quad, helium and propellant pressure are calculated each timestep from propellant mass and valve state.

It does raise some interesting question though, In every image of the FADI ball I've been able to find it appears to have full a 360 range of movement around the Y axis which I assumed Translated to 360* of yaw.

Yes, but the +/-90° yaw areas are marked red (see attached images), if your attitude reaches these areas, you have "gimbal lock" (the mechanical equivalent of the singularities in a 3 gimbal IMU): http://en.wikipedia.org/wiki/Gimbal_lock

As such I applied the same matrix to my guidance programs as (in my vessel at least) they're reading thier inputs from the same function.

The order of the Euler angles (i.e. roll, pitch, yaw) is different between an ADI and a FDAI, but I don't remember them, I'd need to dig that up...

Speaking of ADIs I could really use some help here.

I've no clue about mesh handling in a virtual cockpit, sorry.

Cheers
Tschachim


* GimbalLock.PNG (140.52 KB, 837x323 - viewed 36 times.)

* GimbalLock2.PNG (220.3 KB, 345x405 - viewed 32 times.)
Logged

Pages: [1] 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!