Jump to content

Sign in to follow this  
[frl]myke

Help with vector calculations

Recommended Posts

Hi all,

as i'm really no good in vector calulations *cough*....means i really don't understand those, i would need some help from a math guru with a very special vector calculating problem.

Situation:

I have 2 known positions, POS1 and POS2. These are connected with a imaginary line, same way as waypoints in editor are presented. I'm not talking of editorwaypoints here, just for easier imagination.

As last reference point, i have my own position which might be somewhere but probably not on the imaginary line.

The formula (not script, once i have the formula i might be able to wrap myself a script around it) i need is how do i determine on which side of the imaginary line my actual position is.

Say i'm looking from POS1 along the line to POS2, is the investigated position left or right of the imaginary line and how far away from it.

And as a second formula, how is the formula to determine my relative heading to this line. So let's assume the line has a compass heading straight north, also i am looking straight north so relative difference in heading would be +-0. How would a formuly for this purpose look like?

As said, i don't need it scripted "ready-to-use", just a formula which ArmA 2 will understand and which i can wrap a script around it.

And please, keep your explanation as simple as possible, as you would explain it to a 3 year old child. :D

Share this post


Link to post
Share on other sites

I'm not very much into maths, and vectors are beyond me. but I would solve problem one using a new cartesian coordinate (all lookups being polar) system placed on one of the points (the southern one for easiness), and rotated so that its north is pointing towards the second point. Figuring out your own position relative to the line would be checking if new x coordinate is positive (right of) or negative (left of).

I'm using the same principle to check if a point is located within a rotated elliptical marker at a given point. Hard to do without rotating my point and ellipse to zero degrees around ellipse center, and moving everything from ellipse center to [0,0]. See last thread here for actual code. Some new functions in Arma2 I assume does something similar in insideTrigger function, but I haven't checked.

The second one should be easy (without vectors at least :)). Two points on the line create an angle using atan2. Point at your position and an arbitrary point along your view direction also create an angle. Subtract the angles and there is your difference.

That's how I would think for solving the problem, with no respect to method used. It might be easier ways though. Again, I'm not very much into maths. If you're only interested in solving by vectors, then ignore this post :)

Share this post


Link to post
Share on other sites

Bear in mind it has been a long time since doing a lot of these types of things.

Possibly look at this page on Linear Equations.

Specifically the section on two point form.

Basically the formulae has three sets of x and y.

x1,y1

x2,y2

These would be the two points that define the line.

then x,y would be your location.

Instead of the equals sign, determine if the result to the left greater or less than the result to the right.

Assuming [0,0] is the bottom left of the map then.

If the right side is greater than the left then you are above the line.

If the right side is less than the left you are below the line.

If the two sides are equal you are on the line.

Note it is required you have different values for x1 and x2 meaning you cannot check for a vertical line meaning you would have to have an exception an check that a more easy of comparing the relative x values only.

I derived my information from here.

http://en.wikipedia.org/wiki/Linear_equation

Hope this helps, but bear in mind I am very rusty at this maths stuff.

Share this post


Link to post
Share on other sites

For your first problem, you can use the ccw algorithm (as described here, though in german, it does offer a good illustration):

private ["_ccw"];

// p0, p1, p2 => scalar, where
//  _ccw < 0  == clockwise
//  _ccw == 0 == collinear
//  _ccw > 0  == counter-clockwise
_ccw = {
  ( 
     (((_this select 1) select 0) - ((_this select 0) select 0)) *
     (((_this select 2) select 1) - ((_this select 0) select 1)) -
     (((_this select 1) select 1) - ((_this select 0) select 1)) *
     (((_this select 2) select 0) - ((_this select 0) select 0))
  )
};

In your case p1 refers to your position and you need to sort/swap p0 and p2 (sort by y) to be able to determine a "left" or "right".

As for your second problem, you can retrieve the "heading" of the line easily with the BIS function library/module, since this is the relative direction from p0 to p2:

  _lineHeading = [_p0, _p2] call BIS_fnc_dirTo;

