OpenCPN Runs on Embedded ARM

[seandepagnier]

You should get same fps with glxgears.


I think it is obvious the problem. You are still using the wrong libraries.

LD_LIBRARY_PATH=/usr/lib glxgears

will probably work. If you don't want to type this, then remove the other libGL files

locate libGL

[jonasaberg]

Originally Posted by boat_alexandra

LD_LIBRARY_PATH=/usr/lib glxgears

will probably work.

Sean,
I am a total newbie to this, so bare with, but should it not be configured somewhere in the code which libraries to use, or did you suggest this just for testing?

[it-slav]

Originally Posted by boat_alexandra

You should get same fps with glxgears.


I think it is obvious the problem. You are still using the wrong libraries.

LD_LIBRARY_PATH=/usr/lib glxgears

will probably work. If you don't want to type this, then remove the other libGL files

locate libGL

LD_LIBRARY_PATH=/usr/lib glxgears

Get 60FPS and it started in fullscreen, instead of a window (RPIGears did also start in fullscreen)

Regards
Peter

[it-slav]

Originally Posted by it-slav

I'll do my very best to document.
So far:
Starting with latest raspbian

As root

apt-get install xorg xutils xserver-xorg xterm xserver-xorg-video-fbdev xserver-xorg-video-vesa
apt-get install mesa-utils
git clone https://github.com/seandepagnier/glshim.git
cd glshim
mkdir build
cd build
cmake .. -DBCMHOST=1
make GL
sudo cp lib/libGL* /usr/lib

Now, in .bashrc add this line to the bottom, as pi:

export LIBGL_FB=1

As pi

cd
git clone https://github.com/nfz/RPIGears
cd RPIGears/
make
RPIGears.bin

Get 350 FPS with RPIGears.bin
Get 19 FPS with glxgears

/Peter

When starting glxgears with:

LD_LIBRARY_PATH=/usr/lib glxgears

I get 60FPS

So I continued:

git clone https://github.com/ssvb/glues.git
cd glues/
mkdir build
cd build
cmake ..
make
cp libGLU.so.1 /usr/lib/libGLU.so

git clone -b optimum https://github.com/seandepagnier/OpenCPN OpenCPN-optimum
cd OpenCPN-optimum/
mkdir build
cd build
cmake -DCFLAGS="-O2 -march=native" ../
-- The C compiler identification is GNU 4.6.3
-- The CXX compiler identification is GNU 4.6.3
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- *** Build Architecture is armhf
-- *** Staging to build opencpn 3.3.1618 ***
-- Looking for XOpenDisplay in /usr/lib/arm-linux-gnueabihf/libX11.so;/usr/lib/arm-linux-gnueabihf/libXext.so
-- Looking for XOpenDisplay in /usr/lib/arm-linux-gnueabihf/libX11.so;/usr/lib/arm-linux-gnueabihf/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/arm-linux-gnueabihf/libX11.so
-- Found OpenGL: /usr/lib/arm-linux-gnueabihf/libGL.so
-- Found OpenGL...
--     Lib: /usr/lib/arm-linux-gnueabihf/libGLU.so/usr/lib/arm-linux-gnueabihf/libGL.so/usr/lib/arm-linux-gnueabihf/libSM.so/usr/lib/arm-linux-gnueabihf/libICE.so/usr/lib/arm-linux-gnueabihf/libX11.so/usr/lib/arm-linux-gnueabihf/libXext.so
--     Include: /usr/include
-- Found wxWidgets: TRUE
-- Found wxWidgets...
-- -L/usr/lib/arm-linux-gnueabihf;-pthread;;;-L/usr/lib/arm-linux-gnueabihf;;;-lwx_baseu-2.8;-lwx_gtk2u_core-2.8;-lwx_baseu_net-2.8;-lwx_baseu_xml-2.8;-lwx_gtk2u_html-2.8;-lwx_gtk2u_adv-2.8;-lwx_gtk2u_aui-2.8;-lwx_gtk2u_gl-2.8
--
-- *** Staging to build opencpn  ***
-- *** Will install to /usr/  ***
-- Found Freetype: /usr/lib/arm-linux-gnueabihf/libfreetype.so (found version "2.4.9")
-- Found GTK2_GTK: /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so
-- Found GTK2
-- Portaudio Not Found...
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1")
-- Found BZip2: /usr/lib/arm-linux-gnueabihf/libbz2.so (found version "1.0.6")
-- Looking for BZ2_bzCompressInit in /usr/lib/arm-linux-gnueabihf/libbz2.so
-- Looking for BZ2_bzCompressInit in /usr/lib/arm-linux-gnueabihf/libbz2.so - found
-- Found ZLIB: /usr/lib/arm-linux-gnueabihf/libz.so (found version "1.2.7")
-- Found TinyXML: /usr/include
-- Building with tinyxml includes
-- S57 ENC support: enabled
-- Garmin Host Mode support: enabled
--
-- *** Staging to build PlugIns ***
--
-- *** Staging to build dashboard_pi ***
-- *** Staging to build grib_pi ***
-- Writing spec file...
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CFLAGS


