OpenCPN Runs on Embedded ARM

[seandepagnier]

Originally Posted by Wrong

Sort of out of my league here since I'm an android tablet fan, running OpenCPN in a chroot linux environment. But, regarding the build error reporting OpenGL as not found, I experienced that for some strange reason exporting the library path didn't work. So, I just edited the /build/CmakeCache.txt file like so.

Are you getting full hardware accleration from your chroot on android? Rendering should run 5-10 times faster when you enable opengl.

[seandepagnier]

Originally Posted by sparticle

Hello again,

Sorry for the delay in posting, I went sailing

Just read through, it seems you have OpenGL working after a fashion. In this in lightdm? I also noted you needed to move the libGL to /usr/lib/arm-*

I have the following libGL* files in /usr/lib/arm-linux-gnueabihf already:

libGL.so
libGL.so.1
libGL.so.1.2
libGLU.a
libGLU.so
libGLU.so.1
libGLU.so.1.3.08005

Do I need to copy my compiled ones over these?

Either that, or set LD_LIBRARY_PATH.

Also, don't worry about GLU I don't think it's needed after all, I didn't bother with it.

Do you intent to push the hacks to OpenCPN to the GIT?

The only change I made was to replace calls to "Refresh" in chcanv.cpp with conditionally calling Render() in glChartCanvas.cpp. This is interesting to explore and might actually be better on all platforms.

This makes opencpn more usable, but the toolbar is still invisible. To correct this, a button or gesture could be used which would simply grab the framebuffer used by xorg and push it to opengl. This would be a rather slow operation, so would only be used when the menus and dialogs are needed. The alternative is just to toggle opengl which might be simpler to implement.

I am sure that there are a lot of interested pi users that would love to have a useable OpenCPN particularly with the new B+ with 4 USB ports.

Cheers
Spart

Yes, well you seem to be the only one I know of. Let us know if you get it working at all with opengl.

[Wrong]

Originally Posted by boat_alexandra

Are you getting full hardware accleration from your chroot on android? Rendering should run 5-10 times faster when you enable opengl.

Aside from noticing the details are sharper and zooming/panning is faster, I haven't done any diagnostics. I believe a tablet with 3 gigabytes of ram, like the Samsung Galaxy Note Pro 12.2 has the potential to maximize the benefits of OpenGL in OpenCPN. But, more important to me is the possibility of rendering a video file with Kdenlive Kdenlive | Free and open source video editor for GNU/Linux, Mac OS X and FreeBSD becomes a reality. I only use OpenCPN for planning and to occasionaly check my progress/track while underway. Speed is not a priority. Better detail is good.

[BlackNav]

it's strange, but with my config (Cubietruck and OpenGL @ 60 fps) OpenCPN is not fluent and not very pleasant at all to use : about 1 second for drag of the map.
I'm using CM93 vector charts, located on a USB stick.
Once I receive my SSD drive I will put everything on it and make a try with NOAA Raster charts.

[sparticle]

Originally Posted by boat_alexandra

Either that, or set LD_LIBRARY_PATH.

Also, don't worry about GLU I don't think it's needed after all, I didn't bother with it.

The only change I made was to replace calls to "Refresh" in chcanv.cpp with conditionally calling Render() in glChartCanvas.cpp. This is interesting to explore and might actually be better on all platforms.

This makes opencpn more usable, but the toolbar is still invisible. To correct this, a button or gesture could be used which would simply grab the framebuffer used by xorg and push it to opengl. This would be a rather slow operation, so would only be used when the menus and dialogs are needed. The alternative is just to toggle opengl which might be simpler to implement.

Yes, well you seem to be the only one I know of. Let us know if you get it working at all with opengl.

Can't seem to get anything working in Raspbian apart from the binary pigears program.

I can't believe that I am the only one The Rpi particularly the B+ should be the perfect platform for very low power marine use. I already have an Rpi WiFi AP on board that I also intend to run as a headless nmea mux. Could also be used as a replacement for the nav pi if it goes down. Have just ordered a Model B+ so will start from scratch when it gets here and compile everything fresh. I will make the changes to the cpp files if you post the snippets I am not a c++ programmer

OAN as anyone tried one of these 7 Display 1280x800 (720p) IPS + Speakers - HDMI/VGA/NTSC/PAL ID: 1667 - $169.95 : Adafruit Industries, Unique & fun DIY electronics and kits

They look very good 720p and 12v @ 700ma

Cheers
Spart

[seandepagnier]

Originally Posted by Wrong

Aside from noticing the details are sharper and zooming/panning is faster, I haven't done any diagnostics. I believe a tablet with 3 gigabytes of ram, like the Samsung Galaxy Note Pro 12.2 has the potential to maximize the benefits of OpenGL in OpenCPN. But, more important to me is the possibility of rendering a video file with Kdenlive Kdenlive | Free and open source video editor for GNU/Linux, Mac OS X and FreeBSD becomes a reality. I only use OpenCPN for planning and to occasionaly check my progress/track while underway. Speed is not a priority. Better detail is good.

Is that tablet 8 cores?

You are the first person to report using opencpn with hardware accelerated opengl under linux chroot in android. It would be interesting if you could post the opengl relevant details of the opencpn.log file, I am curious what it says. As far as I knew only opengles is supported on tablets which requires glshim.

Anyway.. the tablet you mention, it's very high powered, so depending on your intended use, maybe speed is not a concern. I am sure if you could time travel 10 years in the future and run that opencpn on this tablet, it would certainly seem sluggish or be unable to complete many of the much more advanced graphics rendering operations available.

Originally Posted by sparticle

Can't seem to get anything working in Raspbian apart from the binary pigears program.

Try setting GL_FBDEV=1 environment variable, I don't know if it will help you. Really the raspberry is getting obsolete fast, and the newer arm boards are so cheap it makes sense to use them instead, especially for this application. The raspberry uses a lot of power for what it can do compared to newer arm boards.

Consider a bananna pi for example, same form factor as the raspberry, but with more ram, faster dual core processor, the graphics capabilities of the cubie truck (about 3 times faster) and more efficient switching regulator so much less power usage. It costs what, $15 more?

I can't believe that I am the only one The Rpi particularly the B+ should be the perfect platform for very low power marine use. I already have an Rpi WiFi AP on board that I also intend to run as a headless nmea mux. Could also be used as a replacement for the nav pi if it goes down. Have just ordered a Model B+ so will start from scratch when it gets here and compile everything fresh. I will make the changes to the cpp files if you post the snippets I am not a c++ programmer

OAN as anyone tried one of these 7 Display 1280x800 (720p) IPS + Speakers - HDMI/VGA/NTSC/PAL ID: 1667 - $169.95 : Adafruit Industries, Unique & fun DIY electronics and kits

They look very good 720p and 12v @ 700ma

Cheers
Spart

I have a display 1280x800 which I got for $50 on ebay and it looks very good running opencpn with smooth zooming on raspberry pi. It also takes HDMI/VGA or analog inputs, and can drive two lcd displays. There are no speakers.

Unfortunately the hdmi lcd driver board is a bit stupid and seems to make a lot of heat (running off 12 volt batteries) so I had to cut a hole in the back of the plastic case I mounted it in.

[seandepagnier]

What I have is nearly identical to this, but cost less than half as much on ebay:

HDMI 4 Pi: 7 Display 1280x800 IPS - HDMI/VGA/NTSC/PAL ID: 1931 - $114.95 : Adafruit Industries, Unique & fun DIY electronics and kits

[Wrong]

Here 's a fresh log file.

By the way, in case you don't know, I'm also the first person ever to install and run OpenCPN on an android device. The instructions here: opencpn.org/ocpn/node/193 were prepared and posted by me in June, 2012.

So, don't mind taking credit for being first here too.

You get credit for piquing my curiosity and suggesting I try.

The Motorola Xoom is powered by a dual-core 1GHz Nvidia Tegra 2 SoC. 1280x800 display resolution, 32GB of onboard storage (expandable via SD), 1GB of DDR2 RAM,

