Onderwerp: Raspberry Pi performance box

Tsja, een echte DSP is wél native real-time; erg handig voor audio processing etc! Om een grafische userinterface op te hosten? Gaat dat?

Mijn vraag of voor deze relatief lichte, trage applicatie wel een native realtime platform nodig is, is nog niet beantwoord. Lijkt mij niet.

roozeboos schreef :
Nee, het hoeft zeker niet allemaal snel. Het subsysteem "wind beweging correctie" wel. Niet omdat de polar berekening het dan beter doet, maar om voor de stuurman een stabielere uitlezing te geven. Dat is het idee althans. Alle dynamica plat filteren kan altijd nog

Mijn redenering was, dat indien de metingen in orde zijn (=zo gesampled als de AWA), een beetje jitter of af en toe een gemist of doorgescoven sample helemaal geen bezwaar hoeft te zijn. Op 4 Hz werkt het tenslotte ook allemaal (áls de data ook zo snel is!)

Hier een experimentje wat ik net gedaan heb en aantoont dat we "pitch & roll correctie" kunnen vergeten met dit soort data. In dit experiment:

• Boot laten schommelen (8 graden piek-piek, meer lukte niet)
• Wind kwam van BB voor, var 2-4 knopen vóór het slingeren
• Metingen zijn geschaald, richtingen zoals gemeten (BB is negatief zowel voor AWA als Heel

Dan krijg je dit:

Probleem met die "blokgolven" is dat je niet weet wanneer een beweging is begonnen. In ieder geval tussen het sample waar je kijkt en het sample (=de laatste wijziging) daarvóór. Maar je weet niet precies waar.

Toch een poging. Slingeren begint bij lijn A. Kijkend naar de bewegingen vanaf lijn B:
-Heel neem af (=boot beweegt naar BB)
-AWS neemt toe (klopt want we hadden al wind van BB)
-AWA draait naar SB (klopt niet!)

Resolutie AWS is veel te laag om te zien wat (en wanneer) er echt gebeurt. Heel wordt te traag gesampeld om de slinger goed te beschrijven.
Kan zijn dat de traagheid (mechanisch) van de relatief zware windvaan meespeelt, maar door de verminkte data is hier niets over te zeggen.

Anyway toch maar voorzichtig filteren en de masthoogte op 0 zetten (=geen motion correction)...

Nachtvlinder schreef : Absoluut niet nodig. Het rekenwerk voor deze toepassing is helemaal niks voor de Pi, die zal zich >99% van de tijd vervelen.

Je ziet continu een verschuiving van dedicated (hardware & embedded) naar general purpose computing voor intensieve taken. En dit stukje rekenwerk kan je polshorloge nog aan

Het gemak van het toepassen van zo'n general purpose stuk hardware en software als de Pi met Linux is de eenvoud van software ontwikkeling. Je kunt alles testen en uitproberen met je desktop/laptop en dan cross-compilen naar de Pi waar de omgeving grotendeels identiek is als elke willekeurige Linux/Debian distributie.

Pas als je gaat nadenken over producten en volume productie dan wordt het belangrijk dat je de prijs van de benodigde hardware omlaag gaat druken. Hier geen issue denk ik zo

EDIT: als aanvulling omdat ik denk dat ik 'm wel om m'n oren gaan krijgen: zo'n general purpose platform vraagt vaak wel meer stroom en dat is een nadeel aan boord.

Als het hier zou moeten draaien op dedicated hardware zou het blijven bij professionals die hun gesloten systemen op de markt brengen. En die zijn er natuurlijk ook. Echter met een prijskaartje waardoor voor mij volstrekt onbereikbaar. Gezien dat de prijs van een Actisense interface al als een hobbel ervaren wordt ben ik niet de enige.

Een beweging sensor boven in de mast naast mijn wind meter plakken zal voor mij het maximum zijn aan DHZ hardware.

Afgelopen tijd flink gestoeid met de RPi2 en ben ongeveer klaar:

• Het NODE Javascript wordt automatisch als achtergrondservice gestart en gesupervised door een "daemon". Mocht die taak crashen (mijn foutafhandeling is verre van perfect ) dan wordt deze service automatisch herstart
• Lazarus IDE geïnstalleerd op de Pi en project overgezet. Buiten lettertypes die niet overeenkomen met Win32 geen enkele issue
• Settings, ORC data en filters vanuit een texfile beschikbaar gemaakt
• 32GB USB stickje wordt gebruikt om de logfiles weg te schrijven
• Shares, SSH en VNC server geinstalleerd om datafiles over te halen of mee te kijken op een mobiel apparaat (Polarplot zou eigenlijk als webapp herschreven moeten worden!)

Nu kan het geheel aan boord aangesloten worden en kan het calibreren beginnen!

Hieronder een kort filmpje hoe het er nu uitziet...


PS: processorbelasting van de Pi2 ligt tussen 20-25% (bij 10 Hz executie)

Knap! Mooi gemaakt.
Ben heel benieuwd hoe zich dat met real data aan boord gedraagt. Of het overeenkomt met de werkelijkheid.

Vandaag de RPi aan boord aan de Zeus aangesloten zoals het uiteindelijk vast gemonteerd gaat worden.

Werkt allemaal goed en videokwaliteit is beter dan ik had verwacht: zelfs de kleine cijfers van de hellingschaal (onderaan in het midden) zijn leesbaar.

Dien alleen nog de RPi overscan settings te tweaken om het polarplot scherm helemaal beeldvullend te krijgen.

@nachtvlinder
ik zit met argusogen naar je polarplot op RP te kijken.
wanneer kunnen we weer een update verwachten?
zoek je al een tester?

Gisteren voor het eerst gezeild met Polarplot. Gespied van Lemmer naar Enkhuizen. Mooi helder weer en oostenwind trouwens. Was geen straf!

Heb nog geen ideeën om de interface te verbeteren; voorlopig lijkt alle informatie die gegeven wordt nuttig en mis ik geen informatie. Bevalt wel: op een nog leeg IJsselmeer had ik geen andere boten om me heen als referentie of ik harder "moest" of niet. Wel geinig om dan in één oogopslag te zien of je boot extra trim-liefde nodig heeft of niet.

Wind was bij vertrek Lemmer plm 14 knopen; later afnemend naar 9 knopen. Tijdens dat afnemen zakte de performance van gemiddeld 90-95 tot onder 90%. Spiboom omhoog en verder naar buiten bracht dat weer naar 93%. Mijn knagende gevoel was juist - de aktie ook

Foto is genomen tijdens een uitschieter (golfje van achteren). Mooie is dat de filtering in een vloek en een zucht is aan te passen: op vlak water weinig filtering, bij meer golven zwaardere filtering. Bij de verschillende apps op mijn tablet heb ik geen idee wat er precies gebeurt: hier wel...



Dan de toekomst. De opsomming beneden is het werk van een mede ZF lid. Wellicht komt ie zelf met meer details indien daar behoefte aan bestaat - en hij die behoefte ook heeft Dit is niet mijn vakgebied en het is nu wel handig om een goede basis te leggen ipv mijn houtje touwtje (hoewel werkende) oplossing.

• We willen af van de complexe koppeling via TCP naar de Websocket server
• Websocket server in de Zeus is niet voldoende stabiel (als ik de Autopilot inschakel bijvoorbeeld wordt de verbinding verbroken en dien ik opnieuw te verbinden). Grootste nadeel is echter dat dit erg specifiek is voor één (mijn) configuratie, waarbij het niet gedocumenteerd is wat die Websocket server met de data doet (zie eerder gepostte tijdreeksen) en wat de latency is.
  
• RPi moet via een PiCAN2 direct op de bus komen en zich als een device gaan gedragen - dit maakt het universeel bruikbaar voor elke boot met een CAN netwerk en voorkomt "single point of faillure" en afhankelijkheid van een (WiFi/ethernet) Access Point
• Architectuur wordt modulair: data acquisitie, berekeningen en grafische schil worden uit elkaar getrokken en worden eigen processen/executables of zelfs RPi's
• We zijn er nog niet uit of dit via een message-broker systeem (clients subscriben zichzelf op data-events) of inter-process messaging (2 of meer kanten op) gaat gebeuren. Of zelfs via de CAN bus zélf (we broadcasten dan zelf PGN's waarop aangesloten nodes uitluisteren)
• Wanneer deze basis klaar is wordt het open-source (via Github oid) zodat mensen kunnen bijdragen aan applicaties op het gebied waar ze goed in zijn
• RPi device kan ook zelf de bus op met berekende data (denk aan een "nieuw" gecalibreerd log apparaat, target angle, target speed of polar performance). Aangesloten MFD's kunnen deze data dan weergeven.

Ben vandaag bezig de CAN bus te loggen om informatie te verzamelen hoe de bus zich gedraagt (ISO address requests, address claims etc). Dit door de apparaten telkens een koude start te geven met steeds meer apparaten aangesloten; de RPi is momenteel onzichtbaar op de bus maar logged alles inclusief timestamps (op ms niveau!) Polarplot moet zich netjes gedragen en geen busconflicten veroorzaken: daarom is het belangerijk dit echt goed te begrijpen!

Inmiddels is het de mede-ontwikkelaar thuis gelukt om via de PiCAN2 een GPS-device aan te maken en op de bus te laten schrijven. In de Zeus in zijn testopstalling is dit als nieuw device zichtbaar en je kunt dit device dan als "position data source" instellen. Dit is een eerste maar belangrijke stap naar het aanmaken van virtuele devices!

PS: na lang zoeken er achtergekomen dat de composite-video uitgang van de RPi staat of valt met een stabiele voedingsspanning! Als je dat rainbow-logo rechtsboven ziet zit je op of over het randje. De composite-uitgang gaat als eerste op zwart - terwijl de RPi zelf gewoon doorgaat. Via VNC heb je nog steeds een display port; op hardware niveau dan al niet meer. Ik heb alleen goedkope standaard laadkabeltjes bij me. De kortste kabel zorgde ervoor dat ik geen onderspannings waarschuwing meer kreeg...

Indrukwekkend!...

erg mooi hoor.

Ik vind t gaaf.

Heel erg gaaf!!

Je gaf aan nog wat problemen te hebben met de overscan settings en je fonts. Wellicht heb je iets aan onderstaande tips. Ik heb deze zelf gebruikt in een ander project.

Overscan settings:
www.webtechgadgetry.com/make-r...-resolution-monitor/

Microsoft fonts installeren:
sudo apt-get install ttf-mscorefonts-installer

edwin30 schreef :
Zeker! Dank (ook voor de eerdere reacties!)

Ziet er mooi uit. Vooral bewondering voor je grafische frontend. Misschien kunnen we je verleiden er een HTML5 versie van te bakken.
Verder zou het erg interessant zijn een 3d sensor aan de raspberry te koppelen. In mijn idee is daar behoorlijk wat winst te behalen. Vooral als die rekenkundig gelinkt kan worden aan de SOG van een GPS, en goede snelle wind data. VHW dan alleen nog te gebruiken als basis om drift en stroom te bereken. Deze laatste zijn in mijn idee trage variabelen. Je snelle variabelen zijn dan alleen de 3d, SOG en wind.

Nachtvlinder schreef :
Ja dat is leuk he! Het houdt je bij de les!
Ziet er fraai uit allemaal.

@3Noreen: ik volg jouw (of was het Noorderzon's?) draadje daarover! Ligt meer voor de hand dit in de Pi te doen dan via een duur maritiem apparaat. Attitude pgn's kunnen via de Pi de bus op, zodat buiten jouw frisse ideen zelfs de Autopilot daar iets aan heeft!

ik word al helemaal blij van hoe polarplot er nu eruit ziet.
De mogelijkheden om intern de berekeningen aan te passen staan mij erg aan.
Alle andere polar en vmg rekendozen zijn inderdaad black boxen.
Jouw houtje touwtje polar plot is juist vanwege de eenvoud lean and mean!
een mogelijkheid om de polar te loggen had je er toch ook al in?

Bedoel je je eigen polar laten maken? Het enige dat Polarplot doet is het loggen van alle inputs en relevante ouputs. Ik werk gewoon met de polar uit m'n meetbrief (alle configuratie gegevens, filtersettings, polardata etc zijn extrern en kunnen eenvoudig aangepast worden voor andere boten). Anyway het zelf maken van je polar schijnt geen sinicure te zijn en vergt menselijke intelligentie! Was laatst een ander draadje over...

ik heb de draadjes :
zeilersforum.nl/index.php/foru...polar-maken?start=75
en
www.zeilersforum.nl/index.php/...-polair-maken#616751
doorgelezen.

De polar op de meetbrief is natuurlijk leidend, heeft geen zin ook om hierover in discussie te gaan met de meetbrief autoriteiten.
Wat ik bedoel met een log functie is een puntenwolk maken op de polar die naderhand gefilterd op windsnelheid te zien is.
Het interpreteren van deze puntenwolk is denk ik voor als nog mensenwerk.
Met de log functie kan je in alle rust aan de keukentafel de bootprestaties zien tov de polar bij welke koersen en windrichting.
ik denk dat jouw log functie dat al doet?

Dat kan Polarplot nu niet; de huidige logfunctie slaat slechts de tijdreeksen op van de (ruwe en gefilterde) inputs en berekende (ruwe en gefilterde) outputs. Gewoon in ASCII formaat met timestamp (voor wat dat waard is bij de manier waarop de metingen via de huidige methode binnen komen).

Ik denk dat wat je voorstelt een leuke uitbreiding kan zijn, maar behoorlijk ingewikkeld volgens die draadjes die je aanhaalt.

Een voordeel van een modulaire aanpak is dat je bijvoorbeeld een "time-series historian" module kunt ontwikkelen die een database vult. Een andere module "polar creator" ofzo kan deze database dan gebruiken om daar statistische bewerkingen op los te laten. Bijvoorbeeld het grafisch weergeven van een query als:

"Toon me alle bootsnelheden die én stabiel én tot de hardst gevaren 95% populatie behoren én bij constante wind tussen 10 en 11 knopen gemeten zijn én die langer dan 10 s continue zijn gevaren"

Zoiets? Leuk voor aan de keukentafel ook!

Als (wanneer) de open-source opzet een geschikte fundatie heeft kunnen mensen die daar goed in zijn, tijd en zin hebben daar mee bezig...

@ Fransb, die puntwolk kan wel in WinGPS gemaakt worden, heb er 1 van mn Comet,maar wat ermee te doen ontgaat me

Als je dus geen polar hebt van je eigen boot zou iemand met dat programma mss aan boord bij jou een meting kunnen doen zodat je die later in de Pi stopt??

die asci reeksen bevatten al de benodigde info.
hup in excel en maar filteren en grafiekjes maken

@Anjo
met behulp van de puntenwolk kun je bepalen op welke ranges koersen en windsterktes je kan optimaliseren en daarop specifiek trainen/trimmen en welke ranges altijd al goed zijn.

Ondanks dat het "professionaliseringsteam" in maart enthousiast gestart is, gaat dit op een lager pitje verder vanwege diverse omstandigheden.

Omdat ik toch (snel) van de houtje-touwtje en in de praktijk onvoldoende robuuste connectivity af wil ga ik zelf, in een parallel traject, verder. Dit met onderstaande doelstellingen:

• Simpel, robuust en voor mij nog net te behappen (ik wil niet telkens een uur moeten studeren om te weten te komen "hoe het ook al weer zat")
• Zo min mogelijk netwerk koppelingen
• Geen user-interaktie: de logging start ik automatisch zoals 3Noreen dat bv doet en de overige toggles gaan eruit. PolarPlot draait altijd in de "stromend water" modus
• Géén gebruik meer maken van de Websocket (aka Tier 2) koppeling naar de Zeus maar native van de CAN bus lezen met het PiCAN2 board
• PolarPlot event-driven maken, dus alléén updaten indien er nieuwe data beschikbaar is

Het CANboat project bevat reeds alle tools die ik nodig heb, deze ga ik koppelen aan de meegeleverde tools bij het PiCAN2 board.

Via slecht één command-line:
Gebeurt het volgende. Van links naar rechts door de pipes:

1. candump can0 leest de ruwe data op de CAN bus (tool van PiCAN)
2. candump2analyzer vertaalt deze ruwe data naar inputs voor (3) (tool uit CANboat)
   
3. analyzer (N2K packet analyzer) zet deze data om naar JSON ASCII strings (tool uit CANboat)
4. n2kd (tool uit CANboat) maakt deze data beschikbaar op zowel een JSON als NMEA0183 TCP server. Omdat de NMEA0183 conversie op dit moment slechts enkele PGN's ondersteunt, gebruik ik de JSON server. Deze ondersteund alle bekende PGN's - zie verder op in deze file
5. PolarPlot maakt verbinding met bovengenoemde JSON TCP server en parsed de binnenkomende JSON strings

Topologie gaat dan van dit:


Naar dit:


Een heel stuk eenvoudiger en robuuster!

Ik heb het nu t/m de TCP server aan de praat op basis van logfiles. Nu begint het stoeien om de JSON libraries in Lazarus aan de praat te krijgen...

Foto's hebben niet zoveel zin nu: je ziet slechts hard over het scherm scrollende data Maar het principe moet gaan werken!

Kleine tip:
Het analyzer programma kent de optie om PGN's te filteren. Dit ga je hard nodig hebben op een druk N2K netwerk anders verzuipt Polarplot in de data. Bij de transformatie van CAN naar JSON explodeert de data sterk, dus selecteer alleen de PGN's die je nodig hebt.

Waarschijnlijk is het zelfs mogelijk om eerder te filteren (meteen na candump), door er een 'grep' regeltje aan toe te voegen. Zover ik me kan herinneren staat het PGN nummer er daar al leesbaar in namelijk.

Mooi, het werkt!

Beetje technisch dit verhaal maar vind het handig dit even vast te leggen (en wie weet gaan er meer lezers met zo'n PiCAN board aan de slag - kost < eur 40).

Énige bash command line om de JSON TCP server uit het CANboat project te starten is:
Omdat ik de Pi nu niet bij me heb simuleer ik met een eerder opgenomen logfile onder Win64 en Cygwin, een soort Linux interpreter (weet dat ook niet precies).

Op de Pi zélf kun je zo'n met candump en timestamps opgenomen logfile real-time afspelen naar een virtuele (of echte) CAN bus dmv canplayer. Je leest deze vcan0 dan weer uit met candump om daar dan iets mee te gaan doen. Dát stuk krijg ik niet gecompileerd onder Cygwin; de CANboat tools wél.

Real-time afspelen lukt dus niet (nu). In plaats daarvan speel ik de (zonder timestamps) opgenomen logfile af met gelimiteerde snelheid, zodat de resulterende datastroom ongeveer net zo snel is als aan boord.

In de command line hierboven:

• listfile.exe is een klein C-programmatje wat niets anders doet dan de logfile (die maar 10 min lang is) eindeloos herhalen, zoals cat dat maar één keer doet
• PlusPlay.txt is de logfile, direct van de bus, zonder timestamps
• De eerste pijp naar pv (pipe viewer) limiteert de snelheid
• De tweede pijp naar grep (goede tip Erwin!) laat alleen de PGN's door die PolarPlot nodig heeft. Je ziet hier de hexadecimale weergave van die PGN's, zoals die ook op de bus staan
• candump2analyzer maakt de stream al iets leesbaarder. Je herkent o.a. de PGN's (nu decimaal), de source en destination device-ID's (255 is een broadcast, dus niet gericht naar één specifiek apparaat zoals bv de autopilot controller dat wél doet naar de AP computer).
• analyzer zet het netjes in een voor parsing geschikt JSON formaat om
• tenslotte verzorgt n2kd de TCP server
(die óók naar NMEA0183 vertaalt en uitzend op een andere poort, maar dat stuk is nog in ontwikkeling (alleen de basis-zinnen worden ondersteund. Je kunt op deze manier dus ook een hele snelle N2K naar NMEA0183 converter/server opzetten zodat je bv iSailor kunt voeden met snelle N2K data.)

In PolarPlot (Free Pascal) werkt het parsen van de JSON data uiterst eenvoudig. Hier bv de heading-data:
Ter illustratie hieronder hoe de data eruitziet door de verschillende pipes heen:

Ruwe data op bus of na afspelen van een logfile:
Ná candump2analyzer:
Ná analyzer in JSON formaat:
Nu PolarPlot nog wat verder poetsen en die onhandige toggles eruit halen...

Voor mensen die ook met de PiCAN2 interface werken is PolarPlot evt beschikbaar om mee (mee!) te testen. Het geheel is nu niet meer afhankelijk van welk merk N2K apparatuur je aan boord gebruikt. PolarPlot is een autonome CAN client geworden in zekere zin. Grafische uitvoer kan ook naar een scherm aan de Pi of een VNC sessie...