Alinghi GC 32 wrong wind

[jonasseglare]

According to Yves Detrey, our wind is not the right one here:

http://localhost:9000/map/576be118c5c661ac23e7c1a5?l=0.49119740750078955,0.33275548861371074,0.000018747358773940626&c=576be118c5c661ac23e7c1a52016-06-22T13:10:452016-06-22T15:45:25

At 17:27, it should be: TWDIR: 272 degrees TWA: -130

[jpilet]

Yves sent me a CSV file of the same session recorder by another logger https://drive.google.com/file/d/0B9sxrfjrXQSdVWwzY1VwMlF3ZnM/view?usp=sharing

[jpilet]

on anemolab, the same problem is visible on https://www.anemolab.com/map/56a3a9912333f1aba9ed24ff?l=0.4912104668435133,0.33275511517365575,0.00003951174688238135&c=56a3a9912333f1aba9ed24ff2016-06-22T09:40:162016-06-22T11:11:46

[jonasseglare]

Currently hard to say exactly what's wrong, but I added some code to analyze it under the branch

jo-debug-true-wind-dev

It will output some files beginning with /tmp/tilestep... that let us better understand where in the computations errors might have been introduced.

[jonasseglare]

So I am trying to get a clear idea of what is going on. First of all, the recorded log files from our box only extends to about 15h45 on the 22nd of June, so therefore I take a snapshot of the log files at 15h27, instead of 17h27 as mentioned above. I also load the CSV data without doing anything to the time and I get all this:

At reference time, we have:
   - Time (seconds): 0.293000
   - X (meters): -283.945000
   - Y (meters): 184.656000
   - [loadedData_Anemomind estimator]: 214.690000
   - [loadedData_NMEA2000/c078be002fb00000]: 236.510000
   - [loadedData_Simulated Anemomind estimator]: 354.751000
   - [groundTruth_CSV imported]: 309.684000

If I look inside the CSV file at 15h27, I get the value 309.68, which is consistent with what is printed out above. In other words, I seem to be parsing the CSV file correctly. But that value differs a lot from [loadedData_Anemomind estimator] and [loadedData_NMEA2000/c078be002fb00000].

Now, if I look at 17h27 in the CSV file, I get the value 236, which seems to agree with the NMEA2000 registered value. This suggests that I need to apply a shift when I load the data CSV data.

The current commit and branch is [jo-debug-true-wind-dev 140b92f] wip

So let's apply that shift and redraw the graph to see what we get.

[jonasseglare]

A rerun with time shifted data suggests a close agreement between the CSV-data and the NMEA2000 data.

All four curves resemble each other, but are not identitical.

The current state is now [jo-debug-true-wind-dev 4553aa6]

What is the actual problem? I think some numbers on Anemolab were strange or so.

What can we do? Maybe plot more winds, etc...

[jonasseglare]

What we can try: List all heading/gps-bearing channels, and all TWA channels. Then for every heading/TWA channel, we compute the TWDIR by adding them together and plot them. The twdir should not have jumps at manoeuvers. If there are visible jumps, then something is probably wrong.

[jpilet]

It makes sense!

On 30 juin 2016, at 20:33, jonasseglare notifications@github.com wrote:

What we can try: List all heading/gps-bearing channels, and all TWA channels. Then for every heading/TWA channel, we compute the TWDIR by adding them together and plot them. The twdir should not have jumps at manoeuvers. If there are visible jumps, then something is probably wrong.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jpilet/anemomind/issues/743#issuecomment-229748798, or mute the thread https://github.com/notifications/unsubscribe/AB-XAGylsNjEEVqYrsy0keHoawKaBlgdks5qRAvqgaJpZM4I8zpq.

[jonasseglare]

Headings exported in

[jo-debug-true-wind-dev 71b37ff]

let's see what we get...

[jonasseglare]

At [jo-debug-true-wind-dev 78c95ce] we have

At reference time, we have:
   - Time (seconds): 0.293000
   - X (meters): -283.945000
   - Y (meters): 184.656000
   - [tilegen_Anemomind estimator]: 214.690000
   - [tilegen_NMEA2000/c078be002fb00000]: 236.510000
   - [tilegen_Simulated Anemomind estimator]: 354.751000
   - [groundTruth_CSV imported]: 236.334000
   - [tilegen__gpsBearing_Internal GPS]: 0.000000
   - [tilegen__gpsBearing_NMEA2000/c07891002fb3645a]: 22.530000
   - [tilegen__magHeading_NMEA2000/c050a0012fb3245a]: 30.530000
   - [groundTruth__magHeading_CSV imported]: 30.538700

