Autopilot Control

[DotDun]

Originally Posted by fgd3

The track feature on my Raymarine autopilot doesn't work very well. It makes several violent course changes while it hunts for the track. It typically sags to the right of the desired track about 60 feet.

It's not setup properly. Start again with the dealer/dockside setup (assuming your AP is less than 15 years old).

[rgleason]

DotDun
Thank you for the excellent summary of the interface. May we use it in the wiki?

Only one thing...I wouldn't say O is not interested in n2k. It is a matter of programming resources and benefit. I expect there are several ideas to use signalK and indeed there are some git forks which show some interest and work in this direction.

"OpenCPN could use n2k, but there is no one interested in it. Does n2k make additional features available related to autopilot route following?"

--If there is seen a compeling reason, I have no doubt it will happen.

[seandepagnier]

Originally Posted by DotDun

You are taking XTE way out of context, it has nothing to do with waypoint arrival or course change.

To elaborate.. XTE would be a reasonable algorithm for routes with only one segment. It's major shortfall is not at all considering the next segment before you reach it. Not being able to tune (in most systems) to a lesser extent is also a problem.

Originally Posted by fgd3

How would you hand steer while trying to follow a route looking at the chart plotter?

Good question, and it depends on the person also. It's fair to say I consider more factors than just cross track error, and I can learn from mistakes also.

The track feature on my Raymarine autopilot doesn't work very well. It makes several violent course changes while it hunts for the track. It typically sags to the right of the desired track about 60 feet.

Maybe it is overtuned? In this case, the plugin would allow you to at least easily divide the cross track error so it doesn't hunt as hard.

My usual practice is to set the autopilot to follow a magnetic bearing which is the bearing to the next waypoint the GPS has given me. I monitor the track displayed by the GPS. If the track is different from the desired bearing I adjust the autopilot bearing to compensate. The difference between the bearing and track tells me how much I need to change the autopilot setting. Monitoring cross track error tells me how successful I have been at steering the right course to stay on track.

Doing this automatically from logic in opencpn is one of the goals of the route plugin. Many parameters so you can tune it to follow routes better than rely on one specific algorithm built into the autopilot.

Maybe the autopilot is installed incorrectly, this would also provide an alternative solution provided you can actually follow a compass course.

Much of my autopilot use is while under power where the demands on the autopilot are simpler. My autopilot does not have a wind vane input so its performance under sail is never optimal. Since it can't respond to wind shifts I can't trust it to sail close hauled. Reaching or

There is a windvane plugin for this, but you need some kind of wind vane input to opencpn to use it.

running it will hold course fine but wind shifts require me to actively trim the sails if I want to maintain best speed.

Fabbian

I intend to implement an upwind mode in my autopilot that uses machine learing to optimize sailing upwind in gusts. The apparent wnd angle actually changes slightly depending on wind
speed, and the reaction time needed is fast.

[DotDun]

Originally Posted by rgleason

DotDun
Thank you for the excellent summary of the interface. May we use it in the wiki?

Only one thing...I wouldn't say O is not interested in n2k. It is a matter of programming resources and benefit. I expect there are several ideas to use signalK and indeed there are some git forks which show some interest and work in this direction.

"OpenCPN could use n2k, but there is no one interested in it. Does n2k make additional features available related to autopilot route following?"

--If there is seen a compeling reason, I have no doubt it will happen.

Per the NMEA police, OPCN would need to get their approval before any mention of supporting N2K.

This of course includes any hardware you connect to 'their' network. Since there are no laptops with native canbus interfaces, you would need to choose a gateway.

[DotDun]

Originally Posted by boat_alexandra

To elaborate.. XTE would be a reasonable algorithm for routes with only one segment. It's major shortfall is not at all considering the next segment before you reach it.

FYI, NMEA has never supported routes with more than one segment.

Originally Posted by boat_alexandra

Not being able to tune (in most systems) to a lesser extent is also a problem.

FWIW, AP response level to XTE is user adjustable. From the user manual for my AP:

