[API Question] precision of ShiftCOG?

[jedidia]

I started to tackle one of the few problems that plague the IMS core mechanics, which is inprecisions in module integration. Here's how it works:

Modules are attached to te main body of the vessel, and when integrated, I read and convert their relative possitions, direction and rotation, delete the old vessel and instead do an addMesh on the received position and a MeshGroupTransform to fix the alignement. It all works very nice up to this point. Then I shift the COG to reflect the new arrangement, and stuff starts getting weird. It all works well enough for perpendicularly aligned stuff, but anything at an angle gets slowly but surely in trouble. The longer you build, the more trouble you get.

The attachement points, modified by ShiftCOG, start to get out of position, and with them do of course the attached modules. If I integrate four modules of the same type symmetrically around a center at 45 degree angles, the position of the last one is 6 glorious centimeters out in the X axis, and 2 in the y axis. If I don't do ShiftCOG, the positions are all perfect.

Knowing about the problems that can arise from incrementaly modifying a double over and over again I modified the initial incremental COGshift to something more absolute and wrote a function that would reset the COG to its original position before going on to calculate the new cog based on the module's positions and masses. It even has a slight bit of smart built in that does not modify the COG for modules that are in symmetrical positions and with equal mass. It works pretty nicely, and my COG is rock-stable now.
However, the modules position on integration, and by implication the position of the attachment points, still are not. Indeed, going from this, I did not calculate any COG shift, but simply shifted the COG back and forth by a fixed vector (1,1,5) after every integration, and the inprecision was the same in the end.
Does ShiftCOG do any rounding, are the positions of the attachment points rounded, or is this just a result of the usual inprecisions that happens when adding doubles together? I don't quite see how that could reach an error of 0.06 in only four operations, really. Does anybody have a suggestion how to solve this problem?

[N_Molson]

Personally, I had so much difficulties with ShiftCoG that I gave up. And I've read over there that a lot of people have troubles with it too. There is something wrong or maybe imprecise, as you say, with that function.

I hope it will be enhanced in the next release

---------- Post added at 10:11 AM ---------- Previous post was at 10:01 AM ----------

You might be interested in reading that thread :

http://orbiter-forum.com/showthread.php?t=22907&highlight=Center+of+Mass

That ended with an official bug report on ShiftCG()

[jedidia]

I dealt with the missing features advertised in the docummentation, those are not the problem...

I've made a bit of progress, using shiftCenterOfMass, shiftMeshes and a custom function for the attachment points and docking ports to get better Control and an Idea of what is going on. It seems that shiftCOG isn't the culprit, as I first assumed.

The conversion from global to local coordinates is.

The modules are in perfect position on attachment now.
I took the position and converted it to vessel local coordinates right after attachment, and it reads

		x	3.2354027535797005	double
		y	-3.2354035749994448	double
		z	-5.4570845015016136	double

Then I read the position again right before integration:

		x	3.2561084011027539	double
		y	-3.2354035749982724	double
		z	-7.2760928941958074	double

That's twenty-one milimeters right there in the X axis. In case you wonder where the discrepancy in Z comes from, that is perfectly explainable: The attachment happens in the current center of gravity, for the integration the center of gravity is reset to its origin position, which currently reads:

		x	0.00000000000000000	double
		y	0.00000000000000000	double
		z	-1.8190249999999999	double

There is a slight inprecision in the z-axis from the shift, but that is bearable. X and Y haven't been modified.

I think I found the reason for this, here's the global position of the vessel:

		x	-148531568613.16550	double
		y	20976436.501225375	double
		z	14796160455.381121	double

There's only 5 digits available in x, while there's plenty more in y and z. I think that this leads to the large conversion error in the x axis when converting from global to local coordinates. Is that possible?

If it is, then the ultimate question would be:
How does Orbiter do it? The orbiter core has no problem whatsoever with vessel placement at this distance. Attached and docked modules are placed just fine, so it has to be possible to obtain an exact position relative to my vessel. Does anyone have an Idea how? Martin?
Or am I on the wrong track alltogether?

EDIT: Could still be a combination of factors. The error does get larger if center of gravity shifts are involved, but it's also there without it. I'll need a method to pin down those local positions more accurately. milimeter-precision at least, and even without cog shifting it's barely within a centimeter.

[martins]

The global to local conversion is given by L = R^T (G-Gs), where G is a global point, Gs is the object's global position, R is the rotation matrix, and L is the resulting local point.

The loss of precision occurs at the subtraction G-Gs. At Earth's distance from the global origin, you lose about 11 significant digits. But with IEEE floating point arithmetic (52 base-2 digits in the mantissa ~ 16 decimal digits), you should still have about 5 digits left, i.e. sub-millimetre precision. So a single local to global conversion shouldn't give you the amount of error you see, unless you do repeated backwards and forwards mappings and accumulate rounding errors.

[jedidia]

Quote:

So a single local to global conversion shouldn't give you the amount of error you see, unless you do repeated backwards and forwards mappings and accumulate rounding errors.

No, I'm not doing that... this is getting weird. Where on earth is that error hiding?

---------- Post added at 04:00 PM ---------- Previous post was at 02:11 PM ----------

Ok, moving on.

Testcase was four modules of the same type attached around a center at 45 degrees relative angle.

Procedure went like this: Attach module, get global position, convert to vessel relative.
In a later step before integration, get modules global position, convert to vessel relative.
Compare to previous position.
Correct new position for CoG, compare with CoG.

I can make three definite statements out of this experiment:

1. error on CoG shift is negligible, usually in the last one or two digits.
2. error from coordinate conversion starts at the sixth digit. Not a problem.
3. There is a consistent error of 0.00687 between the first relative position at attachment and the second reading before integration in both x and y axes.

As far as I can see, no modification to either the vessel or the attachment point is made during the time in between. So where on earth could such a consistent deviation come from??

---------- Post added at 06:57 PM ---------- Previous post was at 04:00 PM ----------

Interesting. It seems to have gone away, and I'm not sure why... Good riddance in any case. Seems to be working nicely now.

[jedidia]

HA! know what happened!

The readings resulted from a combination of factors: First I use attachment points and docking ports simultaniously. Docking ports because they can be put together easily by the scenario editor, attachments for identification.

I did not know until now how orbiter handles that potentialy problematic duality, but saw that it didn't cause any trouble. Well, now I know more.
It seems that orbiter only gets the position of the docking port/attachment point at the moment of attaching/docking, or when the points were updated, calculates and saves the relative position of the vessel and does not recalculate for future use. Makes a lot of sense, one less operation in the loop.
For me, this comes down to meaning that the position is relative to whatever was modified last, attachment or dock. So if the two didn't match exactly, there would be a difference between the vessel's position.

I undock all modules from the module to be integrated right at the beginning of the integration process. Although usually nothing gets undocked, this call resets the position to the docking port. And there was an error in my test scenario of 0.00687 between attachment points and docking ports in my scenario. The error disapeared when I loaded an earlier scenario and repeated the step of copying the attachment points/docking ports. In other words, I fixed the actual error some time ago, but didn't notice it because the error happened a lot earlier in the process than I expected