Space Computer. Brought to you by kOS and hopefully many nerds.

[Payload]

We'll the kOS release thread is starting to get clustered with code example questions and such. I thought it would be a great idea to start a new thread so that those things can be discussed without making a mess.

My idea was that we build a basic flight computer out of txt modules that can be accessed from a main menu. I have a few ideas kicking around about how to do that. I could do the whole thing but then I wouldn't really learn anything and you guys wouldn't either.

It needs parts. Or modules.

1. Lift off to orbit.

2. Change orbit.

2a. change apoapsis/periapsis/circularize.

3. Execute node.

4. Landing from orbit.

4a. with deorbit burn and without.

That is about all I think we can do for now. As time goes on and kOS becomes more robust I think many features could be added.

Notice!. Requires kOS v0.71

Update 10-15-2013.

Found the time to update the Orbital calculation place holders. Circularization and Transfers are now handed with Vis-a-Vis.

Added some checks to the menu system. Now you cant accidentally run the orbit script when you are already flying. May need tweaking.

Added Cancel options to the Transfer and Landing scripts. You now have the option to go back to the menu when you get the burn dialog.

Other various changes.

10-11-2013. Bro, do you even land? SC does! Most of the time.

http://www.youtube.com/watch?v=lXvvJpWK--4

Changelog..................................................................................................................................FAR+DRE Video by Kalista

Massive round of bug fixes related to Recursive ON statements.

Menu now functions.

Primitive landing function.

Scripts hosted on pastebin.

Other things I probably forgot already.

9-16-2013. Added comments to the launch script

9-15-2013. Added roll control to the launch script.

Update 9-14-2013.

O.K. Guys. New updates.

Heading is now set via yaw with the Variable tHeading. Inclination launches are now as easy as setting a heading.

The further you stray from equatorial the more Your inclination will vary from heading.

Worst is polar at around 84deg inclination. 45 deg heading was 44.6 inclination. YMMV.

Rockets launched into inclination should now circularize much better.

Pitch is set just like it used to be only with a better term and the numbers now correspond to the Nav Ball.

Throttle limiting is in. You can currently limit your TWR directly via the variable tTWR. You can turn throttle limits off with the variable throttleLimit.

Auto warp is in. If you have focus on the kOS window then the auto warp will default to Physical Warp for some reason. So make sure you don't.

Hohmann transfer updated with warp script.

Scripts below have been updated.

Scripts updated 10-15-2013.

Menu system.

Spash Screen.

http://pastebin.com/J0YRUueD

Menu.

http://pastebin.com/epwUK7aN

Launch to orbit. Note the eccentricity. That is correct. MechJeb said .000

http://pastebin.com/zZwek06Z

Hohmann transfer.

http://pastebin.com/RxN9a4n3

Landing Program. No Image Yet. See video..

http://pastebin.com/eteJFMUg

I would enjoy any questions and feed back on these items as they are.

Special thanks to Cpt. Kipard and Ralathon for dropping the orbital calc knowledge.

Also thanks to Kalista for making great videos for us.

Known issues.

G-turn is not dynamic. That is getting worked on soon.

As always, still need to setup a config file to run that will replace constants.

The Mun is getting closer to our grasp. Once some bugs in the newest version of kOS get sorted, there is nothing stopping us.

Still requires kOS version 0.71 for now.

Need MORE Modules!

Again, we need people to get in and write some modules. We are still missing the standard orbital ops functions. I have written the transfer to give you an example of how those things can be accomplished since it must do all of them.

Grand programming experience is not required. Examples and advice are available. Everyone has to learn this language from scratch anyway. Get started now!

Available test crafts can be found here.

kOS Test Craft v1.0.. http://www./download/hp5epoz6u3daq96/kOS_Test_Craft.zip By Cpt. Kipard. This baby has enough dV to go to duna at least. It is also a very KSP style rocket. It's a little wobbly but it gets there.

The Jebpollo... http://pastebin.com/2zp4N9MU. Serial staged Apollo like craft that I have been using for testing. Has all the things to get Jeb to the mun in style.

Edited October 16, 2013 by Payload

[CaptainKipard]

