Onderwerp: Sailing Performance Dashboard

Dat werkt. Dank hanst.

Ik zal eens kijken hoe ik dat kan toevoegen aan SPD, maar eerst zou ik graag wat specs hebben over wat het nu precies moet worden als je headless wil draaien.
De komende v2.7.0 (nog even de manual bijwerken) start op met alle parameters uit de ini-files, en dan zonder enige scherm-output, dus ook geen knoppen.
Het kan zijn dat er een fout optreedt waardoor er een schermpje oppopt, maar dat zie je dan niet.

Al die pop-ups indien headless vervangen door iets anders kan (veel werk, maar niet ingewikkeld)
Het bedienen van knoppen én daar feedback van geven (de actuele stand van een knop of een filter) moet dan ook op een of andere manier.

Het voorbeeld van hanst gebruikt een line-terminal (telnet) om een knop-functie aan te sturen.
Dat lijkt me niet ideaal; tekst tikken in een terminalvenster. En hoe weet je welke tekst....

Dus.. hoe stellen we ons voor dat je headless SPD gaat bedienen.

En misschien is de onbedienbare headless versie die v2.7.0 nu al is wel voldoende.
Je kan via de webserver alle output zien, ook de standen van de knoppen.
Als dat voldoende is hoeft alleen het bedienen van knoppen en het melden van pop-ups erbij.

Overigens wil ik mijn tijd liever besteden aan het toevoegen extra nuttige informatie-meldingen aan de zeilers. Nu zijn er header-lifter (velocity en echt) en stroom-waarschuwingen.
Maar op het scherm kan je ook zien of de helling te groot of te klein is.
Dat zou een waarschuwing kunnen worden. Te veel of te weinig helling.
Idem voor roerhoek.
Voor te hoge of lage TWA aan de wind, of een foute DA.
Die waarschuwingen kunnen via voice ("Don't Pinch! ", "High Heel" ) of elke andere vorm van output.
En zo is er een heleboel te verzinnen dat echt kan helpen om sneller te varen.
Dat is de bedoeling met SPD; niet om extra technische hoogstandjes te verzinnen....

As we speak is Github aan het werk om versie 2.7.0 samen te stellen.

Version 2.7.0 of 9 January 2022
- It is now possible to use SPD without a screen. Output will not be available on screen, but it will be there in all 7 other channels for output such as voice, NMEA (serial or network), webserver, logfile, NMEAlogs, wifi-UDP messages.
A result of not having a screen is also not having the buttons of SPD. It is hence not possible to change values (thresholds, filters etc) when running. This can only be done using the values in the ini files read during start.
You start a headless (no screen) SPD by simply having a file named headless.ini in the /systemfiles/ folder of SPD. An empty file will do. Just its existance is enough. Rename it or delete it when you want on-screen info again.
You should realise that no info- or error-messages can be seen in this headless mode.
Also no choices can be made, as the headless mode automatically switches on the Noquestionsasked switch to Y.
Voice will still be determined by the boatspecifics:
[Outputcontrol]
speech interval = 5
Set it to 0 to stop her talking.

Dat is voorlopig wel even genoeg
van 1 december tot nu flink veel uitbreidingen:
- de ini-config files ipv de txt files
- met heel veel nieuwe variabelen!
- TCP en UDP als NMEA-sources toegevoegd
- screen-layout user-configurable gemaakt
- veel knoppen toegevoegd en/of verbeterd
- en nu dus headless (voor de non-Pi gebruikers: zonder scherm. Dat ze dat willen.... onbegrijpelijk)

Ik was van plan nu eerst even te gaan skiën, maar ik weet niet of dat verstandig is....

