[0.17] Multiversal Mechatronics - Munolith Research Division - 1.3

[Nibb31]

There is no light on the short range device. That\'s part of the fun

[noneyabidnis]

So, I\'ve seen some prior attempts at math, but I wanted to give it a go myself and then check my own findings against the ones here. I haven\'t looked at a math problem in 15 years, so the past few evenings were spent refreshing myself on a bit of geometry.

Note that this all should work if the large detector is a sphere with a 150km radius. I assume that\'s how it works, but it would be good if someone could confirm. I approached the problem from an 'intersection of spheres' angle. Further, I used two completely different methods to cross check, and the results were exact down to the meter, and then the rest was rounding error.

The first approach is pretty easy. First, it\'s to determine the distance from the midpoint of the moon to the mid-point of the chord (the imaginary line / plane drawn through the spot where the two spheres intersect). After determining the distance from the chord to the center of the moon, I then plugged it into a calculator I found online and let it do the rest. http://www.easysurf.cc/circle.htm#cltorccc (Calculate Chord Length given radius and circle center to chord midpoint distance)

To get the distance to the chord from center of moon, use the following:

(combined distance of altitude and moon\'s radius)² - (radius of detector)² + (radius of Mun)²

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

2 x (combined distance of altitude and moon\'s radius)

If my altitude was 70 KM, it would look like this:

270² - 150² + 200²

--------------------------------------------------------------------

2 x 270

The result is: 90400 / 540, or 167.407 km.

Next, I take that number and plug it into the 'Calculate Chord Length given radius and circle center to chord midpoint distance' calculation here:

http://www.easysurf.cc/circle.htm#cltorccc

Radius = 200

Distance to chord = 167.407

This returns 218.86. Divide in half to get the radius, which would be 109.430.

So, at 70 KM circular orbit around the Mun, the effective range on the surface of the Mun is 109.43KM in every direction.

Now, there\'s another formula that\'s a bit more complicated, but doesn\'t use a magic calculator to get the answer. Perhaps the magic calculator uses the same formula - I don\'t know. I doubt it - I\'m not very bright and the magic calculator looks like someone pretty bright made it.

Note, in order to simplify, 'd' will be the combined distance of moon\'s radius and altitude.

(1\(2*d)) x [(-d + detect radius - mun radius) x (-d - detect radius + mun radius) x (-d + detect radius + mun radius) x (d+ detect radius + mun radius)]^1/2

Example at 70KM circular orbit:

(1\(2x270)) x [(-270 + 150 - 200) x (-270 - 150 + 200) x (-270 + 150 + 200) x (270 + 150 + 200)]^1/2

Which is:

(1\540) x [(-320) x (-220) x (80) x (620)]^1/2

.00185 x 3,491,840,000^1/2

.00185185185185185185... x 59,091.8 = 109.429

So, while in a 70KM circular orbit around the Mun, the detector will have 109.429 KM of coverage in any given direction on the ground.

Is there anyone on these forums that is is good with math like this? If so, am I on the right track?

Next, I want to figure out the optimal orbit to ensure the least amount of overlap on each pass. That may be hard to do on the Mun give it\'s slow rotation, but the equations should work just as well for Kerbin. And perhaps someone who\'s good at making calculators could whip something up quickly that lets you plug in your altitude on Mun or Kerbin, and it quickly returns ground coverage. Alternatively, I might have good enough skills with Excel or SQL to create a table of values - perhaps incremented in each 1KM of altitude.

Thanks for taking the time to read (if you managed to get this far. ;D).

[Muka]

@noneyabidnis Just look at My reply at page 3. All math is done there if You want to compare

[noneyabidnis]

@noneyabidnis Just look at My reply at page 3. All math is done there if You want to compare

Hi Muka,

Yes, I did the math in your reply, however, the conclusions were fairly far apart. So, who is closer?

[Zephram Kerman]

I did originally set out to use carts however I\'m pretty impatient; I kept taking off at 50m/s and spiralling back into the ground with a very Kerbal firework show. So I switched to a hovering lander. No terrain worries as with the cart and you can traverse the surface much faster than on wheels; great if you lack the patience to trundle along the surface.

Your method of location is essentially the same as mine... establish a baseline then head off on a normal course from it til you hit paydirt.

\'Great minds...\'

Albatross included a MechJeb, which helped a lot with stability. All I did was put it in Surface mode, any random heading with pitch 90° or so. Any time we hit a bump and went flying, it usually straightened out before it came back down. Although it did frequently require some manual piloting. My cart also included some RCS thrusters, which was very handy for hopping over (or down into) steep spots. I\'ve since made a more powerful version for Kerbin that has two small LFE instead of the RCS.

So it\'s basically a wheeled lander with autopilot and the large muon detector.

[Excalibur]

Albatross included a MechJeb, which helped a lot with stability. All I did was put it in Surface mode, any random heading with pitch 90° or so. Any time we hit a bump and went flying, it usually straightened out before it came back down. Although it did frequently require some manual piloting. My cart also included some RCS thrusters, which was very handy for hopping over (or down into) steep spots. I\'ve since made a more powerful version for Kerbin that has two small LFE instead of the RCS.

So it\'s basically a wheeled lander with autopilot and the large muon detector.

Even with MechJeb or strong SAS I find a good portion of my rovers are pretty unstable so I never even considered SURF. Always assumed it would only be good for atmospheric flight. Guess I need to think outside the box a little more...

That\'s why I like the forums so much though - such a good collection of brilliant ideas.

Oh and a quick question... do you know if MechJeb can make use of SAS modules? Or does it only use active control systems (i.e. RCS)?

[Kreuzung]

I think so, it whould explain the pod stability magic. I also sometimes read 'MechJeb resetting PID controller' on the console, which could also mean that SAS is involved. Just try it out.

[Excalibur]

I\'ve thought so too in the past but if you have say just a MechJeb and a pod in orbit, functions like KILLROT seem rather weak giving me some doubts. I guess it\'s just a balance issue then.

[Kreuzung]

Pod SAS is not that strong compared to a SAS module and it lacks the I in PID, whatever that means, search the wiki for SAS ;P

[Zephram Kerman]

Pod + MechJeb helped, but only just a little. I think it\'s because MechJeb takes a little while to think about what should be done. It\'s even slower-witted than I am! So I still had to use F9 a lot.

[Alchemist]

My version about how to find a munolith. Requirement: heavy lander with the large detector and enough fuel for long hovering (separate return stage recommended to ensure you don\'t lose your crew because of not enough fuel left after the maneuvers).

1) You should approximately know the region. You can spend one lander for orbital search with multiple plane changes. Find an orbit where the signal gets strong and note approximately the place where the light turns red. If you spent much fuel, send the next lander in a low orbit that approximately passes over the place. If you feel confident that this lander can do an attempt you can use it for the next step.

2) On the first orbit note the exact place where the light turns red. Just note the coordinates on mechjeb surface information if you use it.

3) On the next orbit initiate breaking burn so that you will end in that place. If you fly over get some horizontal speed in reverse direction, if you didn\'t reached the place leave some horizontal speed. Gently hover to the place where the light turns red and kill all your H-speed. Now get some speed in perpendicular direction (don\'t forget to zero the vertical speed!) and note if you get closer (green light - continue in this direction) or fly away (red light - turn opposite!).

