Autopilot Control

[bdbcat]

I like this approach/description...

From Panbo article:
"When your vessel goes off course while navigating between the origin (previous waypoint) and your current destination waypoint because of a remote control command, etc. the NAV mode uses one of two methods to get back on course: COURSE or XTE. (See figure in below.) If COURSE is selected, the NAVpilot-500 will calculate a new course based on your new position after dodging, etc. that will take you directly to your destination waypoint. If XTE is
selected, the NAVpilot-500 will use XTE or cross track error to steer the boat towards your ORIGINAL course before dodging. You may select, either COURSE or XTE as shown below."

We could do this in OCPN, I think.

But what is clear from reading is that whatever we do must be configurable, and that the tried and true XTE method must be the default.

Sean, it seems to me that a PlugIn with lots of configurability would be the way to start. This would allow others to play, and build a knowledge base regarding A/P and boat response characteristics. Once we understand the behavior well enough, bring it into the core as a configurable option.

Dave

[rgleason]

I find this all very interesting. I have an old ST4000 and after a "dodge" it just heads back to the original heading and waypoint with out using XTE, ie XTE is reset.

I found this statement from the article very interesting:

Raymarine displays have a fairly-easy-to-get-at function called "Reset XTE" which would make the SPX30 return to a waypoint course just like the 300 used to.

Why? Because Opencpn has such a feature too. Right Click and pick Zero XTE, also shown towards the bottom here Activating Routes and Active Route Console

[Paul L]

On the Navpilot mentioned above there is also another interesting mode. You can set it up so that when you tell the AP to steer a specific compass course it will then create an imaginary waypoint far ahead of the vessel and then use XTE to steer to it. In this case you'll see your steering course change over time. The default mode is to just accept the compass course steer that course.

[rgleason]

We could do this in OCPN, I think.

Dave, I am wondering if you already have this with the Zero XTE choice, albeit a little indirect?

[rooiedirk]

Sean, it seems to me that a PlugIn with lots of configurability would be the way to start. This would allow others to play, and build a knowledge base regarding A/P and boat response characteristics. Once we understand the behavior well enough, bring it into the core as a configurable option.

I just had a new PluginMessage in the message system about the active route leg. For now it has info about waypoint lat/lon XTE and BRG. Maybe you need for this purpose some additional info as last waypoint lat/lon. The time to do this would be now as O is in beta at the moment.

f( g_pRouteMan->m_bDataValid )
            {
                v[_T("error")] = false;
                v[_T("range")] = g_pRouteMan->GetCurrentRngToActivePoint();
                v[_T("bearing")] = g_pRouteMan->GetCurrentBrgToActivePoint();
                v[_T("XTE")] = g_pRouteMan->GetCurrentXTEToActivePoint();
                v[_T("active_route_GUID")] = g_pRouteMan->GetpActiveRoute()->m_RouteNameString;
                v[_T("active_waypoint_lat")] = g_pRouteMan->GetpActiveRoute()->m_pRouteActivePoint->GetLatitude();
                v[_T("active_waypoint_lon")] = g_pRouteMan->GetpActiveRoute()->m_pRouteActivePoint->GetLongitude();
            }
        }
        wxString msg_id( _T("OCPN_ACTIVE_ROUTELEG_RESPONSE") );
        g_pi_manager->SendJSONMessageToAllPlugins( msg_id, v );

[seandepagnier]

Originally Posted by rooiedirk

I just had a new PluginMessage in the message system about the active route leg. For now it has info about waypoint lat/lon XTE and BRG. Maybe you need for this purpose some additional info as last waypoint lat/lon. The time to do this would be now as O is in beta at the moment.

f( g_pRouteMan->m_bDataValid )
            {
                v[_T("error")] = false;
                v[_T("range")] = g_pRouteMan->GetCurrentRngToActivePoint();
                v[_T("bearing")] = g_pRouteMan->GetCurrentBrgToActivePoint();
                v[_T("XTE")] = g_pRouteMan->GetCurrentXTEToActivePoint();
                v[_T("active_route_GUID")] = g_pRouteMan->GetpActiveRoute()->m_RouteNameString;
                v[_T("active_waypoint_lat")] = g_pRouteMan->GetpActiveRoute()->m_pRouteActivePoint->GetLatitude();
                v[_T("active_waypoint_lon")] = g_pRouteMan->GetpActiveRoute()->m_pRouteActivePoint->GetLongitude();
            }
        }
        wxString msg_id( _T("OCPN_ACTIVE_ROUTELEG_RESPONSE") );
        g_pi_manager->SendJSONMessageToAllPlugins( msg_id, v );

It's a start, but I have issues:


1) I need to generate the APB messages from the plugin. As far as I can tell, any ports set for output, will also generate these messages from the core which will conflict.

2) The plugin needs to determine when the waypoint is reached, or the next one activated.

3) I need to know the position of the next waypoint after the active one, but preferably the entire route (see below)


So the plugin either needs:

1) an api where the plugin "takes over" autopilot calculations
2) the plugin could implement it's own "active" mode which is completely separate from the core. This solves #1 and #2, but is confusing to use because of the two modes (like watchdog and core anchor alarm) The "This Leg" dialog would not be used.. so I prefer #1


I would support many different modes:

