Real time helm control of rudder - how to implement this

[chrisclaydon]

Hey guys, thanks for all the great work on the signal K project.

I noticed that the Autopilot plugins seem to be lacking the commands needed for controlling the helm position.

Is this something we could add? There are many cases when it is useful to hand steer using the autopilot motor, either wirelessly or from a wired controller. Often larger vessels do not have a mechanical steering wheel at all and the only way to hand steer is via the autopilot system.

There are two basic modes:

1. Proportional (AKA Follow-on or follow-up) : Send the desired rudder angle in degrees and the autopilot will put the rudder there (ramping up and down motor power to do it smoothly but as quickly as possible). This is used by proper proportional helm controllers (wheel or tiller type) which usually either send NMEA sentences or a simple 0-5v signal.

2. Non-follow-up : For basic controllers with buttons like [-10] [-1] [+1] [+10] these adjust the rudder angle by a small amount. Usually these are the same buttons which adjust the course when the autopilot is engaged, they adjust the rudder position when the autopilot is not engaged.

3. Plus a bonus mode:
   Dodge function - with some autopilots, moving the helm control while the pilot is engaged will allow you to hand steer around an obstacle and then the autopilot will resume steering on the same course.

Most good autopilots allow commanding a rudder position by sending NMEA 2000 PGN number 127245 but we might need to do a bit more to trick them into believing the sentence is coming from their own branded controller.

We should perhaps also consider the possibility of cutting out the autopilot altogether and talking to a rudder motor controller directly. Then we also need to use the rudder sensor so we don't push it beyond the limits. Perhaps the best way to do this is with a signal K "autopilot module" which doesn't actually implement autopilot capability, just helm motor control.

Some questions:
Is this the right approach?
Is Signal K fast enough for this or would there be too much latency for real time steering?
How much latency is typically added if the helm command is forwarded through a signal K server compared to if the helm controller sends an NMEA sentence direct to the autopilot?
Does pypilot already accept rudder position commands like this or is work needed in pypilot too to make this possible on a pypilot boat?
Can I help with this and make a pull request or do the primary developers prefer to keep things in house?

@panaaj @seandepagnier

[sbender9]

The autopilot plugin does this.

[sbender9]

It only currently works with Raymarine AP's, but it's pretty easy to add new ones.

There are no issues with latency.

We always welcome pull requests!

[sbender9]

Yes I agree. And you should look at and comment on the new v2 autopilot apis: SignalK/signalk-server#1596

I have not yet implemented that in the autopilot plugin, it will be doing it this summer.

[sbender9]

The current AP plugin APIs are not vendor specific.

[chrisclaydon]

Raymarine does offer proportional follow-on rudder controllers - see here:
https://www.raymarine.com/en-gb/our-products/boat-autopilots/autopilot-control-heads/follow-on-tiller-controllers

I'm not sure whether they output standard PGN127245 or something proprietary. In any case, I'm not planning to use raymarine, it would either be pypilot or something else, so the first step is to ensure the signal K autopilot API can support passing those commands to the autopilot module in a generic manner.

[sbender9]

Oh, forgot, the v2 work has been started SignalK/signalk-autopilot#31

[chrisclaydon]

Great that work on v2 is already in progress!

It would be wonderful if we could, for example, control our PyPilot autopilot with one of those Raymarine tiller controllers, for example if we replaced a dead Raymarine autopilot with PyPilot but we kept the nice waterproof proportional tiller controller.

That's where Signal K could be really useful to mix controllers and pilots of different types from different manufacturers and translate the signals.

In the middle of Signal K there should just be a generic signal K "set rudder angle" command corresponding to PGN127245, with translation from and to the proprietary stuff (if required) at both the source and the destination of the command.

[chrisclaydon]

Some more thoughts.... Looking at the work in progress on autopilot API v2 I think some of the basic data structure needs alterations to account for manual rudder control. For example currently it has:

    options: {
      state: ['enabled', 'disabled'],
      mode: ['gps', 'compass', 'wind']
    },

I would suggest state should have three values: auto, manual, disabled
because disabled implies the autopilot is fully switched off, it will not move the rudder. In manual state it is not steering automatically but it can control the rudder for hand steering. In auto state the autopilot is steering.

mode might need two more values : follow-up, non-follow-up. Perhaps they could be combined as a single manual mode but I think there is value to having both. Although it is possible for a mixture of non-follow-up and follow-up controllers to be connected at the same time, pressing a non-follow-up rudder control button will cause the rudder to move to a different position from what the follow-up tiller lever has been set to so you can no longer see the true rudder position by looking at that control lever. Moving the follow up controller would then put the rudder back into follow-up mode.

