Onderwerp: Raspberry Pi performance box

Het lijkt me leuk eens een nieuw projectje te definiëren om komende winter/wanneer ik ver van de boot ben met iets leuks bezig te kunnen zijn.

Zit te denken om op basis van een RPi een blackbox te bouwen die de volgende functies zou kunnen vervullen:

Performance tools:
-Logging data uit instrumenten tbv off-line analyse
-Detaildisplay TWA voor aan-de-windse en ruime-windse sectoren
-Grafische liveweergave polar plot en punten/wolk waarop je zeilt
-Idem voor UA/UD via deze plot voor actuele wind
-Trend en getalsmatige weergave actuele performance
-Niet-lineaire correctie BSP voor helling en snelheid
-Dynamische correctiewindrichting en -snelheid op basis van pitch en roll informatie

On-board entertainment:
-Muziek en filmserver op basis van Kodi (XBMC)

Eerste ideeën interfacing:
-Zeus plotter (kuip) heeft een composite-video ingang, waarmee dit het primaire scherm zou kunnen zijn. Dit scherm is in full-screen modus op te roepen, maar ook náást kaart, instrumenten of andere pagina's.
-HDMI uitgang naar scherm binnen (video kijken, ontwikkelen/prutsen)
-Audio via BT of kabel naar autoradio
-Waterdichte BT bediening buiten (up, down, left, right, enter of liever push/turn+back)
-NMEA informatie IN via vast bedraad TCP/IP
-Besturing KODI via tablet/smartphone en WiFi

Als OpenCPN of wat voor kaartplotter dan ook schijnt de RPi te traag te zijn, echter heb ik al een plotter buiten en iSailor binnen. Daar dus geen behoefte aan voorlopig.

Wie heeft ervaring met zoiets of ziet nuttige andere toepassingen?

Al enige jaren gebruik ik een headless ARM kloon met linux om de volgende zaken te regelen.

- NMEA datastroom van correcties te voorzien. En toevoegingen te doen o.a. snelheid t.o.v. polar.
- Log files te maken GPX & NMEA
- ankerwacht
- wifi router die de koppeling maakt met extern internet via wifi-vpn, umts, inmarsat. Vanwege kosten (je wilt niet weten hoeveel data honger een smartfone heeft) en veiligheid.

Dus geen beedscherm !
Zodra je een GPU + scherm gaat gebruiken wordt er stroomverbruik aanzienlijk hoger. Zeker omdat het ding bij ons 24/7 aan staat willen we dat niet. Verder wil je zeker geen buffering in je nmea datastroom. Zware grafische toepassingen kunnen makkelijk de CPU voor 100% opslokken.

Ik heb een klein linux variant boxje (mk808bplus) op welke de volgende functies heeft:

-Kodi (mediacenter)
-Router/accespoint voor Alpha Tube-U wlan antenne (tethering)
-DVB-t decoder (digitale tv kijken)
-(ais)Kaartplotter
-Repeater naar smartphone
-DLNA//UPnP Server
-ftp server (thuis films uploaden)
-Ankerwacht
-Gameconsole voor de kids

Bedienen gaat met de T2 2.4G Wireless Air Fly Mouse erg goed zelfs vanuit de kuip.

na laptop blijft nu ook de ipad thuis..

Kijk eens naar de specs van de Nexus race box. Wie weet geeft het inspiratie?


Dat Aanpassen van de windrichting adhv een HPC copmas is denk ik erg lastig, omdat je daar in ieder geval een vorm van correctie voor de massatraagheid en delay van de windgever in moet verwerken.

Even korte offtopic opmerking over data honger van een smartfoon:
Ik gebruik "noroot firewall" en dat scheelt aanzienlijk in de data. Je kan voor elke applicatie kiezen wat die wel of niet mag. Als je realtime alle pogingen ziet van alle software weet je waarom Google voor geen cent te vertrouwen is.
En ontopic maar weer.

Ik schat dat 30-60% van je bundel gekaapt wordt door zelf gekozen malware.

Ik ga het anders doen. Waarom zelf applicaties gaan ontwikkelen waar anderen dat al gedaan hebben en veel beter kunnen? Bovendien zou het systeem complexer dan nodig en minder overzichtelijk worden door de veelheid van connecties.

Onderstaande adapter besteld waarmee het scherm van de iPad2 gedupliceerd wordt naar de een van de CVBS video ingangen van de Zeus plotter. Op de tablet blijft dan iRegatta draaien, waarbij het scherm buiten (full-screen of split-modus) zichtbaar kan worden gemaakt.

iPad is natuurlijk niet te bedienen vanuit de kuip, maar het gaat me voornamelijk om die enkele pagina van iRegatta. Wel jammer dat alleen de GPS snelheid ipv boatspeed gebruikt wordt om de performance te berekenen: weliswaar nauwkeuriger dan boat speed, maar nutteloos op stromend water...