• Leisure — suitable for long passages where tight heading control is not critical.
• Cruising — good course-keeping without overworking the pilot.
• Performance — emphasis on tight heading control.

FWIW,

Typical AP 'Track' Scenario:

1. A user pushes "Track" on the APCH
2. Assuming the CP is producing the appropriate NMEA messages, the APC turns the boat to match HDG to BTW.
3. The APC then looks at XTE and turns the boat to get on track
4. The APC will continue to steer the boat back and forth across (overshoot gets smaller each time) the track until it maintains a course on the track.
5. At this point, COG matches BTW. HDG may not equal BTW/COG due to wind/waves/current.
6. At arrival (as determined by the CP), the APC disengages (or goes to AUTO mode)

[bcn]

Originally Posted by DotDun

Per the NMEA police, OPCN would need to get their approval before any mention of supporting N2K.

This of course includes any hardware you connect to 'their' network. Since there are no laptops with native canbus interfaces, you would need to choose a gateway.

This is not correct. The Actisense modules are type approved and have the official N2K stamp - and you can use an Actisense gateway plus the Canboat libraries to get the N2K sentences for an application.
There exist even Actisense clones and other equivalent gateways for the nautical CAN bus.
Consider that N2K from the basic protocol is just CAN, and there is a myriad of CAN sniffers you can use. Without asking NMEA.
If you want to use the brand name of NMEA2000 they might get picky, but if you just state that a device gives access to the CAN bus in boating environments - with reverse engineered information - you can just do what you like.

[DotDun]

Originally Posted by DotDun

Per the NMEA police, OPCN would need to get their approval before any mention of supporting N2K.

This of course includes any hardware you connect to 'their' network. Since there are no laptops with native canbus interfaces, you would need to choose a gateway.

Originally Posted by bcn

This is not correct. The Actisense modules are type approved and have the official N2K stamp - and you can use an Actisense gateway plus the Canboat libraries to get the N2K sentences for an application.
There exist even Actisense clones and other equivalent gateways for the nautical CAN bus.
Consider that N2K from the basic protocol is just CAN, and there is a myriad of CAN sniffers you can use. Without asking NMEA.
If you want to use the brand name of NMEA2000 they might get picky, but if you just state that a device gives access to the CAN bus in boating environments - with reverse engineered information - you can just do what you like.

I stated you need NMEA's approval before you claim supporting NMEA2000.

I stated you need a gateway.

What is not correct?

[bcn]

So we shall claim to support NMEA0183 neither? Isn't this a trademarked by NMEA as well...

What one can't do is selling a product claiming NMEAxxx support. In the case of N2K this will require NMEA homologation if you want a completely homologated system. ©NMEA .

Food for lawyers....
Perhaps misplaced here.

Hubert

[DotDun]

Originally Posted by bcn

So we shall claim to support NMEA0183 neither? Isn't this a trademarked by NMEA as well...

What one can't do is selling a product claiming NMEAxxx support. In the case of N2K this will require NMEA homologation if you want a completely homologated system. ©NMEA .

Food for lawyers....
Perhaps misplaced here.

Hubert

AFAIK, 0183 does not have the shackles on it that 2000 does.

[hoolie]

Originally Posted by DotDun

AFAIK, 0183 does not have the shackles on it that 2000 does.

I think it might have done when first introduced. But I think it was quickly reverse engineered and made public. Years on, NMEA have come to terms with reality and don't care - after all they have N2K.

Actually they do publish a list of standard N2K PGNs but without the data formatting needed to make them work.

[transmitterdan]

Originally Posted by fgd3

The track feature on my Raymarine autopilot doesn't work very well. It makes several violent course changes while it hunts for the track. It typically sags to the right of the desired track about 60 feet.

Fabian,

If your AP makes a rapid change in the rudder position find the setting in your AP for "rudder gain" and make it smaller.

If that does not help then adjust the "RESPONSE" setting to a lower value.

