New Release Interplanetary Modular Spacecraft RC9

[PeterRoss]

In any case, if symmetry axes of the vessel can be not just shifted but rotated as well the whole symetry check makes no sense at all. We could have used engine axis as symmetry axis but then again we have four different engine groups... I could think out two solutions: either make symmetry check to work around all three axes relative to last calculated COG independently from each other (I can't imagine results, I guess I just have to try and see what will come out of it), or just clip symmetry check and then round results down to a COG with some hand-picked inaccuracy coeffitient.

 

[Furet]

...that would require some intelligence to detect an axis of symmetry completely dynamicaly.

I’m just raving, but could it be possible to do it manually ? I mean, would it be possible to manually override the CM by choosing another module as reference for the symmetry code (or maybe several modules from stern to bow)?

 

[PeterRoss]

I’m just raving, but could it be possible to do it manually ? I mean, would it be possible to manually override the CM by choosing another module as reference for the symmetry code (or maybe several modules from stern to bow)?

I'm afraid it's impossible because of the CG recalculating mechanism used by IMS. Don't worry, we will find a fix for it eventually

 

[Furet]

I'm afraid it's impossible because of the CG recalculating mechanism used by IMS.

I'm not surprised. I was just dreaming about further IMS design possibilities. :lol:

Don't worry, we will find a fix for it eventually

 

[jedidia]

I'm afraid it's impossible because of the CG recalculating mechanism used by IMS. Don't worry, we will find a fix for it eventually

The axis on which to check for symmetry could be set manually, that wouldn't be that big of a deal. The only reason it defaults to the z-axis along the CM is that because most often this is the case, and anything else would require some rather intensive analysis of the construction to find the optimal axis. since CG update happens every 10 seconds, this wouldn't be very healthy...

However: we could step the whole thing up by an order. Earlier we had CG re-calculation on integration, and then saved the CG to file. This led to appreciable errors due to double inprecision over time, since the CG was only modified incrementally instead of set from an absolute zero (which is a bad Idea, as every toolmaker ought to know).
So I changed it to recalculate the CG completely from scratch every time it needed to be modified. Nothing saved in the scenario at all, and as a bonus it allowed for CG shifts due to propellant consumption, which is a nice detail.

So here's the logical next step: Have a function that looks for the optimum axis of symmetry (that should be quite an interesting algorithm, he...) that runs only on integration and simulation start, to keep the number crunching down, and then just use that axis as axis of symmetry during the regular CoG updates.
Alternatively/additionally, the axis could be set manually. It wouldn't be very hard to code, but it might be a bit confusing for users if they have to set it manually...

 

[PeterRoss]

The axis on which to check for symmetry could be set manually, that wouldn't be that big of a deal.

Well, yeah, I was thinking rather about universal solution and, I'm afraid, I took that question in my own context. I just want it to work by itself. The need to set touchdown points manually is the bad thing already.

However: we could step the whole thing up by an order. Earlier we had CG re-calculation on integration, and then saved the CG to file. This led to appreciable errors due to double inprecision over time, since the CG was only modified incrementally instead of set from an absolute zero (which is a bad Idea, as every toolmaker ought to know).
So I changed it to recalculate the CG completely from scratch every time it needed to be modified. Nothing saved in the scenario at all, and as a bonus it allowed for CG shifts due to propellant consumption, which is a nice detail.

Little remark here: we do save CG (to be precise - CG shift relative to absolute zero i.e. CM mass center) into scenario file now. It is needed for CG not to be calculated before the first frame. Otherwise it works just as you described.

So here's the logical next step: Have a function that looks for the optimum axis of symmetry (that should be quite an interesting algorithm, he...) that runs only on integration and simulation start, to keep the number crunching down, and then just use that axis as axis of symmetry during the regular CoG updates.

Algorithm like this is way out of my league. Do you have any proposals about its logic?

 

[jedidia]

Algorithm like this is way out of my league.

Well, the nice thing with algorithms like that is that you don't have to be a code whiz. You won't need more than some loops and conditions. The difficult thing is to wrap your head around what the computer should actually do...

A simple solution which I'd expect to work in most cases would be:

1. calculate position of CG without symmetry.

2. From that point, check for symmetrically placed modules in all three axes. The axis with most modules in symmetry wins.

3. Symmetry axis is then the axis you got from step two, crossing the CoG from step one. Set axis, and in future recalculate CoG with that axis as symmetry axis. Repeat search for symmetry axis if the vessel structure changes (i.e. a new module is added).

I figure this should work most of the time, but we'll probably get some cases where it fails miserably, although I cannot quite conceive them currently. Expierience tells me there's always something you didn't think of beforehand, although a spacecraft where the axis of symmetry does not go through the mass center seems a bit stupid. Someone might come up with a symmetry that is not perpendicular to one of the three principal axes, then the algorithm would fail, but the worst thing that could happen would be that you don't calculate symmetry if you don't get an axis with at least two modules in symmetry...

 

[Furet]

2. From that point, check for symmetrically placed modules in all three axes. The axis with most modules in symmetry wins.

Could be cross-checked with the current thruster group (or at least group number 1)?

 

[jedidia]

Could be cross-checked with the current thruster group (or at least group number 1)?

Could be, but it wouldn't make much sense. If the thrusters are aligned symmetricaly, they will figure into the calculation anyways. This operation would not in any way influence the actual alignement of the vessel. It's merely a helper to improve the precision of the CG calculation, because if you just add and substract the module's masscenters times mass to find the center, you can get errors in the range of some centimeters with larger vessels even if they should be perfectly symmetrical, which is enough to get really annoying in longer burns at some time acceleration.

The symmetry check does nothing else but not figure modules that are symmetrical to an axis (with a small tolerance for the double imprecision, otherwise we'd never get any symmetry at all) into the calculation for the other two axes, which results in the CoG being spot on on the axis of symmetry if the vessel is built symmetricaly.

The modifications suggested above would merely mean that this symmetry axis doesn't necessarily have to be the z-axis, and that the CoG doesn't have to go through the CM for it to work. The Z-axis of the vessel would still be the Z-axis, no matter where your symmetry axis lies.
In real life, you'd have such minimal deviances from the CoG too, actually, due to reality being notoriously imprecise, but there you don't have to deal with time acceleration either. The whole thing is really more of a user convienience.

 

[PeterRoss]

...due to reality being notoriously imprecise, but there you don't have to deal with time acceleration either.

I hear Einstein rolling over in his grave :lol:

 

[jedidia]

It just occured to me that the above algorithm is lacking an important step, to be inserted after step 2.

In step one, you will get a CoG with some error, which is the point of having a symmetry axis at all.
In step 2, you check for symmetry with some tolerance, to account for that error.

So after that, you have to calculate the center between the modules recognised as symmetrical to correct the initial CoG in the two axes that are not the symmetry axis. Something like taking the first two modules in symmetry, and calculate their center. Take the next two, calculate their center, aso. In the end, the final CoG through which the symmetry axis has to run is the average of those values.

 

[Urwumpe]

What about calculating an inertia tensor? This way you can solve the problem of which axis is symmetric and the CoG off-balance in one pass...

 

[jedidia]

Sounds good, but I had to look up what an inertia tensor is and don't understand it even after looking it up :lol:

 

[Urwumpe]

Sounds good, but I had to look up what an inertia tensor is and don't understand it even after looking it up :lol:

:lol: It is what Orbiter creates with the PMI. The tensor essentially describes how a spacecraft would rotate.

By calculating the full version of it, instead of the diagonal vector that Orbiter uses, you can also get information about symmetries and off-balance CoG.

 

[Hlynkacg]

:lol: It is what Orbiter creates with the PMI. The tensor essentially describes how a spacecraft would rotate.

By calculating the full version of it, instead of the diagonal vector that Orbiter uses, you can also get information about symmetries and off-balance CoG.

Slightly off topic but if I already have the full 3x3 tensor matrix how do I convert it to an orbiter format PMI?

 

[BruceJohnJennerLawso]

Slightly off topic but if I already have the full 3x3 tensor matrix how do I convert it to an orbiter format PMI?

Not sure, but if you watch shipedit do its calculations, it seems to be doing just that. It looks an awful lot like normal matrix operations, just trying to get to RREF, but harder since it goes into decimals & stuff

 

[astrosammy]

Slightly off topic but if I already have the full 3x3 tensor matrix how do I convert it to an orbiter format PMI?

It's quite easy: http://www.orbiter-forum.com/showthread.php?t=14805

 

[BruceJohnJennerLawso]

IMS has been completely quiet for too long :facts:

Unfortunately, my current situation in life has left me with very little room for free time (or anything else). I do have a start into an orbital asembly dock orbiting the habitable planet in the UPS-A system.

 

[PeterRoss]

I'm working on making my summer house a habitable place currently, no time for doing anything any more intellectual. Now I can only use Orbiter as a game - fly Arrow from the Moon to Earth and back, load an XR5 with some containers by a gantry crane and so on. One day I'll be ready to work on IMS again.

 

[BruceJohnJennerLawso]

I'm working on making my summer house a habitable place currently, no time for doing anything any more intellectual. Now I can only use Orbiter as a game - fly Arrow from the Moon to Earth and back, load an XR5 with some containers by a gantry crane and so on. One day I'll be ready to work on IMS again.

Well, Im nearly halfway through my programming tutorial, I suppose I can work on the source solo. Is there anything you could flag for me to look at/work on?