The mode setting would therefore simply reflect whether the last rudder command came from a follow-up controller or a non-follow-up controller. Is that useful or should it be just manual mode whatever the controller type? I think some autopilots might internally treat these as completely different steering modes while others can take a mixture of helm input types in a combined manual steering mode.
Sometimes the same proportional controller can work in both modes - it either controls rudder movement speed - the further you push the tiller to the side the faster the rudder moves (non-follow-up) or the position of the rudder corresponds proportionally to the position of the tiller lever (follow-up)

I see there isn't yet a dedicated function to set rudder angle so I thought perhaps the setTarget function could do that when state=manual but then I noticed that the setTarget function in MockAutopilotProvider has validation that the value passed is -180 to 359 so it's obviously intended specifically for setting a heading rather than generically setting a value. Therefore I guess a separate setRudder function is needed?

[chrisclaydon]

... Another reason to have separate follow-up and non-follow up modes is because some autopilots only support one of those modes, not all of them can accept a proportional input. A touch screen controller could query the autopilot module to find out what modes are actually available and then display an appropriate UI to the user, showing only the available controls.

[panaaj]

Looking at the work in progress on autopilot API v2 I think some of the basic data structure needs alterations to account for manual rudder control. For example currently it has:

    options: {
      state: ['enabled', 'disabled'],
      mode: ['gps', 'compass', 'wind']
    },

I would suggest state should have three values: auto, manual, disabled

The options listed are an example of what PyPilot returns for these values.

The state and mode values are not static, they are dynamic and are intended to be populated with the autopilot device's supported "states & modes".

[chrisclaydon]

Hi Panaaj, Yes I understand that but, shouldn't there be consistency between all autopilots as to what values they use, so that any controller can talk to any autopilot and can query the current state and available features? Perhaps there should be a static enumeration of possible values from which each autopilot can use a subset?

I don't think disabled is actually the right response from pypilot because it does support manual steering when the autopilot is not engaged - the pypilot's own web interface has non-follow-up buttons for hand steering so pypilot should return state:manual, mode:non-follow-up when the pypilot is switched on but not engaged.

I would expect disabled to only be returned when the pypilot is switched off, when it's not connected to signal K or when there is a motor controller fault so it can't move the rudder.

[panaaj]

Given the plethora of devices and the various modes they may support, there has been some attempt in the proposed API to "normalise" states.
An example is the mapping of returned device states to represent:

• Enagaged (pilot is actively controlling)
• Disengaged (not controlling)
  The onus is on the provider plugin to map the device states to one of these two.

The same approach could be applied for other identified "normalised" states.

[seandepagnier]

Back to latency:

You can basically route signalk in a myriad of ways. Especially with wifi links. Using non-realtime processes running signalk server can have unexpected delays.

100ms latency degrades manual control of an autopilot, more is worse and worse. So I dont know if you measured the latency or not, but saying latency is not a problem is an oversimplification. This is exactly why autopilots should not get their inertial data or send the rudder commands via signalk or any other type of network: it degrades performance.

If you want the best manual control of an autopilot I seriously doubt you want messages going through signalk, nmea or any generic data protocol at all. Unless you can demonstrate guaranteed latency below 100ms (which is not the case on a raspberry pi running signalk-node) latency is an issue. Otherwise it is like trying to steer with lots of slack in the cables and so on.

Just because it works on one boat doesnt mean it is fast enough on a high performance boat, or that it will work if people bounce signalk through several systems, or that even a single pi's wifi wont occasionally lag from interference or any number of reasons...

For these reasons, reporting latency to the user in manual control should be at least considered by measuring the time from the command to when the rudder feedback detects movement, or the motor controller detects current.

[chrisclaydon]

Thanks Sean, that's good to know. For my particular project, accurate control is important so I will probably skip Signal K and interface directly to PyPilot, at least until Signal K rudder support is a bit more mature. I think there is still value in adding the functionality to signal k.

I'm developing an Arduino-based proportional rudder controller. What do you think is the best way to interface that to PyPilot? I would prefer it to be hard wired for reliability.

Would there be a benefit in skipping PyPilot too and interfacing the proportional controller directly to the PyPilot motor controller, with a physical change-over switch to change between that and PyPilot control?

[seandepagnier]

why not open a thread in the pypilot forum or an issue on github for pypilot specific questions?

[chrisclaydon]

Hi Sean, I see there's already a relevant topic on the pypilot forum so I added my questions to it here:
https://forum.openmarine.net/showthread.php?tid=4591&pid=30530#pid30530