Baasklusje schreef :
Oke, ik hap. Headless betekent dat de user interface niet meer direct gekoppeld is aan de applicatie. Alle meldingen, knoppen, inputs zijn dan los van de applicatie geïmplementeerd. Er is generieke input / output (via streams, functies of telnet in de demo van Hans). Dit betekent niet dat je gelijk die IO als gebruiker aan moet roepen, maar het zorgt ervoor dat iedereen die dat wil zelf zijn eigen user interface of IO kan koppelen. Hoe je SDP headless gaat bedienen is niet interessant en ik denk ook dat je dat juist nu niet weet omdat iedereen andere wensen heeft. De huidige user interface zou bij een goede opzet ook gewoon van de headless code gebruik kunnen maken. Een tweedeling kan er ook voor zorgen dat je je kan richten op de informatie meldingen en berekeningen, terwijl anderen bezig kunnen zijn met de manier waarop ze dit op hun boot zichtbaar willen maken (via spraak, klokjes, displays of iets anders). Bij een goede verdeling hoef je ook de code voor de berekeningen niet vrij te geven, maar kan wel iedereen die dat wil het op zijn eigen manier integreren.

Ik denk dat een ontkoppeling tussen SPD berekeningen etc en de UI de modulariteit ten goede zal komen. Lastige is dat je dit niet vooraf bedenkt en dat het best wat werk zal zijn om de huidige programmatuur aan te passen. Is het een idee om een headless applicatie op te zetten zonder enige berekening, maar wel de inputs/outputs waarvan we weten dat SPD ze nodig heeft? Dit kan dan een goede test/demonstratie van het concept zijn, zonder dat het op dit moment veel tijd kost. Op het moment dat het concept dan staat zijn de berekeningen eventueel over te zetten?

De vraag is ook wat je allemaal zou willen doen binnen SPD in een headless situatie....
- Replay lijkt me niet, dat vraagt om filenamen van de te replayen logs. Beter met scherm.
- files selecteren voor boatspecifics, polars, stw-correctie, deviatie: ook niet. Dat doe je vooraf, met scherm. Of je edit startupfiles.txt waar ze allemaal in staan en start dan blind op.
- Postprocessing ook niet: dat wil logfiles lezen en die moet je selecteren. Is bovendien een achteraf bewerking die je thuis zal doen. Maakt ook afbeeldingen op het scherm.
- Pre-processing (polar maken uit een meetbrief bij ORC) ook niet. Eenmalig vooraf.

Blijft over:
- het ontvangen van error- en info-meldingen. Daar ben ik aan bezig. Je kunt straks als target opgeven het scherm, de standaard-print-out, en nog meer targets die we nog even niet kennen. (momenteel 7 parameters daarvoor gereserveerd in SPD_showerror en SPD_showinfo)
- Soms wordt er een ja/nee vraag gesteld. (tk askquestion). Dat kan ook met een SPD_askquestion opgelost worden waarbij het antwoord wordt ingetikt o.i.d.
- het drukken op knoppen. Elke knop is een functie-aanroep in SPD. Daar zijn er 31 van. Hoeven niet allemaal headless: snellere/langzamere replay niet, bijvoorbeeld...
Het zijn allemaal functies die zonder parameters worden aangeroepen. Die kunnen vast op een andere manier worden aangeroepen dan met de knop-klik.

Tk/tcl zit er ook in (omheen, eigenlijk) om op te letten of er buiten de loop van SPD nog iets gebeurt (een knop!) . Dat gaat nu allemaal vanzelf, omdat heel SPD draait binnen de root.mainloop() van Tk.
Als het ware een stukje besturingssysteem om SPD heen om op de interrupts van de knoppen te letten.
Daar zit het lastige stuk.
Opdrachten om functies uit te voeren (knop) op een andere manier inserten in SPD zullen we iets voor moeten zoeken. Bijvoorbeeld binnen de loop van SPD steeds even kijken of er op een queue (in aparte thread) nog iets is neergezet waar wat mee moet.

Ik denk dat we een heel eind zijn als de showinfo en de showerror op een nette manier ook zonder scherm de gebruiker bereiken. Print, of via de webserver output. Dan zie je iig de info en de foutmeldingen.
Volgens mij zal de behoefte om input aan SPD te geven (knop) tijdens het varen minimaal tot nul zijn, als je vooraf goed alle parameters hebt ingesteld...