-- Build files have been written to: /media/7830-41F1/opencpnhack/OpenCPN-optimum/build

The OpenGL stuffed looked promising. However it might be the wrong libs?

make
make install

LD_LIBRARY_PATH=/usr/lib opencpn -fullscreen

When starting it works quite well, I just miss the icon that shows gps status.
It seems faster then before.

When changing to opengl it totally hangs and console fills with:

glXGetProcAddress: glGenFramebuffers not found.
glXGetProcAddress: glGenFramebuffers not found.
glXGetProcAddress: glGenFramebuffers not found.
glXGetProcAddress: glGenRenderbuffers not found.
glXGetProcAddress: glGenRenderbuffers not found.
glXGetProcAddress: glGenRenderbuffers not found.
glXGetProcAddress: glFramebufferTexture2D not found.
glXGetProcAddress: glFramebufferTexture2D not found.
glXGetProcAddress: glFramebufferTexture2D not found.
glXGetProcAddress: glBindFramebuffer not found.
glXGetProcAddress: glBindFramebuffer not found.
glXGetProcAddress: glBindFramebuffer not found.
glXGetProcAddress: glFramebufferRenderbuffer not found.
glXGetProcAddress: glFramebufferRenderbuffer not found.
glXGetProcAddress: glFramebufferRenderbuffer not found.
glXGetProcAddress: glRenderbufferStorage not found.
glXGetProcAddress: glRenderbufferStorage not found.
glXGetProcAddress: glRenderbufferStorage not found.
glXGetProcAddress: glBindRenderbuffer not found.
glXGetProcAddress: glBindRenderbuffer not found.
glXGetProcAddress: glBindRenderbuffer not found.
glXGetProcAddress: glCheckFramebufferStatus not found.
glXGetProcAddress: glCheckFramebufferStatus not found.
glXGetProcAddress: glCheckFramebufferStatus not found.
glXGetProcAddress: glDeleteFramebuffers not found.
glXGetProcAddress: glDeleteFramebuffers not found.
glXGetProcAddress: glDeleteFramebuffers not found.
glXGetProcAddress: glDeleteRenderbuffers not found.
glXGetProcAddress: glDeleteRenderbuffers not found.
glXGetProcAddress: glDeleteRenderbuffers not found.
glXGetProcAddress: glGenerateMipmap not found.
glXGetProcAddress: glGenerateMipmap not found.
glXGetProcAddress: glGenerateMipmap not found.
glXGetProcAddress: glGetCompressedTexImage not found.
glXGetProcAddress: glGetCompressedTexImage not found.
glXGetProcAddress: glGetCompressedTexImage not found.

I guess that I still don't have correct drivers.



/Peter

[seandepagnier]

Unfortunately you slipped up on something that should possibly be changed anyway.

Basically, I am searching for opengles support as you can see by the many #ifdef ocpnUSE_GLES in the code. Your log indicates it did not detect it (see the detection in CMakeLists.txt) it is searching for a header file (either GLES/gl.h or GLES2/gl2.h) which must be in /usr/include or /usr/local or something. On the raspberry these are in /opt or somewhere possibly. To get past this, either copy them (bad way) or fix the CMakeLists.txt detection (much better for other users) to correct this.

