Autopilot Track Following

[RobbieW]

Hi Folks,
I'm trying to figure out why my autopilot swings 0.02 Nm either side of its desired track without settling on the inputted track from the 'in use' OpenCPN route.

The background is that I have recently switched from MaxSea (it finally broke on XP) to OpenCPN, which I've used off and on for about 18 months. I had recently discovered that on the new (to me) boat I could set up MaxSea to recieve GPS input from the GP32 and output commands to the Raymarine S3G autopilot, thus the autopilot would accurately follow the 'in use' route in MaxSea.

Having switched to OpenCPN (initially 2.3.1, now 2.5) the autopilot now hunts as described in para 1. I'm not pointing a finger at OpenCPN but at the moment that change seems to be the point where things went awry. The boat used to 'wind follow' accurately with MaxSea in use, that too started to hunt at about the time I switched to OpenCPN.

Having read these forums a bit, I should say that the GPS input and autopilot output are both on COM1. I have tried a couple of suggestions from the forum to gain some insight into the scenario. So, I've tried adding the RMC message to the autopilot output - no difference. I have AIS input but that comes in on COM5 from a NASA AIS Engine, nonetheless I defined my GPS input port as an AIS shared port - on my system it seems to do exactly that and shared COM5.

Today I tried using a GPS mouse on COM4 instead of taking GPS input from COM1 and doing some wind following which worked perfectly. I have not yet been able to try a track follow with the GPS input separated from the autopilot output.

At the moment I'm thinking that the shared COM1 setup is where the problem lies? I dont seem to have the option of making this a shared AIS port as thats not where AIS input comes from but that seems to be the pre-req for port sharing in OpenCPN.

The way the boat is wired puts input and output on COM1 using an Actisense PC-Opto-1-A NMEA/RS232 adapter. If I can find the button to add a document about the wiring I'll do so, but bear in mind this documents what is inside a connection box not what the function of each pair of wires is at its functional end!

[alex2035]

The wiring is not very helpfull because we dont see what is sent/received, just colors. But you say it worked with MaxSea but now it doesnt, or "hunts" trying to stay on course. I asume under very similar sea conditions. I wonder if MaxSea had some kind of data damping that OCPN doesnt, I mean, like the windvane pilot function, that is a well known damped AP function, that disregards small wind changes, so as to avoid exactly that, "hunting" a course.
Just the obvious but I ask anyway, I asume you do have a calibrated pilot, I think so, because that model does it by itself, but you have to tell it to do it, this is fundamental for an optimal AP behaviour .
It could be nice to have a log of nmea sentences performed at the output of both programs to see what happens.
Sharing in and out on the same com port is quite normal, and usual, have done it with a lot of configurations, dont think the problem lies there but I havent much experience on this with OCPN.

[RobbieW]

Thanks Alex,
Calibration was the first thing I tried, the autopilot has recently been run through its sea trial routines for both magnetic variation and tracking sensitivity.

I'll see what I can do to collect some NMEA sentences. It may take a day or two to post results as I'm in France and they seem unwilling to sell me a 3G data sim so I'm reliant on finding a WiFi service. I'll also see if I can add some detail to the wiring setup.

[RobbieW]

A bit of a ps - just re-read the manual on autopilot output:
"OpenCPN does accept autopilot output on the main GPS input port, using the same baud rate, unless it is set to "AIS Port (Shared)"
now I see what its trying to say, had previously assumed there was a hidden 'not' between does and accept - just my english usage but it might make the sense clearer to replace 'does accept' with 'accepts' or 'allows'.

[tonyappuk]

If you are using the standard OCPN autopilot output this will be of NMEA RMB. This only includes cross track error for the autopilot to use. There has been correspondence regarding this before and Dave kindly posted a work around which allows both RMB and RMC (which contains course info) to be fed to the autopilot. This may be why your autopilot "hunts".
The OCPN help file contains this statement.
Autopilot Output Port: Connect any NMEA 0183 compatible autopilot. Select the correct serial port from the list. OpenCPN does accept autopilot output on the main GPS input port, using the same baud rate, unless it is set to "AIS Port (Shared)".
If you need the NMEA RMC sentence output on your autopilot port, add the following in the opencpn.ini file, called opencpn.conf in Linux:
..........
[Settings]
AutoPilot NMEA Sentence Out=RMB;RMC
..........
Default is RMB only, and works for most autopilots.
Most users will not need this config entry

Tony

[Littlechay]

To throw confusion into the works. If the pilot is following wind it won't be using input from OpenCPN surely? It will be following the wind instruments, particularly the apparent wind angle. It will alarm if the wind-shift exceeds a set amount (data from heading sensor) or perhaps other systems will alarm if crosstrack XTE is exceeded depending their configuration.

Could well be wrong but if your pilot has started hunting in wind mode your change of plotter software could be a complete red herring.

Chris

[alex2035]

Originally Posted by Littlechay

To throw confusion into the works. If the pilot is following wind it won't be using input from OpenCPN surely? It will be following the wind instruments, particularly the apparent wind angle. It will alarm if the wind-shift exceeds a set amount (data from heading sensor) or perhaps other systems will alarm if crosstrack XTE is exceeded depending their configuration.

Could well be wrong but if your pilot has started hunting in wind mode your change of plotter software could be a complete red herring.

Chris

There is no possibility to mix Wind Mode with Track Mode in Raymarine AP, or one or the other, if you go wind way, you check the route manually. Indeed it is not following OCPN but wind instrument, apparent or real, the new instruments allow this to be configurable. But I think he is not speaking about this situation but the "Track Mode" itself.
I dont understand the expression "red herring", can you explain, I am not native english. Thanx. alex

[Littlechay]

Alex,

That's what I was getting at.. Wasn't sure if wind mode took an external input for XTE limit though.

In this case a red herring is an expression that means that something that at first sight seems a likely cause is actually totally unconnected with the real cause.

Red herring - Wikipedia, the free encyclopedia

What I was getting as is that as his auto pilot is wandering in wind mode, and as you say the plotter, or nav software, has nothing to do with the pilot in this mode that it could just be that his pilot has developed a fault that is not connected to the change of software. Or one of the filter settings has been changed to reverted to default.

Chris

[DotDun]

Originally Posted by RobbieW

Thanks Alex,
Calibration was the first thing I tried, the autopilot has recently been run through its sea trial routines for both magnetic variation and tracking sensitivity.

I'll see what I can do to collect some NMEA sentences. It may take a day or two to post results as I'm in France and they seem unwilling to sell me a 3G data sim so I'm reliant on finding a WiFi service. I'll also see if I can add some detail to the wiring setup.

IMO, the problem is due to the AP not knowing the current magnetic variation. OpenCPN sends the RMB sentence for bearing to wp, which AFAIK, RMB supports only a true bearing (not magnetic). Since the AP works from it's own magnetic compass to steer the boat, it needs to know magnetic variation for the current place and time in order to perform the math on the true bearing (received in the RMB sentence). The AP discovers the current magnetic variation from the RMC sentence, but OpenCPN doesn't seem to have magnetic variation tables built in. So, if your GPS doesn't supply magnetic variation in the RMC sentence (and Sirf III chipsets won't), neither will OpenCPN.

My guess is that MaxSea has the magnetic variation data and includes it in the RMC to the autopilot.

[janp391]

Originally Posted by RobbieW

Hi Folks,
I'm trying to figure out why my autopilot swings 0.02 Nm either side of its desired track without settling on the inputted track from the 'in use' OpenCPN route........

This is perhaps of no help but I have the same AP and it runs very well and no hunting.
I have Raymarine instruments and GPS, the AP is a S3G. All are wired together with SeaTalk.
I take the GPS signal from the AP NMEA out and feed it to my computer via com1. The signal from the computer goes from com1 to the AP NMEA in.
I make a route in OPCN (2.5), make it active, press auto on the AP and then Track mode, accept what the AP will do, and off we go.

[sgschwend]

Since an AP provides compensation in a non continuous way it will always hunt, we may just not be able to observe it. I would agree that the data set must be different, but the AP should be able to be tuned to minimize the awkward feeling of hunting.

In my view a small tracking error is not a concern, I would rather have that over working my hydraulics to death which is a concern.

[alex2035]

Originally Posted by sgschwend

Since an AP provides compensation in a non continuous way it will always hunt, we may just not be able to observe it. I would agree that the data set must be different, but the AP should be able to be tuned to minimize the awkward feeling of hunting.

In my view a small tracking error is not a concern, I would rather have that over working my hydraulics to death which is a concern.

Correct, that is why "wind mode" is a mode with much more damping, that neglects small wind changes. Ideal AP action would be one that looking back stern you see a straight wake with minimum AP activity, of course that depends in a lot of conditions, but a well installed, cabled and calibrated AP should be able to do it. Even more so with the actual software in the course computer and the inclusion of a gyro in all models.
True compass is derived direclty from GPS position if present or you can enter variation value manually, then you choose which one you want to see, usually "true", this with Raymarine equipment, this is to answer an above post. alex

[DotDun]

Originally Posted by sgschwend

In my view a small tracking error is not a concern, I would rather have that over working my hydraulics to death which is a concern.

Adjust the response level of the AP.

A good AP uses the bearing to wp as the starter heading then uses XTE to fine tune. It'll eventually settle in on the exact track, even to the extent of crabbing the heading several degrees to stay on track. The response level adjusts how quickly it performs that process.

[RobbieW]

Originally Posted by DotDun

IMO, the problem is due to the AP not knowing the current magnetic variation. OpenCPN sends the RMB sentence for bearing to wp, which AFAIK, RMB supports only a true bearing (not magnetic). Since the AP works from it's own magnetic compass to steer the boat, it needs to know magnetic variation for the current place and time in order to perform the math on the true bearing (received in the RMB sentence). The AP discovers the current magnetic variation from the RMC sentence, but OpenCPN doesn't seem to have magnetic variation tables built in. So, if your GPS doesn't supply magnetic variation in the RMC sentence (and Sirf III chipsets won't), neither will OpenCPN.

My guess is that MaxSea has the magnetic variation data and includes it in the RMC to the autopilot.

The GP32 has variation built in and the inbound RMC messages captured by OCPN on Com1 have the same value in the appropriate message slot as the GP32.

What I dont know, & perhaps someone can point to a method, is how to capture the outbound messages going from OCPN to the AP. THen we'd have a good idea that he AP was getting all it needed. What would be great is the ability to pipe those into a file as well as the message going to the AP.
NB - it would be handy to be able to pipe the output in the NMEA data stream window into a file as well.

I'd sort of given up on this because the work around is simply to use the AP in straight course mode and visually check for deviation from course on the laptop. I suspect the next proper step in PD would be to reinstate Maxsea and try route following from that again.

[DotDun]

Originally Posted by RobbieW

What I dont know, & perhaps someone can point to a method, is how to capture the outbound messages going from OCPN to the AP. THen we'd have a good idea that he AP was getting all it needed. What would be great is the ability to pipe those into a file as well as the message going to the AP.

You can use any comm program (even Windose Hyperterminal) with another serial port. Just connect the additional serial port to the OCPN output. A good NMEA decoder is NmeaReader from Actisense. NmeaReader can also save to a file to be later read by EBL Reader from Actisense.

Index