Aan de outputkant is m.i. al gerealiseerd dat de gebruiker dat helemaal zelf kan invullen.
Zowel met NMEA-records met eigen invulling als ook met de webserver. Daarkan iedereen mee doen wat hij wil (zoals je als geen ander weet )

Het geheel uit elkaar trekken van SPD in een UI-deel en een rekendeel zie ik niet als mogelijk. Dat zit allemaal veel te geintegreerd in elkaar (tk als schil om SPD heen)
Andere manieren van output versturen (print, webserver) ben ik aan begonnen.
Andere manieren voor een deel van de input (sommige knoppen) is een overweging waard.

Als voorbeeldje:
hoe stel je je voor dat de knop IO&Files dan zal worden behandeld?
- die geeft eerst een overzicht van gebruikte files (polars, correcties)
- en vraagt dan of je een andere polar wil gaan gebruiken.
- zo ja: dan moet je een polarfile kiezen. Hoe gaat dat dan??? Nu krijg je een schermpje met alle beschikbare polars. Geheel vanzelf verzorgd door Tk askopenfilename() dat de functies van het OS daarvoor aanroept. Klik er een aan en klaar.

Een voorbeeld van hoe headless met een webui werkt is bijvoorbeeld de H5000 van B&G.
Dat wordt door allerlei topteams gebruikt, waardoor we volgens mij kunnen aannemen dat het 'proven technology' is.

www.blur.se/2019/03/23/bg-h5000-calibration/
Een webinterface waarmee je values van variabelen kunt veranderen. Net als dat je op Zeilersforum een plaatje kunt uploaden is het uploaden van een Polar ook geen probleem.

Het halve internet werkt zo en de software van de top teams werkt zo. De technology is niet het probleem.

Heel mooi en je ziet het overal inderdaad. Maar dit had wel van begin af aan een ander ontwerp van SPD gevergd lijkt mij?

Ik kan mij vergissen, maar volgens mij is SPD "gewoon" gestart als vervanging van het obsolete TacticTool; als (ik bedoel dit niet negatief!) "ouderwetse" PC applicatie met verweven GUI?

Het zou wel gaaf zijn een modulaire open-source app met webHMI te ontwikkelen waar mensen aan kunnen bijdragen op die vlakken waar ze goed in zijn/hun passie ligt, maar is het daarvoor niet te laat nu?

Nachtvlinder schreef :
Niet te laat, maar voor de meeste gebruikers ook helemaal niet nodig

Overigens, de getoonde calibratie-functies zitten (grotendeels plus een paar extra) allemaal in SPD.
Op basis van de logfiles maaktSPD je STW- en Deviatie-correcties ook nog gecorrigeerd voor helling (gaat vanzelf met een post-processor).
Rekening houden met helling-invloed op AWS en AWA, etc, is er allemaal.
En een nette ground wind-berekening ook. Getest en blijkt geen afwijkende windrichting te geven bij tacks (de holy grail, immers....)

Alleen doet B&G dat live (als je tijd en moeite erin steekt) en niet obv een log (lekker thuis achter de PC). En als je het live doet moet je wel die metingen live kunnen opslaan...

Alsnog gefeliciteerd met deze vergeten verjaardag Thomas!

Ruim een jaar serieus aan het ontwikkelen al! Ik denk dat je voor velen in een lang gekoesterde behoefte aan het voorzien bent en dat op een zeer gestructureerde manier doet!

Dat wordt gewaardeerd

dank, dank!

Het is een leuk hobby-klusje voor de rustige uurtjes.
Als ik programmeur had willen worden had ik dat 50 jaar geleden wel gedaan...
En het gaat verder en verder.
Inmiddels zit er van alles in waar ik niet van had durven dromen toen ik begon.....

En jullie gooien mij steeds nieuwe uitdagende kluiven toe....

De meest recente is dat headless gedoe, met output naar en input van andere channels dan het scherm (met tK/tcl)
Updateje:

inmiddels kun je in processfile.ini het UIchannel opgeven. Nu screen, printer of web.
Dan wordt de output van info- error- en askquestion-routines gerouteerd naar scherm (bekend, tk/Tcl), naar printer (stdout van Python) of naar de webserver gestuurd (waar ook alle data in uitkomen).

