Autopilot Control

[seandepagnier]

Originally Posted by Douwe Fokkema

Almost. There is a proprietary PGN that allows setting the heading of the Raymarine EV-1 pilot when it is in auto mode. This is PGN 126208 with a data length of 14. In canboat format this pgn looks as follows:
Z,3,126208,7,204,14,01,50,ff,00,f8,03,01,3b,07,03, 04,06,f0,3d
The last 2 data bytes indicate the heading to be set in thousands of radials, least significant first (divide by 174.53 to get degrees). So the above will set a heading of 91 degrees.
This is tested with canboat and a Actisense NGT-1 and functions flawless.

The autopilot route plugin could easily be extended to emit this message. I cannot really implement it because I have no way of testing it.

[rgleason]

Sean has updated his Autopilot_Route_pi

https://opencpn.org/wiki/dokuwiki/do...pilot_route_pi

[seandepagnier]

The autopilot route plugin capable of steering under sail in harbors is used in my video:
https://youtu.be/KQuBwLSMSxI

[DGH]

I have a question about the physical connection of OpenCPN on my laptop to my Raymarine autopilot.
I can execute the software set-up steps in the OpenCPN manual but how to connect to the AP?
Can I use a USB cable from one of my USB ports and then simply take two of the wires from the cable to the + and the - NMEA input terminals on the AP? ( I would use the green and the white wires, and remove the red and ground wires).
I am running Windows XP on a small ASUS laptop. OpenCPN itself works fine.
I have tried the above but the AP still says "No Data". I have tried reversing the NMEA connections at the AP and also re-starting the computer.
All and any suggestions gratefully received!

[Dsanduril]

NMEA is a serial connection using the RS422 physical layer. While the 'S' in 'USB' does stand for serial it is an entirely different serial system. You will need a USB-serial converter for your laptop (unless your laptop has an actual serial port, most newer ones do not). Done properly you would get a USB-RS422 converter, but most systems will also work with the more common USB-RS232 connector.

You will also need the driver for your operating system and the converter you select, not all are created equal so make sure your flavor of operating system is supported. After that the converter will appear as a 'COM' port in Windows and you configure O to output to that COM port.

There are lots of other options, including adding a WiFi dongle to your Raymarine that means you don't have to use wires, but those get more complicated.

[DGH]

Thank you Dsanduril for your quick and very helpful reply and explanation.
Now understood. Have now ordered a USB-RS422 converter and software and will install when it arrives. Just have to figure which 2 terminals to connect to AP, but shouldn't be too hard I hope.

[DGH]

