[1.8.x] DMagic Orbital Science: New Science Parts [v1.4.3] [11/2/2019]

[DMagic]

I will be setting up composition classes for Custom Asteroids. However, I'd like to see what interface Taniwha decides on for asteroid mining before I implement this, so it may be a while.

Any idea of how you'll assign types? I'd like to do it based on something in-game, not just randomly assigning a type based on something that I implement.

It seems like the seed # might be the best option, but I'm not sure if it's connected to the size class somehow. They don't seem to be, but I haven't actually checked that many asteroids.

Also this would require visiting the asteroid since the ModuleAsteroid doesn't get created until it comes within loading range. That would seem to eliminate any kind of long range spectral-type assignment. But maybe you could instead just force the module to load when the asteroid is first generated.

[Starstrider42]

Any idea of how you'll assign types? I'd like to do it based on something in-game, not just randomly assigning a type based on something that I implement.

It seems like the seed # might be the best option, but I'm not sure if it's connected to the size class somehow. They don't seem to be, but I haven't actually checked that many asteroids.

Also this would require visiting the asteroid since the ModuleAsteroid doesn't get created until it comes within loading range. That would seem to eliminate any kind of long range spectral-type assignment. But maybe you could instead just force the module to load when the asteroid is first generated.

I was planning to assign types randomly, with probabilities set by population. So, for example, NKOs might be largely stony or metallic asteroids, while Kuper belt objects might be almost all carbonaceous or icy.

I'm still trying to figure out the API (and I may PM you later to compare notes, since it seems you've done a lot of the work) but I'm pretty sure the ModuleAsteroid seed is just used to generate the asteroid mesh.

Edited May 6, 2014 by Starstrider42

[DMagic]

Another Tuesday, another weekly installment of mod dev notes.

I took a short leave of absence after releasing the last update (by which I mean playing X-Com Enemy Within, which is awesome, rather than working on KSP) so I haven't done very much.

But in the last few days I have been working on the second iteration of asteroid science. Now I'm glad that Squad didn't do anything with asteroids because it gives me a blank slate to implement whatever I want.

My thinking is to assign spectral types to asteroids; I'm not sure what the best way of doing this is, preferably something that can be compatible with other mods, like Custom Asteroids, but not have any dependencies. Right now I'm just assigning type based on each asteroid's seed #, but this has some issues, and I'm not sure if the number is truly random or has some connection to an asteroid's size class.

