API Question HorizonRot inconsistency?

[fred18]

Hi all,

I'm experiencing something that I am not able to figure out.

Obiective:
I need to determine the eastward component of my velocity vector.

I am able to get the relative velocity of the ship in local vessel frame, so everything is fine up to his. Now my idea is to simply use HorizonRot to get and get the X component of the result.

But this does not work fine for me and I give you this example.

I am landed on a certain point of the planet (latitude 36.7°), pointing north.

My local speed vector has of course as expected only the X component, to the right: v=(373,0,0)

Then performing a HorizonRot on this vector, since I have only a eastward speed I expect to obtain a vector with only a X component, so the very same vector v=(373,0,0), but what I get is:

v= 359.7 , -97.06 , 0

How can this be possible? Y component is "up" as per orbiter api, but I am landed, so no "up" component should be present.

Thanks in advance for any help! :tiphat:

 

[Enjo]

Hello

It may be the velocity that is the inward velocity that pretends to keep your ship on ground.
Anyway this is the way I do it:

http://sourceforge.net/p/enjomitchsorbit/code/HEAD/tree/launchmfd/MovementParams.cpp
http://sourceforge.net/p/enjomitchsorbit/code/HEAD/tree/lib/Orbiter/SpaceMathOrbiter.cpp#l93
http://sourceforge.net/p/enjomitchsorbit/code/HEAD/tree/lib/Orbiter/SpaceMathOrbiter.cpp#l195

The current_vel variable is what you're looking for.

 

[RisingFury]

Obiective:
I need to determine the eastward component of my velocity vector.

GetHorizonVelocityVector() returns velocity where x+ is east, y+ is up and z+ is north.

 

[fred18]

Thank you very much for your replies! Enjo i will give it a try, as usual thank you very much for your availability!

@rising: there is only "gethorizonAirspeedVector" but airspeed is not what i am looking for, thank you anyway.

Anyway what i exposed above about the result it is totally impossible to understand for me... maybe there is something not clear in the horizonRot function... i don t know...

 

[RisingFury]

Thank you very much for your replies! Enjo i will give it a try, as usual thank you very much for your availability!

@rising: there is only "gethorizonAirspeedVector" but airspeed is not what i am looking for, thank you anyway.

Anyway what i exposed above about the result it is totally impossible to understand for me... maybe there is something not clear in the horizonRot function... i don t know...

GetHorizonAirspeedVector returns the velocity relative to the air as far as I understand. But because air rotates around the planet as the planet spins, an object stationary relative to the air will have a velocity of 0. If it's moving, however, you'll get the x component of the vector.

However, keep in mind that the planet does rotate and if you want that component of the velocity as well, you'll either have to calculate it (w * r * cos(latitude)) and subtract or go about it another way.

---------- Post added at 13:31 ---------- Previous post was at 13:24 ----------

Ok, I see that you want the rotation of the planet as well. One way is to calculate it manually and subtract it from GetHorizonAirspeedVector.

HorizonRot rotates from vessel local frame, where X is right, Y is up and Z is forward. You said you got the local vector, but its exact values are (373, 0, 0). From that I can only assume that your ship is level with the ground and pointing straight north.

If it's not, then you have not expressed the vector in vessel local coordinates - which is what I'm guessing happened here. Hod did you get the vector (373, 0, 0)? Maybe it's in planet's local coordinate system, not in vessel's...

---------- Post added at 13:40 ---------- Previous post was at 13:31 ----------

You could do this, but it's costly and might be numerically unstable:

Get planet's global velocity, get ship's global velocity.

Global detla velcoity = Planet's velocity - ship's velocity.

Get ship's global position.

Then call

