This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 2 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Web-based autopilot route
#21
There are essentially 2 GPS modes:

1) following a gps course.   pypilot does this normally in gps mode
2) following a route.    pypilot sets the gps course from APB nmea sentences if it receives them staying in gps mode.

Now some users want to ignore the APB messages at times, and follow a true non-changing gps course and be able to switch this on and off from the autopilot.  So they want to be able to tell the autopilot to ignore the plotter or not.   I believe some autopilots actually have a separate "nav" mode.   I'm not sure I personally like this but I do want to support as many features as possible and have not come up with a solution yet.  For me, I can do this from opencpn which I need anyway to make the route.

It seems that  steering.autopilot.target.headingTrue should be used if  steering.autopilot.mode is gps.    But then what about navigation.courseGreatCircle.nextPoint.bearingTrue?   Should opencpn set both if the route is active so that the autopilot doesn't need to read "navigation" keys at all?


It seems like all the keys for rhumbline and great circle are duplicated... again I would prefer to just have a key specifying which calculation is used since this would simplify client logic as well, but it seems everyone else wants to have as many keys as possible in signalk.

The spec seems to be trying to say that following routes should be from point to point but alternative logic already exists.  So I suggest something like:

navigation/courseGreatCircle/xte/bearingTrackTrue
navigation/courseGreatCircle/routePositionBearing/bearingTrackTrue
navigation/courseRhumbLine/xte/bearingTrackTrue
navigation/courseRhumbLine/routePositionBearing/bearingTrackTrue

This is 4 keys for a single key, so there will end up with around 40 keys

 I would prefer:
navigation/bearingTrackTrue
navigation/mode (xte or routePositionBearing)
navigation/coordinates (rhumbLine or greatCircle)

This would end up using about 12 keys with less lines of code in every implementation. The problem gets worse because there are a few more than xte and route position bearing

 OpenCPN outputs APB not using great circle but mercator bearings.    The autopilot route plugin lets you choose mercator or great circle calculations.   The math is really completely different (spherical trigonometry), but on segments that are not very long the result is nearly the same.

So far to my knowledge nothing from opencpn outputs signalk, it only reads signalk at this time, so this needs to be added in the future.   How AP nmea sentences are currently getting converted is unclear since nmea doesn't specify mercator or great circle.
Reply
#22
I just wanted to thank everyone that has taken the time to look at this and do some discussion. Again, I really love OpenCPN, and both the pypilot plug-in and flask web application. However, as web applications like Freeboard (and even Avnav) are getting more and more popular, having some kind of connection between routes and autopilots sound unbelievably nice to me and maybe others too.

Not trying to sound pushy in any way, just hoping that there might be others that might also benefit from such a feature.
Although I fully realize that something like this is probably not easy in any way to be developed.

Thanks...
Reply
#23
You should start by describing what you would like it to do and the expected behavior. This would at least give a goal and starting point. Without knowing this development is impossible, and this is the situation I face.

Do you want for example, opencpn to output the entire active route, and other programs like avnav could read this and plot it, and pypilot would follow this route, and even if opencpn stops, since pypilot knows all the waypoints it could continue? Since currently if opencpn stops outputting APB messages, pypilot will just hold the current course. This could be a starting point, but it means adding duplicate calculations and logic into pypilot that are currently handled by OpenCPN. What do you suggest?
Reply
#24
True. Ok, I think I can think of a suggestion from a functional point of view.

The following is a screenshot from Freeboard and depicts the menu bar from which the routes can be drawn:


[Image: 2021-10-09-16-42-22-Any-Desk.png]

When a route is set-up it may look as follows:

[Image: 2021-10-09-16-43-57-Any-Desk.png]

When you select the route you can press "Activate"

[Image: 2021-10-09-16-45-01-Freeboard-and-2-more...t-Edge.png]

And the active route looks like this:

[Image: 2021-10-09-16-46-12-Any-Desk.png]