I'm still not sure the best way because some people _may_ want arm builds using big opengl at some point, but for our purposes we want opengles because the bcm driver is only opengles.

Now.. glshim _mostly_ handles translating big gl to opengles, but in many cases also falls short, or there are other reasons, so we must also do some things in opencpn to make opengles work properly.


Are you sure it hanged, or possibly just has no video output? Can you still quit with control q for example?

[seandepagnier]

What do you think of a $25 raspberry pi with a $25 lcd display?
5" High Resolution HD 800 480 Car TFT LCD Monitor Screen 2CH Video | eBay

Of course we still need a cheap efficient buck converter to make 5 volts from whatever batteries, and some kind of input keypad or possibly mouse or touch screen? What would work best if it could also get splashed?

[MAd]

Hi everybody,
I'm completely new to this board trying to get OpenCPN running smoothly on a cubieboard2. I've installed Cubian both on SDcard and in NAND, added some packages I assume to be useful (synaptic etc.), configured screen resolution to 1920x1080p60 and compiled and tried both OpenCPN 3.2 and 3.3 beta booting from SDcard or NAND. Both are basically working with OpenSeaMap .kap files of the Baltic Sea, but both versions are pretty slow on CubieBoard2. Before I start trying to understand how to implement HW graphics accelerationm, one basic question:
If my main purpose is to use OpenCPN with OpenSeaMap files, do you suggest to use a Cubietruck instead? Does 2GB of RAM instead of 1GB makes a huge difference when using OpenCPN?
Sorry for "hijacking" this thread, but it seems to me, that this is the best one to ask
Regards,
Martin

[it-slav]

Originally Posted by MAd

Hi everybody,
I'm completely new to this board trying to get OpenCPN running smoothly on a cubieboard2. I've installed Cubian both on SDcard and in NAND, added some packages I assume to be useful (synaptic etc.), configured screen resolution to 1920x1080p60 and compiled and tried both OpenCPN 3.2 and 3.3 beta using DCcard or NAND. Both are basically working with OpenSeaMap .kap files of the Baltic Sea, but both versions are pretty slow on CubieBoard2. Before I start trying to understand how to implement HW graphics accelerationm, one basic question:
If my main purpose is to use OpenCPN with OpenSeaMap files, do you suggest to use a Cubietruck instead? Does 2GB of RAM instead of 1GB makes a huge difference when using OpenCPN?
Sorry for "hijacking" this thread, but it seems to me, that this is the best one to ask
Regards,
Martin

Actually I have the same question.
What lowpower hardware is good enough to run OpenCPN on?
I know that the question is like "How long is a string?" but the RPI seems to weak for the task and I'm thinking of buying some better hw. Gpsd itself take approx 30% of the CPU on the RPI.

Does anyone has a recommended low powered hw recommendation?
So far I've looked at:
Wandaboard: Wandboard - Freescale i.MX6 ARM Cortex-A9 Opensource Community Development Board - BLOG
Utilitie: Home | Utilite
Cubieboard: Cubieboard | A series of open ARM miniPCs
Beagleboard: BeagleBoard.org - BeagleBone Black
Cubox: Products | The CuBox i From SolidRun

Or maybe it is best to wait for the marine version of the sollaptop, http://http://solaptop.com/en/products/laptops/
On their website it has said "coming soon" since august 2013.

/Peter

[MAd]

@Shean re converter:
I'm using a (way oversized but pretty small) adjustable step down converter (15A, in 4-32V, out 1.2-32V) to power my cubieboard and a 21" 1920x1080 12V monitor. This converter is low loss and costs 20EUR incl. shipment on e.b.a.y.
Regards,
Martin

[bcn]

Martin, we have an Olimex A20 with OpenCPN here, which runs from 6-16V DC directly.
Power conditioning on the same board.

[MAd]

Hi,
what do you mean with "we have here"? In use on your boat? If yes, do you experience adequate performance?
Martin

[bcn]