oapiGlobalToLocal(Vessel's handle, &(Global position + Global delta velocity), &Local delta velocity)

You now have Local delta velocity, which is actually the velocity relative to the planet, expressed in vessel's local frame.

Then all you have to do is call HorizonRot on Local delta velocity to get it into horizontal frame. From there, the x component will express east/west velocity. If the vessel is just sitting on the planet's surface and the planet is rotating, it'll show some velocity.


Keep in mind that this way subtracts two very large numbers and adds a relatively small number to a large number, so that part might be numerically somewhat unstable. It should work fine in vicinity of Earth, but might start bugging out further out in the solar system. There might be a better way...

 

[fred18]

Thank you rising, You expressed the calculation that I am performing at the moment.

Anyway the thing is this:

HorizonRot rotates from vessel local frame, where X is right, Y is up and Z is forward. You said you got the local vector, but its exact values are (373, 0, 0). From that I can only assume that your ship is level with the ground and pointing straight north.

If it's not, then you have not expressed the vector in vessel local coordinates - which is what I'm guessing happened here. Hod did you get the vector (373, 0, 0)? Maybe it's in planet's local coordinate system, not in vessel's...

Yes, that is the problem. My vessel is landed and pointing straight north... and speed is in local vessel coordinates, i am 100% sure about this :

planet = GetSurfaceRef();
GetGlobalPos(glob_vpos);
GetRelativeVel(planet, glob_rvel);
Global2Local((glob_rvel + glob_vpos), loc_rvel);
 HorizonRot(loc_rvel, spd_vec2);

That is why I don't understand the result of horizonRot, it is non sense to me, it should be exactly the same.. 373,0,0... :beathead:

I managed to have the result anyway, but the output of horizon rot is not consistent with what it should be

 

[Enjo]

Thank you very much for your replies! Enjo i will give it a try, as usual thank you very much for your availability!

Happy to help whenever I can.

May I know what is the theme of this experiment? Because if you're making a test bed for yor multistage PEG, then I have a placeholder for this in Launch MFD already, so you could simply plug it in...

 

[RisingFury]

Well, snap! Then I don't know where it's going wrong...


You can always try this:

GetEquPos(Position.x, Position.z, Position.y)
GetHorizonAirspeedVector(Airspeed)

Airspeed.x - 2 * PI * Position.y * cos(Position.z) / oapiGetPlanetPeriod(PlanetHandle)

But make sure to check for oapiGetPlanetPeriod being 0, you don't want to break the universe.

Also keep in mind that currently GetHorizonAirspeedVector works fine because there are no winds in Orbiter 2010. But the next release implements winds and a new function will be introduced that gives the same functionality as GetHorizonAirspeedVector does now.

 

[fred18]

Happy to help whenever I can.

May I know what is the theme of this experiment? Because if you're making a test bed for yor multistage PEG, then I have a placeholder for this in Launch MFD already, so you could simply plug it in...

I am trying to refine a bit the inclination control of my launcher. Even if I launch with the perfect azimuth and if i follow the ideal azimuth for all the powered ascent I get an error between 0.1 and 0.25 degrees, still don't know exactly why.

About the Multistage PEG I recently made it work! but the code is still a lot messy, since I did a lot of trial and errors on it.

My idea is to describe in the thread I opened some weeks ago the full details of the algorithm I used, and to release later on, when the it has been cleaned and is understandable.

Actually I have to say that the multistage PEG is very "rocket specific", because to perform the calculation correctly you have to know in advance some characteristics of the next stage (typical full and empty mass, isp and thrust), so not easy to implement it in the launch mfd, unless make the user input those characteristics manually before launching!

anyway in the next days I will propose the full algorithm!

 

[Enjo]

Thanks! You're my hero! There have been no real advances in this field here for nearly 5 years.

I am trying to refine a bit the inclination control of my launcher. Even if I launch with the perfect azimuth and if i follow the ideal azimuth for all the powered ascent I get an error between 0.1 and 0.25 degrees, still don't know exactly why.

Check the equatorial LAN difference upon insertion. I bet this is it. In Launch MFD we use "OffPlane Corrector" to fix this.

Actually I have to say that the multistage PEG is very "rocket specific", because to perform the calculation correctly you have to know in advance some characteristics of the next stage (typical full and empty mass, isp and thrust), so not easy to implement it in the launch mfd, unless make the user input those characteristics manually before launching!

This system is already present in Launch MFD, but it has been deactivated, since I halted the MultiPEG development. I'm able to detect staging and note the ISP, mass and total stage's thrust, which I push onto an array of stages and save to file, which is then a base for calculations for the next launch. So basically, not to have to input the values manually, you can perform one test launch to get the values, and then restart the sim and launch for real. The previous values will then be used and will be corrected. After you're satisfied, you can persist them in an another file, so the dynamic ones will be ignored.
But of course, if you prefer doing it your own way, then I'm fine with it. I'm a better programmer than mathematician, so I'll have no problem adapting your hard work to a system that I know very well.

 

[fred18]

This system is already present in Launch MFD, but it has been deactivated, since I halted the MultiPEG development. I'm able to detect staging and note the ISP, mass and total stage's thrust, which I push onto an array of stages and save to file, which is then a base for calculations for the next launch. So basically, not to have to input the values manually, you can perform one test launch to get the values, and then restart the sim and launch for real. The previous values will then be used and will be corrected. After you're satisfied, you can persist them in an another file, so the dynamic ones will be ignored.
But of course, if you prefer doing it your own way, then I'm fine with it. I'm a better programmer than mathematician, so I'll have no problem adapting your hard work to a system that I know very well.

That's brilliant solution! well actually I am way better on math than in programming, since i learnt the basics of c++ only for developing in orbiter :lol:
let's put our best skills together then, I will post the entire algorithm with all explanations within this week :thumbup: