OpenCPN on Raspberry PI2

[Schooner Chandlery]

A couple years ago, we fixed any power issues by getting a DC to DC 12V:5V regulated power supply (50 watt) -- so 12 V in 5V regulated out and it supports any number of USB powered devices like our USB powered HDMI monitor, the Pi, charging phones, go-pro, on and on.

The issues with the earlier generations of Pi had to do with drivers, too, and those were eventually updated. This new generation of RPI may not have bullet-proof drivers yet. We just got ours in the mail on Friday and are still in the mist of getting all our regular (non-OpenCPN) boat apps onto it. We have used the older RPI exclusively for offline imap of email, monitoring our airmar WX station, DST, all the onboard NMEA0183 stuff. So, making the transition to the new Pi at this time. It will probably be a few days because we're headed out on Wednesday for an extended time and we're doing last minute prep right now.

[Schooner Chandlery]

and "mist" is an accurate term versus midst. LOL

Update -- David just relays all is working right now on the new Raspberry Pi ARMV7 Pi2 ! Yes-- OpenCPN works, we have GPS, tides&currents, and we're on our hdmi monitor direct to the Pi. This is on Debian Jessie, no Raspbian. If anyone is interested in trying it, he'll make the .deb available for download.

[Schooner Chandlery]

We'll do a full description of what we've got and how it's working later -- but for now David relays that this has been the easiest Debian install EVER for us on any computer (and he's been doing linux since...mid-1990's) only thing not working is XMonad (his preferred light weight GUI, haven't tried gnome but it's a heavy GUI) but the LX desktop works fine. We put over 5.5K packages on, easy, everything is easily working. We do use a 12 year old puck GPS that pre-dates all drivers anyone's ever heard of so we have our own little routine there. LOL. OpenGL (hardware accel installed no problem) and a quick look at test program GLXGears shows OpenGL working fine * and we have hardware acceleration enabled in OpenCPN w/textures and it all works fine. Good. So-- look for a blog post and .deb on Wednesday after we've re-anchored.

[seandepagnier]

You are probably using software drivers as the raspberry pi doesn't support opengl, only opengles, and the drivers for opengles only support full screen mode.

So yes it will work with opengl, but much slower and using more power than what the hardware is capable of.

[Schooner Chandlery]

Originally Posted by boat_alexandra

You are probably using software drivers as the raspberry pi doesn't support opengl, only opengles, and the drivers for opengles only support full screen mode.

So yes it will work with opengl, but much slower and using more power than what the hardware is capable of.

Well gee, I'm sitting here fat, dumb, and happy without having done much of anything to enjoy great performance from the RPI2 on our sail today and right now at anchor.