Now you can easily compute the difference to your angle, though there most likely are two, a smaller and a larger one. You probably wanna opt for the smaller one.. Though, I don't quite see, what you're gonna do with this difference in angle. Aren't you more interested in a direction from p1 (player) to a point on the line, be it p0, p2 or the intersection point where the normal (90 angle onto the line) from p1 hits the line (which is the smallest distance between point and line)?

Share this post


Link to post
Share on other sites

I have to read through those answers after i got some sleep, right now i can't follow it pretty far but i'm sure it probably lacks of my knowledge rather than on the explanations.

To give an idea what the purpose is, it is about to fill this gauge with more or less sensefull life:

F16C_HSI.jpg

The compass itself is just a regular compass, not involved in this problem here.

The part with the 4 dots horizontally and the pointer which points to the N on the pic does rotate depending on the set curse (waypoints-like but not from actual position but from WP to WP). And finally the vertical line which on the pic is on the far left and which indicates where the Flightpath relative to the plane is located. This line rotates along with the underlying curse indicator and moves only in a transitional path. The plane symbol in the middle is fixed and doesn't rotate nor move at all, indicating actual heading of the plane.

The far goal is to simulate VOR/ILS functionality, more than ArmA 2 actually provides as usable data. Also flight path (waypoint-like) should be displayed with this gauge with data provided from avionics system of the plane.

Share this post


Link to post
Share on other sites

There are a bunch of routines buried in the BI functions library and more in the CBA mod. And then I have some code that does even more - tensor routines make vector manipulation easy.

gj6TJEyazO8

Share this post


Link to post
Share on other sites
  Myke said:
I have to read through those answers after i got some sleep, right now i can't follow it pretty far but i'm sure it probably lacks of my knowledge rather than on the explanations.

To give an idea what the purpose is, it is about to fill this gauge with more or less sensefull life:

F16C_HSI.jpg

The compass itself is just a regular compass, not involved in this problem here.

The part with the 4 dots horizontally and the pointer which points to the N on the pic does rotate depending on the set curse (waypoints-like but not from actual position but from WP to WP). And finally the vertical line which on the pic is on the far left and which indicates where the Flightpath relative to the plane is located. This line rotates along with the underlying curse indicator and moves only in a transitional path. The plane symbol in the middle is fixed and doesn't rotate nor move at all, indicating actual heading of the plane.

The far goal is to simulate VOR/ILS functionality, more than ArmA 2 actually provides as usable data. Also flight path (waypoint-like) should be displayed with this gauge with data provided from avionics system of the plane.

Ok emulating a VOR is fairly easy, basically all aVOR gauge does is track how many degrees you are off your desired track that you entered into the gauge.

As such a VOR gauge is more sensitive the closer you get to the vor station.

So all you need to do is enter the desired beaing, then check that against the aircrafts actual direction to the vor station. The needle deflection is then calulated relative to the amount of difference between the two values.

Here is a quick script I used for my own testing. Note you would need further code when checking the 360-0 mark one when one value is on one sid and the other is on the other side of 0 degrees.

_point2 = getmarkerpos "w2";
_pointA = position player;
private ["_Left","_Right","_offset","_lineHeading"];

while {true} do
{
_lineHeading = 327;
_lineHeadingP = [_pointA, _point2] call BIS_fnc_dirTo;
if (_lineHeadingP < 0) then
{
	_lineHeadingP = 360 + _lineHeadingP ;
};


_diff = _lineHeading - _lineHeadingP;

If (_diff < 0) then
{
	hint format [" Track %1 Left of Track %2",abs(floor(_lineHeading)),abs(floor(_diff))];
}
else
{
	hint format ["Track %1 Right of Track %2", abs(floor(_lineHeading)),abs(floor(_diff))];
};


sleep 2;
_point1 = getmarkerpos "w1";
_point2 = getmarkerpos "w2";
_pointA = position player;

};

Now if you emulating a gps you might have to go complicated like this to calculated the distance off track. So the below script checks the distance of the line perpendicular to the desired track. Not the angle. It's a bit rough but I mocked it up to test my theories validity.