They're selling used for around $150-200 now. New, $300+.

06:25:16 PDT:

________

06:25:16 PDT: 2014-08-05
06:25:16 PDT: ------- Starting OpenCPN -------
06:25:16 PDT: Version 3.3.1931 Build 2014-07-31
06:25:16 PDT: wxWidgets version: wxWidgets 2.8.12
06:25:16 PDT: MemoryStatus: mem_total: 715 mb, mem_initial: 28 mb
06:25:16 PDT: SData_Locn is /usr/share/opencpn/
06:25:16 PDT: Using existing Config_File: /home/android/.opencpn/opencpn.conf
06:25:16 PDT: Styles loading from /usr/share/opencpn/uidata/styles.xml
06:25:16 PDT: No styles found at: /home/android/
06:25:16 PDT: No styles found at: /home/android/.opencpn/
06:25:16 PDT: Setting Viewpoint Lat/Lon 37.8691, -122.496
06:25:16 PDT: Setting Ownship Lat/Lon 37.8691, -122.494
06:25:17 PDT: System default Language: en_US
06:25:17 PDT: Opencpn language set to: en_US
06:25:18 PDT: ChartSymbols loaded from /usr/share/opencpn/s57data/chartsymbols.xml
06:25:18 PDT: Using s57data in /usr/share/opencpn/s57data
06:25:18 PDT: Setting Viewpoint Lat/Lon 37.8691, -122.496
06:25:18 PDT: Setting Ownship Lat/Lon 37.8691, -122.494
06:25:18 PDT: Creating glChartCanvas
06:25:18 PDT: PlugInManager searching for PlugIns in location /usr/lib/opencpn
06:25:18 PDT: OpenGL-> Renderer String: Mesa X11
06:25:18 PDT: OpenGL-> Texture rectangle format: de1
06:25:18 PDT: OpenGL-> Using Vertexbuffer Objects
06:25:18 PDT: OpenGL-> Using Framebuffer Objects
06:25:18 PDT: OpenGL-> Using FBO Stencil buffer
06:25:18 PDT: OpenGL-> Using Stencil buffer clipping
06:25:18 PDT: OpenGL-> Using Scissor Clipping
06:25:18 PDT: OpenGL-> Not Using compression
06:25:19 PDT: ChartDB Cache policy: Application target is 343 MBytes
06:25:19 PDT: Loading chart db version: V018
06:25:19 PDT: Chartdb: Chart directory list follows
06:25:19 PDT: Chart directory #0: /mnt/sdcard/charts
06:25:19 PDT: Chart directory #1: /mnt/sdcard/CM93
06:25:19 PDT: GPS Watchdog Timeout is: 6 sec.
06:25:19 PDT: Loading World Chart Q=0 in 0 ms.
06:25:19 PDT: Background world map loaded from GSHHS datafiles found in: /usr/share/opencpn/gshhs/
06:25:19 PDT: Loading World Chart Q=2 in 2 ms.
06:25:20 PDT: Initializing Chart /mnt/sdcard/CM93
06:25:20 PDT: CM93Composite Chart Root is /mnt/sdcard/CM93/
06:25:20 PDT: Loaded CM93 Dictionary from /mnt/sdcard/CM93/
06:25:21 PDT: Loading CM93 cell /mnt/sdcard/CM93/03300660/D/03810711.D
06:25:22 PDT: Loading CM93 cell /mnt/sdcard/CM93/03300660/C/03780708.C
06:26:17 PDT: LOGBOOK: 2014-08-05 13:26:17 UTC DR Lat 37.86910 Lon -122.49420

Originally Posted by boat_alexandra

Is that tablet 8 cores?

You are the first person to report using opencpn with hardware accelerated opengl under linux chroot in android. It would be interesting if you could post the opengl relevant details of the opencpn.log file, I am curious what it says. As far as I knew only opengles is supported on tablets which requires glshim.

Anyway.. the tablet you mention, it's very high powered, so depending on your intended use, maybe speed is not a concern. I am sure if you could time travel 10 years in the future and run that opencpn on this tablet, it would certainly seem sluggish or be unable to complete many of the much more advanced graphics rendering operations available.



