Find Planet Center

Threw this together because I needed the planet center coordinates for something else I'm working on.

For it to work you need a remote control and text panel (and a programmable block, obviously).

Run the PB with the following arguments:
1) "sample" takes a gravity measurement at the current location (using the first remote control it finds)
2) "calc" calculates the center point using all the samples taken so far and writes GPS coordinates into the first text panel it finds
3) "reset" clears the stored list of samples

Two samples is enough for an estimate, but taking more is better. I personally set a timer to take samples every one sec then flew around. You need some separation between samples to get a good estimate, 1km will work, but 10km would be better (for a large planet). Also, it's best if the points aren't all in a straight line. For example you could fly 5km straight, then turn 45deg and fly another 5km (taking samples along the way).

I'm not officially releasing this code because it has a few issues. There's no error checking and it can sometimes exceed the script complexity limit. If anyone wants to clean this up (or chop out pieces) and make an official release, feel free.

Then, without further ado:

 

Wouldn't a sensor retrieve the centre of the planet in Sensor.LastDetectedEntity? I haven't checked though.

 

It might, I haven't tried either. But of course, that would only work if your within 50m of the planet

 

Good stuff.
One could reduce the complexity of the code by removing unnecessary sample points: those that are too close to each other. Actually it would be good to have gravity vectors to have an angle as near as 90° between each other (using a simple dot-product). Then, you can cap the number of samples to something like 10.
That would still bring a precise result.

 

Actually, i've noticed, that even 1% angle is enough to calculate planet center by intersection of 2 gravity vectors with ~1m error. Acceptable for planet-size object.

 

I tried this a week or two ago as it seemed the easiest way to get the center coords when launching a missile from the ground, but it gave me some coords 500 m away up in the sky somewhere. Unlike asteroids, i think planets consist of many voxel chunks that each have their own center coords that are given by LastDetectedEntity. It's a shame. Would have been an easy solution.

 

Nice I was thinking of doing something just like this lol

 

Even asteroids have this problem. The coordinate is the 'spawn' point. The actual formation of the asteroid is determined by randomly performing a set of voxel 'actions' on the area around the 'spawn'. Some of these operations are symetric (think the donut asteroids), but many are not (the hole blown through the side).

I've seen many large asteroids where the 'position' was way off to one side of the actual mass of the asteroid.

For small asteroids, the 'position' is still not always the exact center; but it's a minor error compared to large asteroids.

 

Makes sense. Using incredibly inaccurate tools, Eratosthenes did the same kind of math and estimated the circumference of the Earth way back around 200 BC, without leaving Egypt (small change in angle). Finding the center is a simpler problem, and we have super-accurate measurement of position and gravity. With precise measurements of position and the gravity vector, it should be easy to find a planet's center without having to travel very far - basically just enough to compensate for the rounding issues.

 

I wonder, if anyone can repeat Al Biruni measurement of Earth radius in SE

 

That's exactly right

Pennywise came up with the math required for this as well. As far as I understand it now, it is basically finding the the "closest point of approach" of the two gravity vectors to find their "intersection" (or near intersection, due to inaccuracies). You don't really need more than two samples, as long as they are a reasonable distance apart.

I realize now that I used this kind of math before to find the intersection of two turret-vectors aiming at the same target. It is exactly the same math, basically just triangulation. There are some versions of this on the forum as well I think.

Check here for Pennywise's compass and gps tool.
The part that pertains to this thread is on the bottom of the 2nd page.

The TargetGPS method mentioned in his thread is exactly what you are talking about, but as I said, it is not the only one on the forum. There are many "triangulation" scripts. Some are made to triangulate with turrets, some with a camera and ship-movement. All of these use the same steps as you use when triangulating with two gravity vectors. Not all are equally efficient CPU-wise though.

 

How do you access the gravity vector?

 

RemoteControl.GetNaturalGravity();