The idea is to make asteroids behave like a planet and have the spectral type behave as a biome as far as recording science reports is concerned. That way I could make experiments that are dependent upon spectral type and give different results, and make others that aren't dependent on type and give one set of results for all asteroids. I'll use the asteroid size class only to determine a science value multiplier (and I've found a better way to determine the size class).

The other goal of this version is to allow for reports from multiple asteroids with diminishing returns. I don't know of any way to do this using the stock R&D scenario module, so I'm creating my own (Scenario Modules are used to save data in different sections of the persistent file: the R&D module saves tech node and science results info, the Progress Tracker stores info on where you've been, etc...).

This way I can create a new science cap for my asteroid experiments and assign science values for the current experiment based on how much has already been earned from other asteroids. Then I can pass off the science value to the regular R&D module so that your results and science still get recorded. Basically I'm just bypassing the stock subject value (the planet/situation base multiplier), scientific value (the diminishing returns multiplier for repeated experiments), and the science cap (normally based on the science cap defined in the SciendDefs.cfg file * the subject value). This all seems fairly simple to do, but I'm sure there will be problems that crop up at some point.

The end result of all this is that you'll be able to conduct the same experiments on multiple asteroids while gaining a diminishing amount of science.

So the first experiment (using the magnetometer while near an asteroid) would give you the full science value: the base value of 5 * the multiplier for the asteroid (say 10, for a class E). The next asteroid you visit, another class E would give you only 40, then 30 for the next, and so on until you reach a cap, maybe 250 science total.

Because you get more science for larger asteroids this would mean that you would have to visit a larger number of smaller asteroids to reach the cap. So another way of doing this might be to set a soft cap and limit the number of asteroids you can research. Instead of conducting experiments until you reach the 250 science cap you could conduct experiments on 10 different asteroids. If they are all large you would get more science, if they are all small you would get fewer points.

For a spectral-type-dependent experiment like the laser there would be a separate science cap on each type, one for carbonaceous, one for stony, etc...

I've started coding some of this, and it doesn't seem to complex. I'm mostly replicating how the R&D persistent node stores science results which is all fairly straightforward. I still need to figure out the exact math of how to set diminishing returns and I need to figure out the spectral type thing.

I've also made some designs for the Universal Storage Goo experiment, but I'll wait to see how their empty wedge design comes out before going any further with that. And I still need to come up with ideas for the other two stock experiments and finish cramming my telescope into a wedge.

[MaverickSawyer]

Possible issue with the anomaly scanner... The Monolith on the plains to the north of the KSC does not trigger a response from the scanner. I was parked literally right next to it, and got no response. Is this an intentional, or is it an accidental oversight?

[DMagic]

Possible issue with the anomaly scanner... The Monolith on the plains to the north of the KSC does not trigger a response from the scanner. I was parked literally right next to it, and got no response. Is this an intentional, or is it an accidental oversight?

It's not really a bug per se, it's more of a technical limitation due to how anomalies are stored by the game and scanned. The KSC is one object with its center located about 30m below the path between the launchpad and the VAB. All of the surrounding buildings, including that monolith, are considered part of that one object. It's possible to set it up to scan individual objects, but I don't want to have different results for every building at the KSC (and the airfield). Coming up with something specifically for that monolith might be a little easier, but I'm not sure if it's worth it.

The general rule is, if the anomaly doesn't show up on SCANsat or ISA, then my scanner won't pick it up either.

And if you want to know the exact distance and location to an anomaly (not the intentionally vague directions shown on-screen) open up the debug window with alt+F2, it will show the exact values.

[MaverickSawyer]

Ah, that explains it. OK, then, nevermind.

[xEvilReeperx]

The other goal of this version is to allow for reports from multiple asteroids with diminishing returns. I don't know of any way to do this using the stock R&D scenario module, so I'm creating my own (Scenario Modules are used to save data in different sections of the persistent file: the R&D module saves tech node and science results info, the Progress Tracker stores info on where you've been, etc...).

One option is to stuff your extra information at the end of the subject id the way stock does (I borrowed crewReport here):

// your experiment here, available through ModuleScienceExperiment
var exp = ResearchAndDevelopment.GetExperiment("crewReport");

// when player deploys experiment:
    // generate an id for this experiment
    // another note: if you don't want vessel situation to matter,
    //               just consistently provide an appropriate one (InSpaceHigh probably)

    var subject = ResearchAndDevelopment.GetExperimentSubject(exp, ScienceUtil.GetExperimentSituation(FlightGlobals.ActiveVessel), FlightGlobals.currentMainBody, "ClassC.SomeType");

    subject.subjectValue = 1f;
    subject.scienceCap = 220f; // you can set this by class
    subject.dataScale = 1f;
    subject.title = "Sample of a Class C YourType asteroid";

    // submit initial report: science value = 110 * 1 = 110 points
    ResearchAndDevelopment.Instance.SubmitScienceData(110f, subject);

    // stock game will reduce value for us automatically, but 
    // it's overridden easily
    subject.scientificValue = .8f;   // let's make this next report 20% less
                                        // note: R&D will store this value for us persistently

    // this report is now worth 20% less = 88 science
    ResearchAndDevelopment.Instance.SubmitScienceData(110f, subject); // test diminishing returns

    // third experiment will be worth 60%
    subject.scientificValue = .6f;

You'd probably want to look for subjects for a given experiment for every body if you don't want actual location to matter, but that's trivial. You already do your own work with ScienceData so things should be quite straightforward

[DMagic]

One option is to stuff your extra information at the end of the subject id the way stock does (I borrowed crewReport here):

Hmm, you're probably right. I actually do something similar already with the anomaly scanner and with my existing asteroid science system. I also have a pretty good method for assigning experimental situations, though it doesn't handle multiple nearby asteroids very well.

My original hangup with using the R&D center was that I wanted to append the asteroid seed # to every subjectID, the same way that stock asteroid samples do. I was thinking this would cause problems when trying to identify what has already been recovered because every asteroid would give a new ID. But as I've been working on it I realized that I don't really need to append the seed #, so every report would be the same except for the host planet. And really it probably wouldn't be very hard just to check for the relevant parts of the ID anyway.

But the more I've been thinking about using my own scenario module the more I like it. I alluded to this a little, but using my own module allows me to store extra information, aside from the standard science values. The most obvious example is an experiment number (first sample, second sample, etc...). For the asteroid thing I could use this as an easy way to determine the diminishing returns. But I could also use it for doing things like ordering experimental results (the first magnetometer scan of Duna gives result one, the second scan gives result two, etc...). Maybe there's an easier way of doing that too, but this is turning out to be fairly simple, well, assuming it actually works right, which it probably won't.

[DMagic]

Chapter 1: Radio and Plasma Wave Science

Chapter 2: Magnetometer

Chapter 3: Telescopes and Imaging Systems

Chapter 4: Laser Ablation

Chapter 5: Core Drill and Biological Experiments

Chapter 6: Neutron Reflections and Subsurface Water

Chapter 7: X-Ray Diffraction and Surface Composition

Continuing on with my bi-monthly (read, -annual) series on what all this stuff does, I'll be going over the magnetometer today.

On a basic level magnetometers are rather simple, they measure the magnitude, and sometimes direction, of a magnetic field. Near the Earth's surface these kinds of measurements are extremely valuable for navigation purposes. In space they are used to study many aspects of the solar system and its planets.

Considering that every planet, moon, and large asteroid is associated with a magnetic field of some kind, it's not surprising that most interplanetary, and several Earth-orbiting probes come equipped with magnetometers.

The Boom

About the boom, except for the large high-gain antenna and maybe the solar panels, the boom is typically the most noticeable feature of a probe craft. The reason these long boom are used is that the probe itself can emit a significant amount of magnetic interference. The body of the probe usually contains several ferrous (iron-containing, magnetic alloys) metals and there is a lot of electric current passing through the probe, these factors can generate a lot of background magnetic noise. Putting the magnetometers on a long boom, typically 10m, moves the instruments away from most of this interference (which tapers off quickly with distance) and allows for much clearer reading of the surrounding magnetic fields. In most cases there is one instrument placed at the end of the boom and another placed near the middle.

The boom itself is made of non-magnetic materials, sometimes carbon fiber in newer designs, and aluminum in older spacecraft. Occasionally the magnetometer is mounted at the end of a solar panel, the Juno probe uses this design. This saves the weight and complexity of the boom, but can add complexity elsewhere (not to mention that Juno is the only outer-solar system spacecraft that actually uses solar panels).

The Instruments

There are a wide variety of different magnetometer instruments, most of which aren't really appropriate for spacecraft use. But there are still a fair number different types used by various spacecraft. I'll only go over the two used in my model which is based on Cassini's magnetometer.

Fluxgate Magnetometer

Back to the instruments themselves now. A common type is the tri-axial fluxgate magnetometer. One of these is mounted in the middle of the boom on the Cassini spacecraft and is what I've modeled my design on. The tri-axial part means that it measures the magnetic field in three dimensions by combining three individual instruments into one, with each instrument aligned 90^o away from the others.

An individual fluxgate magnetometer is very simple in principle (anyone who's tried the wrap-a-wire-around-a-nail trick will be familiar with the basics of this). It consists of a central magnetic core wrapped with two sets of wires. The first, usually inner, set of wires is the drive coil. An alternating current is passed through this wire to induce a constantly reversing magnetic field in the coil. This magnetic field then induces a current to flow through the second, sense coil, wire.

When you put the whole thing in an area with a background magnetic field (that would be anywhere in the solar system, or galaxy for that matter) this background field subtly alters the induced field in the fluxgate core. This alters the signal that is produced in the sense coil, and, with some very sensitive electronics, can give you a reading of the magnetic field strength. When you combine all three sensors you can figure out the magnetic field strength in all three dimensions.

Helium Vector/Scalar Magnetometer

The other type of magnetometer included in my design, and also found at the end of Cassini's boom, is the helium vapor magnetometer. This one uses an entirely different method to produce a measurement similar to that of the fluxgate magnetometer.

The specifics of how this instrument works are, let's say, complicated. There are basically four components: an infrared lamp, an infrared detector, a chamber filled with helium gas, and a number of surrounding loops of wires called Helmholtz Coils.

The lamp generates IR light at a very specific frequency that is passed through the helium chamber. The helium molecules absorb this light, then some physical chemistry, quantum physics and hand-waving happens, and the IR detector measures the results. When the helium chamber is placed in a magnetic field the interaction between the helium and the IR light changes, and these changes can be monitored through the IR detector.

With some modifications to the sensor's electronics in can be used in vector and in scalar mode. In vector mode the Helmholtz Coils can be used in a feedback loop to determine the magnetic field components in each dimension, allowing a single instrument to do what three fluxgate magnetometers can do. In scalar mode the total magnetic field intensity is measured with a very high degree of accuracy.

The Science

So what's the point of all these finely tuned instruments being strapped onto nearly every interplanetary probe? There is much to be learned from studying the magnetic fields of other planets, the sun and the Earth.

Measurements

On Earth the most immediate application is for navigation. Compasses point at the magnetic north pole, but there is a surprisingly high variation in the intensity and direction of the Earth's magnetic field near the surface. The two measurements frequently used for purposes relatively close to the Earth's surface are magnetic inclination and declination.

Magnetic inclination is a measure of which direction the magnetic field is pointing relative to the Earth's surface. Near the equator the field is mostly parallel to the surface, so it is around 0^o inclination, closer to the magnetic poles the field begins to point downward, into the Earth's center. Near the magnetic north pole the inclination approaches +90^o, near the magnetic south pole it's -90^o.

Magnetic declination is the difference between magnetic north and true north, basically the difference in what a compass says is north, and what is actually north. This changes greatly with latitude and is obviously useful for navigation.

Both of these components show a great deal of variability across the Earth's surface, much more than you would expect from a simple magnetic field model. Earth orbiting satellites are used to make very precise measurements of the magnetic field at all locations above the surface; data from these and surface-based observations are used to calibrate models used to predict these components (the standard version of which is used by my magnetometer).

These two images show the variation in total field intensity (left) and magnetic declination (right). You can see the south magnetic pole between Australia and Antarctica, it coincides with a peak in intensity and the declination can be as high as 180^o near this area. There are two more peaks on either side of the north magnetic pole, which is at about 80^o north and not visible on this map, and a low point over South America. This is called the South Atlantic Anomaly and is the point where the Van Allen radiation belts come closest to the Earth's surface (still about 200km up though).

Further away from the surface the magnetic field is usually reported in terms of its three-dimensional components, the X-, Y-, and Z-fields (or sometimes they are given in spherical coordinates of B-radial, B-theta, and B-phi) and the total intensity. My magnetometer switches between reporting the inclination and declination while close to the surface, to the vector components when far away (the X- and Y-dimensions are combined into a horizontal measurement, given along with the vertical measurement) while always displaying the total intensity.

Magnetospheres in the Solar System

Some large planets, like the Earth, generate an enormous magnetic field that wraps around the planet. This field gets warped and stretched by interactions with both the sun's magnetic field and by the constant stream of charged particles flowing out from the sun, the solar wind. These charged particles and their interactions with the Earth's magnetosphere are responsible for a number of events, from trapped high-energy bands of radiation, to geomagnetic storms like auroras, to a band of charged particles constantly spinning around the equator called the ring current. Many of these events can be studied by very accurately measuring the magnetic field in the space around the Earth.

The presence or absence of an intrinsic magnetic field can also tell us much about a planet's interior composition. The Earth's magnetic field is believed to arise from the liquid iron outer core spinning around the solid iron inner core. The fact that Venus has no intrinsic field suggests that it lacks this kind of geologic activity (though it does have an induced magnetosphere generated by the interaction of the solar wind with its atmosphere). For smaller bodies the presence of large amounts of iron, or other magnetically active elements can be inferred from magnetometer measurements.

For truly complex systems like Jupiter and Saturn magnetometers can be used to learn a great deal. They can give an estimate of how large the planets' cores are and how fast they are rotating. The composition and presence of subsurface activity on the larger moons can be studied with the magnetometer. They can also give us an idea of how a moon's thin (or thick in the case of Titan) atmosphere interacts with the parent planet.

Here is a look at Saturn's magnetosphere. The solar wind, coming from the right, pushes down on Saturn's magnetic field. A lot of interesting things get trapped in the region where the two meet, some of which was discussed in the RPWS post. You can also see where Titan passes through this soup of the magnetic field and all of the particles that get trapped within it.

Sometime soon, or not soon, I'll continue on with the other instruments.

Update (3/15/2015):

Magnetospheric Multiscale Observatories (MMS)

A really interesting launch happened a few days ago. The payload contains four identical satellites meant to orbit in formation and take very precise, high speed measurements of the Earth's magnetosphere. In particular, they are designed to study the points where the Earth's magnetic field reconnects; points where magnetic fields intersect and recombine after having been pushed around by the solar wind.

 

 

During two stages of its mission the satellite quartet will move into two elliptical orbits to intersect the points where magnetic reconnection occurs.

The actual instruments onboard are fairly similar to those described above and are present on many spacecraft. The primary difference is that there are so many of them. The instruments designed to monitor energetic particles usually rely on the spacecraft turning to get a complete view of the area; each MMS has multiple copies of each instrument (eight per craft in the case of the Fast Plasma Investigation instruments), which helps to give very rapid measurements covering the entire area.

 

 

Edited March 3, 2016 by DMagic
links

[enneract]

Any chance of seeing US Wedges for Materials bay and goo experiments?

[madmat]

That's a terrific write up for the magnetometer and magnetospheres DM. Great, now I've learned something today. Anyway, definitely worth my 400th post and some rep to boot. Great work on this mod too.

[DMagic]

Any chance of seeing US Wedges for Materials bay and goo experiments?

The chances are very good. Daishi is still working on making an empty US wedge, so I'm waiting for that before I continue. But I already have a rough outline for a goo pod and I plan on making wedges for the materials bay and the atmospheric sensor too.

That's a terrific write up for the magnetometer and magnetospheres DM. Great, now I've learned something today. Anyway, definitely worth my 400th post and some rep to boot. Great work on this mod too.

Thanks, it can be hard to figure some of this stuff out using things like Wikipedia. It tends to be either too complex or too vague to be of any real help. So I put together this and the RPWS chapter from a lot of different sources and hopefully condensed it all into something understandable.

[enneract]

And, do you have any plans on adding the 'hide structure' feature present on stock US parts to yours?

[DMagic]

And, do you have any plans on adding the 'hide structure' feature present on stock US parts to yours?

That animation is up to Daishi to implement (though I suppose it's probably possible to include on my end through a plugin), but even if it is included I might not use it. My parts don't quite fill in the space and would kind of awkwardly float if the outer wall wasn't there.

[enneract]

er, so adding the the same module animation configuration from one of the stock US parts would work on yours?

[Daishi]

er, so adding the the same module animation configuration from one of the stock US parts would work on yours?

If everything works, he should be able to use our SIM bay directly and embed his parts into it. Our animation plugin (Stupid_Chris's AdvancedAnimator, which gives more options and capabilities than the stock animation module) should continue to function from our directory and there shouldn't be extra things Dmagic needs to do.

The structure visibility toggle is only a 1 frame animation that scales things to 0%, and is set as "Take 002" in the wedges .mu file at the end of the clip. "Take 001" is the doors opening, so as long as Dmagics parts allow for a delay for that animation to finish, he should be able to merge his "Take 001" with mine easily. Once this SIM bay is finished we'll start testing this out properly

[enneract]

SIM stands for..?

[Daishi]

Scientific Instrument Module

In our case its going to be a small empty cargo bay where you can stash science sensors and equipment and retrieve data on EVA (if you want), and Dmagic is going to nest his models within it and keep them as stand-alone parts. You'll still require Universal Storage though (as it references assets), specifically the Core and KAS packs.

Edited May 18, 2014 by Daishi

[DMagic]

If everything works, he should be able to use our SIM bay directly and embed his parts into it. Our animation plugin (Stupid_Chris's AdvancedAnimator, which gives more options and capabilities than the stock animation module) should continue to function from our directory and there shouldn't be extra things Dmagic needs to do.

I've never used model {} nodes with animated parts before, but I don't believe that's how it works. I would create a new part.cfg that would refer to both your SIM bay mesh file and my mesh file for the interior parts. KSP should still be able to find the animations within each mesh file, but the animation node would need to be added to my part.cfg file. I'll have to see how my parts looks in the new wedge before I decide about adding that module.

[Daishi]

No worries, sorry that it's taking longer than expected :|

[DMagic]

No worries, sorry that it's taking longer than expected :|

That's fine. I have barely been working on this mod, and primarily on back-end stuff.

And by module I meant animation module, not the wedge. I'm sure I'll want to use the mesh itself.

[acc]

The duna atmosphere parameter is wrong. You set it to 50km, but the atmosphere starts at ~41.5km (exactly at 41.446km)

[DMagic]

The duna atmosphere parameter is wrong. You set it to 50km, but the atmosphere starts at ~41.5km (exactly at 41.446km)

How do you mean? Is something giving you "flying high" reports when you are still in space? The values I'm using for that should be coming straight out of the game, CelestialBody.maxAtmosphereAltitude, but it seems that might not be right. There is apparently another way of calculating the max altitude for some reason.

I'll look into it more.

[acc]

How do you mean? Is something giving you "flying high" reports when you are still in space? The values I'm using for that should be coming straight out of the game, CelestialBody.maxAtmosphereAltitude, but it seems that might not be right. There is apparently another way of calculating the max altitude for some reason.

I'll look into it more.

If the vessel is above 50km I get the "can't be used in atmosphere" message. but there is no atmosphere. Zero drag, nothing, stable orbit. And other instruments (stock and other mods) give still "in space near duna" outputs.

The orbit was PE 49 and AP 51km (SCANsat)

[DMagic]

Wow, the values are off by quite a bit in some cases.

The top values are from:

CelestialBody.maxAtmosphereAltitude

and the bottom values are from:

CelestialBody.atmosphereScaleHeight * 1000 * Math.Log(1e6)

which Anatid's documentation tells me is the accurate value for maximum altitude, and those numbers look right to me.

[LOG 11:57:37.790] [Kerbin Max Altitude] 70000
[LOG 11:57:37.790] [Kerbin Altitude Scale] 69077.5527898214
[LOG 11:57:37.791] [Eve Max Altitude] 90000
[LOG 11:57:37.791] [Eve Altitude Scale] 96708.5739057499
[LOG 11:57:37.792] [Duna Max Altitude] 50000
[LOG 11:57:37.793] [Duna Altitude Scale] 41446.5316738928
[LOG 11:57:37.793] [Jool Max Altitude] 200000
[LOG 11:57:37.794] [Jool Altitude Scale] 138155.105579643
[LOG 11:57:37.794] [Laythe Max Altitude] 50000
[LOG 11:57:37.795] [Laythe Altitude Scale] 55262.0422318571

I'll make sure to correct that in the next release, though I'm pretty sure I've seen other mods use a similar scheme to what I have, so you might want to watch out for this bug occurring elsewhere.