Inmiddels mijn oude een beetje sleets geworden linux boord computertje aan het vervangen door een raspberry pi 2 met 1 Gb ram. Helaas ten kosten van wat extra stroom. 2,5 watt i.p.v. 1 watt die mijn oude nodig had om wakker te blijven.
Mijn oude boxje kon net de zaken afhandelen die hij te verwerken kreeg. De nieuwe raspb. heeft duidelijk nog wat rekenkracht over. Kan meerdere ip/tcp opbouwen zodat zowel laptop als telefoon tegelijk kunnen werken. Verder probeer ik het af te kunnen zonder exotische hardware. Een edimax wifi stick, 1 usb verbinding met de crismux en een standaard speaker voor akoestisch alarm. Dus geen gedoe meer met Gpio pinnen. De crismux geeft door of de motor aanstaat en of er ankerwacht gehouden moet worden.

De extra rekenkracht gaat gebruikt worden om performance data naar de NKE app op de telefoon te sturen. Target snelheid/ %performance t.o.v. polar / %performance VMG-wind. Dus % polar snelheid als je de optimum windhoek zou varen / optimum up/down wind hoek.

Nachtvlinder schreef :
De iPad-naar-composite adapter gaat het helaas niet worden. Vage niet-compatibiliteiten tussen verschillende iOSsen en louter onsamenhangende postings op fora daarover. Apple zélf zwijgt ook in alle talen - het kabeltje lijkt obsolete al wordt dat nergens formeel onderkend. Na een jailbreak en 2 gekochtte kabeltjes (één was er inderdaad stuk, maar dat was de tweede) heb ik er genoeg van.

Inmiddels begonnen met het bouwen van een RPi applicatie die data binnenhaalt via TCP/IP (de plotter "bridged" de N2K data naar TCP/IP), het nodige berekent en grafisch weergeeft op de video ingang van de plotter. Er worden geen electrische/WiFi signalen uitgezonden; de bedoeling is slechts om een nieuwe "performance" pagina beschikbaar te hebben op de plotter buiten.

Het scherm moet uiteindelijk een B&G stijl gaan krijgen, dus nog op zoek naar wat carbon-achtergrondjes etc.

Omdat ik ver van de boot ben heb ik (om te kunnen testen) onderaan het scherm in een handmatige input voorzien, wat straks met plm 10 Hz van het boordnet moet komen. App scant nu elke 100 ms deze velden en draait voorlopig in simulatie mode.

Erg inzichtelijk en leuk om mee te spelen! Vooral de invloed van slingeren en stampen bij weinig wind is groter dan ik had verwacht...

Scherm (bovenste deel zonder de inputvelden) heeft dezelfde verhoudingen en resolutie als het scherm van de plotter - het is nog even afwachten hoe de uiteindelijke beeldkwaliteit wordt via die composite ingang.



De aktieve upwind/downwind VMG wordt automatisch geselecteerd en de UA/DA en target snelheden worden uit de polar gehaald. In het plaatje zie je dat voor zowel de boatspeed als VMG de performance wordt berekend.

-witte curve is de polar bij aktuele TWS,
-groene lijnen zijn UA en DA (bij heersende TWS),
-blauwe lijn is ware wind richting, gele stip geeft aan hoever je van het target zit,
-paarse pijl is de schijnbare windrichting

Gezien het blackbox idee valt er weinig te bedienen, zeker buiten niet. Ik denk echter aan een waterdichte druktoets (in motorpaneel is ruimte over) die ik (door langer of korter in te drukken) kan gebruiken om de verschillende toggles aan of uit te zetten. Ik zou daarvoor een van de GPIO inputs kunnen gebruiken.

Straks eerst maar eens kijken of ik dit live aan boord aan de praat krijg.

Ziet er mooi uit. Snap nog niet helemaal hoe je het effect van slingeren en stampen zonder echt te varen al kunt meten.

Mijn aanpak is duidelijk wat simpeler. Rasp zit met USB aan mijn Chris-mux waar hij minimaal NMEA VHW en MWV vandaan krijgt. Waar de rasp met behulp van de polar (in de zelfde format waar OpenCPN mee werkt ) en die gegevens ware wind, target speed bij de gezeilde windhoek , Optimale windhoek down/up bij de actuele wind, % gehaalde snelheid t.o.v.target en percentage van optimale VMG die behaald wordt. Dat zend die via wifi door aan de NKE app die op een smart phone of tablet draait.
Nu al een mijl of 200 mee rondgevaren en het blijft inmiddels stabiel draaien. Er valt nog het nodige te schaven aan demping van de input en het kiezen van de meest geschikte interpolatie methode. De meest succesvolle tot nu toe gebleken is een cubic interpolatie. Met Catmull-Rom splines werkt niet echt beter en maakt het alleen maar nodeloos ingewikkelder.
Het werken van toggles via GPIO is me niet bevallen omdat de rasp duidelijk instabieler door wordt. De enige toggle die ik gebruik is overigens of de motor loop. Om zeker te weten of er wel echt gezeilt wordt. Omdat de rasp ook een stukje zelf lerend aan de polar "schaaft".

