Tactics Plugin

[Canne]

Originally Posted by rgleason

This one is not downloading "specs.4.8.gz" which was downloaded by wget and is in home/rgleason


is there a way to point it at that file?


gem install home/rgleason/specs.4.8.gz travis ?

Rick, it does not look that bad for a botched system!
Professional me tells me "redeploy from scratch since there is a method which works which works for me" but hobbyist me understands your attachment to this strange thing . I will look later on, now, quickly just try these:

sudo service ssh stop
sudo service xrdp stop

They are not needed in this gem travis business from the command line which you have on a Windows window.

[rgleason]

Actually it is a very "clean" install of WSL, xFCE, xRDP overseen by TDan.

However this morning decided that I needed to "allow" the firewall.
I have Norton, Under Norton 360 > Settings > Firewall > Program Control > Added
C:\Windows\System32\wsl.exe Microsoft Windows Subsystem for Linux Launcher

The standard xFCE WebBrower still did not work and I discovered that that is just two scripts that don't go anywhere and that there is no "internet browser" software loaded! So I need to pick one and install it. I use FF but that is huge. I think there must be a very good lightweight one that is good.

Have now tried in this very strange system

rgleason@Dart:~$ sudo service ssh start
* Starting OpenBSD Secure Shell server sshd [ OK ]
rgleason@Dart:~$ sudo service ssh stop
[sudo] password for rgleason:
* Stopping OpenBSD Secure Shell server sshd [ OK ]
rgleason@Dart:~$ sudo service xrdp stop
* Stopping Remote Desktop Protocol server [ OK ]
rgleason@Dart:~$ gem install travis -v 1.8.10 --no-rdoc --no-ri
ERROR: While executing gem ... (OptionParser::InvalidOption)
invalid option: --no-rdoc
rgleason@Dart:~$

What next?


https://github.com/bundler/heroku-bu...undler2/pull/1
https://stackoverflow.com/questions/...or-gem-install

Note that --no-ri and --no-rdoc have been deprecated according to the new guides. The recommended way is to use --no-document in ~/.gemrc or /etc/gemrc

So I'll try that.
https://guides.rubygems.org/command-...e/#gem-install

[Canne]

Originally Posted by rgleason

Actually it is a very "clean" install of WSL, xFCE, xRDP

I am sure, but you are not using it for the intended purpose which Microsoft/Canonical are defining: "Ubuntu 18.04 on Windows allows one to use Ubuntu Terminal and run Ubuntu command line utilities including bash, ssh, git, apt and many more.". If it can be done it does not mean that it should be done... the GUI and RDP add-ons certainly modify quite a few settings which may complicate our life. I installed one instance yesterday just to help you and on this fresh installation everything went like a charm as I described earlier.

Word of advice - if you do not mind - for your work once the travis is actually building those packages: use one server for one purpose! (like I do my job w/ 200+ servers.)
You can do it too, one virtual installation for travis work, one virtual installation for testing O with Ubuntu 18.04 LTS and yet another one with the latest Ubuntu version. When you don't need one, you just stop it. Read this how-to.

Ok, back to today's agenda:

Originally Posted by rgleason

The standard xFCE WebBrower still did not work...I think there must be a very good lightweight one that is good.

I have used in my resource poor Linux box successfully the low-footprint Midori browser - it works with GitHub (not all small browsers do). On my Ubuntu it installs with

snap install midori

This might be a good plan: it would be easier to debug with the browser if is this a network problem (it should not be, since the apt-get works). On the other hand, with wget-command you can test to retrieve a file from a known URL so you do not necessarily need a browser for that test.

Originally Posted by rgleason

Note that --no-ri and --no-rdoc have been deprecated according to the new guides. The recommended way is to use --no-document in ~/.gemrc or /etc/gemrc

In my procedure for 18.04LTS you noticed that I used successfully

gem install travis

The earlier instructions were created and tested with Ubuntu 16.04LTS and there was no issue (older software, obviously).

Originally Posted by rgleason

What next?

Let's see. In the list of known unknowns we have 1) Rick's Windows and its config, 2) Rick's ubuntu1804 command and its configuration.

To make sure that the issue is not with your Windows computer's settings, I would install a fresh minimal Linux on a VirtualBox (see above), start it, browse the Internet from it and then repeat the travis installation procedure on it.

