Forgotten Space Program

[Cydonian Monk]

1 hour ago, KAL 9000 said:

Moar please?

 

17 minutes ago, Choctofliatrio2.0 said:

It's coming soon. Don't fret

 

Fret not, unless on the guitar you strum, then fret on and be brave. Strut too, for struts and frets go hand in hand, as boosters light their way to a watery grave. 

[Geschosskopf]

On 2/24/2016 at 7:52 PM, Cydonian Monk said:

Sideways. 

Your use of kOS even for crewed missions is inspiring me to try to learn how to use it myself.  I used to have a lot of fun with "C-Robots" back in the 80s, which is about the last time I did any real coding, and getting KSP rockets to do my bidding automatically sounds fairly similar.  I note that the limits on kOS programs are about the same as real systems back in those ancient days

 

[Cydonian Monk]

6 minutes ago, Geschosskopf said:

Your use of kOS even for crewed missions is inspiring me to try to learn how to use it myself.  I used to have a lot of fun with "C-Robots" back in the 80s, which is about the last time I did any real coding, and getting KSP rockets to do my bidding automatically sounds fairly similar.  I note that the limits on kOS programs are about the same as real systems back in those ancient days

 

Cool. I'm all for anything that gets people interested in programming, doubly so if space is involved.

Using kOS as much as possible raises some interesting engineering problems the likes of which I've not seen since college. Ex: Here lately I've been hacking on the landing routine, trying to find a method that uses radar velocity and radar altitude to detect a landing algorithmically. Sure, I could just wimp out and check vessel:state (or whatever) to see if it's landed according to the game, but real spacecraft don't have magic states to check. (And given some career decisions I need to make here real soon now, this might have real-world uses beyond just being toy coding for a game. The problem is the same in both spaces.)

The only real complaint I have with kOS is its occasionally obnoxious user interface.... which is kinda necessary to have a development environment inside of a game that uses keybindings. I'm always tripping over myself by typing in a still-highlighted kOS window when I thought I was doing something else, like going to the map view.

[waterlubber]

Positive vertical speed, maybe.

Or 0 radar alt.

 

 

 

[Cydonian Monk]

3 minutes ago, waterlubber said:

Positive vertical speed, maybe.

Or 0 radar alt.

Sort of. It's possible to have a positive (or zero) vertical speed when hovering (to find a better landing site, for example). And the radar altitude is based on distance from the root part (where presumably the radar is mounted) to the ground and is slightly inaccurate based on the physics simulation. 

I've got the problem mostly solved, though much like the launch scripts, the landing script has to be customized for each craft. 

The combination of both helps, and with the addition of time it can be verified. 

[Geschosskopf]

4 hours ago, Cydonian Monk said:

Using kOS as much as possible raises some interesting engineering problems the likes of which I've not seen since college. Ex: Here lately I've been hacking on the landing routine, trying to find a method that uses radar velocity and radar altitude to detect a landing algorithmically. Sure, I could just wimp out and check vessel:state (or whatever) to see if it's landed according to the game, but real spacecraft don't have magic states to check. (And given some career decisions I need to make here real soon now, this might have real-world uses beyond just being toy coding for a game. The problem is the same in both spaces.)

Hmm, I think real spacecraft have a "landed state" they can check, often via several redundant ways.  You know, contact switches on the bottom, noticing the compression of the landing gear suspension, that sort of thing.  IOW, you can rationalize a check for the landed state by saying it's actually checking such sensors instead of just a ready-made variable, and save some code.  But OTOH, then you don't have the challenge of deriving the state from other observations.

4 hours ago, Cydonian Monk said:

The only real complaint I have with kOS is its occasionally obnoxious user interface.... which is kinda necessary to have a development environment inside of a game that uses keybindings. I'm always tripping over myself by typing in a still-highlighted kOS window when I thought I was doing something else, like going to the map view.

I have this problem when I'm on IRC and playing at the same time

[Cydonian Monk]

1 minute ago, Geschosskopf said:

Hmm, I think real spacecraft have a "landed state" they can check, often via several redundant ways.  You know, contact switches on the bottom, noticing the compression of the landing gear suspension, that sort of thing.

Quite true. Contact switches seem to be a popular solution to that (based on a quick sample size of two....), though they too could also have false-negatives. Valid argument regardless. 