Tell us what model of Raymarine AP you have and we might be able to recommend additional parameter changes that could help. When motoring a preprogrammed route a Raymarine AP should hold nearly zero XTE without making S tracks. It should get close to the track and run in a straight line even with crossing current and wind.

[jongough]

Hi,
I have come to this thread a bit late and it has been moving fast. I do have a windvane plugin for OCPN. I have used it for sailing in most directions and, for me, it seems to work fine. BUT you do have to keep an eye on it as very fast wind changes will cause issues due to the speed at which information is provided and the rate at which the autopilot can react.

The plugin is 'alpha' at the moment, but it may be worth giving it a go to see what needs to be added to make it work better. The code is in git here:
https://github.com/jongough/windvane_pi

It takes wind sensor input and outputs either the real RMC, APB and XTE nmea messages when it is not in use or 'fake' ones that are responding to the wind direction. To make it work OCPN will need to get the wind sensor input and you will need to filter the output to the autopilot to ensure that the 'EC' versions of the message are suppressed and 'WV' versions are allowed. The plugin, when not 'active' will just re-issue the 'EC' messages with 'WV' as the identifier.

When the plugin is activated a window will be shown which shows the desired wind angle (a yellow moveable bug), the current apparent wind angle (blue pointer) and the 'smoothed' wind angle (orange pointer). There are sliders for adjusting:

Angle error/XTE ratio - the rate at which the XTE will increase with increasing divergence between the desired wind angle and the measured wind angle

Sensitivity - the 'smoothing' applied across multiple wind direction readings, meant to slow down the reactivity of the autopilot

In the preferences you can set the update frequency to the autopilot and the limits to be applied to the sliders on the active window.

I am open to any ideas about how to improve this.

Regards
Jon

[DotDun]

Originally Posted by jongough

Hi,
I have come to this thread a bit late and it has been moving fast. I do have a windvane plugin for OCPN. I have used it for sailing in most directions and, for me, it seems to work fine. BUT you do have to keep an eye on it as very fast wind changes will cause issues due to the speed at which information is provided and the rate at which the autopilot can react.

The plugin is 'alpha' at the moment, but it may be worth giving it a go to see what needs to be added to make it work better. The code is in git here:
https://github.com/jongough/windvane_pi

It takes wind sensor input and outputs either the real RMC, APB and XTE nmea messages when it is not in use or 'fake' ones that are responding to the wind direction. To make it work OCPN will need to get the wind sensor input and you will need to filter the output to the autopilot to ensure that the 'EC' versions of the message are suppressed and 'WV' versions are allowed. The plugin, when not 'active' will just re-issue the 'EC' messages with 'WV' as the identifier.

When the plugin is activated a window will be shown which shows the desired wind angle (a yellow moveable bug), the current apparent wind angle (blue pointer) and the 'smoothed' wind angle (orange pointer). There are sliders for adjusting:

Angle error/XTE ratio - the rate at which the XTE will increase with increasing divergence between the desired wind angle and the measured wind angle

Sensitivity - the 'smoothing' applied across multiple wind direction readings, meant to slow down the reactivity of the autopilot

In the preferences you can set the update frequency to the autopilot and the limits to be applied to the sliders on the active window.

I am open to any ideas about how to improve this.

Regards
Jon

What AP is this targeted to work with?

[Paul Elliott]

Wouldn't Jon's scheme work with any autopilot that is responding to XTE?

[DotDun]

Originally Posted by Paul Elliott

Wouldn't Jon's scheme work with any autopilot that is responding to XTE?

APs steer the boat primarily with 2 sets of data from a CP, BTW and XTE. Some also require destination waypoint lat/long, DTW, SOG, etc. At some point the AP is going to get confused when the COG/BTW don't coincide with where XTE is taking the boat. I have to believe at some point (30° of crab?) the AP is going to error out. As stated earlier, changes in BTW will require acknowledgement, which would get real annoying real fast when sailing in wind mode.

Question: Since all?/most commercial APs already have wind mode, what advantage is there with wind mode in OCPN?