Onderwerp: Polar performance, speed plugin voor SignalK maken

Vmg berekening moet geen probleem zijn, maar zal na ‘t weekend worden.
Dampening hoor ik graag een gewenst algoritme voor.

Ik heb geen haast hoor, al schep je wel verwachtingen met de snelle opvolging die we gewend zijn

Een eerste orde laagdoorlaatfilter (veel gebruikte manier van “demping”) in een systeem met vast sampling interval is onderstaande recursieve formule:

Yn = a * Yn-1 + (1-a) * Xn

Y gefilterde output
X ruwe input
n laatste cycle/event
n-1 voorlaatste cycle/event
a filterconstante [0..1] 0=geen filtering; 0.999=veel filtering

Nu is SignalK event driven en gebruikt geen vast sampling interval. Als je mathematisch zuiver wilt werken (je kunt a dan zelfs een tijdsdimensie geven!) kun je voor elk nieuw sample de deltaT tov het vorige sample uit de timestamps halen en a dynamisch aanpassen. Maar je kunt dat ook niet doen In het pypilot algoritme kun je zien hoe de dynamische bepaling van a aangepakt is. Daar is dat kritisch omdat dit het stuurgedrag direct beïnvloedt. Hier niet…

SPD middelt een (instelbaar) aantal laatste samples (moving average); dat geeft een ongedefinieerd niet-lineair filter met (ik noem het maar) “schokeffecten”. Ik ben meer voor een eerste orde filter.

Ik denk dat als we aannemen dat de samples in de praktijk een redelijk vast interval hebben, de formule hierboven intuïtief en goed werkt. Effectiefst is om niet de output maar de inputs te filteren: de gebruiker kan de meest ruisige input dan bewust sterker filteren dan een input zonder ruis. Zo vertraag je de berekening niet onnodig, vanwege die ene ruisige input.

VMG met polar VMG en polar VMG ratio zit er nu in.

Alleen de volgende inputs worden gebruikt:
- speed through water
- speed over ground
- true wind speed

True wind speed is waarschijnlijk degene met de meeste variatie. Daar focus ik eerst op.

Nachtvlinder schreef :
Ik heb wat hulp nodig deze te begrijpen.

De data komt op een redelijk vast interval binnen aangezien speed en wind sensors meestal een vaste uitzendfrequentie hebben. In veel gevallen 1hz voor AWA wat door SignalK's derived data in een redelijk stabiele tijd omgezet wordt in TWA. De frequentie van binnenkomst schommeld misschien een paar %, maar dat lijkt me geen grote invloed hebben. Eens?

Dan de formule. Yn = a * Yn-1 + (1-a) * Xn

Voor een nieuwe waarde die binnenkomt wordt Yn berekend met behulp van de vorige Yn en de huidige Xn. a en n zijn constant. Yn wordt bewaard en de volgende keer gebruikt als Y(n-1).
Y(n-1) bevat daarmee de uitkomt van de vorige iteratie van de formule, dus die hoeft niet recursief te worden berekend, toch? Ik zie tenminste niet hoe de uitkomst zou veranderen als ik het over de laatste 10 zou berekenen. Ik hoef daarom volgens mij alleen Y(n-1) te onthouden en niet alle voorgaande. Of mis ik iets?

Wiskundig is het een recursieve functie, maar in de code niet.
Met het onthouden van Y_n-1 ben je er inderdaad.

Ok, dan zit dat er nu in voor TWA, TWS en STW/SOG (BSP) om zo de inputs te kunnen dempen.

En het werkt! Super!

De voorgestelde manier van dempen geeft geen voorspelbare uitkomsten. Je bent namelijk sterk afhankelijk van de frequentie en regelmaat waarmee gegevens binnenkomen. Vooral wat betreft frequentie kan je aanname flink roet in het eten gooien. Stel dat je windmeter 10 sample per seconde geeft ipv 1 (en die zijn er) dan bespreken je veel minder hard dan je denkt. Beter is het om een algoritme te gebruiken waarin je werkt met een time constant en tijdsintervallen expliciet meeneemt. (Bron)Dus eigenlijk niet veel anders dan het huidige algoritme, behalve dat a elke iteration opnieuw berekend wordt adhv een time constant en de delta t.

Eens, al is voor één boot de frequentie vaak wel min of meer gelijk (met af en toe een hickup omdat er een sloot AIS signalen doorheen moet...)