[Geschosskopf]

59 minutes ago, Cydonian Monk said:

Quite true. Contact switches seem to be a popular solution to that (based on a quick sample size of two....), though they too could also have false-negatives. Valid argument regardless. 

Well, that's one reason to have several redundant checks.  A long rod sticking down below everything else, contact switches on each foot, and suspension compression checks on each leg.  Then you arbitrarily decide how many and in what order and combinations constitute real ground contact.

[Dunbaratu]

A real craft can "feel" how many "G"'s are acting on it with an accelerometer.  In freefall it should read zero.  If it's not zero, then that is either due to the thrust it's undergoing or an external force acting on it.

The craft should also be able to know how much thrust it can expect from its engine and current throttle setting.

If the "G"s it's feeling are close to the number of G's expected on the planet surface, with a bit of fudge tolerance for altitude, and that cannot be accounted for with engines, then those Gs are being provided either by the ground, or by air drag.  If you're not currently moving very fast, then it can't be air drag and there's only one answer left - the ground is doing it.

If your thrust is operating on a PID controller trying to maintain a constant descent for the last few seconds, then when you first touch the ground it will notice you're not descending anymore and throttle back..still not descending so throttle back more..... and eventually be throttled back enough to trigger the check mentioned above.

I think that might work and even accommodate craft that tip over and thus don't trip a contact wire.  If you're feeling an upward push that can't be accounted for by your engine or by air, then the ground is doing it.

 

 

[Cydonian Monk]

17 minutes ago, Steven Mading said:

A real craft can "feel" how many "G"'s are acting on it with an accelerometer.....

Also a good argument for requiring data sources in kOS to be derived from a part on the ship.  

[Dunbaratu]

1 hour ago, Cydonian Monk said:

Also a good argument for requiring data sources in kOS to be derived from a part on the ship.  

One of the frustrations we have is that in stock KSP the sensor parts were never designed to be used programattically and therefore the only publically exposed fields on them are text for human reading, not actual numbers.  When you click the acellerometer and it displays "9.8 m/s^2" it literally is that, as a string, not as the floating point number 9.8.  add in that it sometimes changes scaling on things using a variety of nonstandard nomenclatures(i.e. adding a 'M' for million when the number gets too big in some cases, but using scientific notation in others) and it became too messy to try to pass that information on to programs in the form of a number rather than a string.

 

[Cydonian Monk]

1 hour ago, Steven Mading said:

One of the frustrations we have is that in stock KSP the sensor parts were never designed to be used programattically and therefore the only publically exposed fields on them are text for human reading, not actual numbers.....