For the second unknown, ubuntu1804's config, seeing that apt-get https:// is working but that there is an issue with the https://rubygems.org/ one can imagine that there is an issue with the SSL certificates (unlike with the browser, the script may not be verbose). Apparently, on ruby you can test SSL with this script:

$ ruby -ropen-uri -e 'eval open("https://git.io/vQhWq").read'

What can go wrong, for example is that if the clock of Ubuntu is not correct, future time will not be accepted. You can synchronize it (if not already done) with

sudo ntpdate ntp.ubuntu.com

Updating of certificates is so complicated that, before trying that we can try to upgrade the gem itself (with certificates):

gem install bundler
gem update --system

Let's see where we end up with these - thank you for trying!

BTW, don't you have your own thread here for the building process? Quite likely this build stuff does not interest Tactics users?

[rgleason]

Petri,
I am sorry, I have hijacked you and the thread the way this has evolved.
I've started a new thread here

WSL - Ubuntu - Install Travis CLI

I will read your last post carefully and respond in the new thread!


Also
O5 Linux in Ubuntu 18.04LTS for Windows10

[Canne]

OK, after a sidekick in the packaging business, I am now back to finalize perfomance tests in Dashboard-Tactics. Big silence here means either good (no more bugs) or bad (nobody's using my fork). Anyway, based on my porting effort, it’s time for some new ideas - all comments welcome, especially from those who have experience of NMEA 2000 vs. a NMEA 0183 multiplexer with WiFi or USB at 52kb/s:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Request for Comments
====================

Background
----------

Tactics algorithms are subject of suffering from the inaccuracy of the acquired data sets: bad or non-existing calibration of the instruments (cf. https://github.com/canne/dashboard_t...tactics_pi.pdf ) and the non-existing notion of timing in data, which is the subject of this study.

Problem statement
-----------------

NMEA 0183 is only a serial line protocol definition without a notion of time. We cannot have sets of data for magnetic heading, wind angle, speed, heel and pitch and assign those into a same, accurate moment in time. We cannot define a fixed time and request a new set of the data after that time. All we know is that data was collected somewhere within a time window which can be several seconds. We cannot say that when the wind angle was this the heel angle was that, right at that moment, the window is too large. When beating in heavy weather, for example, many things can and will happen to the boat and in its environment during this time frame but we cannot associate a data set to any given position of the wildly moving boat.

Possibilities for improvement
-----------------------------

We have two possibilities to improve the situation:

(1) - To keep the sampling rate and the data transmission method but add timestamps to the data

(2) - To increase the sampling rate and reduce the size of the aforementioned time window in which those samples belong to


Analysis in the practical context
---------------------------------


(1) - Is not practical since non-existent in COTS (commodity off the shelf) boat instrumentation. One would need to build one's own components (like with Rasberry Pi) into a NMEA 0183 multiplexer role in order to add the timestamps. Also, since NMEA 0183 does not define a timestamp field, we would need a proprietary layer on top of it.

(2) - Looks more realistic: NMEA 2000 ( http://www.nmea.org/Assets/NMEA 2000-digital-interface-white-paper.pdf ), based CAN-bus, available commercially ( eg. SeaTalk NG, Simnet, etc.) is much faster and allow better sampling rates.


Proposal for implementation
---------------------------

There is now a new plug-in ( http://www.cruisersforum.com/forums/...in-209706.html ) called "twocan" for NMEA 2000 to NMEA 0183 conversion to feed the OpenCPN - and eventually the Dashboard like all plugins who are interested in receiving NMEA 0183 data. From the GitHub feature description ( https://github.com/TwoCanPlugIn/TwoCanPlugIn ) we can read that it supports several CAN-bus adapters and - for Linux - SocketCAN. One can therefore assume that data is available from those sources at higher rates (2).

The hardware implementation would consist of connecting all the sensors which are used by Tactics' algorithms using NMEA2000-compatible interface boards (SeaTalk NG/2K, Simnet, etc) making sure there is no NMEA 0183 to NMEA 2000 conversion in between or that it would be one-to-one. NMEA2000-compatible bus would be connected to the computer with OpenCPN. One possible hardware platform would be Rasberry PI CPU under Linux with Waveshare CAN Hat.

The software implementation would consist of using twocan plug-in to feed OpenCPN main program with converted NMEA 0183 sentences at reduced speed. These sentences would also feed Dashboard plugin, to keep instruments working at the refresh speeds required by the human eye. In the background, Tactics algorithms would request from the twocan plugin the NMEA 2000 data at full speed, ignoring the slower NMEA 0183 data for the performance key data. For this, both the sending NMEA 2000 interface and the receiving Tactics algorithm would need to be detached from the OpenCPN plugin paradigm and so that they can be executed in their corresponding threads without allowing interruptions from OpenCPN or from its GUI, only from the operating system.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[bcn]

Originally Posted by Canne

(1) - Is not practical since non-existent in COTS (commodity off the shelf) boat instrumentation. One would need to build one's own components (like with Rasberry Pi) into a NMEA 0183 multiplexer role in order to add the timestamps. Also, since NMEA 0183 does not define a timestamp field, we would need a proprietary layer on top of it.

(2) - Looks more realistic: NMEA 2000 ( http://www.nmea.org/Assets/NMEA 2000-digital-interface-white-paper.pdf ), based CAN-bus, available commercially ( eg. SeaTalk NG, Simnet, etc.) is much faster and allow better sampling rates.

NMEA0183 4.0 (= IEC61162-1) does define "TAG blocks", one being time stamps.

http://www.cruisersforum.com/forums/...ml#post2885498

https://www.nmea.org/Assets/may%2009...00183_v400.pdf

Some days ago we had here in the Forum a thread about IEC 61162-459, or LWE (LightWeightEthernet), which is NMEA4.0 on Ethernet. The example data do show the TAGs nicely.
http://www.cruisersforum.com/forums/...ps-219524.html

An extension for VDR adding time TAGs would allow a synchronous playback, the same you are requesting to fine tune the performance data.

[rgleason]

For this, both the sending NMEA 2000 interface and the receiving Tactics algorithm would need to be detached from the OpenCPN plugin paradigm and so that they can be executed in their corresponding threads without allowing interruptions from OpenCPN or from its GUI, only from the operating system.

All of this is very interesting. I had not realized that Tactics was so restricted by lack of timestamps etc. This would be a much better instrument using Nmea2000. It sounds like it becomes a companion Tactics Program almost, but it has got to stay connected to OpenCPN due to the graphics on the screen... I guess it would have the faster Nmea2000/canbus communications (separate from Nmea0183) however.


I ask another stupid question. If this interface is done for Opencpn Tactics, how hard is it to do for all of OpenCPN? Maybe it is best to do it in smaller PI baby steps because it does not impact the entire program.

[transmitterdan]

OpenCPN is not a “real time” system. It is a huge conceptual leap to make it so. O is event driven not time driven. You will give up lots of potential platforms (Pi, Android, low power PC’s, etc.) to add real time features to the base requirement.

Personally, I don’t care which way it goes. But everyone should be aware of the pratfalls with making things happen in real time with specified latency. None of the supported operating systems have such RT features as are normally found in real time systems such as a high end MFD or an embedded device like AIS transceiver.

O exists precisely because it has a broad set of platforms and minimal requirements from the OS. If it was a real time system it would never have achieved the popularity it has today. 99.99% of users do not need nor want the overhead of a real time system.

Be careful what you wish for....

[Canne]

Originally Posted by bcn

NMEA0183 4.0 (= IEC61162-1) does define "TAG blocks", one being time stamps.

Thanks, that's interesting information. I can observe there is "CPC: Configure Parameter-code for UNIX time parameter". Without knowing the details of that, one can presume that NTP-protocol level inter-device time synchronization accuracy is reachable (10 - 100 ms), which is totally acceptable for the acquired data (I am not talking about vibration analysis of a foil, for example, just what we got now). So, theoretically and preferably timestamps should be used.

Originally Posted by bcn

An extension for VDR adding time TAGs would allow a synchronous playback, the same you are requesting to fine tune the performance data.

Absolutely, the data analysis would be much also more relaxed from performance constraints (see below Transmitter Dan's concern).

What worries me is that the standard is ten years old and I don't know are there many recent boats equipped with IEC61162-1 compatible COTS instruments?

I am looking for something more practical, which can be realized today, in a boat of about ten years of age and with a shoestring budget. With NMEA 0183 still but performance improvement for some key parameters = more data for analysis with better accuracy. NMEA 2000 - I have a little bit of it. I can add more. Maybe one day a live boat's 3D model? There is data for that.

[Canne]

Originally Posted by rgleason

I had not realized that Tactics was so restricted by lack of timestamps etc.

Well, it is not so restricted, Tom_r has added smoothing functions etc, and with my high speed multiplexer and USB connection it gets a lots of data to chunk. It just hurts me to give an algorithm values from multiple data sources without knowing when they were collected. What do I know if the data set contains some historical data from that previous wave. This is about a wish to have data sets which belong together with a known precision (the time and maximum delta is known).

Originally Posted by rgleason

Maybe it is best to do it in smaller PI baby steps because it does not impact the entire program.

I think we all agree on that, of course. This is just a RFC, nothing has been done yet, and even if will be done, that will be done outside of O, but coupled with it using some well established IPC method via a plugin. O's integrity would not be touched.

For the rest, I don't know. Accepting multiple data formats never hurts but I don't have any numbers of the actual market. Is NMEA 2000 worth to be interfaced coverage-wise, I don't know.

[Canne]

Originally Posted by transmitterdan

OpenCPN is not a “real time” system. It is a huge conceptual leap to make it so. O is event driven not time driven.

Fully understood and agreed. Myself, I wish to keep O that way, it is essentially a GUI which should remain event driven. Of course, if there is ever a modernization plans coming up, multi-threaded execution would be welcome (cf. any browser today), I am sure that good candidates for that can be found.

Originally Posted by transmitterdan

You will give up lots of potential platforms (Pi, Android, low power PC’s, etc.) to add real time features to the base requirement.

Agreed, that's why I proposed an implementation outside of O, in threads where the exact latency, jitter and other "real-time" parameters remains TBC. Anybody who wants to empty his boat's battery park with this can be warned, hey you need a four core for this but you have only two! The plugin which communicates with the external thread using an IPC method would protect O's integrity and hard-earned HW compatibility.

Originally Posted by transmitterdan

...such RT features as are normally found in real time systems such as a high end MFD or an embedded device like AIS transceiver.

Right, here one has a Can-bus interface card with some buffered memory and embedded protocol handlers. I am a fan of putting all type of real-time stuff (for me <1us range is RT) on FPGA's, for example. We're on the same page and this is widely accepted paradigm in distributed control and monitoring systems (which boat's systems also are) - the GUI is not the control system, it is for the operator, measurements and actions are executed in the background.

Originally Posted by transmitterdan

If it was a real time system it would never have achieved the popularity it has today. 99.99% of users do not need nor want the overhead of a real time system.

Completely agree, this RFC addresses that 0.01 % who is keeping inventing crazy needs like this and attempting to find solutions for them. Something good may get back one day to the bigger audience, one never knows.

[transmitterdan]

O has multiple threads.

[rgleason]

I tried to connect O to an artisense outputting nmea2000, thinking it was nmea0183 (boatyard communication problem), and I was getting strange figures in the nmea window, but O was accepting very high speeds. I think it was 105 mbps.
So maybe it could run faster? Maybe that would help with latency?

[bcn]

Given the low dynamics (in comparison) of boats, real time , i.e. resolution better than ms should not be required.

People racing top notch prototype yachts may have some different requirements, but my feeling is that data coherent within 0,1 to 0,5 s should be sufficient.
Data recording in the 1 - 2hz range.

Anybody working with data recording on recent racing yachts to comment?

[RonSouthworth]

Originally Posted by bcn

Given the low dynamics (in comparison) of boats, real time , i.e. resolution better than ms should not be required.



People racing top notch prototype yachts may have some different requirements, but my feeling is that data coherent within 0,1 to 0,5 s should be sufficient.

Data recording in the 1 - 2hz range.



Anybody working with data recording on recent racing yachts to comment?

Hi Petrie,

There is a breakpoint I think when you simply may be better off utilising instrumentation and control systems technologies, probably in terms of effort / cost of ownership may be more beneficial an approach to use. Wanting to know what a value is every 100ms is not a small demand, plenty of real time OS solutions (SCADA) with real time databases, lots of tools to very easily create dashboards etc. the main challenge is in porting vector graphics and usually keen to sponsor racing folks as well ?

/Ron