Plaatje van tijdelijke opstelling aan boord.

Leuk!

Het lijkt erop dat we zo'n beetje dezelfde informatie weergeven; waarbij de applicatie waar ik mee bezig bent een en ander ook grafisch laat zien.

Ik denk dat dat wat extra inzicht/sneller overzicht tijdens het zeilen zal geven. Bijvoorbeeld dat het bij mijn polar bij afkruisen heel weinig doet voor je VMG of je nu plat voor de wind of 30 graden opstuurt. Dat zal voor jouw boot heel anders zijn! Dat opsturen geeft bij mij echter wél een hogere boatspeed (en dus meer roereffect) en de golven komen veel prettiger in. De live-polar laat direct zien hoe ver je kunt gaan bij de actuele wind.

Jammer dat die toggles niet fijn werken, is dat ook je ervaring met de RPi 2? Dat was zo'n beetje m'n enige hoop om de applicatie van afstand te kunnen bedienen. Slim idee om je motorsignaal mee te nemen. Ik denk nog na om het log automatisch te starten/stoppen op basis van stationairiteit van de input; voorlopig is dit een handmatige toggle.

Qua invloed slingeren en stampen op de gemeten wind heb ik als hieronder geredeneerd:

• In de haven is de AWA/AWS meting meestal erg stabiel;
• Onder het zeilen niet. Dit komt niet door veranderingen in de echte wind maar door de invloed van de masttop die in beide richtingen versnelt;
• Op basis van de eerste afgeleidde van 'heel' en 'trim' (10 Hz data) bereken ik de schijnbare wind die de masttop 'zelf' maakt in deze richtingen. Dit is een vector net zoals de gemeten schijnbare wind;
• Pi*Masthoogte*Hoeksnelheid is evenredig met dit effect (zou zelfs een fysisch bepaalde relatie moeten zijn). Dit zit er nu vast ingebakken, maar de variabele 'Masthoogte' zal een tuningsfactor kunnen worden;
• Door de gemeten schijnbare wind te ontleden (SB/BB en voor/achter component) kan deze gecorrigeerd worden met het berekende bewegingseffect;
• Indien nodig (dynamische modellen via Matlab gebaseerd op ruwe data) kunnen filters, delays etc toegevoegd worden. Ik verwacht dat de beste correctie een combinatie is van de fysica van hierboven en wat fudge factoren. De Hydra units van B&G gebruiken ook een ingebouwde bewegingssensor hiervoor; hun berekening kan niet veel anders zijn lijkt me!
• Bas noemde eerder het effect van massatraagheid; het spul in de masttop is echter goed gebalanceerd en wat er dan nog inzit aan dynamica kan dmv die custom filters verdisconteerd worden. Perfect zal het nooit worden, maar ik verwacht wel een stabiliserende werking op de AW en daarmee op de berekende TW.

Blijft een experiment natuurlijk, maar ik denk dat deze basis een uitgangspunt kan zijn.

Zal eens inlezen in die interpolatiemethode die je noemt. Mijn polar bevat wat gekke dipjes die niet consistent zijn met toenemende/afnemende wind. Beste werkt denk ik om je eigen polar te maken (veel loggen dus)...

Gave projecten hoor, ziet er goed uit. Welke software gebruiken jullie op de Raspberry? Of is dat volledig zelf geschreven software?

Ik gebruik Lazarus, dat is een open-source, multi-platform taal, lijkt erg op het oude Pascal, maar heeft volledige RPi ondersteuning, ook op hardware niveau.

Wat je nu ziet draait gewoon onder Windows, maar er zijn ook compilers voor RPi; zelfs de ontwikkelomgeving geloof ik...

Lazarus is toch een afsplitsing van Delphi? Wow, ik wist niet dat die ook al RPi konden doen. Toch maar eens naar kijken.
Mooi werk Nachtvlinder!

Dankje. Ja inderdaad schijnt het van Delphi afgeleid te zijn, en vanwege het open-source karakter is er erg veel on-line kennis beschikbaar en vooral goed vindbaar. Voor mij was het meer dan 10 jaar terug dat ik voor het laatst geprogrammeerd had dus ik heb dat wel nodig gehad.

