Onderwerp: Raspberry Pi evaluatie voor navigatie

Wegens aanhoudende discussie over opencpn op de raspberry heb ik een poging gedaan een installatie te simuleren.
Voorlopig beperkt dit zich tot opencpn, maar zygrib enzo zullen later ook nog wel aan bod komen om uit te zoeken of dit bordje nu aan boord een praktisch nut kan hebben of niet.

Let wel op, dit is een persoonlijk verhaal met persoonlijke keuzes. Dit is geen bijbel maar alvast, happy reading. Hier gaan we.

Er wordt veel geschreven en gediscussieerd over het gebruik van een Rasperry Pi aan boord.

Wat is een Raspberry eigenlijk?
Als je een pi koopt, koop je eigenlijk niet meer dan een printplaatje waar alles op zit. Een volledige pc die op 1 printje past lijkt toch te mooi om waar te zijn.

Even inzoomen waarom dit interessant kan zijn voor de botenwereld.
Eerst en vooral, de prijs. Op dit ogenblik kost een Rasperry Pi (model $35 + shipping costs. Op zich is dit erg goedkoop. Daar moet nog wel een keyboard, muis, scherm, gpsmuis,… bij. Echter het totaalplaatje blijft echter zeer goedkoop.

If you pay little, you get little. Dus ook zal je ‘t moeten doen met 512MB ram, een arm gebaseerde processor die standaard op 700Mhz loopt en een gpu (grafische processor) die krachtig genoeg is om HD op een tv toestel af te spelen.
Dan krijg je nog een paar usb poorten en basicly dan hebben we de belangrijkste componenten wel gehad.

Op www.raspberrypi.org/ vinden we dan een plaatje hoe het ding er eigenlijk echt uitziet.



Image courtesy of Switched On Tech Design (www.sotechdesign.com.au)

Inderdaad, het bordje heeft geen harde schijf, geen aan/uit knop etc. De software gaat op de SD card, die kan je ook zelf maken/voorbereiden en aan/uit, dat is eenvoudig, gewoon stroom of geen stroom.
Als we ‘t over stroom hebben, hebben we het ook over de grootste troef van dit bordje. Het verbruik. Op dit moment heb ik nog geen pi ter beschikking maar forums, internet zijn heel lovend over het verbruik.
Raspberry Pi loopt op 5v micro USB. Maximaal kan de Pi 1A verwerken, maar dan moet je ‘m wel voeden met een usb hub die aan de stroom hangt.
Kunnen we nu ook effectief iets doen met dit bordje? Er is al veel over geschreven en gebabbeld maar een consensus is blijkbaar moeilijk te vinden.

Op dit moment heb ik geen Pi (na nieuwjaar wel ☺ ) dus heb ik een emulator op mijn pc die de arm processor simuleert.

Daarvan zijn massa’s guides te vinden op internet over hoe een emulator te bouwen en zou ons hier te ver brengen.

Als OS voor de PI-simulatie heb ik voor raspbian gekozen. Waarom? Persoonlijke voorkeur. Dit is een gestripte en voor arm gebaseerde pi debian linux distributie. De anderen zullen waarschijnlijk ook wel werken, echter (nog) geen ervaring mee.



Hieruit zien we dat als we de Pi opstarten in emulatie, dat hij wel degelijk gebruik maakt van de arm architectuur en ook raspberry arm kernel.

Nu OpenCpn. Out-of-the-box, vergeet het. Dat is echt een no-go. Dus moeten we onze versie zelf bouwen.

Eerste stap is altijd de handleiding lezen. Dus die vinden we hier: opencpn.org/ocpn/compiling_source_linux

Staat veel bruikbaar in. Bvb de prerequisites. Die zijn sowieso nodig, dus die kunnen gewoon overgenomen worden en dat werkte ook direct. Geen problemen hier. Alles zat netjes in de linux repository. Misschien dat hier en daar nog optimizaties mogelijk zijn, moet verder bekeken worden. Nu focussen op “getting it running”.

Git clone is ook vrij standaard, geen problemen tegengekomen. So far so good, dus de source code is binnen.

Eigenlijk is het niet moeilijk, builden heb ik (in laatste poging) gedaan voor met native flag en nog een paar andere.
Uiteindelijk is de build volgens de opencpn site vrij rechttoe rechtaan en na de installatie zelf, start het programma ook op. Klinkt veel belovend!

Na de opstart moet je de kaarten toevoegen. Ondertussen zal iedereen wel weten hoe dit werkt, dus gaan we niet dieper op in.
Ik beschik over een versie CM93 kaarten (1,4GB) en vanaf deze geselecteerd werden gebeurt er … niks. Geen kaarten, overzoom, inzoomen, … niks. Logfiles blijven leeg en tonen enkel dat de kaarten goed ingelezen worden. Wat is hier toch aan de hand.
Verder uitzoeken leert dat cpu verbruik gigantisch de hoogte in gaat vanaf de kaarten gelezen worden. Dus dat wijst richting de code. De manier van zoeken zal ik jullie besparen, maar voor deze kaarten zat het probleem in cm93.cpp. Eigenljk zat er geen fout in, ik zou de code ook zo schrijven, maar na een waarde vast te zetten ipv dynamisch op te halen, kreeg ik na een hercompilatie plots een kaart te zien na ongeveer 1 seconde. Traag maar werkbaar.

Volgende test. Detail toevoegen. Ik selecteer in OpenCpn volgende opties:



Dit lijkt ook te werken aan redelijke snelheid, dus gaan we zoomen om bvb een haven te kunnen aanlopen. Want schaal 1754100 is nu niet echt bruikbaar. Echter, vanaf er dieper gezoomd dient te worden, crasht heel opencpn er gewoon volledig uit. Eerst geprobeerd met swapfiles etc maar desondanks dat voor een goeie werking de swap van het systeem toch groter moet zijn dan de standaard 100MB (ik heb deze vergroot naar 1GB) en overclocken etc, niks helpt. Dit moet dus ook weer in de code zitten. Zoals gewoonlijk, niks in de logs, geen dumps,… op zoektocht dan maar.

Na een lange zoektocht blijkt dat veel van de “problemen” in de wxwidgets zitten die opencpn gebruikt. OpenCpn heeft minstens 2.8 nodig. Heb de originele versie niet bijgehouden, maar sinds 11 november 2013 is versie 3 “current en stable”. Er is niks dat op performance degradatie kan wijzen, dus het kan enkel beter worden. Na een nachtje builden op de emulator zijn de widgets ook geupgraded naar de laatste versie.
Echter opencpn heeft hardcoded verwijzingen naar de versies van deze widgets. Deze moeten dus vervangen worden en een paar methods moeten ook aangepast in een 3 tal cpp-files. Eigenlijk voornamelijk slordigheden in de programmatie. Bvb checks die overbodig zijn, casts die ontbreken, dat soort dingen.
Anyhow, na aanpassingen in de code de opencpn opnieuw gebuild (duurt een kleine 2uur op emulatie) en inderdaad! We krijgen kaarten te zien en kunnen zoomen binnen de seconde! Dit is traag maar bruikbaar.



Missie geslaagd? Niet volledig. Dit is verre van af. Deze installatie maakt bvb nog geen gebruik van de OpenGL. Dit zorgt voor foutmeldingen bij ‘t opstarten. Mits juiste glx-versie natuurlijk wel op te lossen.

Volgende uitdaging is de gpsd ook aan de praat krijgen, echter zal dat volgens mij niet lukken op emulator (alhoewel ☺ ) maar eerst deze build eens op een echte Pi proberen. Na de glx problemen zijn opgelost.


Samengevat, de Raspberry Pi is een leuk stuk hardware! De arm-achitectuur maakt het natuurlijk net dat ietsje moeilijker.

Is het mogelijk opencpn aan werkbare snelheid te krijgen? JA! En eens niet zo erg moeilijk als je ‘t weet.
Is het voor iedereen weggelegd? Ik zou zeggen neen. Er zijn veel eenvoudiger manieren om navigatie op een energiezuinige pc te zetten. Dit werkt nu, maar hoe gaat dit zich gedragen als het gepatched/upgegraded wordt? Deze installatie lijkt in niks op de builds die OpenCpn zelf aanlevert.
Dat neemt niet weg dat het een zeer leuk knutselprojectje is en als toevoeging op de navigatie kan het zeker dienen en als overzichtskaart zou ik het zelfs bij mij aan boord durven gebruiken. Echter enkel als aanvulling, nooit als primaire navigatie. Daarvoor is (op dit moment) nog teveel knutselwerk mee gemoeid om in geval van, je leven ervan te laten afhangen.

hoe verhoudt de snelheid van jouw simulatie zich tot de werkelijke snelheid van een raspberry?
idem voor geheugengrootte en i/o?

zonder deze info kun je niet veel zeggen over de echte snelheid (van OpenCPN) op een echte berry....

100% gelijk Thomas.
emulator is met deze parameters gestart:

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 512 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw elevator=deadline rootwait panic=1" -hda 2013-09-25-wheezy-raspbian.img -hdb swapdisk.img -redir tcp:5022::22

Dus hij gebruikt normaal dezelfde processor en snelheid als de echte model B. Ook geheugen is niet mee geprutst. Blijft de 512MB die op een standaard model B zit.

I/O haal ik 70MB/s (gemiddeld) op read en 34MB/s (gemiddeld) op write.
Is dit vergelijkbaar met de Pi? Ik weet het niet. Moeten we meten op een echte.

Eigenlijk ben ik hoopvol om de image eens op een sdcard te zetten en op een berry te laten draaien. Na nieuwjaar komt een vriend met zijn berry naar me thuis en dan doen we de echte testen. Zal wel sowieso sneller zijn dan de emulator. Ik zie toch wel wat overhead in de emulator ook en om eerlijk te zijn, qemu heeft qua overhead niet echt een goeie reputatie.

ook van belang natuurlijk de snelheid van de geheugenchipjes.
Een SDkaart zal vast flink langzamer zijn dan SDRAM of zo in je PC...

Wel mooi dat je die emulator wat performanceparameters kan meegeven!

net even dd tests gedaan op mijn emulated pi.
mijn native os is write 362MB/sec ter vergelijking.
dus ik vermoed dat de emulator ook wel rekening houdt met de max performance van de sd card (bewijzen kan ik dit niet).

Zet een img ergens op het net. Dan kunnen anderen ook genieten. Hier op mijn buro ligt een Rasb nix te doen. Mijn kennis gaat niet zo ver maar een img naar een SD schrijven gaat wel lukken.
- een van de nadelen van een SD is wel dat die niet erg lang mee gaat als die vaak wordt beschreven. Maar dat is makkelijk op te lossen door elk seizoen met een nieuwe kaart te beginnen.

en zelfs daar zijn oplossingen voor.
linux is eigenlijk ontworpen voor op draaiende schijven te werken en sd cards slijten het hardst van "fout" gebruikt. Nu kan je linux ook aanpassen om er wel deftig mee om te gaan.
Voor "niet bewegende opslag" moet je andere filesystemen aanmaken enzo eigenlijk. Journaling zou je kunnen afzetten, noatime parameter zetten, uw "uitlijning" van uw storage goed doen...
Staat dus ook nog op de todo list.

image is nu 10GB, hoe groot zijn je sd'cards? Welke card ga je gebruiken want van de kaart zelf hangt HEEL veel af. een class 10 zal bvb sneller zijn dan je class 4 ... )

morgenavond eens in het OpenGL probleem duiken denk ik.

Die van mij ligt ook stof te happen....

Ik heb volgens de methode op deze site; www.agurney.com/raspberry-pi/pi-chart OpenCpn proberen te installeren, maar krijg het niet draaiende..
Ik ben nu nog wat andere distro´s aan het proberen; www.raspberrypi.org/downloads (Arch, RISC-OS, Pidora) draait allemaal leuk, vooral met RISC-OS is hij (voor een ARM processor) best wel snel. RISC-OS is ook de lichtste distro die er op het moment voor de Raspberry is.
In een .img ben ik ook zeer geinteresseerd, want tot nu toe ben ik wel een beetje vastgelopen met de Pi en OpenCpn.
Mijn plan was om de Pi in te bouwen in de boot, met een 10¨ inch usb touch-screen. Het moet allemaal gevoed worden via de accu/zonnepanelen, en gezien de afmetingen van mijn boot, een leisure17, zijn dat niet erg grote panelen. dus een laag stroomverbruik is voor mij zeer interessant.

Martijn

16 Gb is geen probleem. Nu heb ik er een 32 in. maar die wis ik liever niet. Veel verschil in snelheid heb ik overigens niet kunnen ontdekken bij verschillende kaarten op de rasb. Mogelijk wel als opencpn veel naar verschillende files moet. Bovendien een class 10 @ 16Gb kost nagenoeg het zelfde als de rasb.

ok goed, ik ga een manier bedenken om de 10GB bij jullie te krijgen.
even een kleine "disclaimer"

Dit is een pre-alpha build. Er zitten nog fouten in op glx, die foutmeldingen krijg je ook bij opstart.
Gps connectie is nog niet gechecked, lijkt mij ook wel belangrijk

Kaarten zijn niet van mij, dus "eigenlijk" moet ik ze uit de image wissen, maar ik ga er van uit dat jullie netjes de kaarten gekocht hebben en dit dus geen probleem hoeft te zijn.

Aan de linux moet nog VEEL gesleuteld worden, vooral voor de throughput naar de sd card toe.
Yep 3noreen, die kaartjes zijn "relatief duur", maar hun performantie wel waard.
Voor deze build steek er niet je beste kaartje in omdat alles nog getouched gaat worden!
Controleer ook de build of de swapfile groot genoeg is. In de emulator durft hij de 2e disk (zo heb ik het tijdelijk opgelost) soms niet vinden en dan moet je zelf effe snel je swap aanzetten.

Een build op risc staat ook nog op het wishlistje, maar eerst maar even zien hoe deze quick en dirty hack op een echte raspberry pi reageert.

Accepteren jullie dat dit nog niet echt gebruikt kan worden en gewoon "om te zien of het traag maar bruikbaar qua responsiveness" is?


edit: GLX foutje gevonden denk ik, maar dat zou willen zeggen een volledige rebuild van een nachtje kunnen jullie nog wachten tot volgende week om te testen?

Absolut geen haast. Ook nog geen intentie om in nu al in te zetten aan boord. Gewoon leuk om mee te experimenteren.
Wis de inhoud van de kaarten map die kunnen wij zelf wel weer vullen met onze eigen materiaal. Of we gebruiken kaarten van RWS. Dan kunnen we wat publiekelijker met de img om gaan.

Geen probleem, ik heb geen haast Er liggen hier ook nog een hoop andere ¨projecten¨ te wachten

Martijn

Ik volg dit met argusogen en hoop dat het dan misschien toch kan,OpenCPN op mijn Pi.
Maar voor het zover is, zal ik blijkbaar nog een hele hoop moeten leren, voornamelijk hoe kernels te rebuilden, cross compiling etc etc .

Hoeft niet hè Tony als de image beschikbaar is, is het image op sdcard, kaartjes opzetten en runnen maar.
Da's het mooie van de pi. Hardware is altijd 't zelfde (model dus kan je in de build alles insteken.
Ben er ook nog niet uit of het rasbian blijft of niet, maar voorlopig doet het wel goed.

Hulde voor al deze inzet!

Mijn PI crashed inderdaad bij het inlezen van de kaarten, waardoor de PI door gebrek aan geduld en onkunde in de hoek beland is.

We lezen gulzig mee.

Maar ik mis even de reden voor dit project.

Kosten kan het zijn, maar je moet flink uitkijken met je componenten om niet boven de 300 E uit te komen voor het hele verhaal.

Dan stroomverbruik. 1A is VEEL! De vraag is geheel wat voor voeding, 12V/5V converter, je er voor zet. Mijn webbook gebruikt 600mA/12V met het beeldscherm aan!

De enige die dan over blijft is hobby.

Tja, daar is niks tegenin te brengen.

Joop66 schreef :
Net als varen natuurlijk......

Tja ik had ook 2 Pi's aangeschaft voor al dat leuks aanboord (en thuis) en ondertussen lopen ze ook stof te happen. En dat gedoe met die SD kaartjes helpt ook niet echt.
Toen ik mijn Pi net had beef het steeds opnieuw booten. Het bleek dat de voeding die ik had niet genoeg stroom leverde en dat vand de Pi niet leuk.
Ondertussen zijn er ook andere fabrikanten die linux experimenteer bordjes leveren. Eentje die me erg charmeert is Olimex die heeft dit bordje het kost €65 dat is 2x zo duur als een Pi maar je krijgt er ook heel wat meer voor. (A20 cpu=dual core ARM 7, 1GB ram 4GB flash, SATA aansluiting, VGA/HDMI/LCD aansluiting, 6-16V voeding spanning!) Antratek.nl heeft ze ook. Bij Olimex verkopen ze ook bijpassende schermjes.
Ik wordt erg blij van dit apparaat. Oh ja en voor de knutselaars (ik dus ook) voldoende I/O aansluitingen.
Als ik een goede kaart kan vinden voor openCPN dan ga ik zo'n ding kopen.

Mijn persoonlijke reden? Eenvoudig, ik lees er zoveel her en der over dat ik op de duur niet meer weet wie te geloven. Enige manier is het dan zelf uit te zoeken.

Rebuild van deze nacht geeft geen gewenst resultaat, maar weet wel waar 't zit en is niet simpel te fixen.

Bij Linux heb je 1voordeel, niet gaan bestaat niet. Zal er wel rond geraken, maar zal even tijd vragen. Komt wel goed, ziet er veel belovende uit. Ik heb zo'n gsm autoladertje dat 5v geeft, en met een gsm eraan zit dat onder de 0,5A, dus maar met mijn kerncentrale aan boord lukt dat net

Nou ik heb dat bordje inmiddels besteld. Ik was zo verlekkerd toen ik naar de beschrijving keek
Ik zal nogwel laten weten hoe dat gaat in een nieuw topic.

Wat verbruikt zo'n olimex? Enig idee?

300mA bij 12V zonder 'peripherals', 500mA met. Vooral de ingangsspanning is interessant, pakt alles aan tussen de 6 en de 16V, kan dus gewoon aan het boordnet.

Inderdaad interessanter dan raspberry pi dan.
Een ding vraag ik mij dan af, waarom is de pi zo bekend en olimex nog niet?

Waarom is Windows zoveel bekender dan Ubuntu? Heb intussen ook een site gevonden van iemand die die A20 op Ubuntu heeft laten draaien...
olimex.wordpress.com/2013/10/1...s-for-a20-olinuxino/
Het grote voordeel is dat Opencpn gewoon op Ubuntu draait hier.

Ubuntu is nog altijd debian based he. Als je'n gui'ke belangrijk vindt, tsja maakt niet veel uit op zich.

Wel effe rekening houden dat't ook een arm gebaseerd bordje is en dat je dus ook je opencpn zelf zal moeten builden.
Waarschijnlijk door de "grotere power" van dat bordje kan't wel zijn dat je met de guide op opencpn tot een werkende build komt zonder aanpassingen. Zoniet, laat even weten he, dan geef ik de hacks in de cpp files wel door (in pb, is hier geen computerforum voor compilers he )