Project Lunar Module "Spider" (Updated 11/01/2012)

[Submariner]

Do I put it in the root Orbiter directory? Or in modules?

 

[Hlynkacg]

Where did you put it?

Simply in the Orbiter root directory?

If so I'll just add it to the download package.

 

[Submariner]

Yeah I put it in the root directory and it worked! Thanks!

 

[Grover]

As you noted this is "true to life" and for the moment at least I intend to leave it as is. It's also worth noting that the flight-plan you described matches the historical one very closely and with your permission I'd like to include it in the documentation of future versions.

well, how about a config file lookup that alters the fuel ISP, either between preset values, or a config-file derived ISP? (similar to the XR series)

and sure, i can type a more detailed version if you like, that was just a quick how-to

 

[Hlynkacg]

well, how about a config file lookup that alters the fuel ISP, either between preset values, or a config-file derived ISP? (similar to the XR series)

and sure, i can type a more detailed version if you like, that was just a quick how-to

I could work with that.

It's also worth noting for your flightplan that the original Apollo Operations Handbook reccomended using the translational RCS for orbital manuevers.

The thrusters being over-powered in comparison to the ascent stage's PMI makes a bit more sense with this in mind.

 

[orb]

If so I'll just add it to the download package.

Don't add the MSVCR100D.dll to the download package. Instead rebuild the module in "Release" mode instead of "Debug".

The MSVCR100D.dll is a debug library, only usable when you have Visual Studio 2010 debugger, otherwise it will slow down the code using it, because of additional debug routines in every function. It isn't redistributed with the VC++ redistributable package, but only with the Visual Studio 2010 compiler/linker.

 

[Grover]

I could work with that.

It's also worth noting for your flightplan that the original Apollo Operations Handbook reccomended using the translational RCS for orbital manuevers.

The thrusters being over-powered in comparison to the ascent stage's PMI makes a bit more sense with this in mind.

i had another idea, how about a multiplier? just add a line to the CFG (default setting being 1) that is multiplied by your default ISP at clbkCreateClassCaps to set the working ISP, so you could set 100 (100x the burn time) for practising hover manoeuvres, 1 for realism, and something like 1.1 or 1.05 for a slightly easier loadout

and i did use the RCS for orbital stuff, i just thought it wasn't worth mentioning, since the main engine was so hard to use, you want me to type up a good flightplan?

laters

---------- Post added at 03:04 PM ---------- Previous post was at 02:18 PM ----------

ok. ive done a little more investigating into the time acceleration problem:

up to 1000x accel, the craft is normal, but at 10,000x accel, the orbit CHANGES DIRECTION and REDUCES SPEED, without affecting the trajectory (MFDs show the "normal" trajectory, and the spider doesnt lose altitude), it also starts rotating rather strangely, oscilating like a decoration found on a physicist's desk.

on another note, i managed a good descent, following my flightplan, and landed less than 500m from brighton beach VOR, with just over 4 minutes fuel left, so a good pilot might even have been able to get it onto the pad

and me previous bug wth the A Autopilot not disarming itself, may have been my mistake, it does turn off correctly once KillRot or Level Horizon AP is activated, though it does seem rather useless, perhaps you could reduce the amount that the AP pitches and rolls, so that it can respond quickly enough to its velocity reaching a standstill (like pitching half as much as it currently does, it would be slower, but far more stable, and might even get the velocity right down), but the AP doesnt seem to do anything to the altitude (like you would expect from an autopilot replacing the HOLD ALT function), and all engine work remains to be controlled by the pilot

im gonna see the ascent and descent autopilots now, see if i can think of a way to fix them..

laters

---------- Post added at 03:40 PM ---------- Previous post was at 03:04 PM ----------

ok, Autopilot review:

i couldnt'd find the landing autopilot, [ALT]+[L] wouldnt start anything, and different key modifiers ([CTRL] and [SHIFT]) wouldn't either

ASCENT AUTOPILOT:

from what i can tell, there is a short moment to set the heading (the ascent stage flies upwards only), then it quickly pitches to a "Commanded pitch"

this pitch i guess is calculated to give no vertical acceleration, and hold a vertical speed of +50m/s, and this is done rather well, its nice and stable (with no time acceleration) and holds a nice and steady trajectory

however, once above 15km, this should be set to hold a lower vertical speed, if any. personally, i would have decelerate slowly to zero (perhaps at 0.5m/s^2), then hold level flight.

for example:
the autopilot remains unchanged, but at 15km, the next stage is activated, holding a vertical DECELERATION of 0.5m/s^2. simple calculations give that the altitude will rise by a further 2.5km at this acceleration, giving an altitude of 17.5km as you pass your dynamic ApA. at this point, the next stage is activated, holding a level "ascent" profile (no vertical speed) untill the next stage:
once the PeA reaches 15km, we have MECO, and the craft is left in a rather stable, low orbit, which will do nicely for syncronising with a host craft at 60km (the actual starting altitude for descent, i made an error in my previous post)