Dat werkt allemaal!
Voor de input zijn er de bekende knoppen bij UIchannel=screen, als de UIchannel=printer dan kun je een antwoord typen als er een vraag gesteld is (maar nog niet een knopfunctie opstarten), en voor UIchannel=web is er nog niets voor input.

Het is nu headless en ietsje minder blind en doof.

Tsjonge wat een gekloot om niet via het scherm (met tk/tcl) met de gebruiker te communiceren....

Een voorbeeldje....
Wat nu als SPD bij de start een fout vindt in de file waarin Y of N de webserver wordt gekozen....
En je die fout wilt melden via de webserver
Die niet gestart is omdat er een foutje in de file zat waarin hij wel of niet werd aangezet...
En dat foutje kan dan niet gemeld worden.
En zomaar een queue naar een webserver starten zonder IP en poort is ook zo wat...
Een eeuwenoud bootstrap probleem...

Met print (stdout) gaat dat beter. Net als een Tk-window is dat er altijd gewoon en je kunt er berichten op kwijt.
Maar we worstelen door

haha, ik heb hier eens even een paar pagina's gelezen, snap er helemaal niks van. Maar het lijkt een mooi project.

Volgens mij moet je het anders zien.

Die web UI voor een headless setup is een ‘window’ om naar binnen te kijken.
Errors worden per definitie lokaal gelogd in een file.
Via de web UI kan je daar naar kijken.

Geen webserver? Draait t gewoon door.
En zo nee? Dat wordt t in de file gelogd.
Met inderdaad t risico dat iemand op de command prompt (of lokale desktop) aan de gang moet om de webserver te starten voor remote toegang, of om t probleem te fixen.

HenkT schreef :
Gewoon even downloaden en ermee spelen! Dan wordt alles duidelijk

www.capolavoro.nl

De status van headless en een paar vraagjes.....

- als er in \systemfiles\ (van SPD) een file headless.txt bestaat dan wordt het scherm niet gebruikt.
- in die file moet de 1e regel dan 'printer' of 'web bevatten
- daarmee bepaalt SPD waar de meldingen en vragen heen moeten.
- als die 1e regel '' web' is moet regel 2 een IP zijn en regel 3 een port. Daar gaat de output dan heen.

Aan en uit zetten van headless kan dan door die file te renamen. Op deze manier is vanaf het allereerste moment bekend waar meldingen en vragen heen moeten, zonder ini-files te lezen.

Het op Y zetten van Noquestionsasked in processlist.ini doet 2 dingen:
- zorgen dat er geen meldingen en vragen komen
- opstarten met dezelfde 5 files als laatste keer (polar, heelpolar, boatspecifics, deviation en stwcorrectie). Al die filenamen zitten in /systemfiles/startupfiles.txt.

Het lijkt me dat headless opstarten maar dan wel filenamen moeten opgeven via terminal of webserver niet een goed plan is. Het is erg onlogisch om dat te willen. Je zou beter startupfiles.txt even kunnen editen als je zoiets wil.

Dus in headless mode nooit vragen naar filenamen. Die moeten dan altijd uit de startupfiles.txt komen.
Zijn de Pi-gebruikers het daarmee eens?

Blijft over dat in headless mode naar de terminal of web gestuurd worden:
- infomeldingen
- foutmeldingen
- een enkele vraag waar ja of nee op geantwoord moet worden.
Deze laatste 3 dus alleen als Noquestionsasked op N staat! Anders komt er niets.

Alles samen geeft dan een headless situatie als volgt:

- helemaal niets aan output of vragen (via terminal of web) als Noquestionsasked op Y staat.
- info, foutmeldingen en ja/nee vragen als het op N staat.
- nooit filenamen kunnen invoeren. Wel kunnen editen in startupfiles.txt

Is dat ongeveer naar wens?

Dat is al ongeveer klaar...

Volgende wordt dan het bedienen van een knop via terminal of web.
Dat is weer een heel andere uitdaging....