My kethane operations require me to land tankers right next to my mining/converting rig within a several meters AND on the right side of the rig AND oriented correctly. Right now I deorbit and approach the rig but before touchdown I have to manually hover and position the tanker correctly. Only then do i land proper. Sooooo we need a hover module that allows manual (for now) RCS maneuvers just above the ground. I've already started work on it, but I might need some help understanding PID algorithms.

Since I'm already here I'll design the test vehicle.

Edited September 1, 2013 by Cpt. Kipard

[Payload]

We can't do that right now at all. We have no way of correcting horizontal speed other than manually. Landing from orbit is going to require an atmosphere and a horizontal speed reduction device. AKA parachute. What you are talking about is a job for mech jeb. I think you're misunderstand the capability of the virtual machine we have access to. I think if we wanted mech jeb we would just use that. I don't know. Am I out of touch with what people expect this thing will be able to do? I have high hopes for sure but I don't see this ever getting near mech jeb functionality nor does it need to.

We need a simple Apollo style test vehicle to start with. Test Vehicle 1.0. The current project goals are to make Test Vehicle 1.0 go up, move around, come back. Maybe late in development. We can go for mun free return etc.

EDIT: I mis-read I thought you were talking about closed loop control.

I think maybe you will be able to setup a loop that pulses the steering lock off and the sas on at the same time and then back on lock and sas off. That might give us enough control to cancel our horizontal speed manually.

Edited September 1, 2013 by Payload

[Payload]

Great article here that will help with understanding of PID controllers. Caution! This will hurt your head.

http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/

[CaptainKipard]

This is funny but I always knew I'd get mechjeb one day when I get good at manual flight. That time is nearly upon me, but now I have kOS which is a lot more fun. As for the capabilities of kOS it's already possible to control horizontal speed by pitching and yawing. Of course we have to wait for trigonometric functions, but I'm sure they're coming. Then if you want to hover at a constant height AND use your engines to change horizontal speed you just need to take into account the horizontal and vertical components of thrust and adjust both accordingly. It's semi-complex maths, sure, but it's doable. With that in mind and by checking the target vector you can land right on top of another craft. Of course before you cause a collision you'd run a script to just keep your altitude constant and manually fine-tune your horizontal position with RCS and then finally touch down.

[Ralathon]

My kethane operations require me to land tankers right next to my mining/converting rig within a several meters AND on the right side of the rig AND oriented correctly. Right now I deorbit and approach the rig but before touchdown I have to manually hover and position the tanker correctly. Only then do i land proper. Sooooo we need a hover module that allows manual (for now) RCS maneuvers just above the ground. I've already started work on it, but I might need some help understanding PID algorithms.

Since I'm already here I'll design the test vehicle.

PID controllers are really easy to make. Here's my hovering PID controller (Still trying to figure out a good way to adjust things without breaking the control loop):

Clearscreen.
print "Launch!".
stage.

set TargetH to 50.
lock steering to up + R(0,0,180).
set I to 0.
set deactivateFlag to 0.
on AG9 set deactivateFlag to 1.

until deactivateFlag=1 {
set P to 0.02*((TargetH - ALT:RADAR)-verticalspeed).
set I to 0.02*((TargetH - ALT:RADAR)-verticalspeed + I).
lock throttle to P+I.
}.


print "Thanks for flying!".
lock throttle to 0.

This'll lift up your craft (If able) and makes it hover at 50 meters above the ground. The idea behind a PID controller (Or just PI in this case, the D part isn't really needed here) is that you look at the difference between a certain target and a measurement.

Say for example that you're trying to heat an oven. You set the temperature at 100 degrees. The system then checks the current temperature and takes the difference between the 2. So say your oven used to be 50 degrees. That means the oven will start to pump power towards its heater following the formula "Qp = x*(100 - 50)". Where x is some variable that you can set to adjust how fast the whole thing works (more on that later). The smaller the difference the smaller the power towards the heater, so the more accurate the temperature.

This in itself would be a pretty lousy oven since an oven loses heat to the outside world as well. So at some point it would strike a balance where Qin - Qout = 0. And this means that there is a temperature difference between the desired value and the actual value. This is where the I part of the PID controller comes in. I stands for integral and this section of the controller removes the aforementioned offset. The formula this follows is "Qi = y* integral(Tset - Tmeasured)dt". Now if we have a constant offset this integral keeps growing and growing until eventually it overcomes the heat loss and thus stabilizing the oven at exactly the desired value. It does make your system a lot slower however. The D part of the controller takes care of that, but I doubt you'll ever need that bit for something KSP related.

