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
#1
I use Pypilot headless most of the time on OpenCPN and the pypilot plug-in, but this demands an open VNC connection because I don't have a physical screen. I'd find it realy nice to be able to use a SignalK app like freeboard to activate a route or at least a webbased solution, and Pypilot will follow it and use the Pypilot webapp to activate / deactivate. Freeboard can already draw routes and activate routes, but I think it is just a visual helper rather than a communicator to the autopilot.

I've already asked the developers on Github and they propose to use the derived data plugin to share route data, but at the moment I don't think the plugin or Freeboard can generate APB sentences. 

Does anybody have the same wish, or have come up with a solution to manage and activate autopilot routes web-based?
I am already using Apache guacamole to have VNC in a browser, but still I need to use a mouse to do some fine work and I'd rather have a responsive GUI which can be accomplished with HTML web apps, like freeboard.

Hope someone finds this interesting!
Reply
#2
If you don't have a physical screen, how can you use a web browser or draw routes? What is the reason you can't run opencpn on the device you are using?
Reply
#3
What I meant was, I do have a physical screen but not directly connected to the Pi. I use an Apple iPad with a waterproof casing, OpenCPN doesn't work on that so I have to use VNC. My experience with touch screens and VNC isn't that good on water (small mouse pointer, can barely see it, and when having to activate a route, I need to do some very precise pointing). These are very difficult things to do while sailing. My experience with browser applications is that when not using mouse pointers, the user interface would have bigger buttons, responsive layouts and an overall "smoother" user experience with quicker and easier access to features. Using OpenCPN with a mouse is sometimes just too precise when sailing in certain conditions.

So, in the effort of thinking of an easier quicker solution, I thought maybe integrate some functionalities of OpenCPN into a webapp like Freeboard does.
In Freeboard you navigate through the menu, click routes, click activate. In OpenCPN you need to place your mouse directly over the route, right click (two finger tips) move through the menu and press activate. The process of activating a route is very easy here.

Ofcourse, when drawing a route, one might need to take more time and prepare these things when you have time inside the boat, or at home. But, things like activating a route, or even the function "navigate to here" and then being able to activate the autopilot easily would be a very nice feature to have I think.
Reply
#4
openCPN works well on Android btw. ... that might be an easier solution then engineering a new solution?
Reply
#5
(2020-08-16, 11:06 PM)rastam4n Wrote: openCPN works well on Android btw. ... that might be an easier solution then engineering a new solution?

True, I have an Android smartphone and have purchased the app some years ago. Currently I am subscribed to the beta testing program but the Pypilot app is not working. I am trying to revert to the regular version, but cannot get contact with the app developer.

I find that OpenCPN works well indeed, I am looking just for a more ad-hoc method of activating previously configured routes with less clicks.
For preparation ofcourse I will keep using OpenCPN and Pypilot which I am still a huge fan of.  Smile

Because I saw that in Freeboard less clicks where needed for activating a route, my thoughts where maybe with not a huge ammount of development work we could try and forward APB sentences from there to Pypilot.

Ok I've done some testing, I have the following sentence that is the heading until next waypoint:

navigation.​courseGreatCircle.​nextPoint.​bearingTrue​

How can I send this one to Pypilot? An NMEA converter that takes this value and puts it into APB sentence?
Reply
#6
Is there actually a standard defined for signalk messages to command autopilots that is sensible?

The "first draft" defines multiple redundant messages while ignoring many useful parameters available in pypilot. This would just take more logic and code (maybe more bugs) to implement, and my suggestions which were ignored it seems. But then again, 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.
Reply
#7
I posted the question also in the slack channel for dev-signalk, tkurki answered it with some pointers, here is the thread:

tkurki  2 hours ago
signalk-to-nmea0183 is the logical place for the conversion, but it needs all these paths https://github.com/SignalK/signalk-to-nm...js#L42-L44

tkurki  2 hours ago
otherwise there is no output


tkurki  2 hours ago
and nextPoint needs to be an object with properties`bearingTrue` and probably also bearingMagnetic


tkurki  2 hours ago
@AdrianP thoughts?


tkurki  2 hours ago
will freeboard-sk-helper follow a route or just navigate to the next point?


tkurki  2 hours ago
which is essentially Go To