Mooie ontwikkelingen. Misschien is het handig Sailing Performance Dashboard op het forum te splitsen in 2? SPD ontwikkeling en SPD gebruik. Dan blijft het ook voor pure gebruikers interessant, terwijl anderen jou van allerlei uitdagingen voorzien
Baasklusje schreef : Nogmaals headless betekent alleen dat de UI losgekoppeld is van de programmatuur. De UI kan dan evengoed weer lijken op de huidige UI en is geïnteresseerd in dezelfde input en output. Sterker nog, bij een modulaire opzet kan je eigen GUI ook van dezelfde interfaces gebruik maken. Ga er vanuit dat je in een headless setup dezelfde informatie via een webinterface wil kunnen tonen en dezelfde meldingen en interactie met de gebruiker wil kunnen hebben, maar ook dat je zaken via een command line kan scripten. Via print of web een filenaam opgeven gebeurt dan gewoon door een applicatie met een dialoog (niet veel anders dan de huidige GUI) of door als parameter aan een executable door te geven en niet door handmatig in te typen. Voor de startup files zie ik 2 oplossingen: of je start met de juiste bestanden in startupfiles.txt of je biedt een services (via print of web) om de namen aan SPD door te geven. Performance berekeningen starten dan pas al alle bestanden compleet zijn doorgegeven. Dat eerste is de oplossing die we al gebruiken. Als je van startupfiles ook een ini maakt, kunnen we makkelijker per bestand aanpassen.
Baasklusje schreef : Ik zou de info en foutmeldingen gewoon uitsturen. Als er iets niet opstart val je terug op print zodat de fout altijd te achterhalen is en je niet met een black box zit die niets doet..
Baasklusje schreef : Bedienen van een knop zal een opdracht moeten zijn, waar je gelijk alle benodigde informatie mee geeft, dus zo min mogelijk interactie omdat weer complexiteit en afhankelijkheden in de communicatie veroorzaakt. Voor bijvoorbeeld het schrijven in de log kan je een opdracht maken die mee geeft wat er in de log moet komen.

Een idee is misschien dat je zelf het hele concept test door bijvoorbeeld de postprocessing op deze manier vorm te geven? Aanroepbaar zonder user interface. Kan je mogelijk ook nog kijken of hier performance te winnen is.

Dank voor je antwoord michaelh.

Ik snap dat in een headless situatie bediening (vragen, antwoorden, knoppen, files selecteren) idealiter er ook allemaal bij horen.
De complicatie is dat SPD draait binnen een loop van Tk, de gekozen GUI.
Die Tk-Mainloop doet alle afhandeling van interrupts (knoppen), alle file-selectieschermen, etc etc.
Daarmee is het een soort besturingssysteempje om SPD heen.
Dat gaan uitbreiden (vervangen kan niet, wegens de screengebruikers van SPD!) met support voor nog ongedefinieerde user interfaces op externe apparaten, met een ook nog ongedefinieerde manier van communiceren tussen SPD en die externe UIs, ga ik vooralsnog niet doen.
De laatste maanden ben ik bezig geweest met allerlei mooie uitbreidingen, zoals TCP en UDP ipv serieel, en zeker ook (dank Menno!) met de 2 versies voor de Pi-besturingssystemen.

Maar er zijn andere dingen die voor alle SPD-gebruikers een stuk nuttiger zijn: allerlei live adviezen om sneller te varen. Trimadviezen gebaseerd op real time waarnemingen!

Wat er nu wel allemaal al werkend in zit (binnenkort v3.0.0) :
- keuze tussen screen of headless (ok, cheapo headless ) met de aanwezigheid van de file headless.txt in /systemfiles/
- is die er, dan geen schermen meer. Zo gedaan ivm compatibiliteit met bestaande gebruikers met screen.
- in die file moet dan 1 regel met 1 van deze 2 woorden: printer of web
- daarmee kies je de output voor info- en error-messages.
- Je ziet dus als printregels (terminal) of op de webserveroutput alle info, fouten en afsluiten langskomen.
- als je Noquestionsasked op Y zet komt er niets meer langs (niet op screen, niet in print en niet in webserver) en zie je dus niet of de start goed gaat en of er fouten optreden.