When activating this route I am not sure what "technically happens" within SignalK, if any sentences might be updated. 
You will see in the left-below corner some readings that are relevant to keeping a correct course that will enable you to manually follow that route.
I guess that somewhere in that same screen a button that says "engage AP" would be very nice. 

At this moment the closest I can get to accessing the autopilot remote is: I am able to add the pypilot flask webapp to the right side splitscreen, if using signalk-app "KIP" and put 10.10.10.1:*port to pypilot":

[Image: 2021-10-09-16-47-22-Any-Desk.png]

Don't have KIP installed at the moment, but that will then be located at the right side of the screen in the white area. This will then just show the pypilot remote so no real "integrated" functionality. 

This was in terms of how I see it working in a functional way for me personally.
Technically I can think of the following scenario's although I am in no way an expert:

- Users must be able to send the route created in freeboard to an OpenCPN instance. However even if this is possible the user must then again go to OpenCPN, activate the route and then according to the OpenCPN settings will send the proper autopilot (APB?) messages to Pypilot. My guess is that an OpenCPN plug-in must be built for this that will somehow "listen" to a route that is being received (as an automated export?) from Freeboard. The plug-in will then make sure that that route is automatically accepted and activated in OpenCPN. If OpenCPN is configured correctly to send the APB messages to Pypilot, you can then just use the Pypilot Flask web application to enable / disable autopilot. If a route is active, GPS mode will probably be automatically engaged and the route will be followed. For all this, OpenCPN must be activated in the background though.
- Users must be able to activate a route in Freeboard. All APB messages will be generated by either Freeboard, or a SignalK plug-in or data connection? However, I can imagine that it is difficult to replicate the logic (that is already present in OpenCPN) needed for this. However, I consider it a possible advantage because no running OpenCPN instance is needed so probably less CPU/RAM resources required. But, on the other hand I am not sure what the calculation of a future Signalk plug-in might need for the same requirement. I am not sure if Freeboard can calculate all the values needed to let an autopilot know when a course correction needs to be executed. And, if some kind of functionality like this is possible I can also imagine that users will definitely want to finetune the behavior.
- When it comes to route following behavior I know Sean that you have developed a really cool OpenCPN route plug-in. This enables the user to configure some settings. One of which I remember was when to engage the new course (if next waypoint is at X meters, then engage next waypoint). Some time ago we have discussed in another post that some users including me had trouble that the plug-in kept crashing. We didn't yet got to fixing that problem. But, anyway my point being is that the main idea of this plug-in is awesome. Just thinking out loud here, if Freeboard or SignalK have the capability of doing something similar might it be an idea to put this functionality there.

So far my ideas, hope they might be of any added value. Also really curious about your thoughts.

Kind regards,

Jamos
Reply
#25
This is a strange thread. I am curious what the benefit of a web-based application is on a boat. I have been using OpenCPN for eight years now and I am having difficulty understanding how suddenly a web-based application is better. Pypilot represents a true cutting edge development in the open source community and it is integrated well with OpenCPN. Looking at AvNav, I don't see what the added value is over OpenCPN. Moreover, on the face of it, it looks like it and Freeboard are implementations or derivatives of OpenSeaMap, which I have continuously tried over the years, and failed, to find any value in.

Can someone please explain what the value of a web-based solution is and why it is better than OpenCPN? There is no World Wide Web at sea. Doesn't this just add a layer between OpenCPN/Pypilot and the user. What is a web-based application's benefit over VNC? It seems like the motivation for this discussion is to somehow lead the development of Pypilot and OpenCPN in a direction that supports the development of these other programs and to make up for their deficits.