1) XTE with tunable PID filter. In this mode, normal XTE is computed by the plugin, and the AP is commanded in bearing. The gains are graphically represented and easily visualized.
2) Next waypoint mode. This mode aims for the next waypoint regardless of XTE... the same as continuously resetting XTE, and always using the bearing.
3) Best route mode. This mode uses a specified time or distance, and finds calculates the best position along the route at that distance, or future time, and steers to it. complete with graphical representation. This avoids discontinuities at waypoints as there no longer an arrival radius.


I need the entire route, because I wish to have a button (integrated with the draw plugin) that draws a boundary around the route. The user can then modify this boundary by dragging it.

There could be any number of boundaries specified to avoid also.

The logic to stay in/out the route boundary is less clear, feel free to comment.

[Paul Elliott]

It's probably time for a review of basic guidance-system engineering:

https://www.youtube.com/watch?v=bZe5J8SVCYQ

[rooiedirk]

@Sean,

1) I need to generate the APB messages from the plugin. As far as I can tell, any ports set for output, will also generate these messages from the core which will conflict.

2) The plugin needs to determine when the waypoint is reached, or the next one activated.

3) I need to know the position of the next waypoint after the active one, but preferably the entire route (see below)

To start with 3: With message REQUEST_ACTIVE_ROUTELEG you get an answer including the route name. With this name you could for request the whole route.

For point 1 it might be needed to as soon as an active route is found:

• Deactivate the active route in core O
• Take over complete routing from within the PI, including an own route information window, right click menu, etc etc.

Point 2 would be solved then also. Only I don't know how to stop the active routing in O from a plugin.
Dirk

[transmitterdan]

An autopilot plugin could be implemented that is an alternative to the native route following system in the core. I don’t see anything to prohibit that. So I would prefer to leave the core alone and steer the ideas toward an AP plugin. Call it Automated Passage Plugin.

[transmitterdan]

Originally Posted by Paul Elliott

It's probably time for a review of basic guidance-system engineering:

2 minutes of my life I can never reclaim...but funny nevertheless.

[seandepagnier]

Originally Posted by transmitterdan

So I would prefer to leave the core alone and steer the ideas toward an AP plugin.

This is the plan, as outlined by Dave.

Call it Automated Passage Plugin.

I don't think "passage" makes sense.


I'm not sure I like this name. I have ideas like

1) Autopilot Plugin (too generic?)
2) Advanced Autopilot Plugin
3) Autopilot Route and Waypoint Plugin
4) AP Route Plugin
5) Advanced AP Route Plugin

something better/different?

Keep in mind, I intend to implement advanced configurable "rules" For example, to ensure the boat doesn't jib downwind when following a gps route.

Originally Posted by rooiedirk

@Sean,

To start with 3: With message REQUEST_ACTIVE_ROUTELEG you get an answer including the route name. With this name you could for request the whole route.

There is another function "GetActiveRoutepointGPX" which I can't seem to find what plugin actually uses it.

For point 1 it might be needed to as soon as an active route is found:

• Deactivate the active route in core O
• Take over complete routing from within the PI, including an own route information window, right click menu, etc etc.

Point 2 would be solved then also. Only I don't know how to stop the active routing in O from a plugin.
Dirk

Option 1:

wait for OCPN_RTE_ACTIVATED or OCPN_WPT_ACTIVATED message.
send OCPN_ROUTE_REQUEST to get the route.
Now I need a new message to deactivate the active route/waypoint. This is kind of a hack, as the user cannot deactivate the waypoint anymore in the usual way.


Option 2:

Add support to allow plugins to install context menus for routes, track, waypoints and ais rather than just default menus. This is probably really useful anyway for other plugins.

Then the plugin has it's own form of "activated" which is separate from the core. The graphics rendered can be different as well. If the user activates a route in the core using the normal method, then the plugin would "deactivate"


Option 3:

Allow plugins to perform the calculations while still allowing the concept of active route/waypoint to be used in a universal way. The "This Leg" dialog could still be used This would have the best support for integrating with other plugins. A few functions are needed to implement this.



What other plugins currently use the OCPN_RTE_ACTIVATED message?

[rooiedirk]

What other plugins currently use the OCPN_RTE_ACTIVATED message?

Currently I'm working on a compass deviation PI. For this PI I wanted a bearing to the next active waypoint. Therefore I did a push request with the following two messages.
_T("OCPN_ACTIVE_ROUTELEG_REQUEST"))
_T("OCPN_ACTIVE_ROUTELEG_RESPONSE") );
Those two mess. are available in the current beta of O
With those messages you would need to do a request every second or so to get a response, and if the response has no error set then there is a active route.

I don't mind if this is changed as long as I can get somehow a bearing to the active waypoint in my PI (That still is in alpha at this moment)

[rgleason]

Dirk:

Point 2 would be solved then also. Only I don't know how to stop the active routing in O from a plugin. Dirk

Somewhat silly, but you could just turn it off.

[rgleason]

Sean, if I have a vote, I'd like to see something short like "4) AP Route Plugin"

[seandepagnier]

Originally Posted by rooiedirk

Currently I'm working on a compass deviation PI.

What does this plugin solve? We have WMM, you can manually enter deviation without it, there is an option to command the AP in compass bearing already.

Steering to compass bearing is typically not a good idea for routes, as these are based on gps positions, so it's better to steer to gps.