OpenCPN Runs on Embedded ARM

[akopac]

Go Freddie Go!!! Banana Pro arrived yesterday and going with beta build and mesa installed. GLXgears shows steady ~53. Bren your right about everything else... It just works in this Lubuntu Banana Pro image. Wifi, printers, etc. no issues. I would like to be able to change the freq. of the CPU and hardware acceleration for the video too... Seems the CPU never goes near 1 ghz but is set to change automatically.

[sparticle]

Have been watching this thread with great interest after failing to get the Rpi to run OpenCPN with Open GL capabilities. BoatAlexander had a version but I could not replicate that, I had been holding out for progress on the Rpi, but it looks like that is not going to happen anytime soon, and as new Arm devices become available it seems unlikely that it will happen for the Rpi B+ etc.

Looking at the forums and support sites for the Bpi Pro it seems there are similar problems with the Mali chip. As a very long term Ubuntu user this Bpi Pro platform would seem to offer the best hope for a Ogl accelerated version of OpenCPN running on Ubuntu(lubuntu) 14.04LTS.

I just wondered what the other peoples views were on this.

The Rpi B+ (the 4USB ports are a huge bonus) is fantastic as a black box NMEA processor and wireless cloud device. We have it processing all GPS/AIS and NMEA data onboard and serving as a NMEA Data Cloud. It never gets anywhere near 5W typically .6 - .8 A @ 5V. We have 3 x 110Ah batteries on the domestic circuit. Hope is top have a system that can run nav computer etc. for upto 14days without recharging.

Cheers
Spart

[NahanniV]

Despite a few small remaining problems, I wanted to point out that OpenCPN is running very well on my CubieTruck board.

Since speed is very subjective, here is a short video of panning and zooming using RNC charts (pre compressed), OS and charts are stored on an SD card. I'm planning to add a small SSD to further improve performance and reliability.

Thanks to all the developers and testers who made this possible.

Cheers,
JM.

[NahanniV]

Here is a video that illustrates the biggest remaining problem I see with OpenCPN on the CubieTruck ARM platform.

Other problems have mostly been related to the operating system/video drivers of particular images, but this has been common to all, so I am thinking it may be in the OpenCPN or GLshim code.

As initially reported by GHammond, Certain levels of detail do not display correctly for CM93 charts in OpenGL mode on the CubieTruck.

Note that a problem with the display of OwnShip (as reported by WRONG) is also visible in this video.

[rgleason]

NahanniV Thank you. Cubie truck seems perfectly fast enough from the video. From my experience with Dell Laptop XPS 15 I have noticed some similar detail problems but have not focused on them really. Perhaps I should.

[seandepagnier]

Originally Posted by NahanniV

Here is a video that illustrates the biggest remaining problem I see with OpenCPN on the CubieTruck ARM platform.

Other problems have mostly been related to the operating system/video drivers of particular images, but this has been common to all, so I am thinking it may be in the OpenCPN or GLshim code.

As initially reported by GHammond, Certain levels of detail do not display correctly for CM93 charts in OpenGL mode on the CubieTruck.

First, try disabling vbo (set to false on line glChartCanvas.cpp:993)

Next, try using software opengl libraries (replace libGL.so.1)?
Finally, try disabling opengles in cmakelists?

Note that a problem with the display of OwnShip (as reported by WRONG) is also visible in this video.

I am not really sure, but it looks like the problem is with opengl off.

[NahanniV]

Originally Posted by boat_alexandra

First, try disabling vbo (set to false on line glChartCanvas.cpp:993)

Next, try using software opengl libraries (replace libGL.so.1)?
Finally, try disabling opengles in cmakelists?


I am not really sure, but it looks like the problem is with opengl off.

OK, Tried disabling vbo by commenting out line 993+994 in glChartCanvas.cpp
Verified "Vertexbuffer Objects unavailable" in log file. But no change in behavior of CM93 in OpenGL mode.

Guess I need to get the libGL.so.1 from the original image since I overwrote it with the GLshim version ?

