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

[CaptainKipard]

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

Cool. I'll test this out. Looking through the code I can see one place that could use a little tweak when it comes to timing the burn. If I get it to work I'll post it.

PID controllers are really easy to make. Here's my hovering PID controller

Ok I tested it out it seems to work, except looking at Kerbal Engineer it shows that the rocket is gaining a little altitude. Maybe it's because the center of mass is shifting. That would mean the rocket moves vertically, but the center of mass doesn't. It's too bad KSP doesn't have a special part that allows you to measure altitude from a set location on your ship.

Also thanks for that explanation, it actually made sense. I did actually look at the wiki article before but problem with it is too much information and too much jargon. Also I never understood the purpose of calculus. I wish I had payed more attention in college. Reading your post made me think about some kind of a predictive algorithm that would eliminate oscillation when hovering and also allow suicide burns. Because if I understand correctly PID controllers just respond to errors, right? They don't predict possible future errors?

If anyone's interested, here's my script for boosting to orbit using a sabre engine system (From B9).

That's certainly useful for lightening the rocket, thanks. Also if someone wants to try and take on an SSTO script that would be epic.

EDIT

Here's the test ship guys. It's not pretty but it's designed to get you to Mun or Minmus and back.

kOS Test Craft

A few things about it:

I managed to make it very stable. There might be some tiny wobble right after liftoff, but once the first pair of boosters drop it handles beautifully. I designed it using this map with a few hundred emergency dv to spare. Also I personally hate debris so I made the ascent stage and SM capable of deorbiting on their own, though I didn't add the kOS part to them simply because it's a small stackable part that doesn't really fit anywhere without editor extensions.

Here's how the full trip should happen.

1. Liftoff

2. Stage 1 (First pair of boosters)

3. Stage 2 (Second pair)

4. 80km orbit (leaves enough LFO to deorbit stage 3)

5. Stage 3

6. Deorbit Ascent stage.

7. (Important) Disable fuel crossfeed between lander and SM.

8. Moon transfer

9. Moon circularisation at low orbit (consult the map for orbit altitudes)

10. Undock Lander and stage to enable engines.

11. Moon landing

12. Moon ascent and orbit.

13. Rendezvous.

14. Dock and rearrange stages. All engines at 0, parachutes at 1.

15. Kerbin transfer and circularisation at LKO

15a. (optional) Check lander and SM fuel levels and transfer.

16. Undock Lander

17. Deorbit SM

18. Deorbit lander

19. (Important) When landing the parachutes require TWO stage events. I have no idea why.

19a. (optional) Soften the landing with engines.

The parachute deal is really strange. Even if I stage to enable the lander engines before undocking for the first time, when I dock again the ship acts as though I still need to stage again before finally staging the parachutes. Oh well.

Edited September 2, 2013 by Cpt. Kipard

[Desrtfox]

That's certainly useful for lightening the rocket, thanks. Also if someone wants to try and take on an SSTO script that would be epic.

Here's my code for a sabre based SSTO spaceplane. In my case, the TTW is about 2. Also, this gets a little toasty towards the end of the run, so you may need to adjust targetVert and possibly the intake air switch point for the sabres. I can post the craft as well if you'd like:

print "initializing".
lock air to <IntakeAir>.

set targetPitch to -55.
set targetVert to 82.
set tAlt to 100000.

brakes on.
lock throttle to 0.3.
stage.
wait 12.
brakes off.
lock throttle to 1.
lock steering to up + R(0,targetPitch,-90).


until altitude > 150 {
	if verticalspeed < targetVert {set targetPitch to targetPitch + 0.5.}.
	if verticalspeed > targetVert {set targetPitch to targetPitch - 0.5.}.
	if targetPitch < -85 {set targetPitch to -85.}.
	if targetPitch > -40 {set targetPitch to -40.}.
	lock steering to up + R(0,targetPitch,-90).
	set air to <IntakeAir>.
}.
gear off.

