TMA by least square method

[Dr.Sid]

I'm trying to create formulas for TMA by least square method. Input is LOBs from different positions and times, result is line which match them best.
I have it more or less done, I'm writing the program now to verify the formulas.
Anyway anybody here could know some formulas or methods too. I'd like to compare.

[XLjedi]

Presently, the TMA solution feature built into MoBo is fairly simple. (Have you tried it?)

You take regular bearings at even intervals and from that you can lay a TMA line across the bearings and look for a heading that yields equal distance travelled. Of course, that assumes the target has not changed course or speed.

In MoBo, the TMA line is positioned by human intervention, similar to the way a maneuvering board user would use a ruler with speed notches.

I'm in the process now of researching new and more advanced methods for TMA. Someone mentioned possibly looking into Ekelund ranging as well.

My first challenge was to revamp my vector intercept formula to test for actual line intersection. I think I have something now that can properly differentiate between intercepts (assuming lines extend to infinity) and intersections (finite lines) or any combination of the two.

I believe a least squares solution would require some sort of range estimate, correct?

[Dr.Sid]

No .. it does not require anything. Just the LOBs. It gives line witch fits the LOBs best. Now if there is no best solution (parallel LOBs for example) it gives no solution. If the LOBs are poor, or if the target changes course, even the best match will be rather loose.
But if you have good LOBs, after a leg, or LOBs from same time (let's say towed array and hull array for a sub), it should give good data, best possible in fact.
I guess it must be used on real subs. It is also said in Submarine by Clancy that Brits use automatic TMA all the time. So I wonder what this automatic TMA is.
Now I'm pretty close to have it working (or finding out I have it wrong ).

[XLjedi]

Oh... OK, if a parrallel LOB is possible, that means you're also plotting or inputting an (x,y) position as the point of origin for the LOB. I do see now that you did mention that in your post... and you input an obs time too.

You're taking the DRT (dead reckoning tracker) approach. The benefit to the DRT method is that you don't have to maintain your own course and speed. The downside is you have to track your own position.

How are you entering/determining the position data? I haven't played my copy of DW much since I bought it... I assume it must provide you with a readout showing your position, and that's what you're using for an input?

[Dr.Sid]

I don't mean to use it with DW. As you said .. you don't know your position. I take it just as interesting problem at the moment.
For me, LOB is position, direction and time. You give set of these and you get position and vector of the target, whose length indicates speed.

[XLjedi]

Not exactly sure what your goal is then.

Sounds like you have a least-squares TMA solution that maybe works, provided you can load it with position data that you don't presently have.

If it works as you say, I could possibly incorporate it into MoBo... maybe. I'd have to look at it.

MoBo functions nicely as a DRT, so you could plot your position/bearing/time inputs and I could have MoBo generate a contact with position and vector based on your formula.

[Dr.Sid]

Bah .. I implemented it .. and there is some error in it I can't find. Well I found many of the errors .. but not.

Just for your info:

Inputs is array of LOBs:
Px,Py - position of listener at the time of observation
Sx,Sy - vector of sight - in my implementation I assume it's length is 1 - this represents the bearing
t - time of observation - in my implementation I use t=0 for the first LOB

if you have 5 lobs, you have 5 these. 5 positons, 5 vectors, 5 times.

I'm looking for these variables:
Ax,Ay - position of the contact at t=0
Vx,Vy - vector of speed of the contact, length is speed

Now my actual formulas look like this:

We must solve this matrix, column represents Ax,Ay,Vx,Vy

+sy.sy -sy.sx +t.sy.sy -t.sy.sx +px.sy.sy-py.sx.sy
-sy.sx +sx.sx -t.sx.sy +t.sx.sx +py.sx.sx-px.sx.sy
+t.sy.sy -t.sx.sy +t.t.sy.sy -t.t.sy.sx +px.t.sy.sy-py.t.sx.sy
-t.sy.sx +t.sx.sx -t.t.sy.sx +t.t.sx.sx +py.t.sx.sx-px.t.sx.sy

All elements must be summed for all the LOBs first, then the matrix is solved. But as I said, there is mistake somewhere.

I used the method like this:

First there is formula for distance of point (B) from line (A+V.u)
dist=(ax.vy-ay.vx-bx.vy+by.vx)/(vx.vx+vy.vy)
The part (vx.vx+vy.vy) is 1 in my case (LOBs vector's length =1 ) so I can omit it.

Now I need to specify the 'wrongness' of my theoretical solution. That is here (using variable names mention on top):

delta = px.sy-py.sx-(ax+vx.t).sy+(ay+vy.t).sx

this is error for particular LOB.

Now I need to sum squares of these errors for each LOB, and look for minimum such sum. That is the trick in the least square method.
The error square looks pretty nasty.

+2.ax.py.sx.sy+2.ax.vx.t.sy.sy+2.ay.px.sx.sy+2.ay. vy.t.sx.sx-2.ay.vx.t.sx.sy+2.vx.t.py.sx.sy+2.vy.t.px.sx.sy
-2.ax.ay.sx.sy-2.ax.px.sy.sy-2.ax.vy.t.sx.sy-2.ay.py.sx.sx-2.px.py.sx.sy-2.vx.t.px.sy.sy-2.vy.t.py.sx.sx
-2.vx.vy.t.t.sx.sy+px.px.sy.sy+py.py.sx.sx+ax.ax.sy .sy+ay.ay.sx.sx+vx.vx.t.t.sy.sy+vy.vy.t.t.sx.sx

But I really went thru this part like 10 times and I think it is correct now.

Then you derivate this by each of variables you are interested in. ax,ay,vx,vy in our case. Why we do the derivation ? We look for minimal error, that's where derivation of the error is equal 0. If we have the derivations, we must solve when they are zero and that is our solution.

Derivates looks like this:

ax:
+2.py.sx.sy
+2.vx.t.sy.sy
-2.ay.sx.sy
-2.px.sy.sy
-2.vy.t.sx.sy
+2.ax.sy.sy

ay:
+2.px.sx.sy
+2.vy.t.sx.sx
-2.vx.t.sx.sy
-2.ax.sx.sy
-2.py.sx.sx
+2.ay.sx.sx

vx:
+2.ax.t.sy.sy
-2.ay.t.sx.sy
+2.t.py.sx.sy
-2.t.px.sy.sy
-2.vy.t.t.sx.sy
+2.vx.t.t.sy.sy

vy:
-2.ax.t.sx.sy
+2.ay.t.sx.sx
+2.t.px.sx.sy
-2.t.py.sx.sx
-2.vx.t.t.sx.sy
+2.vy.t.t.sx.sx

And then you simply put these into the matrix, solve it and that's all. I'm almost sure I have not missed any sign anywhere. I feel like I forget to make some step or something. So I need help from somebody who used least square method to solve problems. Somebody who understands what I'm talking about. If you don't, don't worry, one can easily live without it, but I'm afraid you can't help me.

I have this programmed and it almost works .. in same rare cases it even gives correct data. I'm quite sure I don't have it ALL wrong.

[Dr.Sid]

Hm .. if you are really going to recheck these formulas, please wait a bit .. maybe the problem is in the matrix solution. I've tried some online matrix solvers and they give quite different results (while not correct too).

Edit: Oh yes ! My matrix solver is wrong and the online solvers are correct and the matrix IS correct. So I only fix the solver, that should be much easier.

So I don't need any more help I hope. I only need some little time till I release that utility of mine so you could get a grasp what it can do. Of course I offer this to your tool if it could is it somehow, I guess it could. For example in DW you have TMA screen where you see the LOBs in absolute coordinates. Each LOB starts at different point, as your sub moves. You would have to know the times of the LOBs. Now you would have to rely on AUTO sonar crew which marks each 2 minutes. Then you would have to transfer the LOBs into the other tool .. then input your speed (to get the scale of the 'map'). And then you would have the solution.

This methos should also cover special cases like more listeners (sonobuoys or hull and towed array), LOBs can start at very different places and times, this just finds the best line to match them.

[jmr]

Originally Posted by aaronblood

You're taking the DRT (dead reckoning tracker) approach. The benefit to the DRT method is that you don't have to maintain your own course and speed. The downside is you have to track your own position.

Not to derail this thread but I've tried that by running DW in a window and using the transparency slider in Mobo to overlay Mobo over my TMA screen and plot lines accordingly. Unfortunately it's almost impossible to get a target course heading using this method - the best way is to stop, listen, and plot lines for some time. Doing that you're able to get a more accurate stack of the bearing lines on the Mobo TMA tool.

[Dr.Sid]

Well I just looked at that MoBo of yours .. and it's quite cool.
It seems you concentrate on solutions where you know some of the solution parts. There is no magic word 'LEG' anywhere in the manual, and you only touch full TMA in the last paragraph. But as it is oriented toward WW2 it's quite ok.
On the other hand you could track ownship even with your tool. You have the icon of ownship on the map don't you ? That's it. Or you could plot course and speed and compute where your ship is at each moment. Then you would change course to make the leg, grab OS position after heading stabilizes and then you can plot new course again.
Btw. yesterday I have found great good reason why you need a leg. It never occured to me before. Well if you go straight at constant speed, there is always one incorrect solution. That is your own motion ! It lies and all LOBs, no matter how the LOBs goes.

[Dr.Sid]

Ok .. here is the demo: http://roger.questions.cz/other/AutoTMA.zip



It is useless for actual TMA, it only tests and demonstrates the method.
White circles represents ownship. White lines are the LOBs.
Blue circles is test target. It is used to generate the LOBs.
Green circles is the solution computed from the LOBs.
You can use left mouse button to move the test target, and right mouse button to change it's course and speed. Solution is recomputed. It should place the green circles into the blue ones.
Note that with manual test target placement it is almost impossible to create 'no solution' situation. You simply won't be able to create the LOBs parallel enough and even slight change in direction will be taken into acount and solution will be found (end pretty exact one too).

This uses the matrix mentioned above. I only had small glitch in matrix determinant, it was easy to find and fix when I knew the matrix is OK.

[XLjedi]

Why would you say it's useless?

I assume the green and blue dots represent both actual track and formula track.

[Dr.Sid]

Originally Posted by aaronblood

Why would you say it's useless?

I assume the green and blue dots represent both actual track and formula track.

Blue ones are the actual track, green ones is the formula. With leg in ownship course I haven't found case where green ones don't match blue ones.


The tool is useless as it is. You cant edit ownship location or enter LOBs. You can't use it to detect YOUR sub. That's how I meant it. The formulas are not useless, they are even better then I thought ! I guess it could be made part of MoBo easily. I could also make some standalone tool for that but I would need to copy so much of MoBo functionality, that it gives really no sense.

Sorry if something is not clear, English is not my native language.

[XLjedi]

Well, if you like I would be happy to add your formula as a MoBo tool...

It looks like something I was wanting to work toward anyway and this would save me probably a month of research.

If you decide that you'd like to contribute your code to the MoBo project, you would be acknowledged as a member of the MoBo Dev Team and given appropriate credit in the application.

In addition to updating the 1.1 Beta, I'm also working on developing a new retained-mode vector graphics interface (MoBo 2.0, or "MoPro"). I may rename the MoBo app in version 2 cuz I'm tired of searching for "MoBo" and finding a bunch of junk related to PC motherboards... hindsight is always 20/20.

[XLjedi]

Originally Posted by Dr.Sid

Blue ones are the actual track, green ones is the formula. With leg in ownship course I haven't found case where green ones don't match blue ones..

Could you adjust your test case to add a small amount of random LOB error? Maybe +-2°

I'd like to see how the formula behaves when interpretting less precise human plots.