And unfortunately Squad has bigger fish to fry and better "bugs" to fix than those.... Especially since (I'd assume all of) the raw values used by the science parts to build their display strings are exposed through the vessel object in some way. So really there'd be little to gain by them "fixing" those issues. It would be nice if the data was displayed in a consistent format, and those parts aren't the only place that's an issue. Perhaps there's hope in the U5 UI rewrite....

[Dunbaratu]

53 minutes ago, Cydonian Monk said:

And unfortunately Squad has bigger fish to fry and better "bugs" to fix than those.... Especially since (I'd assume all of) the raw values used by the science parts to build their display strings are exposed through the vessel object in some way. So really there'd be little to gain by them "fixing" those issues. It would be nice if the data was displayed in a consistent format, and those parts aren't the only place that's an issue. Perhaps there's hope in the U5 UI rewrite....

We have a feature that sort of does this: You can get the sensors of the vessel with: SHIP:SENSORS:ACC.

Warning, when you do a `SHIP:SENSORS` you get a frozen snapshot picture of the sensor values at that time, so watch out for this trap:
 

// This code snip prints the same number over and over,
// ignoring what has changed:
set s to ship:sensors.
until false {
   print "ACC is " + s:acc.
   wait 1.
}

// This code snip prints differing numbers each time:
until false {
   print "ACC is " + ship:sensors:acc.
   wait 1.
}

We'd like to fix that trap but it hasn't been a high priority compared to other things.

 

We added this because the actual sensors have the problem discussed above.  But, these still do require at least one instance of the necessary sensor to exist on the vessel somewhere.  So for example, you can't read SHIP:SENSORS:TEMP if there's no thermometer part on the vessel.  In fact, that very check is the reason we want to eventually fix the trap mentioned here.  Right now it's a bit more slow and expensive to query SHIP:SENSORS:ACC than it should be, because it's walking the parts list each time you do SHIP:SENSORS, to find what instruments are present on the ship.  But because doing SHIP:SENSORS ahead of time causes the values to be frozen, you can't really escape from that expense at the moment in any real practical way.

 

I'm in danger of talking too much about my pet project in your thread about yours.  I'll stop talking kOS here and let the thread be about your excellent space program reports.

Edited February 26, 2016 by Steven Mading

[Cydonian Monk]

Second Verse, Same as the First

Identical in every respect to the first Phosphorous, P-2 was launched just as soon as updated landing software was available. This time the kerbals had a plan: Land on the far side of the Mün. They were (mostly) guaranteed to be in direct contact with the craft during tis entire descent, so this was less about landing in full isolation and more about landing on the far side. 

 

This launch was less than perfect, thanks largely to an errant K-Box controller left plugged into one of the desks in mission control. Gene had warned the various flight controllers against playing video games on the "Big Board" in MC-1, but there would always be that one kerbal who just had to get in a few more minutes of whatever the super hot game of the Münth was. Super.

It took the crews some time to determine what was causing the excessive undulation of the craft... it seemed to be fighting against itself, oscillating as much as 45 degrees off-course. (The software kerbs were quite happy they had never gotten around to coding the "deviation auto-abort" sequence for the launch script, as the waggling displayed by Phosphorous 2 would've surely resulted in an abort.) In the end it turned out to be the joystick on the K-Box controller not having a large enough dead zone. Hot.

Placed safely into orbit, the P-2 was on its node for Münar Transfer in less than half an orbit. The burn was completed using the RT-2 onboard flight computer. This operation turned out to be a bit less precise than desired, with the craft's resulting trajectory being one that intercepted the Mün. (Though arguably that was the plan anyway....) A short 6.4m/s mid-course correction burn cleaned that up nicely. Super.

 

 

Unlike its predecessor, the P-2 was placed into the more standard retrograde Münar orbit. The basic orbital operations were handled by the RT-2 onboard flight computer, bringing the lander probe into a 12km parking orbit. As it so happened the Boron 4 was in orbit just ahead of the P-2, keeping it company during its short visit and acting as a terrific relay. 

 

 

One orbit later and the P-2 was set up for landing. A short initial burn from the transfer stage was used to deorbit it and the lander, afterwards the four-legged beast took over the show.

Next stop: The East Farside Crater!

 

 

This part of the landing wasn't particularly nerve-wracking, given that it had already been proven in the P-1 mission. As expected the craft managed its descent smoothly, keeping the throttle set just enough to stay within the previously determined optimal speeds. There was some question as to whether it would land on, in, or on the rim of the crater in a crater it was headed for, but ultimately it came down just North of it.

 

And then the moment of truth. Everyone in mission control was gathered around one of two stations. Some had chosen to watch the response from the flight computer, others the telemetry. Some even attempted to set up a betting pool to see if anyone could guess which would report first, but everyone picked one side so they just took their money back. And, as expected, the cheers rang out from the telemetry desk first - No motion! Landed! 

Unfortunately the script running in the onboard kOS flight computer was still in its final descent stage, and had not yet reported touchdown. Fortunately that particular code locked the throttle to zero if the vertical speed was above a certain threshhold, so the craft remained exactly as it landed.

 

Upright.

A SIGKILL command was sent and the landing program aborted. The science teams fired off yet more commands to run their experiments, and waited anxiously as the data was beamed back to Kerbin. Sweet, juicy, science points. The currency of the universe. Don't phone home without it.

 

The software teams would later review their code and attempt to fix the "landing detection" issue, but they only had time for minor tweaks before the next launch.

--

A Little Bit Louder and a Little More Rehearsed

 

"I'm Phosphorous the Third I am. Phosphorous the Third I am I am...." 

Gene was starting to wonder about his Range Safety Officer. Wonder? No. It was straight-jacket worry with a capital B time now. The kid had always been a bit off, but now she was singing as though she was the probe itself. Herself. Itself. At least that's what it sounded like. Should he let her continue? They were in the middle of a launch, as it were, and if anything went wrong it was her duty to kill it. With extreme prejudice. The rocket, that is. Which was a bit tricky, since as far as Gene could determine she was now the rocket. Super.

"I got married to the rocket next door. He'd been married, never before...."

Pressure. Had to be. After this mission was safely away and in the books they would take a short break and let the teams cool off. Had to. They already had one seemingly permanently insane kerbal, no need for a second. Or a third. Or a fourth. Wasn't there a reward check sitting on his desk, ready to be cashed? Time to burn it on some new snacks. Kannolis, perhaps. Hot.

"And every one was a Phosphorous...."

"RSO, Flight."

"Wouldn't have a Sulfur or a Tin. What's up flight?"

"The rocket is. Can we have some peace and quiet for the rest of the launch, please?"

"Sorry flight. Won't happen again. It's the Third old probe named Phosphorous."

 

Phosphorous the Third it was it was. And it sailed onwards to orbit in the near silence of the upper atmosphere. Mission control had also descended into a strange, almost uncomfortable silence. Silence as though someone should be singing or music should be playing.... Looking around the room it seemed to Gene his controllers had all turned into hermits, huddled down into their trenches, every last Kerman of them. Very strange. Good, too. Yes, something told him he might just be into something good. Quiet, yes, awkward, doubly so, but still good.

And Phosphorous the Third slipped silently into the night.

 

Roughly a day later and the P-3 was happily in orbit around the Mün. Once again the ground controllers had a plan - this probe was destined for the Mün's "Right Eye", otherwise known as the East Crater. The P-3 was slightly different than its predecessors, in that the orbital stage included a reaction-control system to assist with attitude control. This was largely done in response to the oscillations observed with the previous launch (just in case the weirdness wasn't due to the errant K-Box controller), and ultimately burned up almost all of its monopropellant early in the flight. Decent enough trade off for the extra launch mass.

As is usual, the first step was to deorbit the transfer stage and its married probe. As was also usual, the upper part of the transfer stage overheated and exploded into..., well, I guess it became pure energy as there wasn't even a hint of shrapnel left behind. Except for five little birds. Four extra pieces of debris - the four monoprop tanks. And the usual backup antenna. (This will be important later.)

 

As with the P-2, the P-3's kOS flight control software handled the descent into the East Crater perfectly. Almost too perfectly. 

 

 

There were a few nervous kerbals in Mission Control Room 1 as the lander headed towards yet another crater-in-a-crater. The previous lander was resting safely on an inclined slope, but hitting the very edge of any of these craters might prove fatal. The "drone probe" operator was arguing his case with Gene that they should abort the software and let him bring it down safely away from the crater. Gene overruled him and stuck with the ones and zeds. 

And while it did come down on some rather steep terrain....

 

... it managed to drift softly down to the regolith, staying upright the entire time.

Yet once again the landing software failed to detect and validate the landing. This was later determined to once again be a case of the position of the radar relative to the base of the lander having been improperly calculated. The hackerkerbs were convinced they knew how to fix it, and were already well on their way to cleaning up the script. It would now have redundant checks to ensure landings were always properly confirmed, as well as a few "extras." But they wouldn't be able to test it until Phosphorous 4. 

The science team was again salivating over the copious amounts of SciencePoints returned by the probe, and had to be dragged away from their terminals when Gene ordered a mandatory after-mission party. If it was a snack, it was at the party. Cheese dip, corn chips, kannolis, yellow mush, it was all available for the taking. The only rule: No talking about work.

As a result none of them noticed Phosphorous the Third had landed near something of a popular vacation spot....

 

And hopefully they didn't notice the universe coming to a crashing halt as Jeb, the Bs, and N more kerbals once again landed somewhere long enough to line break in a 1200 part vessel named "Vessel Name." Because such nonsense never happened. Nope. Not in this universe. This time, instead of an antenna, the four monoprop tanks jettisoned by the P-3 AND another antenna somehow survived being suborbital, and, well, borked the universe.

 

Yay. Easy to fix, but, Yay.

 

With the landing requirements now tested and validated, work could begin on both a sample return mission and with placing kerbals on the Mün. Time was short, the Jool window was fast approaching.

 

Navigation: Next Post

Edited December 4, 2016 by Cydonian Monk

[TopHeavy11]

I like this story! Keep it up! And, do you have craft files and kOS scripts we can use? If not, can you put them up?

[Geschosskopf]

Good job!

So, how do free-range antennae bork the universe?

[Cydonian Monk]

50 minutes ago, TopHeavy11 said:

I like this story! Keep it up! And, do you have craft files and kOS scripts we can use? If not, can you put them up?

Thanks! kOS scripts, yes, though I'll warn you I'm a lazy hacker when it comes to things I write outside of work. Some occasionally ugly code this way lies: https://github.com/cydonian-monk/kOS-Scripts Craft files, not really. I use such a mish-mash of mods that the craft files might be difficult to get everything needed. I don't have them online in an easy to share place regardless.

 

34 minutes ago, Geschosskopf said:

Good job!

So, how do free-range antennae bork the universe?

I wish I knew, but this is twice it's happened. Presumably I've found some strange RemoteTech bug, though I'll need to scratch at it some more to confirm. I have some ideas. Possibly having a connected antenna being the only part on a ship? Or a connected antenna that's lacking an SPU? Might also be a mod conflict or something else entirely.....

[TopHeavy11]

23 minutes ago, Cydonian Monk said:

Craft files, not really. I use such a mish-mash of mods that the craft files might be difficult to get everything needed. I don't have them online in an easy to share place regardless.

i have all the mods you have, I checked. Anyone else who wants to fly these rockets better too.

[Cydonian Monk]

Just now, TopHeavy11 said:

i have all the mods you have, I checked. Anyone else who wants to fly these rockets better too.

OK. I'll look into options when I get home tonight. Not sure if I'll set up a git repo or put them on KerbalX, or use some other alternative.

[TopHeavy11]

Just now, Cydonian Monk said:

OK. I'll look into options when I get home tonight. Not sure if I'll set up a git repo or put them on KerbalX, or use some other alternative.

Dropbox is another option...

[Shania_L]

Awesome series, always a joy to read.

Quick question, why do you use retrograde Mun orbits for your landers? surely you are adding to the Dv requirements to match velocity with the surface?

[Cydonian Monk]

1 minute ago, Shania_L said:

Awesome series, always a joy to read.

Quick question, why do you use retrograde Mun orbits for your landers? surely you are adding to the Dv requirements to match velocity with the surface?

Thank you. 

I use retrograde Mün orbits for two reasons:

1) Free return trajectories for crewed spacecraft. Everything I send to The Mün (or the Moon) that has a living crew needs to be able to return to Kerbin (or Earth) without an additional burn. Since these ships then have to dock with other things (space stations), those other things also have to be in a retrograde orbit.

2) Given #1, to minimize the chance of a high-velocity impact. So if everything in Münar (or Lunar) orbit is orbiting in the same direction, then we're looking at 10-100m/s relative collisions instead of 1200m/s. 

