Tactics Plugin

[Canne]

Thanks, Thomas, installed 1.0007, no issues detected using recorded data. Thank you for your continuous support! tactics_pi is a remarkable piece of software!

[rgleason]

Isn't there a way to extend the nmea0183 sentences with new a new manufacturer designator, or several, which then have unique XDR designators for heel, roll etc? I suppose the problem is that the device itself always identifies itself as a given manufacturer, rather than allowing assignment of a new designator.

[Canne]

Sure, but how would you fill in that designator? In the above use case, all three messages for the same thing (Heel) are coming from a single manufacturer (NKE) and one of them has even a wrong value! I agree with Hubert: XDR, it is a bottomless pit. In this use case the solution is problem resolving by a person who knows his installation, making a decision for a reliable source and then using external filtering functions (MiniPlex multiplexer input filters) to clear everything else out for O. Why not provide powerful message analysis and filtering tools for a non-tech user at the reception of NMEA in O core style ‘hey I’ve got three sentences from your instruments with values A,B,C for the same thing (heel)? Which one you want me to use?" Meanwhile, I use my MiniPlex to do that work, too. Or NavMonPC. Or both...

[tom_BigSpeedy]

Actually I thought about defining different "strings" for the same XDR sentence type like heel, pitch, air temp, water temp, barometric pressure,... in an ini file.
Maybe a simple XML ...
We still have to program the sentence type, e.g. "heel" and supply the appropriate intruments and usage, but it would at least make us independent from manufacturer namings ...
The plugin to read the ini upon startup, and keep the "strings" in arrays.
We could define a generic xml, containing all, and if someone needs to add or remove one ... so just do it in the ini and restart O...

But of course I didn't start working on that yet ...

BR,

Thomas

[Johnny Walker]

Hi Thomas,
I have recently started using this plugin for coastal and offshore racing and it is awesome.

I was sat on the mooring today (with zero boat speed), reconfiguring the instruments, and was wondering why my caluclated current speed was not hovering around the zero mark.

I've had a quick look at the source code on github and I don't think the calculation of "smoothed" current speed and direction is quite right. Current speed and direction is a vector in polar coordinates. To "combine" 2 polar vectors, you have convert both to Cartesian coords; x = R*cos(theta), y = R*sin(theta), do the maths and then convert the result back to polar co-ords R = SQRT(x^2 + y^2) and theta = arctan(y/x).

I'm not an C++ guru, but I think the code in CalculateCurrent() should look something like this.

PositionBearingDistanceMercator_Plugin(mlat, mlon, mCOG, sog_kts, &COGlat, &COGlon);   

PositionBearingDistanceMercator_Plugin(mlat, mlon, CourseThroughWater, stw_corr, &CRSlat, &CRSlon);
   
DistanceBearingMercator_Plugin(COGlat, COGlon, CRSlat, CRSlon, &currdir, &currspd);
   
double currdir_tan = currdir;
double rad = (90 - currdir_tan)*M_PI / 180.;
                                      
mSinCurrDir->SetAlpha(g_dalpha_currdir);
m_ExpSmoothSinCurrDir = mSinCurrDir->GetSmoothVal(currspd * sin(rad));
   
mCosCurrDir->SetAlpha(g_dalpha_currdir);
m_ExpSmoothCosCurrDir = mCosCurrDir->GetSmoothVal(currspd * cos(rad));
   
mExpSmoothCurrSpd->SetAlpha(alpha_currspd);
m_ExpSmoothCurrSpd = mExpSmoothCurrSpd->GetSmoothVal(SQRT(m_ExpSmoothSinCurrDir * m_ExpSmoothSinCurrDir + m_ExpSmoothCosCurrDir * m_ExpSmoothCosCurrDir));                             
   
m_CurrentDirection = (90. - (atan2(m_ExpSmoothSinCurrDir, m_ExpSmoothCosCurrDir)*180. / M_PI) + 360.);
while (m_CurrentDirection >= 360) m_CurrentDirection -= 360;

[Canne]

Originally Posted by tom_BigSpeedy

... Maybe a simple XML ...

What do you think about JSON? I noticed the aforementioned SignalK datamodel is based on it - looks very human readable.

[bcn]

Or why not directly SK?

[Canne]

Originally Posted by Johnny Walker

... I think the code in CalculateCurrent() should look something like this. ...

Try your code yourself, from this temporary URL, compiled w/ mods on 1.0007, see code changes.
Note this fills opencpn.log quite rapidly so better keep the original file. With my recent recorded data (quite monotonic way to compare, NMEA data source changes used as ticks) I've got:

1.0007         1.0007+jw
118.54;118.54  122.01;122.01
...
 47.08;116.82   49.77;120.92
...
106.10;116.31  116.14;120.60

That's +3% roughly.

[tom_BigSpeedy]

I'll give it a try, but it will need solid testing.
It'll take some days ...
Thomas

[tom_BigSpeedy]

Johnny,

Petri (Canne) and I had a quick live check (independent of each other) of your code but it did not really work as expected.
I'm in the comfortable situation that I can do a live comparison, as the NKE Multigraphic instrument
does an internal current calculation as well.
I can simply upload the calculated data from O to the instruments and display both calculations next to each other

I'm not sure if you really understood the purpose of the sin / cos splitting of currdir.
We do already have a valid vector for the current (direction + speed) right in top of your code snippet, as output of

"DistanceBearingMercator_Plugin(COGlat, COGlon, CRSlat, CRSlon, &currdir, &currspd);"

So I see no need to recalculate especially currspd with the trigonometric function.
We can simply smooth it right away as done.

The tricky job is to smoothen the really noisy currdir data where we face the challenge to avoid the 0 - 360° problem
(350° + 10° + 30° should give an average of 10° and not 390/3 = 130°).
And this is the only purpose of the sin, cos, rad and atan2 funcionality.

I simply split currdir (current direction) into its x and y components (sin/cos), smoothen them separately and later on recombine them with atan2
to a smoothened angular value without the 0-360 problem.
(atan2 solves the 0-360 issue)

I did a short test yesterday and your currspd calculation is way off from NKE's internal calculation. currdir is close but stabilizes off the "original" values and also NKEs.
Petri reports similar results.

When I designed this, I did lots of manual calculations (Excel) with the code and the result prooved OK then.

I took this somewhere from the internet, I think it was on the codeproject site, where someone was
dicussing different ways to get around the 0 - 360 problem.
The links are on my old laptop at home, it'll take a week until I get there ...

Regarding your question, why the current does not jump foth and back while moored :

I think the answer is quite simple :
the data in O is dead-noisy, and we use heavy smoothing.
When you're moored, STW will be 0, compass heading should be stable and from the GPS there should be more or less only noise for SOG / COG.
Depending on your GPS COG may also point to 0° without movement...
So in the end the smoothing algorithm removes the noise and gives you a stable view, probably following heading/COG
with the average noise of SOG (which is always somewhat above 0) as speed.


BR,

Thomas

[Johnny Walker]

Originally Posted by tom_BigSpeedy

Johnny,

Petri (Canne) and I had a quick live check (independent of each other) of your code but it did not really work as expected.
I'm in the comfortable situation that I can do a live comparison, as the NKE Multigraphic instrument
does an internal current calculation as well.
I can simply upload the calculated data from O to the instruments and display both calculations next to each other

I'm not sure if you really understood the purpose of the sin / cos splitting of currdir.
We do already have a valid vector for the current (direction + speed) right in top of your code snippet, as output of

"DistanceBearingMercator_Plugin(COGlat, COGlon, CRSlat, CRSlon, &currdir, &currspd);"

So I see no need to recalculate especially currspd with the trigonometric function.
We can simply smooth it right away as done.

The tricky job is to smoothen the really noisy currdir data where we face the challenge to avoid the 0 - 360° problem
(350° + 10° + 30° should give an average of 10° and not 390/3 = 130°).
And this is the only purpose of the sin, cos, rad and atan2 funcionality.

I simply split currdir (current direction) into its x and y components (sin/cos), smoothen them separately and later on recombine them with atan2
to a smoothened angular value without the 0-360 problem.
(atan2 solves the 0-360 issue)

I did a short test yesterday and your currspd calculation is way off from NKE's internal calculation. currdir is close but stabilizes off the "original" values and also NKEs.
Petri reports similar results.

When I designed this, I did lots of manual calculations (Excel) with the code and the result prooved OK then.

I took this somewhere from the internet, I think it was on the codeproject site, where someone was
dicussing different ways to get around the 0 - 360 problem.
The links are on my old laptop at home, it'll take a week until I get there ...

Regarding your question, why the current does not jump foth and back while moored :

I think the answer is quite simple :
the data in O is dead-noisy, and we use heavy smoothing.
When you're moored, STW will be 0, compass heading should be stable and from the GPS there should be more or less only noise for SOG / COG.
Depending on your GPS COG may also point to 0° without movement...
So in the end the smoothing algorithm removes the noise and gives you a stable view, probably following heading/COG
with the average noise of SOG (which is always somewhat above 0) as speed.


BR,

Thomas

Hi Thomas,