This one is based one my first posts theory, and doesn't include the special case of a N-S S-N tracks where x1 and x2 are equal.

_point1 = getmarkerpos "w1";
_point2 = getmarkerpos "w2";
_pointA = position player;
private ["_Left","_Right","_offset","_lineHeading"];

while {true} do
{
//Left and Right represent the formulae sides as per the two point form in the link.
// http://en.wikipedia.org/wiki/Linear_equation

If (_point1 select 0 != _point2 select 0) then
{
	_Left = ((_pointA select 1) - (_point1 select 1));
	_Right = ((_point2 select 1) - (_point1 select 1))/((_point2 select 0) - (_point1 select 0) )*((_pointA select 0) - (_point1 select 0));
};

//Obtain line direction and convert to 0-360 format.

_lineHeading = [_point1, _point2] call BIS_fnc_dirTo;
if (_lineHeading < 0) then
{
	_lineHeading = 360 + _lineHeading ;
};

//Need to check direction of the line to determine if being above or below means to the left or to the right.
_dist = abs(floor(_Left - _Right)) * sin _lineHeading;
if (_lineHeading < 180) then
{
	if (_Left < _Right) then
	{
		_offset = format ["Right of track %1" ,_dist];
	}
	else
	{
		_offset = format ["Left of track %1" ,_dist];
	};
}	
else
{
if (_Left < _Right) then
	{
		_offset = format ["Left of track %1" ,_dist];
	}
	else
	{
		_offset = format ["Right of track %1" ,_dist];
	};
};
//_dist = abs(floor(_Left - _Right)) * sin _lineHeading;

hint format ["Dir %1 : %2", floor(_lineHeading),_offset];
//hint format ["Dir %1 : %2", floor(_lineHeading),_dist];
sleep 3;
_point1 = getmarkerpos "w1";
_point2 = getmarkerpos "w2";
_pointA = position player;
};

Edited by blakeace

Share this post


Link to post
Share on other sites

@blackace

Thanks a lot mate. Your second script provides exactly the data i need. With this i'm able to apply correct (nearly as) anims to the gauge. I have to adapt some small things for my needs but this isn't much of a hassle. Really appreciate your help on this.

Also thanks to all others that replied here. Always thankfull for all input, ever.

Share this post


Link to post
Share on other sites

Omfg, I guess that HSI/EHSI would be nice for the flyboys :) As an old flight sim fanatic involved in panel/gauge design, I know the kind of work you're up against :) I made a "near full implementation" (some impossible ones were replaced with artificial functions, such as holding entry display) of the Sandel SN4500 EHSI for flightsim, but that of course has much better support for gauge modelling.

How do you plan on implementing VORs and radio frequencies? Do they exist in the game? The "ILS" in ACE seems a bit weird to me, hopefully this HSI will give a better representation.

Share this post


Link to post
Share on other sites

To be honest, the VOR implementation will be artificial and i doubt that hardcore-flightsim-players will be 100% happy with it. At least it will be generic (works on all islands/terrains with correct ILS config settings) and help to line up for landing at bad weather conditions.

I've not put it down in each detail but general idea is to have 1 VOR straight lined up with the ILS/runway in XXX meters (have to test what fits best here) and another one in 45degree off this imaginary line so you'll get a rounded approach. Hope you get what i mean.

Besides that, the HSI shall also show waypoints, be it editorplaced WP's or WP's defined by the Pilot itself during preflight preparations.

Share this post


Link to post
Share on other sites

