Onderwerp: Sailing Performance Dashboard op de Raspberry Pi

PI draait Debian denk ik?
Die linux-smaak doen we niet, Er is een versie van SPD voor Ubuntu,

Er is geen beginnen aan om meerdere ux-veries te ondersteunen, er zijn er teveel en ze verschillen teveel.

Als iemand een manier weet om op Github een Debian-compilatie van Python 3 met veel TCL-TkInter te maken dan horen we (Menno en ik) dat graag.

Ubuntu ís een Debian variant. Bovendien doet ie het hier op Fedora ook gewoon prima. TCL-Tk is geen probleem.

Het punt met compileren voor aardbeien is dat ze een ander type processor hebben. Geen x86 maar ARM. Python3 zelf doet het er prima op, maar gecompileerd wórdt het processorspecifiek.

Dat kan Github vast wel, maar ik heb nog nooit iets door Github laten compileren, dat doe ik altijd zelf

Echt gecompileerd is het niet, het is meer een pakket (de exe) waar alles in zit: de applicatie SPD, de Python3.9 interpreter en de nodige pakketten
- pyserial voor de COM/USB,
- TCL/TK voor de GUI,
- pyttsx3 voor speech is er alleen voor Windows
- aiohttp, asynchrone I/O voor webserver output.

De interpreter moet natuurlijk wel de juiste machinecode voor de cpu opleveren, en de Ubuntu-versie doet dat niet voor ARM.
Er is vast wel Python 3.9 voor ARM, maar daarmee is nog niet gezegd dat de nodige pakketten er ook voor bestaan.

En ik ga geen OS- en/of HW-specifieke versies maken.
De huidige versie is geschikt voor Windows 10 en voor Ubuntu, zonder enig verschil in de sources.
Er is maar 1 set sources en die gaat zo de Windows- en de Ubuntu-compilatie in.
En dat wil ik graag zo houden.

Edit:
even wat gegoogled.
Python op ARM is er alleen voor Windows.
En de 4 benodigde pakketten zijn er niet op ARM-Windows.

Frambozen gaan het niet doen.....

Bovendien schat ik zo in dat ze er erg warm van zouden worden.
Mijn Core i5 is zomaar 6 a 8% bezet met live SPD.

Python voor ARM is er gewoon hoor, wordt op de Raspberry Pi zelfs als aanbevolen programmeertaal meegeleverd.
De Linux-versie wordt gebouwd op Ubuntu maar is compatibel met de meeste recente amd64/x86_64 Linux-distributies.

Menno schreef :
Ok, ik kon het niet vinden....

Zouden pyserial, TCL/Tk en aiohttp er ook zijn voor Pi/ARM/debian

Dan kan Github er misschien een versie voor samenstellen....

Nog 1 plaatje dan, van de 24uurs....

blauw de gevaren TWA's, linker as.
De steilte van de lijn laat zien hoe vaak een bepaalde TWA voorkomt.
Veel 80 tot 105.

Oranje de Performance. Rechter as.
Keurig rond de 100%, totdat de TWA boven de 90 komt, ongeveer in het midden.
Dan zakt de performance in tot 90% bij TWA 130...
Meest rechtse stukje is nauwelijks data (zie de steil oplopende blauwe lijn).

Storm spi met wat holle lijken? En dan laag hijsen op een nieuw aan te brengen valhoogte? Boom tegen de voorstag dan blijft de spinaker vrij van die voorstag. Kan dat zonder penalty?

Baasklusje schreef :
Zou het makkelijker zijn als spd berekeningen en de ui gesplitst zijn? De berekeningen in puur python zijn waarschijnlijk meer portable. En beter als black-box bruikbaar. Ik probeer aan boord één geïntegreerde web omgeving te draaien. Het zou mooi zijn als spd dat ook in past. Dan zit je niet op extra toeters en bellen te wachten.

Het tonen van de info kan dan in een app of webbrowser.

Baasklusje schreef : Logisch!

De drie noodzakelijke modules zijn zonder twijfel modules die in de pi community ook stukgedraaid worden. Ik heb ze voor de zekerheid opgezocht.

Python is ongeveer hét ontwikkelplatform voor aardbeien, juist ook op toepassingen met seriële poorten en ander klein aangekoppeld grut. TCL/Tk ook standaard aanwezig. In hoeverre ie het qua CPU aankan kom je maar op één manier achter

Baasklusje schreef : Daar gaat de polar blijkbaar toch van spinnakeren uit. In hoeverre dat reëel is, is aan de crew natuurlijk

Een modulaire opzet vereist een gestandaardiseerd data model. Dat lijkt me heel lastig te realiseren het is al een prestatie op zich van de baas dat hij Sailing Performance Dashboard voor een behoorlijke groep werkend heeft gekregen.

Beauty schreef :
Zoiets zou kunnen helpen, of een asym spi op de spiboom. Wel klein, want het is al gauw te groot met die 20kts wind. Kan allebei zonder penalty, want de grote spi staat op de meetbrief.

In de grafiek ziet het er overigens erger uit dan het is.... nog altijd 90% performance bij 140 TWA.... zonder spi.