Setting up the free-return trajectory requires an extra ~120m/s for the transfer burn but slightly reduces the capture burn. The difference for landing on or launching from the surface is negligible (18m/s). 

 

There are a few satellites in a prograde münar orbit, but most of them are in very high orbit. There might be one or two things in a prograde LMO from earlier saves....

[Geschosskopf]

2 hours ago, Cydonian Monk said:

2) Given #1, to minimize the chance of a high-velocity impact. So if everything in Münar (or Lunar) orbit is orbiting in the same direction, then we're looking at 10-100m/s relative collisions instead of 1200m/s. 

Well, because ships actually teleport from place to place each tick of the clock, the higher their relative velocities, the more likely they are to teleport past each other.  At opposing orbital velocities, in fact, this is almost a certainty even in the extremely unlikely event that they're actually on collision courses.  And teleporting by the other ship hurts a lot less than hitting it at 10m/s

 

[TopHeavy11]

Cydonian, I found a mistake in your modlist. You listed Tantares LV, but your accually using Tantares.

[Cydonian Monk]

Just now, TopHeavy11 said:

Cydonian, I found a mistake in your modlist. You listed Tantares LV, but your accually using Tantares.

Well they're both on the same thread, so it's tough there to give two different links. I'm using both, FWIW.

There is actually a mistake in the mod links where I've copied in a link to the old, retired thread of one of the mods, but the forum was being a bit grouchy when I tried to fix it so I've left it as-is for now.