Wouldn't it be better to have an API and let others go their own way toward developing their own software? Also, wouldn't it be better if Pypilot functionality were continually improved to add autopilot functionality rather than to be trying to fit it into the schemes of others?
Reply
#26
(2021-10-10, 10:53 AM)jamos.tan@gmail.com Wrote: - Users must be able to activate a route in Freeboard. All APB messages will be generated by either Freeboard, or a SignalK plug-in or data connection? However, I can imagine that it is difficult to replicate the logic (that is already present in OpenCPN) needed for this. However, I consider it a possible advantage because no running OpenCPN instance is needed so probably less CPU/RAM resources required. But, on the other hand I am not sure what the calculation of a future Signalk plug-in might need for the same requirement. I am not sure if Freeboard can calculate all the values needed to let an autopilot know when a course correction needs to be executed. And, if some kind of functionality like this is possible I can also imagine that users will definitely want to finetune the behavior.
If the bearing to take is computed by freeboard, all it really needs to do is put this in the APB message and send it to pypilot.   I don't know what it does I have not used/studied freeboard much but if it has computed the bearing it probably would not be difficult to make it work.
Quote:- When it comes to route following behavior I know Sean that you have developed a really cool OpenCPN route plug-in. This enables the user to configure some settings. One of which I remember was when to engage the new course (if next waypoint is at X meters, then engage next waypoint). Some time ago we have discussed in another post that some users including me had trouble that the plug-in kept crashing. We didn't yet got to fixing that problem. But, anyway my point being is that the main idea of this plug-in is awesome. Just thinking out loud here, if Freeboard or SignalK have the capability of doing something similar might it be an idea to put this functionality there.
I am going to re-test the plugin.   I don't know what the problem is and claiming it crashes isn't a backtrace.   Anyway if I can get it to crash or   better feedback I could fix it.   It does a much better calculation compared to the standard XTE method which fails near waypoints with sharp turns often.
(2021-10-11, 02:04 AM)SVHM Wrote: This is a strange thread.  I am curious what the benefit of a web-based application is on a boat.  I have been using OpenCPN for eight years now and I am having difficulty understanding how suddenly a web-based application is better.
Well.  I basically agree with you here but, I will play the contrary advocate.

Everything in future is supposed to be web, because most developers do not go 1 second of a 24 hour day without a high speed connection so much software and frameworks assume such. Many are taught only web development as well so they tend to remain biased. How many people change their religion from the one of their parents?

 So maybe thousands of times the available effort specific to boating is already put into map rendering for web tile maps that can be leveraged by a chart plotter by a few calls could take years and years to get what we have in opencpn which is handwritten (in some cases even assembly intrinsics) and all the different cases for different processors and graphics processors puts a huge burden on few developers and in the past few years the pace is slow.  At current rate, the web-based method may (sadly) overtake opencpn in 10 year or so future because simply not enough developers specific to opencpn compared to leveraging more universal rendering code.
Quote: Pypilot represents a true cutting edge development in the open source community and it is integrated well with OpenCPN.  Looking at AvNav, I don't see what the added value is over OpenCPN.  Moreover, on the face of it, it looks like it and Freeboard are implementations or derivatives of OpenSeaMap, which I have continuously tried over the years, and failed, to find any value in.

Can someone please explain what the value of a web-based solution is and why it is better than OpenCPN?  There is no World Wide Web at sea.  Doesn't this just add a layer between OpenCPN/Pypilot and the user.  What is a web-based application's benefit over VNC?  It seems like the motivation for this discussion is to somehow lead the development of Pypilot and OpenCPN in a direction that supports the development of these other programs and to make up for their deficits.    
The current benefits are an alternative (although currently inferior) as well as the potential that the web will likely be available at sea in the near future (also sad)

vnc uses more bandwidth and slower performance as all of the rendering is remote.   the web application can leverage local gpu resources and local disk for cache etc.   For practical use it may not really make much difference but vnc is not a very efficient system.
Quote:Wouldn't it be better to have an API and let others go their own way toward developing their own software?  Also, wouldn't it be better if Pypilot functionality were continually improved to add autopilot functionality rather than to be trying to fit it into the schemes of others?