I agree the situation when moored is red herring, my Garmin GPS tends to stick on to 0° without movement.

I am surprised that my calculation method is way off your NKE internal calculation.
With the current in a fairly steady direction, both methods of calculation should reveal pretty much the same results, so maybe my code snippet wasn't quite right.

But there are some situations, where you can get very different results.
Take an extreme example, where the outputs of the DistanceBearingMercator_Plugin(COGlat, COGlon, CRSlat, CRSlon, &currdir, &currspd) calculation alternates between 2kts / 280° and 2kts / 100°.
Visually, these 2 vectors are opposites, so intuitively the average current in this situation is zero.

With these figures, the current method eventually gives smoothed current values alternating between 2kts / 280° and 2kts / 100°, and the alternative method gives values alternating between 0.12kts / 280° and 0.09kts / 100°. So good correlation in direction, but very different speeds. Which is right……

The attached spreadsheet illustrates the correlation and differences in the 2 methods. I only used the single exponential smoothing to keep things simple.

BR
Johnny

[transmitterdan]

Unless the speed/course sensors take samples at the same time then there is no "right" way to filter the vector sum/difference. The "right" way is to do the vector sum/difference in Cartesian with same time samples then smooth the result in polar. But if you try to smooth the various vector data before forming the resultant vector there will be disappointment I think. In that case there is a lot of noise added to the data.

Most purpose built instruments sample the data at the same time and then do the vector math on that. Unfortunately OpenCPN has no control over when samples are taken. It just accepts the data whenever it arrives. So no way to guarantee correlation in time.

[Canne]

Originally Posted by Johnny Walker

..The attached spreadsheet illustrates the correlation and differences in the 2 methods. I only used the single exponential smoothing to keep things simple...

Dear Johnny, my apologies - it was after seeing your spreadsheet that I understood that the code which I put in without too much thinking, unfortunately would not work as expected, obviously. The class behind is an algorithm, DESP-based, explained in this paper, see (1), (2) and (6) and the explanation which follows. If I would have made a good job, I would have modified the code further to use SES- or DES-based classes which are present in the code base - the results would have been closer to your spreadsheet. Sorry about that.

Originally Posted by transmitterdan

...Most purpose built instruments sample the data at the same time and then do the vector math on that...

In my DAQ-systems I have to accept the fact that the "same time" can be any time between 50 nanoseconds RMS... I reckon that NKE and other instrument manufacturers which at best have NMEA-2000 bus at their hands must find a way to compensate the data sampling being asynchronous - they don't have triggering bus like I have. I reckon that is why the LaViola predictive method used by Thomas fits so well with the NKE instruments: it actually predicts (and not smooth) the next position of the gamer's hand (yes, virtual reality is the driving force) using not vector calculations but quaternions. I think this is very well suited to the problem of the asynchronous data sampling you mentioned. The paper observes a) fast calculation times and b) very similar results with the vectorial derivate based methods which are certainly more dependent of the sampling being as simultaneous as possible. The paper indicates also the predictions using (1)(2) and (6) being in function of the sampling rate. Most probably, two boats, one with NKE and one with hacked NMEA-0183 multiplexer + OpenCPN would see very different results using the same algorithm.

As conclusion, I completely agree that there is no "right" method but Thomas getting so close to the values which NKE is having with their databus illustrates that we are on the same tracks with this company having years of experience in ocean racing. And all this for free and totally transparent. Which allows us to have these lively discussions which we all like, don't we?

Best regards,

Petri

[tom_BigSpeedy]

Thanks Petri for the explantions ...
Actually this current calculation took most time of the whole plugin development,
I think it took more than a year till I was satisfied ...
I started with SES (Single Exponential Smoothing) but on the one hand to stabilize the current display I had to use very high damping (very low alpha values) and once this worked, it reacted too slow on course and current changes.
Next I experimented with (simple) Kalman filters, but found them too costy in terms of performance and way too complicated to be tuned correctly in regards of the variety of electronics setups out there ...
Finally I came across DES with the LaViola adoption, which has the nice benefit that you need only one filter value alpha (instead of 2 in standard DES, alpha + beta)...
Here is a sceeenshot I took from my Multigraphic, the black data in the center is uploaded from O via the "PNKEP" sentence, blue on the right is calculated internally by the instrument ...
Once I have somehow stable condtions data really aligns perfectly, even over longer periods of time ... I should have recorded a small video instead of just taking a pic...



Thomas

[rgleason]

Thomas, I wanted to use Tactics on the Marblhead-Halifax Race on a friends boat, but was too busy and had lost my Tactics setup when I had to re-init opencpn.ini on the ms pro3.
- Next time for sure!