until air < 0.26 {
	set vertDist to verticalspeed-targetVert.
	set targetPitch to targetPitch - vertDist/40.
	if targetPitch < -85 {set targetPitch to -85.}.
	if targetPitch > -40 {set targetPitch to -40.}.
	lock steering to up + R(0,targetPitch,-90).
	set air to <IntakeAir>.
	if vertDist*vertDist < 300 {wait 1.}.
}.
toggle ag1.
lock throttle to 0.75.
rcs on.
lock steering to up + R(0,-55,-90).
wait until apoapsis > tAlt.
rcs off.
lock throttle to 0.
lock steering to prograde.	
until eta:apoapsis < 5 {
	if apoapsis < tAlt {lock throttle to 1.}.
	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 > 1 {set t to 1.}.
	lock throttle to t.
}. 

Here's a screenshot of the craft in orbit, so you can get an idea of the launch vehicle:

http://steamcommunity.com/sharedfiles/filedetails/?id=175440122

Edited September 3, 2013 by Desrtfox

[Ralathon]

Ok I tested it out it seems to work, except looking at Kerbal Engineer it shows that the rocket is gaining a little altitude. Maybe it's because the center of mass is shifting. That would mean the rocket moves vertically, but the center of mass doesn't. It's too bad KSP doesn't have a special part that allows you to measure altitude from a set location on your ship.

Also thanks for that explanation, it actually made sense. I did actually look at the wiki article before but problem with it is too much information and too much jargon. Also I never understood the purpose of calculus. I wish I had payed more attention in college. Reading your post made me think about some kind of a predictive algorithm that would eliminate oscillation when hovering and also allow suicide burns. Because if I understand correctly PID controllers just respond to errors, right? They don't predict possible future errors?

Could be that the shift is caused by the shifting CoM yea, I do all my test with a grasshopper style craft with just 1 tank, so I never noticed such an effect before. It could also be that the rocket is drifting slightly horizontally. The script tries to maintain radar altitude, so if you're above a slope your height will change. In the former case there's not much you can do about it and in the latter you can change the ALT:RADAR to ALTITUDE.