Voorlopig lijkt me dat met dit alles redelijk headless te werken valt. Het is heel veel meer dan er een maandje geleden was

Zorg vooraf voor alle goede instellingen en filekeuzes (startupfiles) en geniet van alle nuttige informatie die eruit komt

De volgende uitbreidingen van SPD die ik ga maken zullen adviezen zijn om sneller te gaan.
Met alle live data bij de hand moet daar iets van te maken zijn.
Een soort trimclinic-by-computer
De modaliteit waarin die adviezen worden aangeboden is aan de gebruiker; alle mogelijkheden zullen worden ingebouwd.
We hebben nu al op het scherm, in de NMEAberichten en in de webserverdata de waarschuwingen bij Headers en Lifters, zowel echte als de velocity-versies.
Ook de mededelingen over waar de stroming vandaan komt en hoeveel die is zitten daarin.
Spraak met zulke waarschuwingen kan eenvoudig worden toegevoegd.
Ook in de simpele tekst-UDP berichtjes (voor op je telefoon!) kunnen ze erbij.

De vraag is wat er nog meer nuttige mededelingen nodig en mogelijk zijn.
- te hoog varen ("pinching")
- te diep downwind varen
- teveel helling (minder druk maken)
- te weinig helling (te weinig zeil)
- te weinig twist (onder 7 kts TWS, te langzaam varend)
- te weinig twist (boven 12 kts TWS, te veel helling)
- te veel roeruitslag (en teveel helling)
- gebruik buitenschoot genua (tussen 70 en 100 TWA)
- enzovoorts...

Nog voorstellen iemand?

Op dit vlak ben ik vooral aan het leren. Misschien kan je hier iets mee
- Te snel gijpen of overstag waardoor de snelheid af neemt.
- Te veel koerscorrecties na een gijp of overstag.
- Te plotselinge stuurbewegegingen om koers te houden.

Feedback voor de stuurman: Te traag reagerend op windshifts (of reactietijd tussen de shift en stuurcorrectie)
Slingeren qua koers.

Wat Michael al zegt: te snelle of juist te langzame overstag.
Feedback op bootbehandeling?
Verstreken tijd tussen de overstag/gijp en weer op snelheid zijn?
Verstreken tijd tussen om spi te hijsen en tot hij staat?
Verstreken tijd tussen de spi-drop en de boeironding?

Ik denk wel dat je dan wellicht ook een keuze moet kunnen maken in welke info je wel en niet wil zien op het scherm.

hanst schreef :
Kon het natuurlijk niet laten dat te proberen in SPD.

Maar... het levert een conflict op tussen de verschillende Threads.

De Tk root - Mainloop vindt het niet goed dat in de routine def accept_incoming_connections(): een Thread wordt gestart outside the main loop, zegt ie.

Het leek me juist leuk om met een TCP-verbonden device (TCP-viewer oid) de knoppen te kunnen bedienen (en ook in headless mode natuurlijk).
Ik geef die poging weer even op.

Thomas,
Ik kreeg onlangs het “aanbod” over te stappen op Windows 11.
Ik ben nooit zo happig op dat soort dingen, maar al helemaal niet als dat gedoe geeft met SPD. Dan stap ik zeker niet over
Heb jij al ervaring met SPD en Windows 11?

Alle drie mijn laptops zijn niet geschikt voor W11, te oude CPU. Zijn 5 tot 8 jaar oud....
Geen ervaring dus, maar ik denk dat Python zomaar probleemloos zal werken en SPD dus ook.

Dank je Thomas

In het kader van: there is always another bug (ook in Windows 11 ):

iemand anders al ervaring met SPD en Win 11?

Hier draait t ‘droog’ op windows 11 Home.
Geen ervaring ‘real time’ op t water oid.

Risico zit met name in usb poorten etc als ik de berichten zo zie. Heb t nog niet aan de boot gehangen. Zal ik van t weekend nog wel even doen en je laten weten of met mijn setup er issues zijn.