Now, you have 2 variables (3 if you go for the full PID package). By tweaking those you can adjust how the system behaves. How the system behaves is determined mainly by just 3 things:

- Overshoot (The system tends to oscilate quite a bit before it settles. The overshoot is how far it shoots over the value)

- Settling time (How long it takes before the thing is reasonably stable on 1 value)

- Maximum slope (How fast the thing is allowed to change. Don't want your astronauts to turn into pulp due to a 15g burn)

You can see some great pics on the wiki that demonstrate all 3 of these properties.

Now, in control engineering there is this nasty little rule called the "Law of conservation of misery". It basically says that whenever you improve one of the above things, the others will become worse. Fast response, Fast settling time or small overshoot. Pick 1. Wiki has a nice table that shows what messing with the various parameters will do to your response. Figuring out the optimal parameters is an art in itself, but since we can launch as often as we want without angry people shouting at us manual adjustment is the easiest.

[Payload]

What I don't get is, the info we need to cancel Horizontal speed is right there on the navball. I wonder just how hard hooking that is. I haven't tried writing any plugins for this game. That would be one more IDE package on my machine that required constant maintenance. Some call it tired. I'm going with lazy... Might as well tell the truth about it. I bet Kevin already has it working in his little lab over there. Just laughing at us.

[Ralathon]

Cant you calculate it really easily? We know vertical velocity and we know total velocity. sqrt (V(total)^2 - V(vertical)^2) = V(horizontal).

[Payload]

Look at all that math. Why calculate it again? It is already calculated. We just need the variable exposed. You must really hate free cpu cycles.

I think we are just going to have to take it slow for a while. Every time we get a new update something else critical breaks. Now the rockets are having stretchy syndrome like some of the older mods and wigging out KSP. .4.5. try it. My rockets wig out KSP above 6000m now. OR AND operators work though.

Edited September 1, 2013 by Payload

[Ozin]

Cant you calculate it really easily? We know vertical velocity and we know total velocity. sqrt (V(total)^2 - V(vertical)^2) = V(horizontal).

The issue isn't getting the horizontal speed. It's getting the direction of it. We need a surface prograde vector or angle. I'm also missing being able to get my ship's current angle, got my fingers crossed for that one being implemented soon.

Also, I've been playing around with your PI controller script, thanks for sharing that. Slapped this together, it seems to work well, with little-to-no overshoot.

print "Hovering..".
set radius to 600000.
set g to 9.81.
set TargetH to 1000.

lock steering to up + R(0,0,180).
set I to 0.
set deactivateFlag to 0.
on AG9 set deactivateFlag to 1.

until deactivateFlag=1 {
	set WTR to (mass*g*((radius/(radius+altitude))^2)/maxthrust).
	set E to (TargetH - ALT:RADAR) - (verticalspeed*2).
	set P to (0.1*(E))*WTR.
	set I to (0.03*(E + I))*WTR.
	lock throttle to P+I.
	if verticalspeed < (((TargetH - alt:radar)/10)-20) { lock throttle to 1. }.
	if verticalspeed > (((TargetH - alt:radar)/10)+25) { lock throttle to 0. }.

	print "e: " + E.
}.
print "Exiting..".

The two if statements slow the vessel down gradually as it aproaches the target altitude. It should probably take gravity and TWR into account, didn't get to that yet.

The beauty of the pi controller is that it lets me change my horizontal speed while keeping hover to the same altitude. Very nice

Edited September 1, 2013 by Ozin

[Desrtfox]

If anyone's interested, here's my script for boosting to orbit using a sabre engine system (From B9). This rocket has a TWR of about 3.3, but I'm hoping the code works for rockets of varying TWRs. Also, action group 1 is used to switch engine mode.

set air to <IntakeAir>.
set tAlt to 100000.
set maxAccel to 40.
lock throttle to 1.
lock steering to up.

stage.
wait 4.
stage.
lock throttle to maxAccel * mass/maxthrust.
wait 1.
until air < 1/6 {
	set x to x - verticalspeed/135.	
	if x < -85 { set x to -85.}.
	lock steering to up + R(0,X,-90).
	lock throttle to maxAccel * mass/maxthrust.
	wait 1.
	set air to <IntakeAir>.
}.
toggle ag1.
rcs on.
lock steering to up + R(0,-55,-90).
until apoapsis > tAlt {
	lock throttle to maxAccel * mass/maxthrust.
}.
rcs off.
lock throttle to 0.
lock steering to prograde.	
until eta:apoapsis < 5 {
	if apoapsis < tAlt {lock throttle to maxAccel * mass/maxthrust.}.
	if apoapsis > tAlt {lock throttle to 0.}.
}.
set t to 0.5.
lock throttle to t.
until periapsis > (tAlt* 0.99) {	
	if eta:apoapsis > 5 { set t to t - 1/10.}.
	if eta:apoapsis < 5 { set t to t  + 1/10.}.
	if t < 0 {set t to 0.}.
	if t > 40 * mass/maxthrust {set t to maxAccel * mass/maxthrust.}.
	lock throttle to t.
}.

Edited September 1, 2013 by Desrtfox

[Payload]

Simple serial staging.

OHH THAT IS BAD CODE>

If anyone tried that autostage script I'm sorry it was only the top part of it apparently, and that part was broken too.

It checks for total fuel so it won't stage your parachutes unless they are on the same stage and it handles upper stage solids and decouplers. Those four variables are updated in the loop. I haven't tried removing them and using the direct terms. That wasn't working last time I checked.

It won't stage asparagus. Am I right in thinking the test vehicle will be serial staged?

Edited September 2, 2013 by Payload

[CaptainKipard]

Right now it's asparagus, but I'll make it serial if there's no other way. Have you tried parallel staging or are fuel lines simply out of the question.

Anyway I've just manually tested the ship and there's something odd with it. Because it's an Apollo style ship with a undockable lander and SM when you return the lander from a moon to the SM and dock with it you have to rearrange the stages. Then when I returned to kerbin I had to press spacebar twice in order to open the chutes. I think it might have to do something with the separate engines on the lander and SM. I'll do some more tests tomorrow

[Payload]

Right now it's asparagus, but I'll make it serial if there's no other way. Have you tried parallel staging or are fuel lines simply out of the question.

Anyway I've just manually tested the ship and there's something odd with it. Because it's an Apollo style ship with a undockable lander and SM when you return the lander from a moon to the SM and dock with it you have to rearrange the stages. Then when I returned to kerbin I had to press spacebar twice in order to open the chutes. I think it might have to do something with the separate engines on the lander and SM. I'll do some more tests tomorrow

I"m not totally against it. Any idea of how we will make it work? I was thinking something like acceleration checking. but it will have to be tightly windowed so it doesn't stage anything it isn't supposed too.

[JewelShisen]

Guys there is already a retrograde steering command so you can easily drop your HVel to zero for landing by doing what MJ does and just burn retro until it matches the UP direction.

[razark]

The issue isn't getting the horizontal speed. It's getting the direction of it. We need a surface prograde vector or angle.

We've got latitude and longitude. If you take two of those, separated by a known time, you should be able to determine surface direction and velocity, yes? I'm not up on the math for that, though. I'm guessing it probably involves some trigonometry we don't have right now.

[Payload]

Guys there is already a retrograde steering command so you can easily drop your HVel to zero for landing by doing what MJ does and just burn retro until it matches the UP direction.

Retrograde just means west in this computer. I hate to tell you. If it were that easy we would be showing it off already. Now if there is some new development I haven't heard about. By all means enlighten us. I'm sure the landing guys would love to have it for Test vehicle 2.0 time. Test vehicle 1.0 is slated to land capsule only like apollo. Test vehicle 2 is where we attempt to make the software compatible with a much wider range of rockets. I was hoping to get an Apollo style code out because I know there are a lot of people who would love to be able to recreate that as accurately as possible. The Apollo guys had to manually cancel horizontal velocity. At least Neal Armstrong did anyway.

I can say that I have made a boat load of headway. My launch to orbit code now stages "all the things" perfectly without jacking your chutes or anything else. Even asparagus! I have some work to do on my menus and I'm not entirely sure how I will handle that now. I was thinking of using a separate program for setting of initial values then when done executing the launch to orbit program. I think that will work as far as variable retention.

For real this time. Staging all the things launch to orbit code. For asparagus, all I need to know is the amount of fuel in the two sections you intend to drop off when empty and how many asparagus stages you have. It's rough and it's full of unneeded variables and resource tracking that isn't required anymore. When I wrote the majority of this the direct values didn't work in expression.

I will start working on getting it cleaned up and getting the main menu system at least started.

clearscreen.
set rpAlt to 100.
set rProgram to 90.
set r to 180.
set p to 0.
set y to 0.
set orbit to 0.
set tOrbit to 100000.
set hAtmo to 69500.
set tAngle to up + R(y,p,r).
set tThr to 1.
set turn1 to 9999.
set turn2 to 14999.
set turn3 to 19999.
set turn4 to 24999.
set turn5 to 49000.
set selection to 0.
set flagup to 0.
set flagdown to 0.
set confirm to 0.
set Count to 2.


print "Select your orbit altitude.".
print "--------------------------------".
print " ".
print " ".
print "Use action group 9 to add 10Km to orbit alt.".
print " ".
print "Use action group 8 to remove 10Km from orbit alt.".
print " ".
print "Use action group 7 to confirm orbit alt.".

until selection = 1
 {
 on ag9 set flagup to 1.
 on ag8 set flagdown to 1.
 on ag7 set confirm to 1.

 if flagup = 1
 {
 clearscreen.
 print "Select your orbit altitude.".
 print "--------------------------------".
 print " ".
 print "Default orbit alt is set to " + tOrbit + "m".
 print " ".
 print "Use action group 9 to add 10Km to orbit alt.".
 print " ".
 print "Use action group 8 to remove 10Km from orbit alt.".
 print " ".
 print "Use action group 7 to confirm orbit alt.".
 print " ".
 set tOrbit to tOrbit + 10000.
 print "You have selected " + tOrbit.
 toggle ag9.
 set flagup to 0.
 }.

 if flagdown = 1
 {
 clearscreen.
 print "Select your orbit altitude.".
 print "--------------------------------".
 print " ".
 print "Default orbit alt is set to " + tOrbit + "m".
 print " ".
 print "Use action group 9 to add 10Km to orbit alt.".
 print " ".
 print "Use action group 8 to remove 10Km from orbit alt.".
 print " ".
 print "Use action group 7 to confirm orbit alt.".
 print " ".
 set tOrbit to tOrbit - 10000.
 if tOrbit < 80000 { set tOrbit to 80000. }.
 print "You have selected " + tOrbit + "m".
 toggle ag8.
 set flagdown to 0.
 }.

 if confirm = 1
 {
 clearscreen.
 print " ".
 print "You have confirmed " + tOrbit + "m".
 print " ".
 print "Lift Off in 5s.".
 toggle ag7.
 set confirm to 0.
 wait 2.
 set selection to 1.
 }.
 }.

set cAlt to tOrbit - (tOrbit*.2).
set xAlt to tOrbit - 1000.
set hAlt to tOrbit - 5.
clearscreen.
print "Orbit altitude set to " + tOrbit.
print "3". wait 1.
print "2". wait 1.
print "1". Wait 1.
Print "Lift Off!". stage.

set StartFuel to <liquidfuel>.
lock steering to tAngle.
lock throttle to tThr.

when altitude > rpAlt then
 {
 set r to rProgram.
 print "Roll Program".
 }.

when altitude > turn1 then set p to -35.
when altitude > turn2 then set p to -45.
when altitude > turn3 then set p to -60.
when altitude > turn4 then set p to -75.
when apoapsis > turn5 then set p to -90.

when apoapsis > tOrbit then
 {
 { set tThr to 0. }.
 until altitude > hAtmo
 {
 if apoapsis < hAlt { set tThr to .05. }.
 if apoapsis > tOrbit { set tThr to 0. }.
 }.
 when Eapoapsis < 1 then set tThr to 1.
 }.

when periapsis > cAlt then set tThr to .05.

when periapsis > xAlt then
 {
 set tThr to 0.
 sas on.
 print "You Are Now In Orbit".
 wait 1.
 set orbit to 1.
 }.

until orbit = 1
 {
 set Lfuel to <liquidfuel>.
 set Sfuel to <solidfuel>.
 set StageLiquid to stage:liquidfuel.
 set StageSolid to stage:solidfuel.
 set Eapoapsis to eta:apoapsis.
 set tAngle to up + R(y,p,r).
 set throttle to tThr.

 if Lfuel < StartFuel - 215 AND Count > 0
 { stage. set StartFuel to Lfuel. set Count to Count - 1. }.

 if StageSolid > 0 And StageSolid < 1
 { stage. }.

 if StageLiquid = 0 AND StageSolid = 0
 { if LFuel > 0 { stage. }. }.

 }.

[alterbaron]

I'm guessing it probably involves some trigonometry we don't have right now.

If you want trig functions, you could always use:

sin(x) ~= 1-(1/2)x^2+(1/24)x^4-(1/720)x^6

cos(x) ~= x-(1/6)x^3+(1/120)x^5-(1/5040)x^7

These are quite accurate when x is between -pi and pi.

[Payload]

Menu system progress. I need sleep.

[CaptainKipard]

Lol nice touch with he ASCII art there

Ok I've just finished my second test of the craft and I'm about ready to release it. Unfortunately I wasn't able to work out the strange staging after docking the lander to the SM. I've tried every sensible rearrangement of stages after docking and it always needed two space bar presses to open the chutes. It must be a KSP bug. We'll just have to work around it. I'll post the ship in a little while with a short usage guide.

Since no one has suggested it yet, my next project will be a universal script for adjusting the true anomaly. It's main use will be for changing ship locations for synchronous orbits on all the bodies where synchronous orbits are possible. I already have the calculations in a spreadsheet so it should be a breeze.

[Payload]

Lol nice touch with he ASCII art there

Ok I've just finished my second test of the craft and I'm about ready to release it. Unfortunately I wasn't able to work out the strange staging after docking the lander to the SM. I've tried every sensible rearrangement of stages after docking and it always needed two space bar presses to open the chutes. It must be a KSP bug. We'll just have to work around it. I'll post the ship in a little while with a short usage guide.

Since no one has suggested it yet, my next project will be a universal script for adjusting the true anomaly. It's main use will be for changing ship locations for synchronous orbits on all the bodies where synchronous orbits are possible. I already have the calculations in a spreadsheet so it should be a breeze.

That rocket actually flies off the top of the screen!!! Not just pretty pictures. Moving pretty pictures like a bauss.

[Glaucus]

This is really interesting.

But does anyone know the equations for ideal trajectory and ideal velocity for different altitudes to obtain an orbit around kerbin.

[Ralathon]

The ideal trajectory depends on your craft and staging setup. But I imagine you can get a pretty good approximation by simply keeping the ETA to Apoapsis constant at 30 seconds or something. Or have some a turning speed that depends on TWR.

[CaptainKipard]

Orbital velocity for circular orbits of small objects like rockets is:

v_o = (GM/r)^0.5

where:

G = Gravitational constant

M = Mass of the object you're orbting.

r = distance between the centres of mass of your rocket and the object

As for trajectory that's a lot more complex. I read a reddit post once about performing a true gravity turn, which should be possible provided that your rocket is perfectly balanced. You could then run a small script to launch your rocket at the perfect angle needed for a true gravity turn, and just keep it at full power WITHOUT making any course corrections. The pilot would also need to refrain from touching the controls. I think for now it would be simpler to just fake gravity turns by actively controlling the ships orientation according to some preset rules that approximate a gravity turn ascent profile. I've been trying to find some information on this for a while now, with no luck.

[LtPinback]

Hohmann transfer maneuver script based on Payload's Launch script.

clearscreen.

set completion to 0.
set tOrbit to 100000.

set tThr to 0.

set selection to 0.
set flagup to 0.
set flagdown to 0.
set confirm to 0.

set tManeuver to 0.

print "Hohmann transfer maneuver.".
print "--------------------------".
print " ".
print "Current orbit. Ap " + apoapsis + "m. Pe " + periapsis + "m.".
print " ".
print "Select new orbit altitude.".
print " ".
print "Default orbit alt is set to 100km.".
print " ".
print "Use action group 9 to add 10Km to orbit alt.".
print " ".
print "Use action group 8 to remove 10Km from orbit alt.".
print " ".
print "Use action group 7 to confirm orbit alt.".

until selection = 1
 {
 on ag9 set flagup to 1.
 on ag8 set flagdown to 1.
 on ag7 set confirm to 1.

 if flagup = 1
  {
  clearscreen.
  set tOrbit to tOrbit + 10000.
  print tOrbit + "m.".
  toggle ag9.
  set flagup to 0.
  }.

 if flagdown = 1
  {
  clearscreen.
  set tOrbit to tOrbit - 10000.
  print tOrbit + "m.".
  toggle ag8.
  set flagdown to 0.
  }.

 if confirm = 1
  {
  clearscreen.
  print "You have confirmed a " + tOrbit + "m circular orbit.".
  print "Beginning Hohmann transfer maneuver.".
  toggle ag7.
  set confirm to 0.
  wait 2.
  set selection to 1.
  }.
 }.

if tOrbit > apoapsis { set tManeuver to 1. }.
if tOrbit < apoapsis { set tManeuver to 2. }.

clearscreen.

print "Hohmann transfer maneuver.".
print "--------------------------".
print " ".
print "All systems nominal.".
print " ". 

lock throttle to tThr.
sas off.

when tManeuver = 1 then
 {
 print MISSIONTIME + ": ETA to first burn in " + Eapoapsis + "s.".
 lock steering to prograde.
 set cAlt to tOrbit - ( ( tOrbit - apoapsis ) * 0.10 ).
 set xAlt to tOrbit - 500.

 when Eapoapsis < 1 then
  {
  print MISSIONTIME + ": First burn initiated".
  set tThr to 1.
  when apoapsis > cAlt then set tThr to 0.05.
  }.

 when apoapsis > tOrbit then 
  {
  print MISSIONTIME + ": First burn completed".
  set tThr to 0. 
  print MISSIONTIME + ": ETA to second burn in " + Eapoapsis + "s.".
  when Eapoapsis < 1 then
   {
   print MISSIONTIME + ": Second burn initiated".
   set tThr to 1.
   when periapsis > cAlt then set tThr to 0.05.
   when periapsis > xAlt then
    {
    print MISSIONTIME + ": Second burn completed".
    set tThr to 0.
    sas on.
    print MISSIONTIME + ": Hohmann transfer maneuver completed.".
    print MISSIONTIME + ": Apoapsis at " + apoapsis + "m.".
    print MISSIONTIME + ": Periapsis at " + periapsis + "m.".
    wait 1.
    set completion to 1.
    }.
   }.
  }.
 }.

when tManeuver = 2 then
 {
 print MISSIONTIME + ": ETA to first burn in " + Eperiapsis + "s.".
 lock steering to retrograde.
 set cAlt to tOrbit + ( ( apoapsis - tOrbit ) * 0.10 ).
 set xAlt to tOrbit + 500.

 when Eperiapsis < 1 then
  {
  print MISSIONTIME + ": First burn initiated".
  set tThr to 1.
  when periapsis < cAlt then set tThr to 0.05.
  }.

 when periapsis < tOrbit then 
  {
  print MISSIONTIME + ": First burn completed".
  set tThr to 0. 
  print MISSIONTIME + ": ETA to second burn in " + Eperiapsis + "s.".
  when Eperiapsis < 1 then
   {
   print MISSIONTIME + ": Second burn initiated".
   set tThr to 1.
   when apoapsis < cAlt then set tThr to 0.05.
   when apoapsis < xAlt then
    {
    print MISSIONTIME + ": Second burn completed".
    set tThr to 0.
    sas on.
    print MISSIONTIME + ": Hohmann transfer maneuver completed.".
    print MISSIONTIME + ": Apoapsis at " + apoapsis + "m.".
    print MISSIONTIME + ": Periapsis at " + periapsis + "m.".
    wait 1.
    set completion to 1.
    }.
   }.
  }.
 }.


until completion = 1
 {
 set Eapoapsis to eta:apoapsis.
 set Eperiapsis to eta:periapsis.
 set throttle to tThr.
 }.

Edit: Clean up and use of prograde and retrograde vector so it works for orbits with any inclination.

Edited September 4, 2013 by LtPinback