Zie ook uit de freepascal.org wiki: Lazarus on Raspberry Pi

Nachtvlinder schreef :
Mijn log start als de boot binnen 30 seconden meer dan 20 meter zich verplaatst heeft. Via gps gemeten. Deze waarde blijkt in de praktijk een goede threshold.

Ben benieuwd of je databus voldoende real time is om je roll pitch aanpak mogelijk te maken. Als het werkt wel een mooie toevoeging. Tot nu toe ben ik deze aanpak nog niet tegengekomen. Wel een hellingshoek correctie van de windmeting.

Mijn programmaatje is in C geschreven. Lekker veel met pointers met de polar rotzooien.

Heb je nog overwogen om het grafische deel in html5 te doen ?

Met de pi2 niet meer geprobeerd gpio te gebruiken. Er zijn betere alternatieven. In mijn gebruik de schakelaar functie van de chrismux. Maar je zou ook een USB serieel adapter kunnen gebruiken. Dan heb je minimaal 3 logische inputs.

zeilbootje schreef :
Ik gebruik dus C om deze toepassing te schrijven. Verder draait zo'n rasp natuurlijk voor 95% op standaard software.
Voor iemand die een USB poort met de nmea gegevens aan boord heeft, bijvoorbeeld een chrismux, en een smartphone. Dan is alleen nog een raspberry + een wifi adapter nodig aan hardware. Een beetje kennis om met SSH in te loggen op de rasp is denk ik wel noodzakelijk.
Zal eens proberen of ik een image van mijn kaartje kan maken die klein genoeg is om beschikbaar te stellen aan belangstellenden.

Als je meer ingangen nodig hebt wil ik wel wat maken hoor.
Met aan iedere ingang een te programmeren nmea bericht

Voor wie belangstelling heeft.

Met de komst van betaalbare (althans in mijn ogen) daglichtschermpjes en krachtige Single Baord Computers met veel electrische interfaces, heb ik enkele maanden geleden een start gemaakt met wat ik noem een krachtige en flexibele Maritime Instrument & Display Controller. Primaire gericht op OpenCPN en SignalK, maar sluit iSailor (nu op Android) en SeaWi en wat er nog meer wenselijk is, niet uit.

Dit project is uitgebreid beschreven op www.hackster.io/mvandervoort/m...t-display-controller. Concrete specs zijn er ook beschreven.

Het is Work In Progress met laat in de herfst een eerste prototype. Op genoemde Web-site worden vorderingen en sources ook gepubliceerd.

Inmiddels weer wat vorderingen kunnen maken

