Autopilot Development

[Glen96]

I have been developing an Autopilot application for some years but I am new to the Forums and Posting so let me know if I am doing the wrong thing or communicating with the wrong area in OpenCPN. A brief history of my background is mentioned in thread “TCP/IP Help Required”.

With OpenCPN I am now developing and bench testing some Autopilot (AP) software I wrote some 10 years ago. From an AP point of view I have some issues I would like to discuss regarding the output of route data from OpenCPN.

The procedure to define and activate a route if fine. The code to intercept the route from the current ships position to the first waypoint (Wp) is fine also.

The following massage sequence will ill illustrate a problem for the AP:

19/11/2014 06:55:33: $GPRMC,085533.337,A,2810.208,S,15333.710,E,7.1,351 .2,191114,8.6,E*7A
19/11/2014 06:55:34: $ECRMB,A,0.024,L,,001,2810.167,S,15333.666,E,0.056 ,316.510,7.100,V*32
19/11/2014 06:55:34: $ECAPB,A,A,0.024,L,N,V,V,342.270,T,001,316.510,T,3 16.510,T*34
This massage sequence is typical of tracking data before approaching the To_Waypoint (ToWp).

19/11/2014 06:55:34: $GPRMC,085534.352,A,2810.206,S,15333.710,E,7.1,351 .2,191114,8.6,E*70
19/11/2014 06:55:35: $ECRMB,A,0.025,L,,001,2810.167,S,15333.666,E,0.054 ,315.062,7.100,A*25
19/11/2014 06:55:35: $ECAPB,A,A,0.025,L,N,A,V,342.270,T,001,315.062,T,3 15.062,T*22
This is the data stream at the end of a leg as the ship approaches the ToWp. The APB fields changes from “V,V” to “A,V” to indicate that the “Arrival Circle Entered”. Depending on circumstances this may not be early enough.

19/11/2014 06:55:35: $GPRMC,085535.365,A,2810.204,S,15333.709,E,7.1,351 .2,191114,8.6,E*7F
19/11/2014 06:55:36: $ECRMB,A,0.010,R,001,002,2810.096,S,15333.542,E,0. 183,306.363,7.100,V*19
19/11/2014 06:55:36: $ECAPB,A,A,0.010,R,N,V,V,303.093,T,002,306.363,T,3 06.363,T*24
It is not until this RMB is received that the Next_ Waypoint (NxWp) is defined.

From a navigation and AP point of view this is too late to get the NxWp data. The transition from current leg to the next can be very different dependent on data. Speed, turn rate, turn radius, set all have an influence.

I would prefer that the Route message RTE or a sequential list of Wp data WPL was transmitted. At the very least provide the NxWp data just after the leg data is transmitted. Amended data can be resent using the Wp ID as key.

It is the responsibility of the ECS to manage the route data and supply the AP with the data in a timely manner. It is the responsibility of the AP to use the data to manage the helm to achieve an accurate navigation outcome.

I Think OpenCPN is a great electronic charting system and an AP will not go amiss.

Looking forward to hearing your feedback.

Thank you.

Regards
Glen

[nohal]

Glen...
I kind of don't see what could happen in that 1 second between you arrive to a WPT and get a new heading given you travel on a boat and not on a ray of light.
What would the RTE/WPL stuff be good for for the AP? I assume you are not going to duplicate all the stuff you get in RMC/RMB/APB/XTE just to somehow survive that 1 second gap when you "don't know where to turn", do you?
But maybe I just missed the point of the post.
Can you elaborate a bit which circumstances are you talking about and what you imagine is wrong on going straight for another second?

Pavel

[Glen96]

Some what of an interesting response.

Fine sail on for a bit in open water, but not every one is in mid ocean or has the sea room.

My experience in heavily reefed areas with 10 m tides generating some very high currents combined with large heading changes does not permit slack overruns.

A good design principal in all endeavors is to be prepared. The DR of a transit results in a time to turn which is calculated, maintained and valid well before the event occurs. The combination of higher boat speed, following current and slow turn rate or large turn radius can add to more than 1 sec. Not a problem for the computer only for safe navigation.

Rally drivers have navigators to forecast the conditions of the next turn.

I bet you have some anticipation and foresight in life.

Glen

[nohal]

Glen...
That's why boats have navigators and helmsmen...
With this logic, if you think that you can do it better and the standard autopilot logic "Get to the proximity of the WPT, keep going straight and counting time, if the new course does not come in X, issue an alarm" is not good for you, resign on the autopilot sentences from ECS completely and get just the route.
I personally would probably not let a machine steer my boat in a place where 1 second delay in a course change matters. But it is me.

Pavel

[RaymondR]

Pavel, I can see where the autopilot might need to know whether a small wheel adjustment was needed for a small course correction of say 10 degrees or whether a hard over and firm meet the turn wheel adjustment was needed for say a 330 degree turn.

Glen has not given any information on the algorithm he is using for course adjustments whether it's PID or something else and it would be nice to know what the effects of large deviations on input resulted in.

The chart plotter program and autopilot things are very interesting areas of boating and I am sure there are a lot of us who would be interested in the details of interactions between the two systems.

[Glen96]

Pavel an AP is an assistant. It is your choice. You probably would never need it.

Glen

[seandepagnier]

Glen,

I am working on an autopilot as well, mine: https://github.com/seandepagnier/rpi_autopilot
It uses a raspberry pi, and i2c inertial sensors.

Please post a link to your project.


I don't plan to support nmea really because it isn't sufficient. Instead I should be able to make my own signal-k sentences.

How do you handle the drive unit? I am using brushless motor controllers and detecting stops with a shunt to measure current.

[Glen96]

Hi Raymond,

There is a division of labor and responsibility involved in ECS and AP working together. Both have a GPS as the fundamental input.

In the very broadest of terms the ECS is responsible for management of the system, charts, routes and rendering a visual user feedback image. The AP is a bit simpler it is responsible for using the route data and providing helm commands to provide a safe navigation outcome and user feedback with data like XTE, VTG, VWR etc.

NMEA is simple but not the most efficient or sufficient system. There is no reason why the shortfall could not be covered by OpenCPN proprietary messages.

The tracking algorithm uses an offset gain factor that resembles the tangential curve of an ellipse and thus the correction factor ranges from 1 to max value that is applied to the the track error. At the moment no time functions are applied as would be the case with PID.

The turn rate is set as a constant of 10 deg/sec, turn radius becomes a function of speed, step inputs of offset (XTE) are not possible but the rudder response to step input is manageable. Closed loop control theory is a science of its own.

The transit to the next leg is an important calculation and currently the DR includes turn, turn rate, turn radius, speed and set.

My priority at the moment is to have OpenCPN send route data to the AP as outlined in post #1.

Once the frame work is in place the technical issues can be address as development advances.

Hope this brief helps a bit.

Regards
Glen

[Glen96]

Hi boat_alexandra,

Visited github and had a quick look, very interesting, especially the helm.

As yet I have not gone public and do not have a link to the project. My interest is the software side of navigation but the helm hardware and interface is interesting. Electronics is largely a mystery.

I will read your data and respond.

Glen