Try setting GL_FBDEV=1 environment variable, I don't know if it will help you. Really the raspberry is getting obsolete fast, and the newer arm boards are so cheap it makes sense to use them instead, especially for this application. The raspberry uses a lot of power for what it can do compared to newer arm boards.

Consider a bananna pi for example, same form factor as the raspberry, but with more ram, faster dual core processor, the graphics capabilities of the cubie truck (about 3 times faster) and more efficient switching regulator so much less power usage. It costs what, $15 more?



I have a display 1280x800 which I got for $50 on ebay and it looks very good running opencpn with smooth zooming on raspberry pi. It also takes HDMI/VGA or analog inputs, and can drive two lcd displays. There are no speakers.

Unfortunately the hdmi lcd driver board is a bit stupid and seems to make a lot of heat (running off 12 volt batteries) so I had to cut a hole in the back of the plastic case I mounted it in.

[sparticle]

Originally Posted by boat_alexandra

Is that tablet 8 cores?

Consider a bananna pi for example, same form factor as the raspberry, but with more ram, faster dual core processor, the graphics capabilities of the cubie truck (about 3 times faster) and more efficient switching regulator so much less power usage. It costs what, $15 more?

OK this looks good, are you saying that it would be the right answer for running OpenCPN OpenGL? It looks like it only supports OpenGL ES 2.0/1.1 is that the smae as the normal pi? Seems to be faster and Arm V7 and 1GB Ram so Ubuntu/Android etc. compatible, right?

I use Pi's for my media centres and they work fantastically well Full HD etc. No performance issues at all.

Do you believe these Banana pi's are better for this application (marine low power multipurpose computers, Nav Computer/NMEA Mux?Wifi AP/Media Centre) ?

Cheers
Spart

[Wrong]

boat_alexandra,

Anticipation you may ask...

Here's the log output after enabling compression.

06:56:39 PDT: OpenGL-> Using 3dfx fxt1 compression
06:56:39 PDT: OpenGL-> Compressed tile size: 128kb (6:1)

[seandepagnier]

Originally Posted by Wrong

boat_alexandra,

Anticipation you may ask...

Here's the log output after enabling compression.

06:56:39 PDT: OpenGL-> Using 3dfx fxt1 compression
06:56:39 PDT: OpenGL-> Compressed tile size: 128kb (6:1)

If you are actually using fxt1 compression, most likely there is no hardware acceleration. Also the renderer string "mesa x11" indicates software rendering

This makes sense as the tablet probably supports opengles which requires you to use glshim. So while the image may look better, you won't get the larger performance increases that you would see if you were using glshim.

[jonasaberg]

Originally Posted by boat_alexandra

...
Consider a bananna pi for example, same form factor as the raspberry, but with more ram, faster dual core processor, the graphics capabilities of the cubie truck...

Interesting, have not heard of the banana before. But maybe the question is; what is the low power spec alternative fast enough with full (enough) OpenGL support?

The banana and cubie are still only OpenGL ES, am I right?

[seandepagnier]

Originally Posted by jonasaberg

Interesting, have not heard of the banana before. But maybe the question is; what is the low power spec alternative fast enough with full (enough) OpenGL support?

The banana and cubie are still only OpenGL ES, am I right?

OpenGL ES is enough for opencpn.

Anything which can support opengles in xorg works well. As far as I know, this is everything except the broadcom drivers on the raspberry pi. The bananna pi uses mali graphics like the cubie truck. The raspberry pi only supports opengles from the console so it works, but the toolbar and any other dialogs become hidden.

[jonasaberg]

ok, so the banana is better than the rpi for at least three reasons:
-better performance
-mali graphics so will show menus
-should be easier to make it run due to better driver

on the bad side is that it is still
new and somewhat unproven...

[gpshephe]

and right when you enter the harbor at 2AM, wind onshore at 30 knots, seas 12-15 at 4 seconds , fog at zero viz, your ARM ( whatever that is ) boots.