OpenCPN Runs on Embedded ARM

[sbfreddie]

Guy:
I have been using the Cubieboard2 (1 GHz Dual Processor with 1 GB RAM) running Debian to run OpenCPN and its quite a robust and capable little ARMv7 board. Works with any of my usb GPS pucks. (I use the Globalsat BU-353 mostly). Power consumption is between 3 and 5 Watts depending on what its doing. If you couple it with a SSD drive it really flys, yes it also has a working SATA port and comes with a cable for the Drive.

Check it out.

Thanks,
Freddie

[JRM]

Originally Posted by Lake-Effect

This is a fast-changing area. It's fun to play with the current crop (I have some Raspberry Pi's) but for a long-term embedded platform for OpenCPN, I'm gonna wait for a bit; the coming ARM SBCs will be much more capable. In the meantime, i like netbooks. They're available used for under $100, they're complete and self-contained. Insert a bootable SD card with Navigatrix and charts, plug in a GPS USB fob (or a serial-USB adaptor taking a NMEA0183 feed), and you have a running OpenCPN platform in about 30 minutes.

I put OpenCPN on a Raspberry Pi yesterday and it basically works out of the box. Installed and updated the current Raspbian image, added myself as a user (don't forget to add yourself to the proper groups), and then cut and pasted the directions from the OCPN site (too lazy even to retype). Copied over some raster charts and it works. OpenGL didn't, but I didn't mess with it, so that may be an easy fix.

A few thoughts:

OpenCPN is much more usable on the Pi than on the Beaglebone Black I tried a bit ago. I still wouldn't want to use it for day to day navigating or even planning, it's just not smooth enough. I definitely second the above poster, a netbook or laptop is the way to go right now. But in a pinch, you can make due, and it might be nice for a remote display (say in the head) so you can contemplate while you contemplate.

As far as using something for a mux, I think the Beaglebone is much more powerful. It has four UARTs out of the box, the Pi only has one and it's assigned to the console port initially. That gives you four 0183 ports, and it has CANBus support as well. That opens up the possibility of N2K (it does require a transceiver, but the bus is there already). It also has *way* more GPIO pins, a faster processor, more RAM, and a built in EMMC. All for $10 more.

Having tried both the current "ARM hobbyist" boards, I second the above about the ARM boards being not quite there (for interactive OpenCPN use) yet. However, at the rate of change, they will be soon.

JRM

[JRM]

I've been thinking about this since I posted, and I want to modify my opinion a bit. We are, after all, talking about computing platforms that are basically $50US not counting a display. That's pretty incredible, really. So while it might not run as smoothly as I would like, it does run. Given the low cost in both dollars and watts, it runs pretty darn good.

I was just going to uninstall OCPN from the Pi, but I think I'll give it a bit more time and effort and see how it goes.

JRM

[Aikiguy]

Keep us posted, I am very interested in how it works.... I should probably get one and play with it too.

Guy
:-)

[ticki]

hello @all ,
i was wondering what my first post is going on .
sorry , but i was totally busy and had no time to answer.

i read the complete threat and my tip for the comunity is the follwing :
- if many interests on a open source embedded chartplotter, choose first open source hardwareplatform ( beagleboard, pandaboard or someth.)
dont choose the cheapest, look for the best hardwareperformance, memory and ...lookup that it can be extented.

it is to complicated to support all ambedded platforms
if found platform, then we can optimize it. there alot of things to solve beetwenn
a X86-"carotte" and ARM. the simplest sample ist, that ARM Cores normally are optimized for integer operations ->X86 has float number preprocessor most times.
you can if you use linux , optimize as basic alot in the operating system, disable many services which are not used, optimize kernel , load only driver which nessesary for the board support package,

and if all help on the same platform, the normal opencpn desktop version will profit from them because you will see, that opencpn code has alot points which can optimize too. that points you find at best , if you use it on an optimized OS
and hardware with limit.

so long
have fun with embedded and opencpn

regards ticki

[Aikiguy]

I have my raspberry pi running the latest version which is also optimized by boat_alexandra.

It is working well, and faster than the standard build. I would put it firmly in the usable camp. You could use the raspberry pi and a usb to serial device for nema 0183 to navigate with. It isn't smoking fast, you are going to have to be somewhat patient when planning routes, but for underway it would work fine.

However I could swear back a ways before I did a general PI update that I had opengl working on the PI for the charts. Now all I get is a grey area where the chart should be if I enable opengl.

