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
#11
(2020-08-19, 02:44 AM)seandepagnier Wrote: 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.

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.  

Looking at the published spec (https://signalk.org/specification/1.4.0/...gautopilot), it looks like we're not that far from your suggestions:

We have:
  • autopilot.state: missing enum values, but would conceivably be something like "enabled", "disabled", "error", etc., mapping to your "enabled" proposal
  • autopilot.mode: again missing enum values, but would map to the values you mention
  • autopilot.target: that's where it diverts; it's using different sub-keys for different value "types", but you would presumably only look at the pertinent one depending on the mode you're in.
I think we should really specify the target a bit more, as it doesn't make sense to provide a wind angle when steering a GPS course. We should explicitely define this as invalid, and clients (or autopilots) could safely ignore nonsensical values.

Other than these main three, we also have:
  • autopilot.deadZone
  • autopilot.backlash
  • autopilot.gain
  • autopilot.maxDriveCurrent
  • autopilot.maxDriveRate
  • autopilot.portLock
  • autopilot.starboardLock
Which seem to me like the main params you'd want to tweak in an autopilot. I propose we keep that top level relatively succinct (but I'm open to adding a few more), and that we create pilot-specific sub-keys that could be "owned" by that specific pilot's maintainer, and store arbitrary data. In this case, we could define a autopilot.pypilot key where Sean can store whatever he wants (including the full internal tree). Other clients would have to add specific support for this, but it wouldn't risk any compatibility issues with other pilots.
Reply
#12
First, thanks for taking the time to post this and please don't be dissuaded by my strong opinions.   We will reach an inevitable agreement (I my latest code now pypilot does now automatically detect and exchange data with signalk node server for wind, gps, imu etc..)