[jonasseglare]

Here, we plot things [jo-debug-true-wind-dev 05938c6]

See this:

[jonasseglare]

The upper graph suggests that there is a problem with how we compute the true wind on the server (the blue line). I would not expect it to change that much...

[jonasseglare]

And what about the webserver? There was an inconsistency, too, I believe.

[jonasseglare]

[jonasseglare]

[jonasseglare]

Interesting. So in the text message before, we had [tilegen_Simulated Anemomind estimator]: 354.751000 but on the debug above it says

twdir: 354.75...

Those two values are the same. Are we mixing them up somewhere, for instance when we export it on the server to MongoDB?

[jonasseglare]

And what about the calibration code? Are we populating the dispatcher in the wrong way somehow?

[jonasseglare]

[jo-debug-true-wind-dev d827e42]

[jonasseglare]

If we deactivate the calibration, it seems like the true wind estimates don't differ

[jonasseglare]

[jonasseglare]

One observation here is that our estimated TWS value of 1.58 differs a lot from the external value which is 4.62. That is true both when comparing the Nav's and the dispatcher snapshots.

[jonasseglare]

In [jo-debug-true-wind-dev 7256560], I added this:

    auto hdg = getHeading(nav);
    auto aw = computeApparentWind<double>(hdg, nav.awa(), nav.aws());
    auto tw = computeTrueFlowFromBoatMotionAndApparentFlow(nav.gpsMotion(), aw);
    auto estTwdir = computeTwdirFromTrueWind(tw);
    auto estTwa = computeTwaFromTrueWind(hdg, tw);
    auto estTws= tw.norm();

    if (fabs(nav.time() - refTime) < Duration<double>::seconds(12.0)) {
      *file << "NAIVE TRUE WIND AT " << nav.time().toString() << std::endl;
      *file << "  TWDIR: " << estTwdir.degrees() << std::endl;
      *file << "  TWA:   " << estTwa.degrees() << std::endl;
      *file << "  TWS:   " << estTws.knots() << std::endl;
    }

and it outputs

...
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -101.009
  TWA:   -123.299
  TWS:   4.60509
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -133.882
  TWA:   -156.292
  TWS:   1.66227
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -133.882
  TWA:   -156.292
  TWS:   1.66227
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -101.221
  TWA:   -123.751
  TWS:   4.61219
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -121.873
  TWA:   -144.503
  TWS:   2.05944
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -101.442
  TWA:   -124.132
  TWS:   5.04945
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -123.698
  TWA:   -146.428
  TWS:   2.12989
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -101.744
  TWA:   -124.534
  TWS:   5.05366
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -101.497
  TWA:   -124.347
  TWS:   5.04235
...

The values seems to be jumping a bit, but many times, the TWA=-124 or so.

If we add 360 to -124, we get 360 - 124 = 236. That coincides with the TWA value from the external instruments. This suggests that we can compute the true wind, but for some reason the true wind estimator fails.

In the above output, we used the GPS bearing as heading.

[jonasseglare]

If we instead use the magnetic heading as bearing, we get

....
  TWDIR: -159.31
  TWA:   -188.97
  TWS:   1.46055
NAIVE TRUE WIND AT 2016-06-22T15:26:59
  TWDIR: -99.8028
  TWA:   -129.463
  TWS:   3.87367
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -100.005
  TWA:   -130.535
  TWS:   3.78211
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -160.94
  TWA:   -191.47
  TWS:   1.48324
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -160.94
  TWA:   -191.47
  TWS:   1.48324
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -100.329
  TWA:   -130.859
  TWS:   3.81545
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -140.847
  TWA:   -171.507
  TWS:   1.62745
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -99.9154
  TWA:   -130.575
  TWS:   4.25422
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -141.63
  TWA:   -172.29
  TWS:   1.7246
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -100.237
  TWA:   -131.597
  TWS:   4.19998
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -99.9542
  TWA:   -131.314
  TWS:   4.19513
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -99.7261
  TWA:   -131.086
  TWS:   4.02817
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -150.267
  TWA:   -182.077
  TWS:   1.61173
NAIVE TRUE WIND AT 2016-06-22T15:27:01
  TWDIR: -149.722
  TWA:   -181.532
  TWS:   1.61341
NAIVE TRUE WIND AT 2016-06-22T15:27:01
...

[jonasseglare]

where the correspondence is not as good

[jpilet]

could we reproduce in a unit test such as #706 ?