I am waiting for the other plotter to output APB.   Just a few weeks ago avnav was updated and in theory should work with pypilot (untested)   as for freeboard I do not know.   I am having enough trouble dealing with signalk:  https://github.com/SignalK/specification/pull/624    but maybe someday that will work.   I know avnav doesn't even work with signalk to output data because of signalk's somewhat ridiculous (in my opinion) security measures which when encrypted wifi is being used, I don't really understand the need for using multiple api (http get and set requests) and websockets etc.   Quite a complex method, but perhaps it protects against viruses/worms or malicious former-guests who still know your wifi code and want to take over your boat.
Reply
#27
(2021-10-11, 02:04 AM)SVHM Wrote: This is a strange thread.  I am curious what the benefit of a web-based application is on a boat.  I have been using OpenCPN for eight years now and I am having difficulty understanding how suddenly a web-based application is better.  Pypilot represents a true cutting edge development in the open source community and it is integrated well with OpenCPN.  Looking at AvNav, I don't see what the added value is over OpenCPN.  Moreover, on the face of it, it looks like it and Freeboard are implementations or derivatives of OpenSeaMap, which I have continuously tried over the years, and failed, to find any value in.

Can someone please explain what the value of a web-based solution is and why it is better than OpenCPN?  There is no World Wide Web at sea.  Doesn't this just add a layer between OpenCPN/Pypilot and the user.  What is a web-based application's benefit over VNC?  It seems like the motivation for this discussion is to somehow lead the development of Pypilot and OpenCPN in a direction that supports the development of these other programs and to make up for their deficits.    

Wouldn't it be better to have an API and let others go their own way toward developing their own software?  Also, wouldn't it be better if Pypilot functionality were continually improved to add autopilot functionality rather than to be trying to fit it into the schemes of others?

Hi SVHM,

I can imagine that this thread might sound strange indeed at first glance, and I'm not saying or want to convince this is something that everyone should have. 

I'm a big fan of OpenCPN, but operating some aspects of it (like drawing a route, activating it and sending it to the autopilot) requires some fine movements of a mouse (when using vnc headless or an hdmi set-up). When I'm sailing solo I'm not always able to operate a mouse below deck, or use VNC from a tablet this is a challenge for me. I also do realize that drawing a route is not always something you'd even want to do while sailing, rather doing it before you leave. However, I've found myself in situations that while sailing sole, I want to plot/draw a route of multiple waypoints and send it to the autopilot. In this case I needed to be quick, and pay attention to the weather, traffic, etc. I've found that in my specific set-up that drawing a route in some web-based applications was more mobile / responsiveness friendly. So that's why I thought to share the idea / request to consider how to make these operations easier in rougher conditions.

I do realize there are touch screens available and that OpenCPN is touchscreen compatible. However, I'd rather use OpenCPN from a system that has more CPU/GPU/RAM resources and is capable of running OpenCPN and performing some heavier calculations. In my case that would be an external stand-alone system like a good laptop, which will connect to the Raspberry Pi as a server. Another option might be using the (un)official Android App of OpenCPN, but I've found that not all features are working well or are not (yet) available. 

About the web-application part, I am not using any online resources for loading the mbtiles charts. I have offline repositories for that, so at this moment Freeboard is loading them locally without the need of Internet, just like OpenCPN. Only difference is that the app can be loaded in a browser. As a lot of smart devices have browsers in my case it saves me time to just be able to go to 10.10.10.1:3000 (or another IP dependent of how you connect to your local network). I'm not saying I prefer web-applications, and indeed OpenCPN provides much much more capabilities. It would take a lot of effort and time to have something similar like OpenCPN in a web application. Also, the idea that you don't need to install anything anymore on the smart devices and just use the browser to load the web application is quite appealing to me. But, on the other hand I do need to make concessions on the fact that it will support less features.