Iets met de dimensie [s.] zou het fijnst werken, omdat je dat bijna fysiek weet wat er gebeurt. Ook is een filter-tijdconstante van (bv) 3 sec op een andere boot óók 3 sec.

Dan moet dt wel gemeten/bepaald worden aan de hand van de daadwerkelijke data.

Solgens mij doet pypilot dat om de I-component in de stuuroutput te bepalen: op het moment dat er een nieuw sample binnenkomt wordt er gekeken hoeveel tijd er zatr tussen dat nieuwe sample en het vorige. Met deze variabele tijd en vaste integratietijd wordt dan bepaald hoeveel het "I-emmertje" verder moet integreren.

Heeft voor mij geen prio, maar mss beter nu goed doen dan later nog eens opnieuw. Dan is dit hoofdstuk af te sluiten

Tijdconstante en dt in seconden, dan ben je er.

Bij bijv een 10Hz wind sensor met 3 sec RC wordt het dan:

var real α := dt / (RC + dt)

a = 0.1 / (3 + 0.1) = 0.032

Dus RC wordt dan instelbaar, niet de a factor. Welke beschrijving geef ik die plugin optie? 'Time constant for low-pass filter'?

“First order time constant [s.] for LP filter”… Zoiets.

Kun je dt uit de binnenkomende data halen? Bijvoorbeeld 10 updates afwachten en dan de gemiddelde dt bepalen?

PS: die . achter s moet weg; lukt niet in deze post want dan stel ik strikethrough in

Ik kan zelf de delta bijhouden en die dan toepassen. Hoe kleiner de delta, hoe kleiner de a toch?

Klopt

Vergeet niet de termen a en (1-a) om te draaien tov wat je nu hebt:



Straks:
RC=0 (geen filtering) —> a=1
RC=oneindig (veel filtering) —> a=0

De time constant kun je "Damping" of Demping noemen.
Hierbij wat waarden de B&G hanteert/adviseert.

B&G noemt dit gewoon “Damping” inderdaad

Het leuke van zo’n eerste orde filter is dat je er ook bewust dynamica aan je systeem mee kunt toevoegen.

Bv:
-Alles stabiel en je boot vaart rechtdoor met 5.5 kn
-De wind neemt (en blijft) ineens toe van 10 naar 13 kn
-Bootsnelheid neemt langzaam (massatraagheid) toe van 5.5 naar 6.0 kn

Performance voor en na de windtoename is 80%

Maar op het moment dat de wind opeens toenam, daalde je performance tijdelijk, omdat de boot nog moest accelereren naar de nieuwe stabiele situatie, maar de daarbij behorende wind er al wel was. In het echt is de performance echter niet ingezakt.

Stel dat die boot er 8 s over doet om te accelereren, en je zou TWS in die ordegrootte gaan filteren, dan maak je de bootsnelheid en wind hier even traag mee, en hef je het verschil in dynamica (dat die dip veroorzaakte) gedeeltelijk op.

Maar dit is eigenlijk misbruik van het primaire doel van de filters: ruisonderdrukking.

Ok, zit er nu in. Beschrijving in config overgenomen van B&G text.

Mooi!

Op basis van hoeveel samples bepaal je nu dt?

Doorlopend of eenmalig bij opstarten?

Per variabele toch (sommige signalen zijn bij mij 1 Hz, andere 10 Hz…)?

Wow! Lekker bezig.

Heb je het idee dat het geheel minder zwaar wordt voor het systeem? Maw beter te behappen voor de pi?

1. TWA komt binnen met RC uit config
2. dt = nu - laatste TWA timestamp dt(n-1)
3. timestamp opslaan voor volgende keer dt(n-1)
4. a berekenen met dt en RC
5. Yn berekenen met Xn, a en Yn-1
6. Yn opslaan als Yn-1

Only Fools Rush in schreef :
Vergeleken met wat? Ik draai alleen SignalK op een RPi4 en dat gaat heel soepel. Dit soort berekeningen gaat volgens mij heel lang goed, dus zie nog geen reden om te focussen op optimalisatie.

Nachtvlinder schreef :
Per variable wordt de laatste timestamp bijgehouden, dus dynamisch per variable.

Helder. Elke timestamp bereken je a opnieuw dus. Dat kan ook wel denk ik.