Onderwerp: Polar performance, speed plugin voor SignalK maken

Het kost niet veel en dan werkt 't altijd volgens mij, ook als de frequentie opeens verandert, of hapert.

Ja precies. En stel dat er een tijd lang géén sample komt (congestie oid), dan convergeert, wanneer dat verse sample dan eindelijk tóch komt…

a = dt / (RC + dt)

richting 1, wat betekent dat de verse waarde vrijwel volledig overgenomen wordt.

Dat is precies wat Aswin uitlegt en de bedoeling is

hanst schreef :
Excuses, ik bedoel vergeleken met de optie om SPD ernaast te draaien.

Only Fools Rush in schreef :
Ik denk niet dat dat veel verschil maakt. SPD doet uiteindelijk ook redelijk recht toe recht aan rekenwerk.

Wanneer je SignalK al draaiend hebt is het denk ik wel makkelijker om te installeren.

Het maakt t wat simpeler op de pi vergeleken met SPD.

Maar om daar een beetje in de buurt te komen qua ietwat betrouwbare / vergelijkbare cijfertjes, zal je ook de calibratie moeten hebben.
En dat is in SPD prima geregeled.

De calibratie plugin zoals die nu in signalk beschikbaar is, die is, hoe zeg ik t netjes, niet echt heel praktisch bruikbaar.

Om t af te maken zou een plugin speciaal voor t aanpassen van log, wind (bij heel), etc wel mooi zijn.

Als ik op mn vorige boot kijk wat de afwijkingen waren van t log over de ene vs de andere boeg bijvoorbeeld, daar werden de performance %'s compleet van vernaggeld.

Maar deze plugin is een mooie eerste stap

[volg modus aan]

Shutter Speed schreef :
Hoe zou een log calibratie plugin ideal werken? Met een tabel met waarden in knopen? Of een automatische calibratie die helling, boeg, SOG gebruikt om een tabel te vullen?

En dan een soort polar plot met een lijn per x graden helling?

Je hebt denk ik 2 dingen: het vullen van een tabel met correctie waarden per helling en per snelheid. En het vervolgens gebruiken van de tabel om een gecorrigeerde snelheid te berekenen.

Only Fools Rush in schreef :
In SignalK kun je als plugin de waarde die binnenkomt aanpassen zodat de aangepaste waarde in SignalK beschikbaar is. Daardoor gebruiken alle andere pkugins dan de goede waarde.

Hans,

Ik was nieuwsgierig naar je code en denk iets anders over het bepalen van de VMG performance...

In de code zie ik dit:



...waar je correct uitrekent wat de aktuele VMG is, echter je leidt de target VMG óók af uit de aktuele TWA in plaats van uit de VUA en VDA die bij die beat resp. gybe koers (en TWS) horen.

Voorbeeld zoals het nu gaat:
-koers is 60 gr TWA (een beat koers dus maar je stuurt veel te laag)
-polarspeed bij aktuele wind is 6.0 kn
-bootje vaart 6.0 kn dus performance is 100%
-je berekent aktuele VMG als 6*cos(60 gr) (dat is correct)
-je berekent de target VMG óók als 6*cos(60 gr). Dat is niet juist!

In bovenstaand voorbeeld vaar je slecht aan-de-wind (je gaat hard de verkeerde kant op), maar VMG performance wordt als 100% weergegeven. VMG performance is nu per definitie altijd gelijk aan polarperformance en voegt niets toe.

Wat volgens mij de bedoeling is, is dat je die VMG performance gebruikt als je aan het opkruizen of afkruizen bent. Zit je te laag, dan ga je mooi hard maar de verkeerde kant op. Nu zie je dat niet. De actuele VMG dient juist vergeleken te worden met de "speciale polarpunten" VUA*cos(DA) (beat) of VDA*cos(DA) (gybe) die bij de aktuele TWS horen. Dán kun je zien of je optimaal aan de wind vaart (en niet aan het knijpen ben of juist te laag stuurt)

performance.polarVelocityMadeGood moet dus ofwel VUA*cos(UA) (beat) ofwel VDA*cos(DA) (gybe) zijn bij de aktuele TWS