(By the way, I was able to at least mitigate the aspect of not having to install client software like VNC. I installed Apache Guacamole so I could do VNC through a browser window. This was really cool, no client software needed. But still in this case I had to cope with mouse movements. And there was an issue with Java or OpenJDK that significantly increased boot-time so in the end I deactivated it)
Reply
#28
Sounds to me like we need a plugin that makes using routes with autopilot within OpenCPN easier to use... and more configurable... something that does not depend on "right click"
Reply
#29
I guess my problem with all this is philosophical. I have been a Linux user for 20 year now and it has become religion for me to not use Microsoft or Apple. We have many examples of monopolizing corporate interests manipulating the market for their own gain. They offer freebies as enticements to get people dependent on their products, then they switch the game once people have built their lives around it. Take Whatsapp, Skype, and West Marine as a few examples. They have very strategic, long term plans to take over. I would argue that the creators of Linux-based solutions should keep that in the forefront of their minds when developing their software. Take Java, for example. When someone makes software that is operating system independent by using Java, they may be sacrificing long-term viability in order to obtain a short-term broad user base. What would happen to all the programs that use Java today if suddenly Oracle required a $1,000 license for it?

I guess I should mention that I am strictly a user of software, not a programmer. My perspective is shaped by what I have to do to use software. My concerns with the development of the software are only related to my present and future ability to use and obtain the software for free and to use it for my own benefit, not for the benefit of corporations. By creating software that requires elements that are provided by huge corporations seems to me to play right into their hands.

As a user, I once had Ubuntu and I loaded OpenCPN and I used it right off the bat. Now, things are getting more complicated. It is, of course my responsibility how deep I want to go into this because if I want to be able to use open source hardware alternatives, I suppose I have to work at it. I chose to use a Rasberry Pi because I took on a wave that sent water into the boat that soaked my laptop. That was the immediate end to my laptop. However, going with the Pi has proven much more complicated. I now need to become a hardware and software engineer to use it. Its probably good for me, and I enjoy the challenge, but things like OpenPlotter and Signal K seem to be bogging me down. I keep getting messages about conflicts. I know I will get it in time but I come back to my philosophical concerns. If, as Sean says, that Signal K “seems to be based on existing nmea2000 autopilots” is in fact true, then what is the intention of the creators of Signal K? Is it an attempt to rescue the developers of commercial equipment from an onslaught by the open source community and guide open source to a point that will force its hand? We need to ask questions like this rather than just uncritically accept every new development in the open source realm as furthering open source in the future.

A few weeks ago, I was having difficulty using Pypilot with OpenPlotter. The screen wouldn’t work and I went round and round with Sean trying to get it to work. However, I decided to try Tinypilot and now it works. With OpenPlotter I could not use Pypilot with all its functionality. OpenPlotter used a much older version of Pypilot and even after I loaded a newer version, I still was not able to use it. The benefits don’t seem to go both ways.

Would it not be possible to develop Pypilot and OpenCPN to be able to obtain NMEA (0183 and 2000) data without Signal K or OpenPlotter? How about being able to output NMEA data without it? As Sean says: “I would rather signalk-server not be written in javascript as it is forcing me into web development for a program that has nothing to do with the web.”

As a user, I want the software to work without continually adding layers and taking my time. I also want to prevent corporate interests from getting at my pocketbook.
Reply
#30
(2021-10-11, 02:27 PM)rastam4n Wrote: Sounds to me like we need a plugin that makes using autopilot within OpenCPN easier to use... and more configurable... something that does not depend on "right click"

Indeed, that might be a good option. Something in the line of:

- Big button for "create new route" (when describing "big" I mean what is responsiveness-ly responsible, if that is even a word haha)
- Option for "first waypoint = x meters ahead of current course"?
- The middle of the screen something like a cross / crossair will be the next waypoint after that 
- When tapping the screen once, that will be the next waypoint
- A big button for Save route
- A big button for Activate route
- A big button for Engage Autopilot (for pypilot)

I'm not sure how the MFD's from Garmin, B&G or Raymarine do this but I suppose it is a good idea to check this, to avoid re-inventing the wheel. (The wheel that is soon to be autopiloted I hope  Tongue)

