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
#31
(2021-10-10, 10:53 AM)jamos.tan@gmail.com Wrote: True. Ok, I think I can think of a suggestion from a functional point of view.
...
So far my ideas, hope they might be of any added value. Also really curious about your thoughts.

I think your post did a really good job of describing on a high level what you are after - and what we are missing as a community.

Let me add in a few details.

We have several players in this game
- User
- User Interface UI (Freeboard in this case)
- Route Manager RM (Signal K server in your case)
- Course Computer CC (nothing in Signal K, OpenCPN with Autopilot Route plugin)
- Autopilot Steering AS (pypilot)

(please forgive any inaccuraries in OpenCPN details, I hope it's close enough)

* User creates a route in the UI. This is valuable in itself: the ability to create routes, calculate their lengths and display on a map in the UI.

* The UI stores the route with the Route Manager.

In O you really can't tell the difference between the UI and the Route Manager, as O looks to the user as a single entity, running on a single computer.

In SK the server acts as the Route Manager. The UI and Route Manage being separate, but connected with a clear API gives us one clear advantage: Freeboards loaded from the same SK server, on any device, onboard or used remotely, can display the same route. For example all crew members can access the planned route on their phones. Route Manager provides an API for creating, editing and deleting routes and their associated metadata (name, description).

* The User activates a route in the UI. The UI tells the Route Manager to activate a certain route. The Route Manager broadcasts which route is activate and where one can find the details for it.

* Course Computer sees the message for activating a route. It retrieves the route details (ordered list of waypoints) from the Route Manager. Given updating navigation data (position, course over ground, heading, speed) the CC can proceed to calculate and broadcast course data: bearing and distance of next waypoint, heading to steer to, direction to steer, cross track error etc. Again this is already valuable in itself: a simple display of this information can tell a human steering the boat where the activated route would be.

* Now the user can activate the Autopilot Steering. If data from CC is available it can steer the boat, and as the boat moves and navigation data updates the data from CC updates.

Now if we consider a simple system like a tillerpilot connected to O with NMEA0183 OpenCPN handles the jobs of UI, RM and CC and tillerpilot is AS.

In Jamos's system he has UI, RM and AS, but the linking CC is missing.

Freeboard is a UI, running in a user's browser. It can operate ONLY when it is open and active. As soon as the user closes the window or the device Freeboard is running it goes away or sleeps. Thus Freeboard can not operate as CC, even if it could technically carry out the calculations.

So we really are missing a Course Computer as a SK server plugin.

Now OpenCPN has RM and CC capabilities, but they are locked inside the monolithic OpenCPN application. While modular in structure O plugins are running inside the process and using the same O UI. The advantage of this is that there is just one single application process and everything is in the same UI, easy to understand and use for the user. The disadvantage is the lack of interoperability.

One way to break out of this would be to create a way to access RM and CC features in O from the outside. In fact O could implement the Route Management part of the Signal K API, allowing route editing from other devices, for example running Freeboard. Or it could be some other protocol, I actually don't care that much, as long as it is accessible from the outside O, as we can create an adapter in SK land (that would be kinda silly, but certainly doable).

O Course Computer output is today APB sentences. APB works but is limited. In this case it would make sense to output something like SK delta messages.

How does this sound - did I miss something important?

(2021-10-11, 02:04 AM)SVHM Wrote: 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?

You asked for reasoning as to why to use web technologies. First of all please understand that we are talking about using web technologies (http, html, css), not using the World Wide Web (accessing web pages and applications through Internet). Web technologies are perfectly usable even on a single computer, with no network connectivity whatsoever.

A user interface implemented using web technologies
- allows accessing the same system from multiple devices (a frequent O question is "how do i have the same O in my helm station and inside")
- allows the UI to change automatically to fit different screen sizes and orientations (VNC shows the same UI on all the devices, no matter screen size)
- allows remote access (for example you can access your routes and tracks on the boat from home via marina wifi)
- is more efficient than screen replication like VNC
- creates a natural API between the UI and the server, allowing for multiple user interfaces (all O features have their own UI, with no easy provision to create alternate UIs)
- has a lot of developers available with the necessary skills
- is more scalable, as the user interface is running on each device (a single Raspberry Pi can server at the minimum tens of devices)
- is easier to update - when you update the app each device will automatically get the latest installed version

I hope I could shed some light as to the motivation. If none of these make sense in your particular environment does not make them less valuable for others where they do.

In my view the heart of this discussion is APIs - or lack thereof, and thus missing interoperability of web tech based interfaces like Freeboard and KIP and OpenCPN.
Reply
#32
For me from a users' perspective what is missing 


1. the ability to create a route within O using the touch screen. It's possible, but not easy. (requires right click)
2. the ability to activate/deactivate a route without right click... maybe a floating window similar to the Pypilot Plugin?
3. the ability to configure how the course is executed. Currently, routes in O often cut corners, basically skips a waypoint for another that may be closer. The Autopilot route plugin did this, but is currently broken... maybe this is an opportunity?
Reply
#33
(2021-10-10, 10:53 AM)jamos.tan@gmail.com Wrote: We have several players in this game
- User
- User Interface UI (Freeboard in this case)
- Route Manager RM (Signal K server in your case)
- Course Computer CC (nothing in Signal K, OpenCPN with Autopilot Route plugin)
- Autopilot Steering AS (pypilot)
Yes, the autopilot route plugin is really an alternate, enhanced CC replacing the one in OpenCPN core which implements the default algorithm with less options.
Quote:* Course Computer sees the message for activating a route. It retrieves the route details (ordered list of waypoints) from the Route Manager. Given updating navigation data (position, course over ground, heading, speed) the CC can proceed to calculate and broadcast course data: bearing and distance of next waypoint, heading to steer to, direction to steer, cross track error etc. Again this is already valuable in itself: a simple display of this information can tell a human steering the boat where the activated route would be.
So freeboard would inform the CC of the route, then the CC would perform the calculations and the result displayed back in freeboard.

OpenCPN does not want to rely on an external CC in this way, because it requires additional external software. However, OpenCPN could be modified to utilize the CC (if built into a signalk server plugin) if it detects it.
Quote:Freeboard is a UI, running in a user's browser. It can operate ONLY when it is open and active. As soon as the user closes the window or the device Freeboard is running it goes away or sleeps. Thus Freeboard can not operate as CC, even if it could technically carry out the calculations.
Well.. it could. OpenCPN has the same issue really.
Quote:So we really are missing a Course Computer as a SK server plugin.
Some users even suggest building this CC capability into pypilot itself to enable route following without using nmea APB messages, and only using signalk route information. This is another option I hesitate to implement because pypilot doesn't deal directly with charts or routes, so to get route following you need some kind of plotter and it is just assumed it provides the function. This may eventually be an option as pypilot can run on a standalone pi zero, and if the system with signalk server resets or is powered off, the route following could continue along the route. An alternative would be to run a signalk server with this CC plugin there, but so far operating multiple signalk servers is something not really well supported. So it is not clear to me if the CC should be part of pypilot or a signalk plugin or possibly both paths should be taken and let the user decide which to use, however this results in less consistent behavior.

Unfortunately this CC capability is needed somewhere but in different use cases it would be preferred in different ways.
Quote:Now OpenCPN has RM and CC capabilities, but they are locked inside the monolithic OpenCPN application. While modular in structure O plugins are running inside the process and using the same O UI. The advantage of this is that there is just one single application process and everything is in the same UI, easy to understand and use for the user. The disadvantage is the lack of interoperability.
This is very relevant to the active discussion about it:
https://www.cruisersforum.com/forums/f13...56169.html

Maybe it is time to inform them that signalk could be used, to allow multiple copies of opencpn to share route information. Then it would automatically get the advantage of operating with anything else that supports it too.
Quote:O Course Computer output is today APB sentences. APB works but is limited. In this case it would make sense to output something like SK delta messages.
Any CC plugin in signalk should probably output both, and if the SK delta messages are supported they could override the APB message, or the plugin configured to set which one. This would be really useful especially for something like following "trajectories" where the APB message doesn't contain all the needed fields.

This is really open to a lot of development. Some users don't want the CC to go to the next waypoint until they confirm it. Other options include trying to determine if doing so could lead to a potential collision (AIS targets) and which algorithm to use to compute the optimal bearing for the autopilot. Additional logic could be used for steering to wind, and tacking along a route etc, and which (if any) interaction with the human is required.

(2021-10-11, 11:24 PM)rastam4n Wrote: For me from a users' perspective what is missing 


1. the ability to create a route within O using the touch screen. It's possible, but not easy. (requires right click)
It is possible and does not require a right click. I think you need to enable the touch screen interface.
Quote:2. the ability to activate/deactivate a route without right click... maybe a floating window similar to the Pypilot Plugin?
3. the ability to configure how the course is executed. Currently, routes in O often cut corners, basically skips a waypoint for another that may be closer. The Autopilot route plugin did this, but is currently broken... maybe this is an opportunity?
Yes, well.. if waypoint 3 is closer than waypoint 2, this is a "shortcut" I don't think it does this with the normal arrival radius logic but I did not test.. generally I don't plan on backtracking..
Reply
#34
(2021-10-10, 10:53 AM)jamos.tan@gmail.com Wrote: This was in terms of how I see it working in a functional way for me personally.
No problem:
   
But use such route directly for autopilot -- the bad idea.
Reply
#35
(2021-10-12, 09:21 AM)Stager Wrote:
(2021-10-10, 10:53 AM)jamos.tan@gmail.com Wrote: This was in terms of how I see it working in a functional way for me personally.
No problem:

But use such route directly for autopilot -- the bad idea.

Nice screenshot, I'll look that up to get a feel of it. Indeed, one needs to be careful at all times and not follow an autopilot with/without a route blindly, or any other piece of technology for that matter. Following an autopilot route for me means it depends totally on the circumstances, with me always being on watch.
Reply
#36
(2021-10-12, 12:29 PM)jamos.tan@gmail.com Wrote: Nice screenshot, I'll look that up to get a feel of it.

  1. Open http://130.61.159.53/map/ 
  2. Open "Handle route"
  3. "Begin" to create a route
  4. "Save route to a server", not necessarily completed
  5. Open new browser private window
  6. Open http://130.61.159.53/map/ in this window
  7. In "Routes and POI" load a saved in point 4. route
  8. Continue edit and save the route in the first browser window
See https://vladimirkalachikhin.github.io/Ga...it-a-route
Reply
#37
(2021-10-12, 01:43 PM)Stager Wrote:
(2021-10-12, 12:29 PM)jamos.tan@gmail.com Wrote: Nice screenshot, I'll look that up to get a feel of it.

  1. Open http://130.61.159.53/map/ 
  2. Open "Handle route"
  3. "Begin" to create a route
  4. "Save route to a server", not necessarily completed
  5. Open new browser private window
  6. Open http://130.61.159.53/map/ in this window
  7. In "Routes and POI" load a saved in point 4. route
  8. Continue edit and save the route in the first browser window
See https://vladimirkalachikhin.github.io/Ga...it-a-route

Thanks, indeed I did some googling and arrived at the github rep. Then opened the demo, but it keeps crashing when I went through all the features through the menu. It might have something to do with the charts that I enabled and disabled. But the general impression seems good to me.
Reply
#38
(2021-10-12, 01:59 PM)jamos.tan@gmail.com Wrote: Then opened the demo, but it keeps crashing when I went through all the features through the menu.

Maybe someone else has problems with GaladrielMap? Feedback will help improve the project.
Reply
#39
(2021-10-14, 01:05 PM)Stager Wrote:
(2021-10-12, 01:59 PM)jamos.tan@gmail.com Wrote: Then opened the demo, but it keeps crashing when I went through all the features through the menu.

Maybe someone else has problems with GaladrielMap? Feedback will help improve the project.

Not sure if you are the developer...  Smile  I can always help if you want, maybe start another thread for it? You can let me know if I can test something out for you, and how to troubleshoot or send you logs.
Reply
#40
(2021-10-14, 01:33 PM)jamos.tan@gmail.com Wrote: Not sure if you are the developer...  Smile  I can always help if you want, maybe start another thread for it? You can let me know if I can test something out for you, and how to troubleshoot or send you logs.
I wrote you a private message, because it's topic is off-topic, of course.

I'm a developer of the GaladrielMap, and any information about using GaladrielMap is very valuable to me. The best way to inform about any trouble -- open an Issue on GitHub. And there are Discussions.
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)