Zitten we op een lijn, of heb jij een andere definitie van VMGperformance?

hanst schreef :

Wanneer het eenmaal draait zal het weinig uitmaken; rekenkracht lijkt mij ook geen issue bij dit soort toepassingen. Het updaten van de HMI (SPD) gaf wel wat stroperigheid bij mij af en toe. De SignalK plugin hééft geen HMI en is dus ook geen vergelijk.

Wél start de SignalK plugin 18 s sneller op (vanaf aanzetten PC tot beeld op de klokken). Dat komt volgens mij doordat SPD wacht totdat alle scentences voor de tweede keer binnen zijn en dan hieruit bepaalt welke gebruikt gaan worden. Ook zal (in mijn geval) het opzetten van de websocketverbinding een sec kosten?? Niet zo'n issue allemaal.

Verfrissend, leerzaam en effectief vind ik om in de code mee te kunnen kijken - voordeel van open source - gezamelijke ontwikkeling (bv het VMG performance dingetje wat ik net gezien heb). SPD is volledig black-box (hoewel je vrij eenvoudig in de runtime kunt sniffen, schijnt), maar dat is meer hacken dan peer-review...

Hoe werkt dat eigenlijk, bij zo'n plugin; wanneer doet die een nieuwe rekencycle? Is event-based toch? Moet één van de variabelen bijgwerkt zijn? Of allemaal... Er draait geen timertje in elk geval...

Edit: ik zie een "subscribe" hoofdstukje. Is elke update van een van de variabelen waarop een plugin geabboneerd is een trigger?

Ja, je kunt op meerdere manieren subscriben. Instant is dat je direct een nieuwe waarde doorkrijgt.
Nu laat ik bij het binnenkomen van TWA de performance berekenen. Dat zou ook bij STW kunnen. Of allebei.
TWA leek mij de beste omdat je daar op stuurt. STW is dan een consequentie.

Correctie: TWS, omdat die bij verandering de gewenste hoek veranderd.

Maar dat kan dus configureerbaar worden gemaakt.

Da's een lastige. Je kunt redeneren dat, wanneer je op élk nieuw sample triggered, je telkens de meest verse data evalueert. Echter als je dan een TWA én TWS én SOG én STW op 10 Hz hebt, sample je met 40 Hz, wat wat overdreven is

Van de andere kant, is je windwet 10 Hz en je log maar 1 Hz, dan krijg je een wat schokkerige weergave als je op je log triggered en gooi je veel data weg.

Mss triggeren op de snelste meting?

Triggeren op wind werkt prima, denk ik.

Bij de snelste heb je net voor de trage update een mogelijk grootste verschil. Bij traagste heb je altijd de meest verse data.

Maar wind freq lijkt me iig logischer dan log ivm oorzaak gevolg.

Ik lees mee en snap echt niks van wat jullie allemaal bespreken, maar ik vind het wel heel leuk om te zien hoe zo’n open source, community driven development ontstaat.

Een paar jaar geleden heb ik intensief gezocht naar wat de "ideale" demping op wind en log. Omdat een beetje computer een overdaad aan rekenkracht heeft voor het experiment actuele samples vergeleken in een grafiekje met een rekenkundig gemiddelde van de laatste 600 samples voor een 10Hz gps en 60 samples voor een 1Hz log. (1 minuut aan data dus.) De uitkomst van het experiment was dat vooral de COG van mijn GPS opvallend vaak als je min of meer een rechte koers vaart vaak de samples in een vaste periode afwijken van het gemiddelde hebben. De tijd tussen twee nul doorgangen van deze afwijking lijkt de ideale tijd om te gebruiken als demping.

@Xander: dit is even nerden maar grotendeels bijzaak; merk je staks niets meer van. Ik ben er ook niet voor om álles configureerbaar te maken; daar wordt het niet gebruikersvriendelijker van. Iets waar veel open-source projecten aan lijden, in mijn ervaring.

De VMG Performance berekening moet wél echt kloppen!

Interessant!

3Noreen schreef :
Zou je hiermee automatisch een filterconstante kunnen laten bepalen die zich instelt op het gedrag van de ruis? Dus hoe sneller deze (onterechte) variaties, hoe sterker filteren?

