Web-based autopilot route

[tkurki]

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?

---

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.