And yea, a predictive algorithm is usually better for control engineering. The problem is that you need to know exactly how your system is going to behave, something that is very hard to do outside the simplest situations. PID controllers are awesome because they can be applied universally and then fine tuned for the specific problem. For example, if you notice a lot of oscillations in that PI controller I posted, just change the 0.02's in the UNTIL loop to 0.005 or something. It'll make the burn slower but it'll reduce oscillations. If you make the integral variable small enough you can even over dampen the system so it won't oscillate at all (But it'll be veeeeery slow).

[Payload]

PID controllers are nice and they give us more flexibility for unknown conditions. However. I have found that a simple loop holds altitude within one meter. At least with ships of 1.5+ TWR. I can't foresee why you would be be bothered to write such a controller unless it is essentially required.

I tested this hover script with a few different craft and it seems to behave as expected.

until count = 100.
 {
 if veritcalspeed < 0 { lock throttle to 1. }.
 if verticalspeed > 0 { lock throttle to 0. }.
 set count to count + 1.
 }.

Of course you could use any method the break out of the loop you wish. I setup a simple counter. I haven't timed it's relation with system time or observed any side effects of condition. It was just something to use as a loop break. YMMV.

It also works equally well as a vertical speed hold. Just change the 0 to whatever. The speed of your computer might play some part in whether or not this works well. It shouldn't, as far as I can tell, but it might.

Edited September 3, 2013 by Payload

[Desrtfox]

Here's my code for a sabre based SSTO spaceplane. In my case, the TTW is about 2. Also, this gets a little toasty towards the end of the run, so you may need to adjust targetVert and possibly the intake air switch point for the sabres. I can post the craft as well if you'd like:

print "initializing".
lock air to <IntakeAir>.

.
.
.


until air < 0.26 {
.
.
.

Here's a screenshot of the craft in orbit, so you can get an idea of the launch vehicle:

http://steamcommunity.com/sharedfiles/filedetails/?id=175440122

Just an FYI to anyone using this. A good rule of thumb seems to be to set the switch intake air value to about 1/10 of the original value of your intakes. I've done this with two SSTO spaceplanes of vastly different masses (though both SABRE jets with TWRs in the 2 to 3 range) and it seems to work well.

Here's the second SSTO:

http://steamcommunity.com/sharedfiles/filedetails/?id=173554539

Apparently, the circ burn portion of the code still needs some work though. Occasionally, it pushes part periapsis causing the burn to stop.

[Desrtfox]

Retrograde just means west in this computer. I hate to tell you.

Just for the record, I'm pretty sure this is untrue.

Prograde does mean in the direction you are orbiting, and it does take into consideration your speed relative to the center of the gravity well you are at, but not velocity relative to the surface.

For instance, in a polar orbit, prograde is going to mean what you think it should mean - in the direction you're going. Driving on the surface with a rover, or any suitably slow craft, you need to consider that the body you are sitting on is spinning, and thus, imparting velocity to your craft even though it may be sitting still on the surface. So, in this case, prograde may not mean what you expect due to the high westward velocity imparted by the rotation of the planet.

Now, if we could compute this velocity imparted by the planetary rotation, and subtract it out of the prograde vector, we would be left with the surface velocity vector. I don't know how to do this off the top of my head though.

Edited September 3, 2013 by Desrtfox

[CaptainKipard]

.....

Apparently, the circ burn portion of the code still needs some work though. Occasionally, it pushes part periapsis causing the burn to stop.

For the purposes of our project here I think circularisation should be a separate script. So we have a script for rocket ascent and spaceplane ascent, but after that the ships really behave the same mostly. I don't know about you but every ship I make, I make sure that the last ascent stage has enough LFO to reach periapsis apoapsis, and circularise with the payload, and deorbit on it's own. No detaching the payload before orbit. I think we should aim to keep our computer modular. IIRC someone already made a circularisation script that makes perfectly circular orbits.

Edit: I meant apoapsis.

Edited September 3, 2013 by Cpt. Kipard

[Desrtfox]

For the purposes of our project here I think circularisation should be a separate script. So we have a script for rocket ascent and spaceplane ascent, but after that the ships really behave the same mostly. I don't know about you but every ship I make, I make sure that the last ascent stage has enough LFO to reach periapsis, and circularise with the payload, and deorbit on it's own. No detaching the payload before orbit. I think we should aim to keep our computer modular. IIRC someone already made a circularisation script that makes perfectly circular orbits.

OK, that seems reasonable.

I have to confess here, that I was just posting generally useful scripts, not focusing so much on the scenario laid out in the OP. Sorry about that, I came in from the kOS thread and just assumed that this thread was a script exchange kinda thing. I'll take a look at the actual mission now!

I don't see the perfect circ script though. I see one from Payload that appears to be similar to what I've done. I'll try his out and see what I get.

[Payload]

OK, that seems reasonable.

I have to confess here, that I was just posting generally useful scripts, not focusing so much on the scenario laid out in the OP. Sorry about that, I came in from the kOS thread and just assumed that this thread was a script exchange kinda thing. I'll take a look at the actual mission now!

I don't see the perfect circ script though. I see one from Payload that appears to be similar to what I've done. I'll try his out and see what I get.

My script is for circularizing a know condition. It's quite flexible as I have used that script to launch to 300km and to 80km and the largest eccentricity I got was .002. I'd say that was circular for all intents and purposes. I'm not sure how it will handle all conditions because it is hard coded to reduce engine power considerably when the periapsis is 80% of the apoapsis. I'm starting to think that either 20% might be too much or .05 thrust might be too little. However, it proves to be fine for my test rocket.

Any proper circularization script has to take into account burn time. For that, you need to calculate twr and required dV. Once you have have burn time you can use eta:apoapsis to set the burn to half and half.

Edited September 4, 2013 by Payload

[CaptainKipard]

I tested this hover script with a few different craft and it seems to behave as expected.

until count = 100.
 {
 if veritcalspeed < 0 { lock throttle to 1. }.
 if verticalspeed > 0 { lock throttle to 0. }.
 set count to count + 1.
 }.

I've tested this and it doesn't work well at all. I'm getting unacceptable variations in altitude. Maybe my laptop is too slow. I have an Intel core i7 2670QM 2.2GHz with up to 3.10GHz Turbo Boost and GeForce GT 555M 2GB card. If it is too slow then that's a mixed blessing since we have a wider range of testing platforms.

Anyway a PID controller works a lot better for me. I'll keep testing.

[Payload]

I've tested this and it doesn't work well at all. I'm getting unacceptable variations in altitude. Maybe my laptop is too slow. I have an Intel core i7 2670QM 2.2GHz with up to 3.10GHz Turbo Boost and GeForce GT 555M 2GB card. If it is too slow then that's a mixed blessing since we have a wider range of testing platforms.

Anyway a PID controller works a lot better for me. I'll keep testing.

I'm betting it's just too slow. Full time 3.6Ghz intel quad here. Ati 6970 2gb video card. In a desktop that cares nothing about how much power it's chooching from the wall. Your laptop isn't what I would consider slow, but the way this game treats CPU's.... I tried with ships from around 1.0 TWR to way over 2.0. The problems for me started below about 1.5TWR. Hover height started to vary around 4m. Too much for a nice dainty landing. Still, we can't reduce HZ speed with thrust until we get the values exposed. You could just use a drogue to cancel your HZ velocity and cut it when you are within a range you are comfortable with. Until then all of this landing talk is speculatory at best.

Just to update. I've added an exit option to the main menu but until we get an EXIT AND RUN command the menu doesn't work with the actual program modules. Even if the menu is done it doesn't actually end until the program you called with run is over. That keeps the modules from actually controlling your craft.

Edited September 4, 2013 by Payload

[CaptainKipard]

I have to confess here, that I was just posting generally useful scripts, not focusing so much on the scenario laid out in the OP. Sorry about that, I came in from the kOS thread and just assumed that this thread was a script exchange kinda thing. I'll take a look at the actual mission now.

Don't worry about it. Posting useful scripts is obviously fine, as long as it improves the Space Comp. I plan on posting snippets here and there too.

For example...

I have an idea for a perfect burn timing snippet that takes into account Newton's Second Law. I also thought about implementing the Tsiolkovsky Rocket Equation into it but I can't see a simple way of faking natural logs, plus it's not essential unless you have a rocket that expends most of its fuel in a short time that also has a large wet-to-dry ratio. What do you guys think?

Edited September 4, 2013 by Cpt. Kipard

[alterbaron]

I can't see a simple way of faking natural logs

Here's a simple way to calculate ln(x) to essentially as much precision as you want (or as much as the computer can handle):

INPUTS:

• x: Number of which to take natural log.
  
• n: Number of iterations (controls accuracy of result)
  

OUTPUTS:

• y=ln(x)
  

sign = 1.0.
if x < 1.0 {
  x = 1.0/x.
  sign = -1.0.
}.

a = x/(x-1.0).
y = 1.0/a.
i = 2.

until i > n {
  y = y + 1.0/(i*(a^i)).
  i = i + 1.
}.

y = y*sign.

Note that the code won't work when x=1. (ln(1) = 0).

Setting n=100 gives you better than 10^-6 accuracy for all 1/10 < x < 10.

Setting n=1000 gives you nearly 10^-6 accuracy for all 1/100 < x < 100.

Should be more than good enough for use in the rocket equation.

Edited September 4, 2013 by alterbaron

[Ozin]

I've tested this and it doesn't work well at all. I'm getting unacceptable variations in altitude. Maybe my laptop is too slow. I have an Intel core i7 2670QM 2.2GHz with up to 3.10GHz Turbo Boost and GeForce GT 555M 2GB card. If it is too slow then that's a mixed blessing since we have a wider range of testing platforms.

Anyway a PID controller works a lot better for me. I'll keep testing.

yeah same here. As soon as you put more into that loop it starts updating too slowly.

Did you give my version posted on page 1 a try? It works perfectly for me on Kerbin

[Payload]

yeah same here. As soon as you put more into that loop it starts updating too slowly.

Did you give my version posted on page 1 a try? It works perfectly for me on Kerbin

Why would you need to put more in the loop? All it does is hover?

You really should keep your loops as simple as possible. If they are too big and nasty, consider breaking the operations up into smaller loops. You don't want your computer trying to do everything all the time.

NEVER, I repeat NEVER, print anything in a time critical loop. Print takes ages.

I did a little testing of orbital eccentricity calcs.

set Rneg to ((apoapsis + 600000)-(periapsis + 600000)). //Where 600000 is the mean radius of Kerbin.
set Rpos to ((apoapsis + 600000)+(periapsis + 600000)).
set Eccentricity to (Rneg/Rpos).

print Eccentricity.

That is only for Kerbin. I haven't figured out how to make use of the Body command since it returns a string and not an integer. Facepalm.

That could probably be shortened to one print command. I haven't bothered yet. There is also hundred different ways to do that math. YMMV. It gives the correct answer. That is all I'm worried about.

[SolarLiner]

Makes me think of a BBCode export feature for my kOS IDE. With the colors and such, would that not be awesome?

[Ozin]

Why would you need to put more in the loop? All it does is hover?

You really should keep your loops as simple as possible. If they are too big and nasty, consider breaking the operations up into smaller loops. You don't want your computer trying to do everything all the time.

NEVER, I repeat NEVER, print anything in a time critical loop. Print takes ages.

Personally I prefer the approach of getting as close as possible to a balanced thrust at a target height as efficiently/quickly as possible. It ends up being a lot more stable for me. True, the interval is increased with more calculations, but as long as it is stable the PI controller works very well. The prints were obviously for debugging.

Edited September 4, 2013 by Ozin

[CaptainKipard]

Here's a simple way to calculate ln(x) to essentially as much precision as you want (or as much as the computer can handle):

....

Thanks. Actually I've thought of a simpler method of achieving my goal, but this is very interesting nonetheless.

Did you give my version posted on page 1 a try? It works perfectly for me on Kerbin

That's very impressive. I got a maximum of 20cm difference over 5 minutes. What is E and what does it do?

Nevermind it looks like error handling.

Edit:

Lol i love this script. I just set it to 30m and dropped a rocket from 8km and it didn't crash!

Edit:

Do you think you could try and make the throttle control not stutter like that when it drops from a high altitude?

Makes me think of a BBCode export feature for my kOS IDE. With the colors and such, would that not be awesome?

Good idea.

Also I'd like to suggest that we all start using more descriptive variable names. Or at the very least add comments when they become available or explanations in your post.

Edited September 5, 2013 by Cpt. Kipard

[Ozin]

That's very impressive. I got a maximum of 20cm difference over 5 minutes. What is E and what does it do?

Nevermind it looks like error handling.

Edit:

Lol i love this script. I just set it to 30m and dropped a rocket from 8km and it didn't crash!

Edit:

Do you think you could try and make the throttle control not stutter like that when it drops from a high altitude?

Thanks, and yeah, here is a much improved version taking a different approach. No uneven or stuttering throttle in both directions now. If the rocket has to climb to reach the target height, it uses the "radar apoapsis" as the error rather than the actual height.

For drops I tweaked the error to work with WTR. I left in some margins of error, could be made more aggressive/fuel preserving. Also works great with parachutes. Lowest TWR I tested it on was a 1.04 dropped from 12km (1.19 by the time it stopped at hover). Highest around 6.5 TWR.

print "Hovering..".
set radius to 600000.
set g to 9.81.
set offset to 20.
set targetHeight to 1000 + offset.

stage.
sas off.
lock steering to up + R(0,0,180).
set I to 0.
set deactivateFlag to 0.
on AG9 set deactivateFlag to 1.
set adjust to 0.
set PI to 0.
lock throttle to PI.

until deactivateFlag=1 {
	set WTR to (mass*g*((radius/(radius+altitude))^2)/maxthrust).
	set radarApoapsis to apoapsis - (altitude - alt:radar).
	if verticalspeed < 0 { set radarApoapsis to alt:radar. }.

	if targetHeight < (radarApoapsis + offset - 10) {
		set error to ((targetHeight - radarApoapsis)/(20*(WTR^0.5))) - verticalspeed - 15.


		print error.
	}.
	if targetHeight > (radarApoapsis + offset - 10) {
		set error to (targetHeight - radarApoapsis) - (verticalspeed*3).
	}.
	set P to (0.02*(error))*WTR.
	set I to (0.03*(error + I))*WTR.
	set PI to P+I.

	on ag2 set adjust to 2.
	on ag3 set adjust to 3.
	on ag4 set adjust to 4.
	if adjust = 2 { set targetHeight to 3000 + offset. toggle ag2. set adjust to 0.}.
	if adjust = 3 { set targetHeight to 20 + offset. toggle ag3. set adjust to 0.}.
	if adjust = 4 { set targetHeight to targetHeight - 10. toggle ag4. set adjust to 0.}.
}.
unlock throttle.
print "Exiting..".

Compared to the last version, this performs a lot better. I'm really pleased with the result

Edited September 5, 2013 by Ozin

[Payload]

Ok guys, can we get an equation for burn time? I've got TWR, and I've got required dV. I just can't find any sensible way to calculate how long it's going to take for me to burn to that target velocity.

[Ralathon]

dV(t) = integral a*dt.

a(t) = F/m(t) = Isp * 9.81 * dm/dt / (M(ini) - t*dm/dt).

Assuming constant thrust:

dm/dt = F/(9.81*Isp).

a = F/(M(ini) - t*F/(9.81*Isp).

integrating gives:

dV(t) = 9.81*Isp * ln (M(ini) - t*F/(9.81*Isp))

Which I could've totally derived from the Tsiolkovsky rocket equation... doh. Anyway, reverse the formula to give time as function of dV:

9.81*Isp*(e^(dV/(9.81*Isp)) - M(ini))/F = t. There ya go. Should work as long as you don't mess around with the force during the burn.

[Payload]

Yea, too bad we don't have isp? I can calculate acceleration at max thrust with A=F/M.

[CaptainKipard]

If you calculate maximum TWR, then rig the rocket to keep that same TWR during the entire burn, then you've effectively made it accelerate constantly (I think), this way timing the burn is as easy as:

time = deltav/acceleration

time to begin burn = node eta - time/2

I'm doing that for my phase adjustment script. It feels really dirty doing it like that but it's simple and it looks like it'll work.

Edit.

Payload I think you should spruce your OP a bit. Like make it tidy and colourful and welcoming to newbies. We might get more interest.

Edit.

This might be pedantic but do you guys think it's a good idea to keep a record of standard variable names for our project here? it might help with reusing code.

Edited September 6, 2013 by Cpt. Kipard

[Payload]

If you calculate maximum TWR, then rig the rocket to keep that same TWR during the entire burn, then you've effectively made it accelerate constantly (I think), this way timing the burn is as easy as:

time = deltav/acceleration

time to begin burn = node eta - time/2

I'm doing that for my phase adjustment script. It feels really dirty doing it like that but it's simple and it looks like it'll work.

Yea but how are you calculating required dV when you don't know what your orbital speed will be when you get to apoapsis? This is just mind numbing and no, I will not force a rocket to a certain TWR because that wont work for things like space planes.

I thought I had calculated req dV but that is a fail too. I have no idea what my orbital velocity will be when I get to apoapsis. It's like a chicken and egg thing. And stupid really. The game is making these calculations already of course. This scripting language feels useless. It's forcing us to do calculations that it should have direct access too. Feels like a low level language but without the freaking speed.

EDIT: So to reiterate my question. Can someone come up with a script that works for this? I've been looking at classic rocket equations all day. They aren't helping. They are making it abundantly clear how much information I don't have.

Edited September 6, 2013 by Payload

[CaptainKipard]

You can try the Vis-Viva equation to get the velocity at any point on your orbit and to get your delta v. I've only used it on circular orbits but I know it works for any kepler orbit.

And why wouldn't it work for spaceplanes? maxthrust gets the total thrust for all engaged engines and you only use rocket engines in space, right?

Edit.

If you'd like to wait, then my upcoming script should clear things up.

Edited September 6, 2013 by Cpt. Kipard