Right now, we note that OpenCPN looks GREAT with accelerated graphics enabled (OpenGL/OpenGL ES ... dunno, when you're sitting fat, dumb and happy, you don't think to go digging around since there's naught to complain about. Perhaps it is that translator mentioned by Nahanni here Note--without hardware acceleration enabled, OpenCPN runs very slowly and looks like crap. With accelerated graphics (OpenGL) click on options of "texture compression with caching" and update rate is maybe 3-4 fps --slow for a video but seemingly fast enough for the four windows I'm watching (Xtide, Htop, and also SSH running our QT application on x-forwarding from another external cpu (the old Pi), and OpenCPN.) The 4 cpu's are roughly equally loaded and on average the total load is less than one CPU.

We're not running OpenCPN full screen--we are using LX Desktop (comes with Jessie) showing all 4 of the above windows and all seems to be just peachy.

Other fun thing-- we were able to run an ethernet cable from the old pi to the RPI2 w/o a hub (thought it could be done) so we're running a couple things on the old Pi (eg the anchor watch program that we know the old Pi does flawlessly with a buzzer/alarm hooked up to the GPIO port and I want to sleep well tonight...) and viewing on the new RPI2.

OpenCPN really needs the accelerated graphics (OpenGL) for it to work properly in Debian Jessie on the RPI2. And, it works beautifully.

David is much (much) more technical than I (Brenda) am and he'll give you guys some sort of update with the .deb link when he gets online in the morning.

Catch you later,

[sailorxyz]

Cool, I'm looking forward to it as I've just purchased a R Pi 2.

[sailorxyz]

BTW Schooner Chandlery, how are you getting Jessie on the Pi? Cause I've only found images for Weazy. Thanks :-)

[sailorxyz]

BTW Schooner Chandlery, Lastly are you using a crossover cable with the two Pi's? Thanks :-)

[seandepagnier]

Originally Posted by Schooner Chandlery

With accelerated graphics (OpenGL) click on options of "texture compression with caching" and update rate is maybe 3-4 fps

Last year I had hacked in modifications to test opencpn (toolbar and all other windows and dialogs became invisible) with an older raspberry pi. With software opengl the speed was 2-3 frames per second, with hardware opengl, 10-12 frames per second. You would also have much lower cpu use and therefore less power consumption.

Since then I managed to fry the hdmi driver on the screen so it can now work only in vga mode so I can no longer work on this.

So hardware acceleration helps a lot, but still the accelerator on the pi isn't very good compared to the mali on the cubie truck or odroids which gives 30 frames per second.

When you enable opengl, you probably get better performance even without using the graphics accelerator. There is no 2d acceleration either, so non-opengl mode is really very slow. Then, the compressed cache helps a lot even if everything is also done in software. Finally the graphics quality is better because of mipmaps and blending.

Sean

[Schooner Chandlery]

Originally Posted by sailorxyz

BTW Schooner Chandlery, Lastly are you using a crossover cable with the two Pi's? Thanks :-)

Hi sailorxyz, I just wrote a blog post about our install of Debian Jessie and the OpenCPN over on one of our sites (here) that includes links to the Debian Jessie source, as well as our .deb file (zipped) that anyone can download for free (of course) on our site.

Regarding crossover, no, not required. The Pi has auto-sensing and automatically does the cross over if it is needed.

++

Regarding the OpenGL ES 2 (or OpenGL on the pi) -- software/hardware well, it works and the average Joe sailor (doing something like 7 kts) probably isn't going to note the difference. The power difference is a thought for sailors, of course. It will be interesting to see what the open source community does further with the Raspberry Pi VideoCore CPU that sailors can also take advantage of.

We're looking forward to hearing about other sailors using OpenCPN on the RPI2 using Debian Jessie as OS. Feel free to PM or email if someone needs something.

Fair winds, Brenda

[bdbcat]

Brenda...

For reference, could you post the OpenGL parts of your OCPN logfile from the RPI-2/Jessie installation?

Like this: (from x86-GTK)

22:01:50 EDT: OpenGL-> Renderer String: Mesa DRI Intel(R) Q35 x86/MMX/SSE2
22:01:50 EDT: OpenGL-> Version reported:  1.4 Mesa 8.0.4
22:01:50 EDT: OpenGL-> Detected Intel renderer, disabling stencil buffer
22:01:50 EDT: OpenGL-> Texture rectangle format: de1
22:01:50 EDT: OpenGL-> Using Vertexbuffer Objects
22:01:50 EDT: OpenGL-> Using Framebuffer Objects
22:01:50 EDT: OpenGL-> Using FBO Stencil buffer
22:01:50 EDT: OpenGL-> Using Depth buffer clipping
22:01:50 EDT: OpenGL-> Using s3tc dxt1 compression
22:01:50 EDT: OpenGL-> Compressed tile size: 128kb (6:1)
22:01:50 EDT: OpenGL-> Minimum cartographic line width:  1.0
22:01:50 EDT: OpenGL-> Minimum symbol line width:  1.5

Thanks
Dave

[Schooner Chandlery]

Hi Dave, here you go:

20:39:17 PDT: OpenGL-> Renderer String: Software Rasterizer
20:39:17 PDT: OpenGL-> Version reported: 1.4 glshim wrapper
20:39:17 PDT: OpenGL-> Texture rectangle format: de1
20:39:17 PDT: OpenGL-> glGenerateMipmap unavailable
20:39:17 PDT: OpenGL-> Using Vertexbuffer Objects
20:39:17 PDT: OpenGL-> Framebuffer Objects unavailable
20:39:17 PDT: OpenGL-> Using Depth buffer clipping
20:39:17 PDT: OpenGL-> Using s3tc dxt1 compression
20:39:17 PDT: OpenGL-> Compressed tile size: 128kb (6:1)
20:39:17 PDT: OpenGL-> Minimum cartographic line width: 1.0
20:39:17 PDT: OpenGL-> Minimum symbol line width: 1.0

That's as it is right now.

[seandepagnier]

interesting.. so it's using glshim with the software rasterizer.... this is not ideal but should work.

I would like to make glshim always be used so we can dynamically select the opengl library at run time. This would allow people to use opengl with a software driver (we can distribute one with the package for windows users) if they have buggy drivers as often the image quality is much nicer, and several plugins omit features if opengl is not available.

[Schooner Chandlery]

Seems like I'd forgotten to set the panning, then went back and looked--that's not in the accelerated graphics tab, btw, ...so it wasn't using framebuffer/mipmap at all. Will have to check that out later.

We compiled against the xcb-dri2 library, that one doesn't allow the use of opengl with QT for example. We just got another raspberry pi library that we haven't tried but the debian raspberry pi lib-dev does have the opengl drivers for the raspberry pi. Need to play more with drivers. Later...

[mattkab]

Originally Posted by Schooner Chandlery

Hi Dave, here you go:

20:39:17 PDT: OpenGL-> Renderer String: Software Rasterizer
20:39:17 PDT: OpenGL-> Version reported: 1.4 glshim wrapper
20:39:17 PDT: OpenGL-> Texture rectangle format: de1
20:39:17 PDT: OpenGL-> glGenerateMipmap unavailable
20:39:17 PDT: OpenGL-> Using Vertexbuffer Objects
20:39:17 PDT: OpenGL-> Framebuffer Objects unavailable
20:39:17 PDT: OpenGL-> Using Depth buffer clipping
20:39:17 PDT: OpenGL-> Using s3tc dxt1 compression
20:39:17 PDT: OpenGL-> Compressed tile size: 128kb (6:1)
20:39:17 PDT: OpenGL-> Minimum cartographic line width: 1.0
20:39:17 PDT: OpenGL-> Minimum symbol line width: 1.0

That's as it is right now.

So @Schooner Chandlery how did you get glshim to work when you built OpenCPN? I'm close, but still not getting any hardware acceleration, only software, and it runs at about 1FPS. You're getting much better performance.

I have installed on a new RPI2 card the newest debian image from the site you linked to on your blog (which is a very nice image, thank you for the info!).

Then I performed the following:

apt-get install libgtk2.0-dev gettext git-core cmake gpsd gpsd-clients libgps-dev build-essential wx-common libglu1-mesa-dev libbz2-dev libtinyxml-dev libsdl1.2debian xcalib libportaudio2 portaudio19-dev libegl1-mesa-dev libwxgtk3.0-0

apt-get install libwxbase3.0-0-unofficial libwxgtk3.0-0 libwxbase3.0-dev libwxgtk3.0-0-unofficial libwxgtk3.0-dev wx3.0-headers wx-common

git clone git://github.com/OpenCPN/OpenCPN.git
cd OpenCPN
mkdir build
cd build

Download opencpn-gshhs_2.2.4.tar.xz
Extract into OpenCPN/data/gshhs

cmake -DBUNDLE_DOCS=ON -DBUNDLE_TCDATA=ON -DBUNDLE_GSHHS=FULL ../
sudo make
sudo make install

And this is what I have in the log:

18:11:31 UTC: Creating MyFrame...size(1920, 1054)  position(0, 22)
18:11:31 UTC: Creating glChartCanvas
18:11:31 UTC: OpenGL-> Renderer String: Software Rasterizer
18:11:31 UTC: OpenGL-> Version reported:  2.1 Mesa 10.3.2
18:11:31 UTC: OpenGL-> Texture rectangle format: de1
18:11:31 UTC: OpenGL-> Using Vertexbuffer Objects
18:11:31 UTC: OpenGL-> Using Framebuffer Objects
18:11:31 UTC: OpenGL-> Using FBO Stencil buffer
18:11:31 UTC: OpenGL-> Using Stencil buffer clipping
18:11:31 UTC: OpenGL-> Using Scissor Clipping
18:11:31 UTC: OpenGL-> Using s3tc dxt1 compression
18:11:31 UTC: OpenGL-> Compressed tile size: 128kb (6:1)
18:11:31 UTC: OpenGL-> Minimum cartographic line width:  1.0
18:11:31 UTC: OpenGL-> Minimum symbol line width:  1.0
18:11:31 UTC: StatusBar min height: 16    StatusBar font points: 12