Dan moet je wél kunnen bepalen welke variaties écht zijn, en welke ruis zijn. In jouw experiment kon je dat uit de data halen, maar voor bv een TWA??

Nachtvlinder schreef :
Mijn GPS COG samples hebben opvallend weinig random ruis. Over het grote deel is er een superposition van een sinus vormige afwijking. De periode van die sinus ligt vaak tussen de 4 en 20 seconde. Mijn instrumenten demp ik bij het begin met 8 seconde. Zodra de subroutine die naar de periode van de afwijking COG een waarde tussen de 4 en 20 seconde vind dan wordt de demping van de instrumenten daarmee ingesteld.

Nachtvlinder schreef :
VMG performance had ik als: hoe is mijn VMG vergeleken met wat ik zou kunnen op deze angle? Dus direct connected met polarSpeed.

Maar ik denk dat je gelijk hebt als ik dit lees:
Dus dat kan aangepast worden.

Wat ik wel ook las is dat je nooit de VMG moet gebruiken om te sturen, omdat je bij het oploefen een tijdelijke verhoging krijgt die dan uiteindlijk inzakt omdat te hoog gestuurd wordt. Sturen op basis can Target TWA and boatspeed en VMG gebruiken om te zien of de zeilen optimaal staan.

Ik zal het evengoed veranderen en dan als er waypoint ondersteuning in komt de VMC gaan berekenen.

We zijn het eens volgens mij.

hanst schreef :
Dat zijn dynamische effecten inderdaad, treedt ook op als er een windvlaag langskomt - performance lijkt dan even in te zakken tot de bootsnelheid ook toegenomen is.

UA en VUA zijn theoretische waarden op vlak water, met perfecte zeilen, schoon onderwaterschip etc. Als het flink golft, zul je lager sturen met de zeilen voor wat meer power ten koste van hoogte getrimd. Als je dan botweg UA zou sturen loop je niet, neemt drift toe etc.

Voor upwind (en afkruisen) is UA/VUA resp DA/VDA nog steeds de beste referentie denk ik. Beide (zeker tegelijk) zul je niet eenvoudig halen denk ik, maar je wilt nog steeds trimmen en sturen om de VMG Performance zo hoog als lukt te krijgen.

Voor down-wind geld nog meer dan up-wind, eerst snelheid dan pas hoogte/diepte. Botweg DA/VDA sturen gaat niet werken als je niet eerst snelheid hebt. Even een stuurfoutje en je snelheid is weg. Kun je het hele spel van eerst snelheid maken van voren af aan opnieuw beginnen.

hanst schreef :
SPD doet dat als volgt:

- per SOG de afwijking van de STW LOG
- stapjes keuze gebruiker, in kts, indien gewenst per 0,1 kts of nog minder.
- per boeg, sb en bb
- indien gewenst: per helling, 0,10,25 en 40 graden, sb en bb apart.

SPD kan die tabel zelf maken uit een flink aantal SPDlogs. Hoe meer hoe beter.

@NV: met de knop " display off" kan je het cpugebruik halveren.

sailmon.com/wp-content/uploads...Reference-Rev1.5.pdf

Zie ook hier pag 44. Sailmon raadt aan erg voorzichtig te zijn met 3D logcalibratie. Is een eigen plugin waard, qua scope

Wat mij betreft de holy grail. Een betrouwbare manier om de snelheid door het water te meten. Het zal mij benieuwen of ik het nog mee ga maken dit iemand een algoritme ontwerpt wat dit probleem eindelijk voorgoed de wereld uit helpt.

Ik maak uit SPDlogs regelmatig een STW correctietabel.
Het is opvallend hoe weinig verschil er is met de eerdere.

Met de RM ST60 log zijn de afwijkingen van SOG van -0,9 kts tot + 1 kts. Grote verschillen ook tussen bb en sb.

Gemiddeld klopt die Correctietabel wel, maar elke individuele meting (seconde) kan er toch nog een andere afwijking voorkomen. Dempen/middelen helpt dan.

NKE gebruikt voor zijn racing computers met ultrasone log hetzelfde recept als SPD. Per snelheid en 9 hellingshoeken de afwijking van de SOG in een tabel.