I did already try disabling opengles in cmakelists, but it made things much worse, even the base map was corupted.

Will try more tomorrow.

Cheers,
JM.

[NahanniV]

Originally Posted by boat_alexandra

First, try disabling vbo (set to false on line glChartCanvas.cpp:993)

Next, try using software opengl libraries (replace libGL.so.1)?
Finally, try disabling opengles in cmakelists?


I am not really sure, but it looks like the problem is with opengl off.

Next, I restored the software Opengl library from the original image:

00:00:25 EST: OpenGL-> Renderer String: Software Rasterizer
00:00:25 EST: OpenGL-> Version reported:  2.1 Mesa 8.0.5
00:00:25 EST: OpenGL-> Texture rectangle format: de1
00:00:25 EST: OpenGL-> Using Vertexbuffer Objects
00:00:25 EST: OpenGL-> Using Framebuffer Objects
00:00:25 EST: OpenGL-> FBO Stencil buffer unavailable
00:00:25 EST: OpenGL-> Using Depth buffer clipping
00:00:25 EST: OpenGL-> Using 3dfx fxt1 compression
00:00:25 EST: OpenGL-> Compressed tile size: 128kb (6:1)
00:00:25 EST: OpenGL-> Minimum cartographic line width:  1.0
00:00:25 EST: OpenGL-> Minimum symbol line width:  1.0

All the levels of CM93 displayed correctly. It was painfully slow.

So, I guess the problem is either in GLshim or something lower ?

When I tried disabling opengles before, it caused a lot of problems with the display.

Why would this problem only show up on certain levels ?

Do you have these CM93 charts ? Are you not seeing this problem ? What could be different ?

Cheers,
JM.

[NahanniV]

Would it be very hard to write a program that would test all the OpenGL functions needed by OpenCPN ? It would certainly help to figure out where the problems are. It would also be an easy way to see if hardware and software support is adequate to run OpenCPN with OpenGL.

[seandepagnier]

I don't think I can write such a program soon. I think opencpn is using a feature in opengl that is not in opengles and not emulated by glshim properly.

Does this happen frequently? Can you check/uncheck vector chart display options to find it? (start with as much stuff not checked and see if there is a problem)

[NahanniV]

Originally Posted by boat_alexandra

I don't think I can write such a program soon. I think opencpn is using a feature in opengl that is not in opengles and not emulated by glshim properly.

Does this happen frequently? Can you check/uncheck vector chart display options to find it? (start with as much stuff not checked and see if there is a problem)

OK, Thanks for the guidance.

It is definitely the "Dredged area" option that causes the problem.

Hopefully, it's easy to fix, but I can live with it turned off for now.

Cheers,
JM.

[seandepagnier]

Great to know, I will try to debug when I get the chance.

[travellerw]

Damn.. I swore I wouldn't get sucked into trying to build a low power ships PC..... but I just couldn't resist..

So... It looks like I will be adding a completely different hardware to the mix. I decided on the Radxa Rock Pro. Its a bit more money than a Raspberry, Cubie or Banana but has the features to back up the cost. 8mb of onboard NAND for the OSs, quad core 1.6ghz CPU, 2GB of RAM, Bluetooth to name a few.

Of course I will be trying to get OpenCPN to run on it. I'm hoping with the horsepower and OpenGL ES support that OpenCPN will run smooth. We will see. I will post back once it arrives and I've had a play around with it.

[muttnik]

Originally Posted by sparticle

I had been holding out for progress on the Rpi, but it looks like that is not going to happen anytime soon, and as new Arm devices become available it seems unlikely that it will happen for the Rpi B+ etc.

Many people will have already seen the announcement but....new pi coming:
BBC News - Raspberry Pi 2 unveiled with faster processor and more memory
Edit: Here's a better link:
http://www.raspberrypi.org/raspberry...e-new-product/
Edit #2....Element14's website seems verrrrrrrrrry slow....

[seandepagnier]

What graphics processor? looks like broadcom again... probably better to use bananna pi, unless the drivers have improved to work in windowing systems.