tkurki  2 hours ago
APB has also stuff like Arrival Circle Entered and Perpendicular passed at waypoint flags, that the “navigation computer” should produce, that I assume nothing produces and that are not handled by sk-to-nmea0183


tkurki  2 hours ago
…but then again, why do we need to convert everything to 0183, when PyPilot is open source, and it could support SK directly? sure, it already does support 0183 and will probably do so in the future, but isn’t it kinda lame to tout A Free and Open Source universal marine data exchange format (now where did I get that catchy phrase…) and then use a legacy format between SK server and  PyPilot?
Reply
#8
(2020-08-17, 07:20 PM)seandepagnier Wrote: Is there actually a standard defined for signalk messages to command autopilots that is sensible?

The "first draft" defines multiple redundant messages while ignoring many useful parameters available in pypilot.   This would just take more logic and code (maybe more bugs) to implement, and my suggestions which were ignored it seems.

The autopilot stuff in the current Signal K specification was not the result of a great design process and I don't have any particular love for it. The only consideration is backwards compatibility, but if we got something wrong that is irredeemable we can have another go at it.

Never attribute to wilful ignorance something that can be explained by a finite amount of time and energy Smile

So, what would a perfect autopilot protocol/interface/api look like in abstract? I can then see about shoehorning it into the current SK or if not possible figure out a way to move beyond the current spec.
Reply
#9
mostly i'm just ranting because I had zero input on the spec and it seems to be based on existing nmea2000 autopilots... so... don't take it too critically.

what would be perfect is subjective. It is really difficult in fact because pypilot has a lot of parameters that just don't have a parallel in other autopilots, like the motor slew speed or period, or even the different gains and pilots that can be set.

So I suggest basic keys for:
mode -- compass, gps, wind, true wind
command -- the command for the above mode. I don't like having separate keys for each mode's command it seems redundant to me and just more work for each client interface to deal with.
enabled -- I guess this could be rolled into the mode but I suggest it isn't so the mode can be known or changed even when the autopilot is off.

this is really the basics, only 3 keys needed. command can move the motor when not enabled.

The other option and one I still hope can eventually work would be to map the pypilot keys directly into signalk. Obviously this will not work with a generic autopilot interface, and there are more than 100 of these now, but it would allow complete control of pypilot through signalk. In order to do this, the server needs to send subscriptions to clients rather than only receiving them. So if two clients subscribe to a key that a third client provides, with say a period of 2 seconds for one and 5 for the other, then the server would send the subscription of the minimum period (2 seconds) to the client that provides the data so that it knows can produce the data only at this rate.

So far when I send data to the signalk server I just output it at 2hz or so, without knowing what rate to actually send because I have no idea if any clients on the server actually care about it or not, and with so many possible keys and things like gyro biases or accelerometer residuals that are usually not important but could be interesting to log, normally you don't want to bother passing all this to the server all the time.

This also allows linking servers quite easily chaining them together and keeping the throughput down because only data that is actually subscribed to at that rate is sent.

as for arrival circle and all of that, I would rather keep it in opencpn or whatever is graphically making the routes and out of the autopilot. The user needs visual interaction for this anyway and opencpn already handles this so sending it to the autopilot only makes sense if opencpn is likely to crash or something, but it's not.

I don't think arrival circles are good anyway. I prefer route position bearing (which makes corrections to follow a route) It is always correcting to get close to the actual route and doesn't use cross track error which can lead to overshoot as the course can change significantly right when you reach a waypoint rather than correcting this error naturally all along. This is not normally desirable anyway and is definitely not how you would normally manually follow a route.

the waypoint arrival and cross track error logic comes from airplanes and in my opinion not really relevant for boats on the water. It's questionable if it's even best for airplanes. From the pilots I've met, they seem to think they know more about boating because they are pilots but in fact these same pilots rely heavily on their engines and I have never used one. So the autopilot route plugin supports 3 or 4 different route following methods with tunable parameters and it's up to the user to decide which is best and so it only needs to send a gps heading to the autopilot, and this makes the interface in signalk simpler because it doesn't need to ever send waypoints, cross track error, arrival radius or any of this to the autopilot, it's all handled in opencpn.
Reply
#10
All I can say is wow, I love this discussion.
Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)