4) Now when you fly in the direction of the target it\'s time to estimate the distance. Start gaining vertical speed until the light turns red. Wait a bit for the light to turn green again (for more precision) and note the direction of your propagation (on the navball on compare vertical and horizontal speed) the target is in the same vertical plane in direction perpendicular to your velocity - look at this direction and estimate the place. Switch to the map and adjust your ballistic trajectory to lead you there.

5) At the place kill your speed and start hovering at low altitude. You can pinpoint the 2 axis independently or use the tactics mentioned several posts ago to get the direction at once. You can also use the distance estimation technique (just don\'t get too fast this time). When the light changes it\'s color get lower and proceed in perpendicular direction (or try to pinpoint the direction precisely) until you see the munolith. But watch your fuel!

6) If the lander fuel is too low to continue hovering longer (but it must be enough for landing - don\'t spend it to the last droplet) land immidiately where you are! Then use this lander as the target (You know how to do precise landings, don\'t you?) for the next one to get there (don\'t land, just hover above the previous) and start search from that place.

7) When you see the thing (it\'s so small that you will need to get in several hundreds meters of it) use your skills to land at it!

8) Now you can return the missed landers home and send your research vessels (if you didn\'t install the equipment on the searcher landers) to the target marked by the last lander.

[r4m0n]

Updated to 1.1, just making it work with KSP 0.15.

[sgtblazing]

Havent the time to try it atm, but any Munoliths on the new moon?

[OldReliable]

Does the Muon detector detect the Mun arches as well as Munoliths?

[Tosh]

Does the Muon detector detect the Mun arches as well as Munoliths?

Yep, it does.

[OldReliable]

I see, I was wondering. I seem to have found an underground Mun arch. I was confused for a while until I slipped my view under the surface.

[Kreuzung]

Tosh already reported that bug.

[GenJeFT]

Finally, its like doing real science.

[G Addict]

I\'ve got a weird issue with the long range detector. On rovers (on kerbin at least), the red/green light has been working fine (though I\'m apparently both an idiot and blind so haven\'t even found whatever it is near the KSC), but on my satellites orbiting the mun I haven\'t been seeing the light. I\'ve got one orbiting at 20km, another at 15km and one at 12km, and I haven\'t been able to see the light on any of them. One of them still helped me to spot an arch, but that\'s no help for the smaller munoliths. Do I have to have a certain graphics setting?

[Nibb31]

You have to be in time warp x1 or x2.

[G Addict]

That\'s the thing - I have been. Do you have to\'ve been in 1 or 2x timewarp for your whole journey? Doubt it, since it\'d be really boring waiting for your ship to get up there but nothing I try seems to fix it. Might be relevant that the detector starts out inside a cuttlefish lander, so is obscured initially? I\'ll try fiddling with my graphics settings, since I doubt it\'s the fault of the plugin...

EDIT: I just took some screens of one of the sats as it passes over the location of an arch. The first one shows the satellite with a rover stationed at the arch being the pink target. The satellite is moving away from the rover. The second screen is the complete lack of red light (or any light) on the scanner a few seconds later. In both cases the time warp was not active.

EDIT again: Aha! I\'ve found the cause. If the Muon Scanner is obscured at launch (like in the ship I posted, with the cargo pod holding it), the light does not work. Odd, but pretty obvious now I think about it. Just wish I\'d realised BEFORE putting three of those sats into orbit around the Mun. :

[Magnus]

Um.... What is a munolith? =P

[lordgiza]

Well, when travelling at relativistic speeds they can live 'long' enough to travel long distances and to be detected. =P

Actually traveling at the speed of light if the particle only exists for 0.000002 seconds it will only travel 599.584916 metres or so. Simple math makes it easy.

[zekes]

Isn\'t there a better way to do the detection?

I feel like Im on a ww1 sub blindly pinging..

[maltesh]

Actually traveling at the speed of light if the particle only exists for 0.000002 seconds it will only travel 599.584916 metres or so. Simple math makes it easy.

You\'re forgetting about two things:

1. Relativistic time dilation. The faster you go relative to an observer, the slower the observer sees time passing for you, and vice versa. So an observer seeing an event occur that normally lasts onlyh 0.000002 seconds can see it taking much longer, if it is moving very very close to the speed of light relative to him. Relativistic Length Contraction, and the inviolate speed of light make it self-consistent, and the equations basically fall out nothing more complicated than algebra.

2. A half-life isn\'t a determinate lifespan. It\'s a statement of probability. An event with a half-life of 0.000002 seconds has a 50% chance of occurring before 0.000002 seconds have gone by, a 75% chance of occurring before 0.000004 seconds have gone by, and so on. It is possible, though ridiculously unlikely, that a muon could sit around for 12 billion years without decaying.