No, not on the boat. We using it as our in-house AIS feed. (And some day to test the S-63 stuff on ARM - pending task).
But I think, there shouldn't be any problem.

On the boat underway there is no quick panning or 25 charts at a time.
Happens when planning or playing, but then performance is not a problem neither. Patience perhaps yes... But even then.
Having 75 AIS targets on the screen (1.920 x 1.080) is not an issue.

What me worries more are points like housings and connectors. The bare boards are an easy prey for corrosion, condensation etc.
One will spend easily more on that for a reliable solution than for the boards themselves. Same for displays.

Hubert

[Eirik]

Originally Posted by it-slav

Actually I have the same question.

What lowpower hardware is good enough to run OpenCPN on?

I know that the question is like "How long is a string?" but the RPI seems to weak for the task and I'm thinking of buying some better hw. Gpsd itself take approx 30% of the CPU on the RPI.



Does anyone has a recommended low powered hw recommendation?

So far I've looked at:

Wandaboard: Wandboard - Freescale i.MX6 ARM Cortex-A9 Opensource Community Development Board - BLOG

Utilitie: Home | Utilite

Cubieboard: Cubieboard | A series of open ARM miniPCs

Beagleboard: BeagleBoard.org - BeagleBone Black

Cubox: Products | The CuBox i From SolidRun



Or maybe it is best to wait for the marine version of the sollaptop, http://http://solaptop.com/en/products/laptops/

On their website it has said "coming soon" since august 2013.



/Peter

I am currently testing out the Utilite (standard version). I've godt OCPN, latest Beta, up and running with CM93 charts. Needed to do a minor patch to source code before compiling (thank you Dave for giving the hint) otherwise the serial connection option in setup would crash OCPN.

Performance is so far clearly acceptable to me, although I have not tested it on the boat yet. Scrolling can be a bit slow. OpenGL does not work, but I consider trying the optimized version to see if this would do the trick.

If interested, I can revert with findings, tricks, etc.

Eirik

[seandepagnier]

With the cubie truck and hardware accelerated graphics and optimum branch, the result is faster and smoother graphics than a netbook with an atom processor. I am getting 25 frames per second. With the optimum branch, opencpn uses very little ram (with right options) so having 2gb vs 1gb or even 512mb makes little difference. Of course if you are using the normal beta or without hardware acceleration it will make a big difference.

Then comes raspberry pi.. it's a bit slow at 4-5 frames per second (only 1-2 without hardware acceleration) but I think usable. Of course it depends on the person.

Many future optimizations are also possible I intend to explore.

As far as power goes.. I am using $1.99 85% efficient switching regulator that takes 8-36 volts and outputs 5 volts for up to 3 amps.

I'm looking at potentially building many chart plotters and reselling them to people who don't have the time or skills to configure all the software and hardware. In this way, people who do have the time will have good instructions for how to do everything, and can also customize it to their needs.

The basic idea is to take either raspberry pi, or cubie board, and attach a 5, 7 or 9 inch display. Add a good quality gps, and optional dvi tvb receiver for ais, and a small speaker (for alarms) then put everything in a completely waterproof case so it can work underwater also (so big waves can strike the box) Then probably using a custom membrane keypad to control it. I have about 30 4x4 membrane keypads already.. so maybe these can be used.

The total parts cost is under $100 (raspberry pi based) or up to $200 (cubie with larger screen) for building a single unit. Any suggestions? Let me know if you have any interest.

Anyone with a 3d printer? This can be used this to make the enclosures.

[jonasaberg]

Sean,
Your link to displays on ebay at
http://www.cruisersforum.com/forums/...ml#post1535093
and

Originally Posted by boat_alexandra

The basic idea is to take either raspberry pi, or cubie board, and attach a 5, 7 or 9 inch display. ... total parts cost is under $100 (raspberry pi based)

It is a great idea, but what about viewability of the screen. I looked at your display link, and they don't state the brightness, but I would guess it is really poor. Did you get one to try?
Does it make sense with a watertight enclosure for a device that can only be used on deck at night. Maybe ... but I would like to aim higher...

/Jonas