• Interface gaat richting B&G huisstijl:
  
  
• "drukknop kuip" toggles werken (via een "press and hold" bediening met timers)
• polars worden nu bilinear geinterpoleerd ipv look-up tabel, bicubic vond ik een té smooth beeld geven (de voor mijn boot toch al kleine "afkruislobes" verdwenen praktisch. Graphics en targets worden nu voor élke TWA/TWS berekend en niet meer per 2 kn en 5 graden. UA/DA + VUA/VDA tabel wordt geinterpoleerd ipv herleid uit polar
• per ingang is een eerste orde filter in te stellen - tijdsconstantes nu is s. ipv 0..1: dat betekent tenmiste iets en is sampletiming onafhankelijk
• datalogging werkt, klein beetje ruis op de klok, maar dat moet op te lossen zijn door system-calls te doen ipv OS (logging en aquisitie elke 50 ms)
• qua correcties (pitch&roll, masthoogte, helling, drift en upwash goede documenten van Ockam en B&G manuals gevonden. Ik twijfel nog of het zin heeft om drift+upwash te implementeren; dit schijnt elkaar bijna atijd op te heffen. Zal later dieper op de implementatie hiervan ingaan

Geinig allemaal, maar de belangrijkste correctie (pitch&roll) is dynamisch en vereist een snelle data input. Helaas zend het Gofree access point voor de meeste signalen niet sneller dan 1 Hz (een aantal signalen zoals GPS gaat met 5 Hz). Dit zou onvoldoende zijn om de pitch&roll compensatie te kunnen doen - in die ene seconde slingert je masttop alweer de andere kant op

Het blijkt echter dat "tier 2" van het Navico protocol óók vrij te gebruiken is en zelfs 2 kanten op werkt! NB Tier 1 is de "standaard" NMEA0183 over TCP/IP, in tier 2 heb je direct (en snel) toegang tot alle(!) data op de Canbus (via de MFD). Ook motordata, tankniveau's etc. Werkt via een websocketverbinding via JSON strings en is goed gedocumenteerd - zelfs met stukjes voorbeeldcode.

Wat me vooral verbaasde is dat je ook mag schrijven: de MFD zet deze data dan op de bus en de Zeus weet niet beter dat er een "echte" Hydra achter hangt. Target hoeken worden dan ook gebruikt in de geïntegreerde layline plots etc. Dit geeft ongelofelijk veel meer functionaliteit!

Leuk van Navico dat ze de dichtgetimmerde N2K norm toch een beetje toegankelijk maken, specificatie is vrij te downloaden onder licentie. Is helaas erg merk-specifiek en wordt wss ingehaald door signal-K, maar mijn boot is op dit moment ook erg merk-specifiek...

Heb jij nog slimme ideeën waarmee je de gemeten snelheid door het water kunt verbeteren ? Blijft in mijn idee het meest problematische gegeven.

3Noreen schreef :
Ja. Nouja - althans niet allemaal van mezelf

Dit is een vrij lange bijdrage geworden en is een kruising tussen een samenvatting van wat ik gelezen heb, wat ik al geimplementeerd heb en wat ik nog van plan ben. Deze structuur is een combinatie van hoe B&G en Ockam hun "Advanced True Wind Calculations" doen met een aantal eigen toevoegingen. NKE ga ik nog naar kijken.

Niet alle hieronder beschreven correcties en calibraties hebben een even groot effect, maar doel was en is om een "performance box" te bouwen dus dat doe ik dan maar. Kunst is vooral gestructureerd te calibreren en niet zo maar je favoriete loterijnummers in te vullen. Ik ben van plan slechts één functie extern beschikbaar te maken (blok 11); de rest zit verstopt in de code of de configuratiefile en ligt vast nadat ze gecalibreerd zijn.



De nummering van de functionele blokken is ook een mogelijke rekenvolgorde.

1. Speed log calibratie
   Reden van compensatie:
   Een paddlewieltje steekt niet of nauwelijks door de grenslaag tussen romp en het daarlangs stromende water heen. In die grenslaag stroomt het minder snel dan net daarbuiten. Omdat de grenslaag dunner wordt naarmate een boot sneller vaart is een fysische eigenschap van dit type sensoren dat ze bij toenemende snelheid in toenemende mate teveel gaan aanwijzen. Dit geldt zowel rechtop varend als onder helling. Echter onder helling komt er nog een effect bij, namelijk dat de stromingsrichting en/of snelheid ook kan veranderen ter plaatse van het wieltje.
   Hoe compenseren
   Het eerste effect corrigeer ik door een lineaire interpolatie uit een look-up tabel. In die tabel staat bijvoorbeeld dat bij een gemeten snelheid van 6 knopen een gecorrigeerde snelheid van 5.8 knopen hoort. De tabel heeft bv 3 of 4 ingangen. Dit geeft een corrigeerde meting die geldig is indien de boot rechtop zou varen. Deze (gecorrigeerde) snelheid dient in een tweede stap gecorrigeerd te worden voor helling. B&G doet dat linear: voor 30 graden helling voer je een correctiefactor in, bv 1.3. Deze factor wordt linear teruggerekend naar de aktuele helling (bij 0 helling is deze factor dan 1)
   Hoe calibreren
   De eerste correctie is het eenvoudigst: op stilstaand water snelle logging aanzetten en rechuit gaan motoren; snelheid elke 5 min een halve knoop verhogen tot op rompsnelheid. Data off-line analyseren en de tabel maken. Voor snelheden boven rompsnelheid een leuk spirak uitzoeken en hetzelfde doen; zoveel mogelijk ruime wind zonder noemenswaardige helling.
   Qua hellingcorrectie denk ik niet dat de B&G methode hout snijdt: ik zie geen reden waarom dat de correctiefactor linear met helling zou veranderen. Ik ben van plan eerst de tabel uit de eerste stap te gebruiken en dan flink te gaan loggen: wellicht zit hier een cosinus, kwadratisch of juist sqrt relatie in. Door lange-termijn data te analyseren valt hier vast wel iets over te zeggen. Desnoods een tabel met factoren als functie van helling


2. "Tidal/non-tidal" schakelaar. Deze schakelaar bedient ook blok nr. 4. Mijn GPS zend met 20 Hz haar data uit en is veel betrouwbaarder dan het log. De uit dit blok resulterende SPEED is input voor belangrijke vervolgberekeningen dus SOG heeft de voorkeur. Op stromend water dien je echter terug te vallen op het log vanwege het feit dat de True Wind (input voor polars) als referentie heeft `stilliggend op (al of niet stromend) water"


3. Kompascompensatie zou nauwelijks nodig hoeven zijn na het doorlopen van de automatische calibratieprocedure (twee cirkels varen). Daarna resterende fouten kunnen in deze deviatietabel opgenomen worden. Deze calibratie door op stilstaand water een cirkel te varen en de verschillen tussen HDG en COG te fitten naar HDG. Waar nodig kan een tabel bevolkt worden waaruit de software interpoleert


4. Drift. Op niet-stromend water wordt de drift bepaald door het verschil tussen de koers over grond en de kompaskoers. Op stromend water kan dit niet en wordt de drift geschat op basis van Drift = K * HEEL/SPEED^2. K verschilt per boot en dient experimeneel (schijnt dat ontwerpers deze soms ook al berekend hebben) bepaald te worden. K=12 voor "a standard cruiser with moderate draft". Calibreren (=K bepalen) dient plaats te vinden door op stilstaand water veel data te loggen. In Matlab of Excel deze factor dan fitten ahv gemeten SOG, COG, HDG en HEEL. Dit zal een ruisig geheel zijn, maar dat kan zoals in elk identificatieprobleem opgelost worden door méér data te gebruiken.


5. Pitch & Roll compensatie compenseert de gemeten schijnbare wind in zowel snelheid als richting. Door de omtreksnelheid in de top van de mast te berekenen in X en Y richting kan de door het slingeren/stampen "induced wind" worden afgetrokken van de gemeten wind (de gemeten wind wordt daartoe ontleed in X en Y component, dan gecorrigeerd en dan weer teruggerekend). Een snelle data acquisitie is hier belangrijk omdat de tijdsafgeleiddes van HEEL en TRIM gebruikt worden [graden per s]. B&G doet dit al bij een sampleinterval van 2 Hz (Hydra) of 4 Hz (Hercules); ik verwacht een aanzienlijk hogere resolutie te kunnen halen. Dit is verder een fysisch bepaald verschijnsel waar niets gecalibreerd aan kan worden.


6. Hellingscorrectie. Elke extra graad helling laat de gemeten schijnbare wind naar voren vernauwen; bij 30 graden helling tot zo'n 4 graden. Om dit te corrigeren wordt de schijnbare wind ontleed in X en Y component, waarna AWSx (dwars op de boot) gecorrigeerd wordt door AWSx = AWSx / cos(HEEL). Daarna wordt weer teruggerekend naar AWA en AWS.


7. Correctie AWA voor drift. Stel dat er 30 graden AWA gemeten wordt (over SB dus) terwijl je boot 5 graden naar BB verlijert. In dat geval wordt de schijnbare windhoek dus 5 graden te krap gemeten. Omdat dit invloed heeft op de berekende TW wordt hiervoor gecorrigeerd: AWA = AWA + drift (waarbij drift < 0 indien naar BB).


8. Van gecorrigeerde AW naar TW. Standaard berekening (gonio)


9. Gradient correctie TWS corrigeert voor het feit dat een polar uitgaat van de wind gemeten op 10m hoogte, terwijl de sensor hoger of lager kan zitten. Eigenlijk alleen van belang indien de sensor écht veel hoger zit (50 ft boten etc). Afhankelijk van de atmosferische omstandigheden neemt de true wind meer of minder toe met de hoogte van de sensor.
   Deze gradient is, samen met windsheer (zie blok 11) de meest variabele component en kan per uur per dag verschillen. Correctie is een grof gemiddelde. Correctie: TWS = TWS / (0.9 + 0.1*Mastheight).


10. TWS correctie voor downwind condities. In tegenstelling tot wat ik verwacht had, vinden er ook correcties plaats ná de omrekening van AW naar TW. Deze hebben temaken met de correctie voor upwash, windsheer en acceleratie van wind boven de zeilen langs. Deze correctie (blok 10) gaat over die acceleratie, die alleen optreedt bij zeer ruime koersen, waarbij de zeilen relatief dwars op de wind staan, waarbij de uittredende wind versneld en omhoog gestuwd wordt. Ockam is fundamenteel tégen sleutelen aan de TW en pakt het in het AW bereik aan met een boel gonio, reefhoogtes en nog steeds fudgefactoren. B&G stelt dat je dit toch niet kunt berekenen en het beste kunt meten hoe dit effect eruit ziet bij de zeilvoering die jóuw boot heeft op dit soort koersen. Hiertoe wordt geinterpoleerd uit een look-up tabel. Input van deze tabel zijn 6 getallen die gemeten dienen te worden bij de voor jouw boot geldende afkruishoek: TWS = TWS + f(TWS). Tussen AWA = 165 en 90 graden wordt linear teruggerekend naar 0 correctie.
    Calibratie. Door (bij verschillende wind snelheden en bijbehorende zeilvoering) af te vallen van aan-de-wind naar lagere koersen bijhouden hoeveel de TWS berekening fout zit. Deze correcties in de tabel invoeren.
    
    
11. Calibratie van het "TWD is tacking with me" effect. Dit is de laatste correctie op de TW en vind plaats op de windrichting. In feite wordt hier gecorrigeerd voor kleine fouten in alle hierboven uitgevoerde calibraties, maar vooral voor de variërende upwash, windgradient en windsheer. Dit is in de commerciele performance modules een snel toegankelijke parameter, die je net vóór de race dient te checken en aan te passen indien nodig. Doel is om bij tacken over beide boegen dezelfde TWD (=magnetische true wind) te krijgen. Ook hier weer een interpolatie uit een look-up tabel.
    
    Calibratie. Bij de heersende omstandigheden 6 koersen gaan varen ten opzichte van de true wind. Symmetrische TWA's gaan varen (bv beginnen bij TWA=45 dan -45 dan -90 dan -160 dan 160 dan 90 - rondje rechtsom). Bij deze koersen TWD noteren (doet het apparaat voor je). Verschillen in de bijbehorende TWD's gemeten tijdens de SB en BB koersen worden gecorrigeerd. Tabel heeft per 5 kn wind 3 waardes, bv bij TWS=10 kn: 45 gr = -3; 90 gr = 1; 160 gr = 3. Het verkrijgen van een stabiele TW (richting én snelheid) wordt als "the holy grail" gezien (ik denk voor de fetishjisten)...


12. Herleiden "echte" AW uit TW. Nodig omdat er in de true wind gerommeld is


13. Magnetische True Wind wordt berekend door HDG + TWA. Dit is niet de (meteorologische) grondwind, maar de windrichting zie je zou pijlen als je boot op de stroom ligt te dobberen. Die gebruik je bij tactische beslissingen (waar het mij hier niet om gaat)


14. Polar performance berekeningen. Alles hierboven is gericht om zo stabiel, ruisarm en consistent mogelijke inputs te verzorgen. Wat Polar doet heb ik een paar posts eerder uitgelegd.

Waar ik o.a. over twijfel: "Welke" apparent wind zou input voor blok 10 moeten zijn? Er zijn verschillende stadia van correcties. De gekozen correctie dient zoveel mogelijk te zeggen over welke wind het zeil "ziet". Zou dat niet gewoon de ruwe meting moeten zijn? Als de boot slingert of drift dan voelt het grootzeil of spi dat toch ook!?

Wat denken/weten/geloven jullie?

Sailing World: Good Data Starts with Good Calibration
Big boat instrumentation
B&G Essential Guide to Sailing Instruments
ORC Speed Guide Explanation
Sailmon Instrument System Calibration Manual and Data Reference
H3000 Owner's Handbook
How Ockam Calculates Things

Leuk zo’n uitgebreid verhaal. Het leest voor mij met rode oortjes. Zelf ben ik veel minder gestructureerd bezig. Het programmeren en experimenteren doe ik bijna uitsluitend tijdens onze zomer tochten. Dus heel dichtbij de praktijk.
Jij hebt verder de beschikking over een can bus waar je sensoren mee communiceren wat vermoedelijk veel minder jitter geeft.
Wat opmerkingen vanuit mijn ervaringen die mogelijk alleen gelden voor mijn boot.

- Log geeft bij gelijke SOG op de motor varend een andere STW dan zeilend. Mogelijk door pitch of het aanvoeren van schroefwater. Alle metingen die ik doe op de motor varend gebruik ik daarom niet.
-Er is een scherpe knik in de afwijking van het log bij het bereiken van de planeer snelheid.
-Drift zie ik als een snelheid haaks op de heading. Is bij mij redelijk onafhankelijk van de snelheid die gevaren wordt. Kan heel anders zijn bij lift gevende zwaarden e.d. Bij mijn boot is het in relatie met wind speed en golfslag. Vreemd genoeg maakt de windhoek weinig uit. Je vermoed hier een sinus. Echter kan ik die niet ontdekken. Vermoedelijk hebben de kracht vectoren op de zeilen een tegengesteld effect.
-Zelf gebruik ik ook een schakelaar SOG/STW Echter ben ik aan het broeden op het idee een stroom vector uit te rekenen die ik over een lange tijd kan middelen. De stroom veranderd niet bij koerswijzigingen en is mogelijk redelijk constant over een periode van enkele minuten. Met deze stroom vactor kan de SOG gecorrigeerd tot een soort STW.
- Verschillende gps’n geven verschillende SOG/COG. Mogelijk door andere plaats op het schip ? Of software verschillen in de gps.

3Noreen schreef :
Hmmm, interessant en aannemelijk: zou inderdaad temaken kunnen hebben met de aanzuiging van schroefwater, al neem ik aan dat je schroef best een eind achter het log zit. Waar ik zelf aan zit te denken is dat de romp, wanneer aangedreven door de zeilen, anders in het water ligt dan tijdens het motoren. Motor grijpt aan ergens achter in de boot op het vlak terwijl de voorstuwing vanuit het tuig voor het midden an de boot plaats vind en dan op (ik noem maar wat) 6 meter hoogte. Dan zou er ook een draaimoment kunnen ontstaan in voorwaardse richting, waardoor de romp vooraan (en bij het log) dieper komt te liggen en de kont omhoog. Op de motor is dat andersom.

Maar als dat wáár is dan zou dat toch door "trim" te meten moeten zijn?

3Noreen schreef :
Ja, dan zal er een boel veranderen in de lokale stromingscondities: boot begraaft zich (bij jou niet zo sterk!) in boeg- en hekgolf en als jij (ik niet!) nog harder gaat zal de boeg juist een stuk op/over de golf gaan varen.
Lukt het om die knik mee te calibreren? Snelheid waarbij dat plaats vindt ligt toch redelijk vast?

3Noreen schreef :
Slim bedacht! Toch moeten jouw rompen ook lift geven; ik neem temiste aan dat je geen gigantische drifthoeken hebt! Misschien lijkt jouw boot wat dat betreft meer op een langkieler; die heeft ook niet echt "hydrofoils" onderwater, maar loopt toch hoogte. Zou dat "langkiel lifteffect" relatief onafhankelijk zijn van watersnelheid?

3Noreen schreef : Hier kom ik op terug! Vanmorgen gelezen dat Sailmon iets soortgelijks doet met de optie "TWA from Heading"

3Noreen schreef : Geen idee: mijn SOG uitlezing is superstabiel en heb ik niet zien driften. In absolute waarde nooit vergelen met een afstandsmeting (omdat ik niet meer ouderwets navigeer in de praktijk). Zal eens gaan meten.


Ik zou terug komen op, zoals je voorstelt, het schatten van de stroming en deze vastleggen/stabiliseren onder de aanname dat die de komende 5-10 min (zou mijn idee zijn) niet verandert. Ik neem aan dat je software deze stroming nog steeds momentaan blijft schatten en dat deze schatting de traag gefilterde versie update? Je zou volgens mij dan inderdaad de door jou "tijdelijk bevroren" waarheid kunnen gebruiken, waardoor je uit kunt gaan van COG en SOG!

Dit is ongeveer het idee achter toestandschatters zoals die in de control theorie gebruikt worden.

Sailmon doet dit volgens mij óók, maar ben er nog niet helemaal achter hoe precies. Heb wat ideeën maar post die pas als ik daar verder mee ben.

Sailmon rekent als hieronder (in vergelijking met mijn struktuur vind éérst de hellingscompensatie plaats en dán pas de pitch&roll. Bovendien vind leeway correctie plaats in het true wind domein ipv daarvoor). Anyway:



Niets nieuws verder, behalve het paars omcirkelde blok dus. Daar wordt over geschreven:




Wat zou daar gebeuren? Ik verwacht niet dat hier van een echt feedforward model gebruik wordt gemaakt: dit zou nooit goed te tunen zijn en dus niet robuust in de praktijk. Wat wellicht wél gebeurt:

1. Elk samplinginterval wordt TWA en daaruit TWD (=HDG + TWA) opnieuw berekend maar niet weergegeven
2. Hieruit wordt een traaggefilterde versie van TWD, bv met tijdsconstande van 2 min "TWD_2" bijgehouden
3. Vanaf dat moment wordt de weergegeven en in de polar gebruikte TWA berekend op basis van de kompaskoers en TWD. Dus TWA = TWD_2 - HDG.
4. TWA reageert dan live op koeswijzingingen, overstagjes etc met een minimum aan ruis
5. Snelle windshifts (welke geen ruis zijn) zie je dan pas vertraagd terug, maar de AWA is nog steeds live

Zou het zo werken? Of anders?

Lijkt dit op wat jij van plan bent of was dit een verkeerde associatie?

Is dit iets om te implementeren?

PS: Staat er nu corrected of connected? Indien "connected" dan zou er iets kunnen gebeuren als ik opsomde, indien "corrected" dan zou er wel sprake kunnen zijn van feed-forward. Dat lijkt me niet aannemelijk: je dient dan een universeel inverse model te hebben van een stap in de heading naar de reactie van de windvaan. Dat valt m.i. onmogelijk te doen en is ook veel "geavanceerder" dan wat ik tot dusver gezien heb.

Robuustheid lijkt de norm te zijn (en terecht...)

Rekenstructuur geupdate en uitgebreid met de "TWA from Heading" optie. Door de filterconstante op 0 te zetten schakel je de feature uit; normaal zal deze waarde tussen 1-5 minuten liggen.



Nu de code maar eens gaan afmaken...