michaelh schreef :
De GUI (TCL/Tk) is overal voor nodig:
- infoberichten en foutmeldingen
- kiezen opstartfiles (polar, heelpolar, deviatietabel, stw-correctie)
- bediening van alle knoppen (filters etc etc, 27 knoppen)
- display van data op scherm
- en ik vergeet vast nog wat.
Die calls naar TCL/Tk zitten dus overal in de code, dat is niet te scheiden van de berekeningen.

Wat wel kan is na de opstart het scherm uitzetten. (knop Display Off)
Dan komt alle andere output gewoon nog door (NMEA, UDP-Wifi, webserver, log).
Dan kan je alles in een app of browser bekijken (de html moet nog eromheen, de webserver output werkt).

Als iemand denkt dat een 'compilatie' (Github) voor Debian op ARM werkt (inclusief de 3 benodigde libraries) dan kunnen we dat proberen.
Wel op Github, want daar zitten de Ubuntu- en Windows-compilaties in 1 pakketje en Github vult ook meteen de download-directory op mijn google drive.
(de iOS-versie voor Apple doen we niet meer; hopeloze TCL/Tk support van Apple).

Baasklusje schreef : Met een sym op de meetbrief kun je toch niet zomaar een asym hijsen?

Ik wil wel een poging wagen op verschillende pi uitvoeringen als je het pakket kan laten compileren voor de pi. Kunnen we ook kijken wat de performance is.

Is het mogelijk om de source ergens te bekijken voor de afhankelijkheden?

Het is 100% Python 3.9

Dit zijn alle imports uit Python zelf of uit 1 van de 3 libraries (pyserial,pyttsx3,aiohttp)

import asyncio
from queue import Empty
from aiohttp import web, WSMsgType
from math import cos, radians,tan,atan,degrees,sin,sqrt
import time
from time import sleep
from string import Template
import platform
import sys
import os
import gc # garbage collector
import serial,codecs,io # uit pyserial
from tkinter import *
from tkinter.filedialog import *
from tkinter.messagebox import *
import socket
import threading
from queue import Queue, Full
import pyttsx3 # for speech
from pyttsx3.drivers import sapi5

pyttsx3 is er alleen voor Windows, niet voor Ubuntu. Het zorgt voor spraak-output ( die er dus alleen in Windows is).

Kan je daar alvast wat mee?

Baasklusje schreef :
pyttsx3 is er ook gewoon voor Linux, maar heeft externe dependencies

Baasklusje schreef :
De downloadbare packages wordt gemaakt door GitHub Actions, op de hosted runners die ze aanbieden. Die runners zijn er in de smaken Windows/Linux/macOS, maar alleen voor x86_64

Het is wel mogelijk om op die runners weer een emulator te draaien die de armv7/aarch64 architectuur van de Raspberry Pi emuleert, maar ik weet niet hoe goed dat werkt.

Ondertussen versie V2.2.2 gemaakt en online gezet.
Wijzigingen:

Version 2.2.2 of 22 September 2021
- Corrected an error in calc_upwash routine when 3rd Gentry param was a 0. This 0 means 'no extra upwash at wider TWA's'. It works now.

- Corrected the routine to correct AWA (for heel, leeway and upwash): big upwash could cause negative AWA... which is nonsens obviously

- Corrected small error in calculation-interpolation of target speed; when big differences between boat speeds are in the polar, f.i between 6 kts and 3 kts of TWS (resulting in 5 resp 1 kts of boat speed) the interpolation delivered somewhat low target speeds. Now corrected.

Op www.capolavoro.nl/download nu twee nieuwe versies:

• linux-aarch64: 64-bits ARM
• linux-armv7: 32-bits ARM

Ze worden nog niet automatisch voor elke nieuwe versie geüpdatet, eerst maar eens kijken of het überhaupt werkt.

Ik ben heel benieuwd.....

Ik ook. Het wordt wel tijd voor wat meer info op de Gotcha! Hopelijk dit weekend wat tijd om het uit te zoeken. We draaien de pi's alleen headless (zonder VNC, de meeste output gaat naar dedicated devices, apps, laptops of webbrowsers die daar zelf beter voor kunnen zorgen), dus het account waar het onder moet draaien en VNC moeten even uitgezocht worden.

Ideeen voor het vervolg:
- Echt headless draaien, dus alle benodigde parameters bij het opstarten doorgeven of op een andere manier zorgen dat we de ui op de pi niet nodig hebben of kunnen verbergen. Mooiste zou zijn geen ui,scheelt performance op de pi.
- Koppelen met signal k, zou misschien kunnen met de homemade nmea output. Nadeel is dat er dan in de pi weer een plugin nodig is die vertaalt naar signal k messages. Alternatief is mogelijk de udp messages, maar daar komt meer "string" parsen bij. Allemaal niet efficient.
Mooiste zou zijn als SPD ook een output krijgt voor Signal K messages.

Een signal K software-mux snapt toch ook NMEA? Misschien een enkel berichtje aan die kant toevoegen. Lijkt me veel eenvoudiger dan een volledige Signal K uitgang aan SPD toevoegen.

He interessant: ik zag net op GITHUB een verzoek aan AvNav om SPD te ondersteunen . . . . wordt leuk (alhoewel niet voor mijzelf interessant).

Blijft toch fantastisch speelgoed!
In actie in de 200myls:



Maar dr zijn grenzen:


Bij 25+ en dikke golven gaat de laptop er van door.

Zal eens kijken naar een robuustere setup.