(2021-10-11, 02:37 PM)SVHM Wrote: I guess my problem with all this is philosophical.  I have been a Linux user for 20 year now and it has become religion for me to not use Microsoft or Apple.  We have many examples of monopolizing corporate interests manipulating the market for their own gain.  They offer freebies as enticements to get people dependent on their products, then they switch the game once people have built their lives around it.  Take Whatsapp, Skype, and West Marine as a few examples.  They have very strategic, long term plans to take over.  I would argue that the creators of Linux-based solutions should keep that in the forefront of their minds when developing their software.  Take Java, for example.  When someone makes software that is operating system independent by using Java, they may be sacrificing long-term viability in order to obtain a short-term broad user base.   What would happen to all the programs that use Java today if suddenly Oracle required a $1,000 license for it?

I guess I should mention that I am strictly a user of software, not a programmer.  My perspective is shaped by what I have to do to use software.  My concerns with the development of the software are only related to my present and future ability to use and obtain the software for free and to use it for my own benefit, not for the benefit of corporations.  By creating software that requires elements that are provided by huge corporations seems to me to play right into their hands.  

As a user, I once had Ubuntu and I loaded OpenCPN and I used it right off the bat.  Now, things are getting more complicated.  It is, of course my responsibility how deep I want to go into this because if I want to be able to use open source hardware alternatives, I suppose I have to work at it.  I chose to use a Rasberry Pi because I took on a wave that sent water into the boat that soaked my laptop.  That was the immediate end to my laptop.  However, going with the Pi has proven much more complicated.  I now need to become a hardware and software engineer to use it.  Its probably good for me, and I enjoy the challenge, but things like OpenPlotter and Signal K seem to be bogging me down.  I keep getting messages about conflicts.  I know I will get it in time but I come back to my philosophical concerns.  If, as Sean says, that Signal K “seems to be based on existing nmea2000 autopilots” is in fact true, then what is the intention of the creators of Signal K?   Is it an attempt to rescue the developers of commercial equipment from an onslaught by the open source community and guide open source to a point that will force its hand?  We need to ask questions like this rather than just uncritically accept every new development in the open source realm as furthering open source in the future.

A few weeks ago, I was having difficulty using Pypilot with OpenPlotter.  The screen wouldn’t work and I went round and round with Sean trying to get it to work.  However, I decided to try Tinypilot and now it works.  With OpenPlotter I could not use Pypilot with all its functionality.  OpenPlotter used a much older version of Pypilot and even after I loaded a newer version, I still was not able to use it.  The benefits don’t seem to go both ways.

Would it not be possible to develop Pypilot and OpenCPN to be able to obtain NMEA (0183 and 2000) data without Signal K or OpenPlotter?  How about being able to output NMEA data without it?  As Sean says: “I would rather signalk-server not be written in javascript as it is forcing me into web development for a program that has nothing to do with the web.”  

As a user, I want the software to work without continually adding layers and taking my time.  I also want to prevent corporate interests from getting at my pocketbook.

I totally understand the points you are making. Avoiding a complex infrastructure, or necessity of installing, configuring and maintaining too many layers just to provide for some functionality may often be not only unwanted, but also can pose a risk. Just trying to build something for the sake of delivering is something that needs to be considered carefully. It's hard to keep things stable and to a certain standard as it is. Reducing complexity and simplifying infra/architecture is something that has always been on my mind and definitely deserves attention. In my personal situation that meant in this specific case being able to use any (smart)device, logging into the WiFi-AP, and just use the browser and point it to an IP that is running the software that I need. Taking out the need of client software was what appealed to me in this case. But, indeed in many cases that piece of software does not always do the things that we want, hence the feature request.

I see that Sean and others who have anything to do with Signalk's development keep putting a lot of effort in discussions around SignalK or Pypilot's compatibility and I'm really thankful for that by itself. I understand that there are strong and open minds or something in between and it can be a challenge in finding some common ground sometimes.

But it is my hope that we'll just keep talking and eventually make things for the better.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)