This is really a new matter, I think, so I hope I am posting in the correct thread.
The issue is controlling a Raymarine Autopilot from Open CPN.
I have installed a USB-Serial port on my laptop which outputs the relevant NMEA sentences to the Raymarine AP NMEA input terminals. I am pretty sure I have done it all in accordance with the OpenCPN instructions and it works properly on test when at the dock. When I input a Navigate to Here mark the autopilot tries to turn the boat towards it and DTW and CTW seem to be indicated correctly.
However when testing underway, after inputting and activating a course, the AP has difficulty in determining which waypoint to go to and tries to go to some waypoint which seems to be other than one in the course set. ( I don't know where it is getting the other waypoint data from.) There seems to be a lot of strange data going to the AP because a lot of unfamiliar numbers and figures flash on the Raymarine AP control head screen at times.
Does anyone have any suggestions please?

[Dsanduril]

DGH,

I had the same exact problem. When checking the NMEA debug window it looked like OpenCPN was seeing its own output to the AP as NMEA input on that port and then it did some very odd things. There isn't a check box for "output only" in the connections dialog, so I ended up putting an input sentence filter on that connection and telling it to drop all the sentences on the input side. That cleared things up and the Ray AP works fine (although I'm very unhappy with Raymarine's programming of the tracking mode).

[DGH]

Many thanks Dsanduril,
I'll follow that lead.

[DGH]

Thank you to Dsanduril, I filtered the input and the system now seems to work correctly but only when I am switched to my SPX course computer.
I have two independent AP computer and electrical-mechanical systems with a multi contact single rotary switch to change between them. One system is on the SPX computer and the other on an old Type 300 computer. Separately each works fine. I have looped the NMEA serial cable input connection from one to the other. There should only ever be power to one computer at a time.
When I switch to the Type 300 the CTW, DTW and WP number start off being correct but after a couple of minutes other data seems to come in and the information goes crazy.
Looking at the NMEA de-bug window the sentences seem to be the same in both cases.
What am I overlooking?
Any comments gratefully received.

[Dsanduril]

I have almost the same system but the 300 is a cold spare and I've never tried using it with O'.

One thing I have found with some equipment is that it doesn't like receiving sentences it doesn't know what to do with. Bad programming, but it has been a fact with a couple of devices I've had. I'd take a look at the output on your NMEA connection and see if you're transmitting unneeded data to the APs. For instance, O' automatically retransmits my AIS data to the AP and the AP has no idea what to do with it. So I put an output filter on the connection to drop the AIS data.

I see that the 300 manual has a complete list of sentences that it can accept, I'd try dropping any others. Or, you can work the other way around and drop everything and then add sentences in one at a time. Either way, I'd only transmit the sentences you need to drive the autopilot, no need to congest the serial network with data that isn't being used.

Don't know if that's helpful, have never worked with the 300 so no direct experience I can relay.

[Hakan]

The "Normal" way to filter output data to a AP is to only transmit ECxxx sentences. (Optional add XTE although XTE data is in CERMB as well.)
By default O use EC as the sender ID for AP-data. (Can be changed as you wish) See my example shot.
Read more here: https://opencpn.org/wiki/dokuwiki/do...o_an_autopilot
And here:
https://opencpn.org/wiki/dokuwiki/do...to_autopilot&s[]=navigate&s[]=here
Håkan

[RonSouthworth]

Hi folks

An interesting discussion for certain. A long reply a lot of ground covered.

I have worked on automation systems for a large percentage of my career, so i will come at the discussion from a different perspective.


OpenCPN is i think accurately described as a Chart Plotter. It is an excellent supervisory forecasting and planning tool. That is a pretty busy scope already. A wealth of plugins.

Very much fits the supervisory and planning function when we look at control systems models.

Autopilots are in theory designed to be robust reliable and energy efficient, and when installed and set up correctly / optimally alleviate fatigue for submariners the world around. They can be very sophisticated or very basic in design and are an excellent aid to navigation.

At a base level autopilots steer a vessel on a setpoint and attempt to control maintaining that point within deviation limits. So they fundamentally all use XTE albeit in some cases an internal only calculated value.

To achieve control they require process variables that derive a bearing point and a means to measure deviation. This is fed back into the controller to allow it to calculate a control output response. Thus maintaining a heading.

The instrumented value used to calculate the bearing can be magnetic gyroscopic or based on positional calculations from a GPS or a combination of all and many other values.

Some installations instrument rudder angle feedback for example, the more basic one’s don’t some are extremely sophisticated. Some compensate for instrument land control action lag.

Some ships utilise a PLC or distributed control system for example.

They can take other parameters into consideration not just XTE in order to optimally tune the control response.

There are a number of external factors that can cause process control upsets, weather / sea state, this can require significant alteration to how the controller is tuned or on certain vessels it is not unexpected that the controller is unable to maintain a heading.

I continually argue that it is not a good design practice to be overly reliant upon a supervisory layer for completely automatic decisional control of a vessel aircraft or any process under manipulation for that matter.

It often is seen as a mitigation of risk and a cost saving exercise however consequences are usually inaccurately reevaluated and at some point in time the true statistical probability of something failing to go to plan becomes self evident.

That being said, OpenCPN is quite capable of providing decisional information based upon a range of sources in order for the captain of a vessel to plan and to optimise a voyage or passage, a human should always be in the loop is something I always contend should be the case.

NMEA 0183 is a reasonably robust and functional communications protocol, adequate to convey instrument information and command control responses, there are other protocols designed to be more resilient however like MODBUS in other parts of automation the maritime industry has such an investment and established use base that i do t envisage it being phased out any time soon.

Maneuvering even a high speed vessel is well catered for utilising NMEA0183.

Compare it to phasing out IPv4 to iPv6, uptake isn’t all that fast paced.

Tight quarters navigation utilising automation is a non trivial task to work out a lot of factors in order to achieve a repeatable result.

There are shipping channels in the water i can see out my window that deep draft vessels need to accurately steer within meters of a heading and track to ensure 4 inches below the keel when fully laden, tidal considerations impact the predicted speed.

Presently opencpn supports downloading and or transmission of waypoint settings, more autopilot brand specific tools I think are always welcome.

Maybe a more sophisticated predicted course indicator is what is needed or maybe better user guides for autopilots and tuning ?

There are some advantages to be had in creating arcs about a waypoint some good rule of thumb safe distances. Depending upon where you are in the world the randomising routine in variance of the Position fx quality in the GPS system can have a dramatic impact on absolute accuracy. That impacts navigation a lot more than people take into consideration.


I think i more than covered the thread,

/Ron

[transmitterdan]

Ron,

O does not “drive” the autopilot. It just provides data such as cross-track error, bearing to waypoint, waypoint coordinates, etc. The AP processor is then responsible for converting that data into proper rudder movements. There are other apps and plugins that try to be an AP processor. And there is an agreed NMEA protocol for sending data to the AP. O follows that protocol already.

But i agree with you, it is not a good idea for the main O program to turn the rudder. Better to offload that to another process or box.

So for me there isn’t much more needed from O in regards autopilot functions.

Someone has asked for the “route following dashboard” feature of O to work based on these NMEA messages. That might be a good idea but a better idea would be a plugin that does that. Then it would work whether or not O was doing the calculations or some other external device was doing that.

[rgleason]

Seans plugin Autopilot Route and Pypilot use different data than XTE for correction. I forget exactly what, but he has found his algorithm is better. I think he also uses acceleration, pitch and yaw and he has a user option for the standard default way.

Someone should really start using and testing these pi because I think they'll save energy too.