Been thinking about this some lately. How about skipping VORs completely and only have it be tuned to the nearest localizer? This one could be coupled with DME. With lack of VOR, which seems a bit hopeless with lack of frequencies/radio control and difficulty of setting an OBS knob (localizer doesn't react to OBS), you could put NDB stations at the extended runway thresholds, and a RMI needle in the gauge that always points to the nearest NDB. Scan cfgWorlds for airports, find out their runway thresholds, and simply create locations or markers with a given name that the NDB needle scans for.

Something like this, although I have no idea if using locations affects other stuff:

locNBD1 = createLocation ["BorderCrossing", _pos, 10,10];
locNDB1 setText "NDB";

That way, you have consistent readout on the deflection (since localizer is way more sensitive than a VOR), and you get a needle pointer to nearest NDB at all time, with no need to set OBS and no radio to tune. NDB could be set to typical middle or outer marker positions. Middle marker probably best (about 1 NM from threshold), since nobody/few would bother worrying about a stabilized approach anyway in Arma :) And those who will would be fully capable of setting a manual intercept waypoint themselves.

It's up to you, naturally, I'm just giving you some extra food for thought. :)

Share this post


Link to post
Share on other sites
  Quote
It's up to you, naturally, I'm just giving you some extra food for thought.

Mate, i have no clue what i'm eating there. :D

If you don't mind, add me to your messenger and i would love to discuss this further with you but keep in mind, i'm no flightsim player. The sentence "VOR" i've read somewhere and i just roughly understood what it does, although it is quite possible that i've misuderstood it completely wrong. :)

However, i'm trying to make this plane as close to flightsim as possible without locking out non-flightsim-players from it's use.

Share this post


Link to post
Share on other sites

Tried, but Miranda claims it can't find user. Hmm...

First obvious stop is wiki:

http://en.wikipedia.org/wiki/VHF_omnidirectional_range#Using_a_VOR

Here is a very good tutorial on this stuff:

http://www.navfltsm.addr.com/index.htm

Should be able to pick up important stuff about VORs from this one:

This one is also fairly good:

It also shows in part two a VOR approach. You might pickup on some of the differences between a classic VOR instrument and a HSI.

Here is a java simulation:

http://www.relia.net/~george/aviation/sim/

Be sure to read up on basic VOR stuff first, so that you can understand the difference with a classic indicator and the HSI you are making.

This video clearly illustrates the power of the ILS, and why it is called a precision approach, as it has vertical guidance.

Would you have dared going this low without it? :)

Very good explanation on how to do the ILS:

From same (very good) source, VOR approach:

Note this guy flying blind, using the ILS indications to guide him in:

There are some key differences on the instrument depending on if you are tuned to a localizer (LLZ, part of the ILS, the other part being glideslope which is automatically received) and a VOR station:

CDI deflection amount: Much more sensitive on LLZ than on VOR. Iirc its 4 times as sensitive on LLZ.

CDI deflection based on OBS setting: Tuned to LLZ, OBS setting does not matter at all since the localizer determines the course, not you in the airplane! On a HSI it will still rotate as OBS setting is adjusted, but the amount of deflection will not change. On a VOR however, the deflection will be based on which radial is set with the OBS knob. This means that adjusting the OBS has no effect when flying an ILS, other than to serve as a reminder to the pilot.

CDI alive or not: Tuned to LLZ, the CDI needle will deflect from center and CDI INOP flag will be removed once you're inside the reception cone. Tuned to a VOR, it will deflect from center and CDI INOP flag will be removed (basically) only as a function of distance (and deviation from set OBS naturally).

Tuned to a LLZ, TO/FROM flag will always read TO. With a VOR, TO/FROM will indicate which side you are of the VOR station you are, compared to the selected radial on the OBS.

The glideslope indicator will always remain centered and flagged INOP when a VOR station is tuned. When a LLZ is tuned, the slideslope (if present, it can be localizer only, without vertical guidance) becomes alive when you're inside the reception cone.

For the sake of keeping it simple, we can assume that both VORs and LLZs always have DME equipment coupled to their frequency. A key point to remember is that no changes in deflection of the CDI needle will happen based on attitude or heading of the aircraft, for both VOR and LLZ usage, and CDI needle does not point you to the station unless you're on the selected radial for VOR or on the LLZ course dictated by the LLZ itself.

More and pretty detailed information about a HSI can be found here, and if you really have the time, I can recommend all flight related articles on his site, much good read :)

If your knowledge about VOR and ILS are limited, I'll restrain myself and not go more into details about this, which became far more than I intended anyways :D

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×