I am running opencpn on some 5 or 6 computers at the moment, so I could be wrong about the PI and opengl, but I do seem to remember it.

Does anyone have a raspberry pi running opengl es with opencpn working?

Thanks,
Guy
:-)

[seandepagnier]

Please confirm that it is actually faster and opengl is not enabled... This would mean that some of my minor optimizations actually paid off. Also.. disable the compass window and status bar.. that should help a bit. I also optimized the world map (not vector or raster chart) if that helps.

Please report idle cpu statistics as well (as this is related to power consumption)

[Aikiguy]

It s definitely faster. I do not have numbers for you on that, but I do have two different installs, one of a standard build and one of yours. Even without disabling anything. It went for not quite fast enough to really create a route, to fast enough to create a route. The difference is notable. Would you like a video? How can I give you data that will help as a tester?

I cannot get Opengl to work on the raspberry pi and opencpn no matter what I do. Any ideas anyone has on that would be great.

I was going to run through some of my normal test activities today concerning I/O and instruments and give you feedback on that.

Thanks,
Guy
:-)

[Dsanduril]

AFAIK OpenGL ES (1 and 2) are supported on the Pi, but not OpenGL. I've only started playing with the graphics side of things on my Pis so don't take that as gospel.

[JRM]

Originally Posted by Dsanduril

AFAIK OpenGL ES (1 and 2) are supported on the Pi, but not OpenGL. I've only started playing with the graphics side of things on my Pis so don't take that as gospel.

Last I looked into this a few months ago, it was OpenGL ES, but the Pi doesn't support it in a window, only in full screen mode. More accurately, the window client in the Pi distros doesn't support it. There was a start of a port, but it was abandoned.

I'm excited about the new code, but I won't have a chance to play with it for a while. Many thanks to all those investing their time in this.

JRM

[seandepagnier]

Originally Posted by Aikiguy

It s definitely faster. I do not have numbers for you on that, but I do have two different installs, one of a standard build and one of yours. Even without disabling anything. It went for not quite fast enough to really create a route, to fast enough to create a route. The difference is notable. Would you like a video? How can I give you data that will help as a tester?

yay!

I think because idle cpu. I found a lot of cycle eaters and made them fast. Can you run top in a terminal and compare statistics between the versions (when opencpn is just sitting there)

I cannot get Opengl to work on the raspberry pi and opencpn no matter what I do. Any ideas anyone has on that would be great.

try to get wayland working and run something opengl

I was going to run through some of my normal test activities today concerning I/O and instruments and give you feedback on that.
Guy
:-)

Afaik rpi now can run wayland and gtk+ and qt but support this, so in _theory_ wx could run on gtk+ on wayland without x but I seriously doubt you could do this without issues.

I would like to strip opencpn of the wxgui (keeping wxwidgets for library routines) and render the toolbar and chart selector windows on opengl. Then with a bit more hacking it should be possible to run opencpn in fullscreen mode with opengl, but I don't know if any of the dialogs could work. At this point another round of optimization, and we should be seeing very smooth graphics indeed.

[seandepagnier]

Anyone following this?

http://hdmipi.com

Maybe it is the solution for low cost chartplotters.

[dacust]

Originally Posted by boat_alexandra

Anyone following this?

HDMIPi | HDMIPi Pre-Orders are Open. | Affordable, portable HD screen

Maybe it is the solution for low cost chartplotters.

Might be A solution for SOME people.

If you want to use it inside out of the wet and out of the sun, maybe. But outside, there's no way it can be viewable. They don't give the specs of the screen, so no idea how many NITS. But if it was much at all I bet they would have been sure to point that out. They also don't mention the power draw, although I would imagine it would be very acceptable.

Also, from what I've heard so far, not too many people think the Pi is fast enough for a chart plotter.

SO, I might consider it for some applications. I will definitely keep an eye on it.

Thanks for posting the link!

-dan

[seandepagnier]

I agree, probably not daylight visible, but I do not sit outside anyway (I have no dodger or anything so it's wet out there) So yes, a solution only for some people.

Does anyone know of a suitable daylight visible display for reasonable cost?

Keep in the mind the pi isn't really fast enough for most people yet, but it will be very soon once all the basic optimizations (for just one example, caching compressed textures should give about a 30x speedup) are complete and it can utilize opengl es.

[nohal]

Sean...
I was betting on Pixel Qi - *See our Blog for latest about Pixel Qi*
But unfortunately it looks like we can start blaming the Google monster for hiring Mary Lou Jepsen...

Pavel