(2020-08-19, 11:02 PM)emilecantin Wrote: Looking at the published spec (https://signalk.org/specification/1.4.0/...gautopilot), it looks like we're not that far from your suggestions:
We have:
  • autopilot.state: missing enum values, but would conceivably be something like "enabled", "disabled", "error", etc., mapping to your "enabled" proposal
  • autopilot.mode: again missing enum values, but would map to the values you mention
  • autopilot.target: that's where it diverts; it's using different sub-keys for different value "types", but you would presumably only look at the pertinent one depending on the mode you're in.


I think we should really specify the target a bit more, as it doesn't make sense to provide a wind angle when steering a GPS course. We should explicitely define this as invalid, and clients (or autopilots) could safely ignore nonsensical values.


This is my disagreement.   You are requiring redundant logic to be re-duplicated in every client that is implemented to deal with the different targets when only one is used.  Also missing the true-wind mode.   What about autopilots that implement more modes than we have discussed?  How will they set a target?   Why wouldn't you just set autopilot.target to the course you want to steer in the mode you are in?

You say it doesn't make sense to provide wind angle in the same field as a gps course, but it is just a number.   So what are you gaining by having separate keys besides making all of the clients have to have extra logic?   If there is a single key and target, the +10 button can just add 10 to the target instead of having to check which mode it's in and then update that specific key even though none of the other keys can be used in that mode.  What am I missing?

Quote:Other than these main three, we also have:
  • autopilot.deadZone
  • autopilot.backlash


I propose most of these are not useful to most users and should not be main parameters.   I think main parameters should be ones that are applicable to all autopilots, not just a specific one and we seem to agree on this.

This leaves us with
/vessels/<RegExp>/steering/autopilot/state
/vessels/<RegExp>/steering/autopilot/mode
/vessels/<RegExp>/steering/autopilot/target

The other parameters are pilot specific and it would be great to put them in a separate category such as autopilot.nmea2000 or wherever they are actually used.   Can we make a list of autopilots intended to be supported by signalk and what parameters each support? This will help determine how they can be classified and maybe some autopilots can share parameters without making them main parameters.

What about tacking, manual dodging, and manual control?  Can these be handled as a main parameter?

Please understand I am frustrated by the possibility of the signalk standard for autopilots being designed specifically to fit proprietary systems.


autopilot.deadZone
autopilot.backlash

These are autopilot specific. In my opinion they are the wrong way to implement the control logic. pypilot has instead a servo.period which sets the minimum amount of time the motor can move or be stopped which seems to work in a wide range of sea states.

pypilot supports alternative pilots and one day, a pilot may be implemented that does use these parameters for comparison purposes, but in any case these are clearly pilot specific.

autopilot.gain

pypilot has 7 gains for the basic autopilot, so a single gain field is not very useful

autopilot.maxDriveCurrent
autopilot.maxDriveRate

According to the signalk specification, these are also not useful parameters to set for any autopilot. the maxdrivecurrent will limit the motor current to a maximum amps?? This is not what you want to do if you want the autopilot to get back on course (and thus minimize errors as well as power consumption)

pypilot has a maximum current setting which is used to detect end of travel (without rudder feedback) and detect if the system is jammed or shorted.

The maxDriveRate is also impossible to set in radians per second if you don't have rudder feedback, and even if you did, you want the motor to move quickly. pypilot does have servo.speed.max to limit motor speed (in relative terms) but it is only actually useful if you used say a 12 volt motor on a 24 volt system to avoid burning it out.

If the idea is the limit power consumption, pypilot does this by setting the minimum motor speed, not the maximum speed or current. This ensures the motor is running at this speed or stopped which is more efficient than running too slowly especially on a high friction drive. The best setting for efficiency (but not noise) is to make the motor run at full speed or stopped on lead screws, and with ball screws you can set it to lower values.

pypilot also has slew speeds to limit acceleration and deceleration which is really important to adjust on some drive units to ensure smooth operation.

autopilot.portLock
autopilot.starboardLock

I don't understand why there are two unless the boat is assymetrical. pypilot has just rudder.range
Reply
#13
Quote:You say it doesn't make sense to provide wind  angle in the same field as a gps course, but it is just a number.   So what are you gaining by having separate keys besides making all of the clients have to have extra logic?   If there is a single key and target, the +10 button can just add 10 to the target instead of having to check which mode it's in and then update that specific key even though none of the other keys can be used in that mode.  What am I missing?

I understand your point about clients having to re-implement logic, but:
  1. I don't think it's that much work to look in a different sub-key for different modes, and
  2. I think the biggest risk here is a client (control interface) providing an invalid value as target because of a bug / bad implementation. One example scenario I'm imagining is the "current mode" not updating properly on a control screen, and it sending a wind angle when the pilot is following a GPS course. This could easily happen with multiple control screens. Having separate keys for different "kinds" of targets helps prevent that kind of issue.
One thing I think we ought to keep in mind is our relative perspectives: The SignalK team is more like a "standards body" in this discussion, and their interest is to minimize the possibility of corrupted data, thus the "single-use" keys. Your perspective is that of an implementer, who wants to minimize the amount of code in his app (a very laudable goal, BTW), so your proposal makes sense in that light. We might have to agree to disagree here, but I hope you can understand my point of view.


Quote:Also missing the true-wind mode.

Let's add it, then!

Quote:autopilot.portLock
autopilot.starboardLock

I don't understand why there are two unless the boat is assymetrical. pypilot has just rudder.range


They'd probably be the same value on most boats, that's true. I'm guessing they want to support the case where the rudder goes a but further on one side, probably.

As for the rest of your points, I agree with you. I wasn't there for the initial implementation, but I suspect the other parameters were there to support a specific autopilot that had these options over NMEA. We can / should probably sweep them under autopilot.nmea2000 if that's indeed the case.
Reply
#14
I'm imagining the boat that is designed to turn in tighter circles to port in a specific harbor, or maybe it's one of those catamarans that has asymmetrical hulls... anyway, I should be able to map it to a single key for pypilot, but is this really needed?? Is this a real case or an imagined one? Most rudders stall beyond a certain angle and you want the autopilot to be able to reach this angle on both tacks if possible. It's only useful to go past this angle (afaik) in harbors when docking it can increase maneuverability and act as a brake (at least under sail or sculling I know nothing about power) to move the rudder past the stall angle, but this is rarely done with the autopilot.

I would be mostly happy to sweep away the keys that are pilot specific. These are what annoy me about the current spec.

I always want to minimize redundant code and logic even in seemingly trivial cases if possible, it's just easier to maintain when you can make a single change rather than several. you could be right that it's needed for signalk especially if the clients have significant lag so I will concede this point for now and it's not that much work...

What about manual control, dodging (manual control override while autopilot is engaged could maybe share this) and tacking? I think we could use keys for these.
Reply
#15
I think we should clear a little what we are talking about when we say "autopilot".

In my current understanding we have separate but sometimes overlapping entities here:
- "navigation computer" - a practical example is following a route and outputting "hey autopilot, please steer this way, and this is where we are in relation to the route I'm following". OpenCpn autopilot plugin, iSailor mobile app's "NMEA Autopilot" feature , which both output nmea0183. All MFDs/chart plotters
- "autopilot" - for example my Simrad TP 32, that can hold a heading on its own (or using magnetic heading from an external source), steer to wind with external wind data and follow instructions from a navigation computer
- "autopilot control" - often separate from the autopilot, but for example in the tillerpillot case integrated. Some display autopilot/steering/navigation related data, such as autopilot mode, xte, heading etc and have "button" for control, such as changing the ap mode, engage/disengage, alter heading/wind angle (+/- 1/10), acknowledge arrival/waypoint switch

In general I'd like to talk about in more precise terms just to ease communication, an example being heading and course instead of compass and gps.

Speaking of which: Sean, could you please explain in more detail what you meant with command?

In Signal K control/command is usually separate from "sensor data", eg. data about the current value of something. Control messages are HTTP PUTs or (ws) messages with put syntax: https://github.com/SignalK/specification...ocs/put.md

______________________________________

To be able to make concrete progress I created a wiki page that I invite you to edit & expand. Discussion on the wiki page is probably less than fruitful, but it might work for collaborative editing and discussion here? (I'd much prefer a github issue to a forum like this, but I can concede..)


https://github.com/SignalK/specification...paths-2020

______________________________________


autopilot.target - I agree with Emile, having explicit keys for different data items is much better: explicit, less chance for error / bugs.

This is also more in line with the rest of the SK data model: a somewhat similar example is that we don't just send "depth" as reported by a sensor and then separately tell if the sensor happens to adjust for transceiver installation depth or not.

> So what are you gaining by having separate keys besides making all of the clients have to have extra logic?

An AP that supports several modes already hsa separate logic for handling the different modes - that must be an order of magnitude more code than the logic needed for separate paths.

We gain explicitness - a practical example would be ease of debugging, you see that the data is a wind target when you were expecting it to be heading.

This allows also managing these separately: you may set target course while the AP is in wind mode and then switch to course mode.

I don't want to see implementation specific paths in the data model, so please no pypilot or nmea2000. What if tomorrow I implement jsPilot that supports some features that are today only available in PyPilot and some only in APs with N2K interface? Doesn't really add value.

The drive to support integration with NMEA devices has resulted in some paths that may or may not make sense. I don't think we need to spend time debating stuff that is in the spec now that seems irrelevant - if the systems we create have no use for them they don't bother us much, unless we expend energy on debate...

>I don't understand why there are two unless the boat is assymetrical.

My tillerpilot mechanical setup is asymmetrical. If/when its electronics give up the ghost one day my plan is to put pypilot in control...



______________________________________


I'll create a separate issue about extending subscription model to cover
- a sensor advertising what data it has available
- the server subscribing to the data
- a client requesting certain update rate and server passing the request on to the sensor
as it is not autopilot/steering specific
Reply
#16
The issue about sensors, subscriptions etc is at https://github.com/SignalK/specification/issues/587 - Sean, please review. Did I understand what you described? Feel free to add stuff there. I can have a stab at implementation a bit later in the fall.
Reply
#17
(2020-08-22, 12:07 PM)tkurki Wrote: I think we should clear a little what we are talking about when we say "autopilot".

In my current understanding we have separate but sometimes overlapping entities here:
- "navigation computer" - a practical example is following a route and outputting "hey autopilot, please steer this way, and this is where we are in relation to the route I'm following". OpenCpn autopilot plugin, iSailor mobile app's "NMEA Autopilot" feature , which both output nmea0183. All MFDs/chart plotters
- "autopilot" - for example my Simrad TP 32, that can hold a heading on its own (or using magnetic heading from an external source), steer to wind with external wind data and follow instructions from a navigation computer
- "autopilot control" - often separate from the autopilot, but for example in the tillerpillot case integrated. Some display autopilot/steering/navigation related data, such as autopilot mode, xte, heading etc and have "button" for control, such as changig the ap mode, engage/disengage, alter heading/wind angle (+/- 1/10), acknowledge arrival/waypoint switch
This "autopilot control".. so it still requires the navigation computer to make the route?

I have made the needed changes to the control portion of pypilot to work on esp32 (using micropython) so it's possible to configure and control pypilot from a wireless esp32 remote control. It does all of what you said except for "acknowledge arrival waypoint" as I don't agree with xte. I prefer to follow a route and the pilot does not acknowledge anything it just goes from one waypoint to the next. If it doesn't, you could run aground in a channel if you don't acknowledge in time, so I really just want the opposite which is to disengage if the autopilot is steering wrong somehow and take over control.

I never would send waypoints from opencpn, only the course to steer. Maybe some people would like this and it can be added eventually.

Quote:Speaking of which: Sean, could you please explain in more detail what you meant with command?
What you refer to as "target" I use the word "command"
Quote:I don't want to see implementation specific paths in the data model, so please no pypilot or nmea2000. What if tomorrow I implement jsPilot that supports some features that are today only available in PyPilot and some only in APs with N2K interface? Doesn't really add value.

The drive to support integration with NMEA devices has resulted in som e paths that may or may not make sense. I don't think we need to spend time debating stuff that is in the spec now that seems irrelevant - if the systems we create have no use for them they don't bother us much, unless we expend energy on debate...
They bothered me because it seems like the signalk spec is trying to tell me the right way to implement an autopilot. If these are top level autopilot keys, then any control interfaces are likely to have interfaces for them that will not be fully functional.

I would like them to be under autopilot.nmea2000 and then I have nothing more to complain about. Now it is clear to everyone where these keys apply and don't and they shouldn't expect them to work with pypilot (because otherwise people will and ask why they don't work)

Quote:>I don't understand why there are two unless the boat is assymetrical.

My tillerpilot mechanical setup is asymmetrical. If/when its electronics give up the ghost one day my plan is to put pypilot in control...

So.. does it fit in different places depending on which tack you are on, or does it always have more range in one tack? If it does, why don't you mount it in the center? If you don't need to, then the extra range on one side is probably not useful anyway. I know it may seem like I'm fighting to reduce keys when it's just another if statement etc... I am, because I can forsee there will end up being many more keys than we discussed and the fewer total keys the better and easier to deal with in the future.
Quote:- a client requesting certain update rate and server passing the request on to the sensor
as it is not autopilot/steering specific

I think the server should just pass the combined subscriptions of it's other clients whenever a new client connects. The subscription format is already defined, but currently it's only sent from clients to the server.

In the pypilot data model the clients all can "register" (signalk it will be advertise) what keys they produce with the server. This way when a "watch" (in signalk subscription) is received by the server it knows which client to send it to (after combining it with existing subscriptions)

So basically it sends the highest data rate subscription to the client producing the data, and uses a priority queue to deal with the various data rates of different clients and different keys. This also is nice because the server knows exactly how long it can sleep before it needs to wake up and send data. The client also uses a priority queue as the first item has the lowest timeout to deal with the various different keys that could be at different rates.

There is already a working pypilot and signalk client which relays data between the two. Currently it just sends or receives wind, gps, rudder angle, and imu (send only) and the rate is fixed to 2hz to avoid too much cpu. If this were working with subscriptions it would allow mounting pretty much every pypilot key under a signalk path which would be pretty cool and variable rates as needed. It would be possible to use with node red or whatever else with ease.

You could also chain signalk servers together and get all the features and rates with minimum cpu and bandwidth.
Reply
#18
(2020-08-17, 10:41 AM)jamos.tan@gmail.com Wrote:
(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?
I agree with your words. Great post!
Reply
#19
The new version of pypilot communicates with signalk directly, but does not read this navigation.courseGreatCircle.nextPoint.bearingTrue yet. It reads steering.autopilot.target.headingTrue instead. I'm not sure which one it should use and how to manage it correctly because you may not want to follow the route.. I need to read the signalk spec some more.
Reply
#20
(2020-08-25, 03:45 AM)seandepagnier Wrote: The new version of pypilot communicates with signalk directly, but does not read this navigation.courseGreatCircle.nextPoint.bearingTrue yet.    It reads  steering.autopilot.target.headingTrue instead.   I'm not sure which one it should use and how to manage it correctly because you may not want to follow the route.. I need to read the signalk spec some more.

Please also "write" the spec, clarify what isn't clear with your understanding, add the keys you think are missing, etc. and send a PR. We'll be able to have a better discussion around a proposed set of changes.
Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)