the maths and programming aren't too complex i dont think, but then again, i have no idea how this thing ACTUALLY runs under the hood, let me know what you think.


as for the descent autopilot, i think a total rebuild is in order (based on how aggrivated it made you earlier). so why not use the same, simple logic from your ascent profile?

leave it to the pilot to get their initial trajectory right (get on-plane with the target), then follow my flightplan mathematically:
first, set the attitude to facing zenith, firing retrograde, and burn till the vertical speed reaches -20m/s, then calculate and adjust pitch to hold this

from here, the bank is controlled by the pilot to stay on-course, the engines stay at full throttle, and the craft goes down nice and easy.

as you approach the end of the autopilot (speed less than 100m/s), the autopilot should pitch down slightly to allow the throttle to come down to 60% power, and hold the same vertical speed, so that when the autopilot ends at a total speed of 100m/s (as given by an API function to return speed), the pilot is in a nice position to take control, and perform the final approach

now, some safety checks:
any standard autopilot activation should end the descent autopilot

is altitude drops below 1km, in any stage but the final stage (as power is lowered), the autopilot instead holds level descent (no vertical speed)

if total speed exceeds 2.5km/s at any stage, the autopilot disables itself (there's simply not enough fuel)

if bank angle exceeds 25 degrees, suspend the pitch control (or simply cut the AP)

*not directly related* if descent stage fuel reaches 0, the ascent stage automatically fires

this leaves some work for the pilot, so they can keep themselves occupied with their course, and be alert when the autopilot drops off and you regain control.

that should work, so long as its within the vessels potential (which i'm sure that it is, since ive flown this descent myself)

let me know what you think, hopefully its what you need

thanks man

 

[Hlynkacg]

This is how the ascent autopilot works "Under the hood".

Stage 1:
Calculate launch azimuth based on target inclination (this variable is currently fixed but all the calculations have been designed so that it can be a player input once I have the center console's keypad working)

Based on OAPIgetbodymass calculate orbital velocity of reference body.

Calculate dv required to reach orbital velocity. (Tangental velocity + gravity loss)

If dv required < dv available procede to next stage.

Stage 2:
Check switches/subsytems, RCS operational, Ascent engine armed, etc...

if true, seperate descent stage and continue.

Stage 3:
Rotate to calculated launch azimuth

Stage 4:
Pitch over and establish target vSpeed.

if vSpeed > 50 m/s procede to stage 5.

Stage 5:
Maintain 0 vAcc.

If velocity > calculated orbital velocity MECO and end program.

NOTES: Using a fixed target speed simplified the dv and pitch calculations. I used 50ms simply because that was the approximate profile I used in my early (manual) test launchs.

The autopilot will not allow a negative vSpee or vAcc.

The autopilot will reject any commanded pitch beyond -89 degrees

 

[BruceJohnJennerLawso]

Hi Hlynkacg, I was wondering If you would be okay with me integrating the work you hashed out on VC redraw displays in your earlier help thread here http://www.orbiter-forum.com/showthread.php?t=28072 into my project. I wa hoping I could use the font bitmap you generated, but maybe recoloured?

 

[Hlynkacg]

I think part of my problem with the landing AP was that I got too ambitious and tried to make it a full on LOLA style "fly-to-x" AP.

The result was buggy as hell, and 4 out of 5 times would run out of gas before completing the approach.

Going for a simple "by the numbers" approach isprobably the way to go

---------- Post added at 05:29 PM ---------- Previous post was at 05:25 PM ----------

Hi Hlynkacg, I was wondering If you would be okay with me integrating the work you hashed out on VC redraw displays in your earlier help thread here http://www.orbiter-forum.com/showthread.php?t=28072 into my project. I wa hoping I could use the font bitmap you generated, but maybe recoloured?

Go for it

 

[BruceJohnJennerLawso]

I think part of my problem with the landing AP was that I got too ambitious and tried to make it a full on LOLA style "fly-to-x" AP.

The result was buggy as hell, and 4 out of 5 times would run out of gas before completing the approach.

Going for a simple "by the numbers" approach isprobably the way to go

---------- Post added at 05:29 PM ---------- Previous post was at 05:25 PM ----------



Go for it

Thankya, Maybe I can actually integrate a Decent VC :thumbup:

 

[Tycho]

This project looks fantastic; kudos to all involved. One suggestion, if I may, however. And I apologize if this is nit-picking, but I'd really like to see a VC that's dark (like the real thing) with only a few small sources of light and lights on the panel (if that's at all possible). Don't know if that's already in the development plans, but that's the major beef I have with the AMSO LM VC. It'd make it more realistic and a lot cooler of an atmosphere. But that's just me.

 

[Grover]

This is how the ascent autopilot works "Under the hood".



NOTES: Using a fixed target speed simplified the dv and pitch calculations. I used 50ms simply because that was the approximate profile I used in my early (manual) test launchs.

The autopilot will not allow a negative vSpee or vAcc.

The autopilot will reject any commanded pitch beyond -89 degrees

why can't a negative VACC be specified? and then how about a lower speed? i use 20m/s

also, my launch AP didn't cut off at a stable orbit, and continued to raise me ApA well above 200k

 

[4throck]

I'd really like to see a VC that's dark (like the real thing) with only a few small sources of light and lights on the panel (if that's at all possible).

Don't want to de-rail the thread so I'll just add that I have done it for AMSO (never released it though).
It is possible to do the same for Spider (at least with the current texturing) but for now I'll not interfere with the current development. For my part, I'll wait for an official release before doing any repaints. :thumbup:

 

[Tycho]

It is possible to do the same for Spider (at least with the current texturing) but for now I'll not interfere with the current development. For my part, I'll wait for an official release before doing any repaints. :thumbup:

Fair enough. Reading back over the thread, it seems as though creating a realistic VC atmosphere is already in the works, so I'll apologize for repeating. Anyways, I'll stop being superficial, what with all the hard-coding that goes into the autopilots and all the other great features the devs are working on and no doubt occupies most of their to-do lists. So keep it up guys, I look forward to a full release.

 

[Hlynkacg]

why can't a negative VACC be specified? and then how about a lower speed? i use 20m/s

also, my launch AP didn't cut off at a stable orbit, and continued to raise me ApA well above 200k

Hmm... what lattitude were you launching from?

The routine for checking MECO conditions has been pretty reliable on my end.

as for a lower vSpeed that's an easy fix to make.

The issue with vAcc is mainly a safety measure. when you're slinging a lot of cos, tangents, sec, csc, around keeping all the variables positive helps make sure nothing comes back undefined.

Fair enough. Reading back over the thread, it seems as though creating a realistic VC atmosphere is already in the works, so I'll apologize for repeating. Anyways, I'll stop being superficial, what with all the hard-coding that goes into the autopilots and all the other great features the devs are working on and no doubt occupies most of their to-do lists. So keep it up guys, I look forward to a full release.

Thanks for the encouragement :tiphat:

---------- Post added 08-31-12 at 12:06 AM ---------- Previous post was 08-30-12 at 08:03 PM ----------

Been working on coding the altimeter and vs gauge but was starting to feel burnt out so I decided to take break and just fly around for a bit.

on another note, i managed a good descent, following my flightplan, and landed less than 500m from brighton beach VOR, with just over 4 minutes fuel left, so a good pilot might even have been able to get it onto the pad

CONFIRMED!

Started the orbital scenario and followed Grover's flightplan to the letter.

It deposited me in a 0/0 hover at 500 meters altitude, 1.5 km north west of BB. I still had approximatly 10% fuel remaining so I turned around and started making my way back towards the base using linear RCS to adjust my my velocity.

Landed with less than 100 kg of propellant remaining but I did land it :thumbup:

10 seconds to touch down...

Wheels err feet stop

 

[Grover]

Well making negative VACCs possible will certainly allow a better ascent autopilot to be produced. How about using modulus functions within your trig code to make the negative calculations more stable?

And I was launching from BB, using your provided scenario.

Any chance of some of your launch scenarios in the next update? Provided that a full mission is possible without cheating of course

 

[Hlynkacg]

Well making negative VACCs possible will certainly allow a better ascent autopilot to be produced. How about using modulus functions within your trig code to make the negative calculations more stable?

And I was launching from BB, using your provided scenario.

Any chance of some of your launch scenarios in the next update? Provided that a full mission is possible without cheating of course

I'll take a look at that, as for your second question unforunatly cheating is required, though I hope to adress that soon.

Now for the status update.

The Range/Altitude and VSI tapes are working, they just need needles.

The rotary dials also rotate now and and the mode select for the ADI works.

Next on the todo list is making the interior/exterior lighting controlable, and debugging the APs.

I've taken Grovers advice and ditched the full featured Landing LP for one that simply maintains a designated course and rate of descent. It's much simpler than my previous design and much less stressful to work on.

fingers crossed I'll be ready to push out a second beta within a week or two.

---------- Post added at 06:13 PM ---------- Previous post was at 03:12 AM ----------

Need some quick feedback.

Are the gauges sufficiently readable?

Also Should I shift the default camera position to get more of the panel and less of the window?

 

[Tycho]

The readability of the gauges looks pretty good to me. As for the camera position, I've got into the habit of shifting to the center camera position when going through the pre-launch and pre-landing checklists. So, spending most of my time in the default position while flying, I think the default position should be fine so long as it has a view out the window and the MFD/other important gauges (like your second screenshot). Keep up the great work--it looks fantastic and (despite the autopilot issues) it's a real pleasure to fly.

 

[4throck]

Looks good. The gauges are readable, at least as readable as in FSX 3D VCs.
My only suggestion would be to have 2 camera positions: one closer and facing the external window (what you already have) and another more distant and centered on the panel (providing a general view of all the switches).