[jonasseglare]

So now I have some test data to investigate what is happening

HERE ARE THE SOURCE MEASURES:
  awa = 315.96 degrees
  aws = 5.69 degrees
  gpsBearing = 23.59 degrees
  gpsSpeed = 6.8 knots
  gps-motion-x = 2.72129 knots
  gps-motion-y = 6.23174 knots
NAIVE TRUE WIND AT 2016-06-22T15:27:00
  TWDIR: -100.823
  TWA:   -124.413
  TWS:   4.79461

My plan is to populate a Nav and then run the TrueWindEstimator repeatedly on that nav to see what I get. The TWDIR, TWA, TWS values on the bottom part, I know how to calculate. And I believe they are close to reality, because they are similar to the external values

External TWDIR: 259, our TWDIR -100, 360 - 100 = 260 =~259 same goes for TWA And TWS is similar too.

[jo-debug-true-wind-dev f771af4]

[jonasseglare]

Because I deactivated loading the calibration parameters, it seems like the DispatcherTrueWindEstimator doesn't attempt to compute anything:

void DispatcherTrueWindEstimator::compute(const std::string &srcName) const {
  Angle<> twdir;
  Angle<> twa;
  Velocity<> tws;

  if (!_dispatcher->get<GPS_SPEED>()->dispatcher()->hasValue()
      || !_dispatcher->get<AWA>()->dispatcher()->hasValue()
      || !_dispatcher->get<AWS>()->dispatcher()->hasValue()) {
    // we can't compute anything useful without GPS.
    return;
  }

  auto t = _dispatcher->currentTime();
  std::cout << "Current time: " << t << std::endl;
  if (_validParameters) {
.............................................

[jonasseglare]

I understand now why the drawing of the wind direction is inconsistent with the table. For the drawing, we use the external TWA value. Debugging in [jo-true-wind-arrow-dev 6394530].

See the function getTwdir inside VectorTileLayer.js.

I don't know what the fix is to this. On the long term, our own TWA value should be good enough. But currently, it isn't.

[jonasseglare]

So Julien discovered issues with the calibration (sampling rate which is 10 Hz instaed of 1 Hz etc. And problems with the grammar producing indices referring to navs and the confusion resulting from that now that we use a NavDatset instead). Since we are working on Alinghi dataset which we expect to have fairly well calibrated instruments, maybe we can fix the calibration parameters to the defaults and see what our pipeline does with that. What are the nav records produced for the server? We have already seen that the true wind estimator, with default parameters, produces values close to the external ones (see https://github.com/jpilet/anemomind/pull/761). That way we can check the rest of the pipeline, assuming we have good calibration parameters.

[jpilet]

762 helps with true wind: it is less wrong. No good enough, though.

[jonasseglare]

Could it be that we use the internal GPS instead of the external one when we estimate the true wind? The internal one just contains zeros...

[jonasseglare]

[jonasseglare]

I looked at the filtered values that are used inside DispatcherTrueWindEstimator to compute the true wind in [jo-debug-true-wind-dev 5756567]. I fixed the calibration parameters to defaults, since I assume that the Alinghi instruments are already fairly well calibrated. I added all the filtered values to the dispather. This is that they look like for gps speed and bearing:

So it seems like we are using the internal GPS when computing the wind, despite its priority being lower than the external GPS:

Dispatcher:
  Channel of type awa named FILTERED (prio: -1000) with 14850 samples with 0 listeners ()
  Channel of type awa named NMEA2000/0 (prio: -10) with 386 samples with 0 listeners ()
  Channel of type awa named NMEA2000/c078be002fb00000 (prio: 0) with 145292 samples with 0 listeners ()
  Channel of type awa named NMEA2000/c0aa82002fb04000 (prio: 0) with 234717 samples with 1 listeners (0x58f7490 )
  Channel of type aws named FILTERED (prio: -1000) with 14850 samples with 0 listeners ()
  Channel of type aws named NMEA2000/0 (prio: -10) with 386 samples with 0 listeners ()
  Channel of type aws named NMEA2000/c078be002fb00000 (prio: 0) with 145292 samples with 0 listeners ()
  Channel of type aws named NMEA2000/c0aa82002fb04000 (prio: 0) with 234717 samples with 1 listeners (0x5109130 )
  Channel of type twa named Anemomind estimator (prio: 0) with 396742 samples with 0 listeners ()
  Channel of type twa named NMEA2000/c078be002fb00000 (prio: 0) with 145226 samples with 0 listeners ()
  Channel of type twa named Simulated Anemomind estimator (prio: 1) with 357261 samples with 1 listeners (0x4e97210 )
  Channel of type tws named Anemomind estimator (prio: 0) with 396742 samples with 0 listeners ()
  Channel of type tws named NMEA2000/c078be002fb00000 (prio: 0) with 290470 samples with 0 listeners ()
  Channel of type tws named Simulated Anemomind estimator (prio: 1) with 357261 samples with 1 listeners (0x556e6b0 )
  Channel of type twdir named Anemomind estimator (prio: 0) with 396742 samples with 0 listeners ()
  Channel of type twdir named NMEA2000/c078be002fb00000 (prio: 0) with 145244 samples with 0 listeners ()
  Channel of type twdir named Simulated Anemomind estimator (prio: 1) with 357261 samples with 1 listeners (0x7a37680 )
  Channel of type gpsSpeed named FILTERED (prio: -1000) with 14850 samples with 0 listeners ()
  Channel of type gpsSpeed named Internal GPS (prio: -2) with 46980 samples with 1 listeners (0x2646a10 )
  Channel of type gpsSpeed named NMEA2000/c07891002fb3645a (prio: 0) with 296941 samples with 0 listeners ()
  Channel of type gpsBearing named FILTERED (prio: -1000) with 14850 samples with 0 listeners ()
  Channel of type gpsBearing named Internal GPS (prio: -2) with 46980 samples with 1 listeners (0x7b32640 )
  Channel of type gpsBearing named NMEA2000/c07891002fb3645a (prio: 0) with 139461 samples with 0 listeners ()
  Channel of type magHdg named FILTERED (prio: -1000) with 14850 samples with 0 listeners ()
  Channel of type magHdg named NMEA2000/c050a0012fb3245a (prio: 0) with 131975 samples with 1 listeners (0x448f7d0 )
  Channel of type watSpeed named FILTERED (prio: -1000) with 14850 samples with 1 listeners (0x7932ab0 )
  Channel of type pos named Internal GPS (prio: -2) with 24856 samples with 0 listeners ()
  Channel of type pos named NMEA2000/c07891002fb3645a (prio: 0) with 310579 samples with 1 listeners (0x51097d0 )
  Channel of type dateTime named Internal GPS (prio: -2) with 16533 samples with 0 listeners ()
  Channel of type dateTime named NMEA2000/c07891002fb3645a (prio: 0) with 40278 samples with 1 listeners (0x7c2deb0 )
  Channel of type targetVmg named Anemomind estimator (prio: 0) with 404828 samples with 1 listeners (0x7a65440 )
  Channel of type vmg named Anemomind estimator (prio: 0) with 404828 samples with 0 listeners ()
  Channel of type vmg named Simulated Anemomind estimator (prio: 1) with 357261 samples with 1 listeners (0x59dc050 )
  Channel of type orient named IMU (prio: 0) with 344173 samples with 1 listeners (0x7c2e9e0 )

This is the output of the replayed dispatcher. Notice that the internal GPS has one listener for gpsSpeed and gpsBearing, but the external gps (NMEA2000....) has 0 listeners.

[jonasseglare]

For AWS, we don't have any problem. Notice the slight delay, though, due to filtering.

[jonasseglare]

So it seems like the bug may have been inside the SimulateBox function. Before, we assigned channel priorities after having replayed the data. But by doing so, the DispatcherTrueWindEstimator does not know about priority. The proper way to do it should be this:

  copyPriorities(src, replay);
  generateComputeCallbacks(src, replay, [&]() {
    estimator.compute(srcName);
  });

which results in this plot, for example, of the GPS speeds:

A few other plots, although there still seems to be problems:

All plots were generated using the visualize2.m file in the nautical/tiles directory.

[jonasseglare]

The TWDIR plot above looks quite bad, but it seems like the jumps are about 2*PI (360 degrees), so they are probably quite good.

[jpilet]

very interesting! we see how simulated anemomind estimator twdir correlates with gpsBearing and we see how good the B+G calibration is: N2K twdir is much less correlated! we should really use this navigation as a benchmark.

it is hard to say much regarding TWS

[jonasseglare]

Good idea to use it as a benchmark.

Regarding the reconstruction of the true wind, I deactivated the use of calibrated parameters for true wind estimator just to keep it simple. But maybe the curve will look different once I use calibrated parameters obtained from the fixed and refactored version of jp-rm-nav.

[jpilet]

Fixed by #762, #770 and #769

VMG target speed still broken, opening #772