Autopilot, Heading, and Steering Interface Handover

This article applies to yachts with autopilot, heading control, track control, integrated bridge systems, steering-control interfaces, wing-station controls, route-following functions, or bridge systems that exchange heading, position, speed, rudder, or track data.

Applicability depends on flag state, class, yacht size and GT, private or commercial use, SOLAS applicability, equipment approval route, whether track control is fitted, whether the system interfaces with ECDIS or INS, and whether steering or propulsion interfaces are part of a wider bridge automation ecosystem.

From an ETO or bridge technician's point of view, the autopilot is not just a box on the console. It is a control loop that depends on sensors, software, steering gear, feedback, alarms, power, cabling, and bridge-team discipline. When it works, everyone forgets about it. When it behaves badly, the fault can sit almost anywhere in that chain.

The simplest version is this: the bridge team asks for a heading, the autopilot compares that heading with the yacht's actual heading, then it sends steering commands to reduce the error.

That sounds simple, but onboard it is rarely just one unit doing one job. On a 50-150m yacht, the autopilot may be taking heading from a gyro or THD, speed and position from navigation sensors, rudder angle from feedback units, and route or track information from ECDIS or an integrated bridge system. It may also be tied into wing stations, joystick systems, bridge alert displays, VDR feeds, or a wider manoeuvring package.

When I look at an autopilot fault, I do not start by assuming the autopilot processor is bad. I start by asking what part of the chain it is relying on:

• what heading source is selected,
• whether that heading source is stable,
• whether rudder feedback matches reality,
• whether the steering gear responds cleanly,
• whether the active bridge mode is obvious,
• whether the alarm shown on the bridge matches the technical fault,
• whether anything was changed recently.

The autopilot can only steer with the information and steering response it is given. Bad input, poor feedback, or a sticky steering system can make a good autopilot look unreliable.

Larger yachts tend to use commercial bridge ecosystems rather than small-boat standalone equipment. You may see Anschutz / formerly Raytheon Anschutz steering and navigation equipment, Sperry Marine NAVIPILOT and VisionMaster systems, Kongsberg K-Bridge or manoeuvring packages, Furuno VOYAGER bridge systems, NACOS platforms, mtu NautIQ, Praxis, or other bridge and vessel-control integrations.

The brand matters for service support, spares, menus, software, and vendor responsibility. It does not change the basic handover question: what is this installation allowed to command, and what does it depend on?

On one yacht, the autopilot may be a fairly contained heading-control system. On another, steering, thruster, joystick, track-control, and bridge workstation functions may sit much closer together. That is where confusion starts. A captain may say "the autopilot is playing up", while the actual issue is a gyro source, rudder feedback unit, steering control interface, ECDIS track setting, or a control-transfer problem between stations.

The handover needs to name those boundaries. Otherwise each vendor can honestly say "our part looks fine" while the yacht still has a problem.

Most autopilot safety discussions come back to mode awareness. The officer of the watch must know whether the yacht is in hand steering, heading control, track control, joystick or manoeuvring mode, and which station has control.

This is easy to say and easy to lose in practice. Modern yacht bridges can have clean glass displays, multiple workstations, wing controls, touch panels, and manufacturer-specific menus. The system may be elegant, but the bridge team still needs a plain answer: who or what is steering the yacht right now?

Use extra caution when:

• entering or leaving port,
• operating in pilotage waters,
• navigating close to traffic,
• working in restricted visibility,
• changing watchkeepers,
• operating after a bridge software update,
• returning from yard work,
• using a system the crew has not trained on recently,
• switching between helm, autopilot, joystick, wing station, or track mode.

Autopilot reduces workload. It should not reduce attention. The watchkeeper still owns the lookout, COLREGs judgement, passage monitoring, and the decision to disengage.

This distinction matters. Heading control tries to hold a selected heading. Track control can steer relative to a planned track or route, usually involving ECDIS or an integrated navigation system.

Track control is a bigger operational commitment. It depends on route quality, cross-track error settings, sensor validity, alert handling, and crew familiarity. If the yacht does not approve or use track control, the article, handover, and bridge procedure should say that clearly.

Do not let vague terms creep into the handover. If the yacht has heading control only, write that. If track control is fitted but disabled, unapproved, uncommissioned, or not used by procedure, write that too. A watchkeeper should not discover at sea that one bridge mode is accepting route-related commands from somewhere else.

The planned maintenance should cover the whole autopilot chain, not only the visible control head.

For routine checks, I would want to see:

• autopilot startup without abnormal alarms,
• selected heading source confirmed,
• rudder angle display checked for plausibility,
• manual steering tested where safe,
• autopilot engage and standby understood,
• control-station indication checked,
• recent changes reviewed before departure,
• fault history or alarms reviewed after any complaint.

For periodic technical maintenance, go deeper:

• inspect heading-source configuration and fallback logic,
• check rudder feedback calibration or plausibility,
• check steering response in safe conditions,
• review alarm presentation on the bridge,
• inspect accessible connectors, terminals, and interface cabling,
• confirm software or firmware baseline,
• back up configuration where supported,
• review service bulletins and manufacturer maintenance requirements,
• refresh bridge-team familiarisation after updates or refit work.

Do not forget the steering gear. Hydraulic pumps, valves, filters, oil condition, linkages, mechanical stops, leaks, local controls, and emergency steering may sit under engineering maintenance, but they directly affect autopilot behaviour. If hand steering feels poor, do not waste hours tuning the autopilot.

In real fault-finding, the autopilot itself is only one suspect.

Typical causes include:

• unstable gyro or heading input,
• wrong heading source selected after service work,
• failed heading data gateway,
• rudder feedback drift or failure,
• steering gear response lag,
• hydraulic or valve issue,
• poor connector, terminal, or cable condition,
• software mismatch after bridge updates,
• lost NMEA, IEC 61162, CAN, Ethernet, or proprietary data,
• incorrect gain or sea-state tuning,
• wing-station transfer fault,
• joystick or manoeuvring mode confusion,
• track-control settings misunderstood,
• power interruption or grounding issue,
• bridge alarm not repeated clearly enough.

The symptom can mislead you. Hunting may be tuning, sea state, rudder feedback, steering response, or speed input. Dropout may be sensor loss, software, alert logic, or control transfer. Poor course keeping may be heading data, not the autopilot processor.

That is why a good ETO or service engineer avoids the phrase "the autopilot is faulty" until the inputs, outputs, steering response, and mode logic have been checked.

First, make the yacht safe. If the autopilot is behaving unpredictably, return to hand steering if required and follow the vessel's procedure. Troubleshooting comes after control is understood.

Then work the chain:

1. Confirm the active mode.
2. Confirm which station has control.
3. Read alarms and event logs before rebooting.
4. Compare heading with an independent source.
5. Compare rudder angle display with actual steering response.
6. Check whether hand steering behaves normally.
7. Review recent work on gyro, GNSS, ECDIS, bridge network, steering gear, or software.
8. Preserve screenshots, settings, and logs before vendors make changes.

If hand steering is normal but autopilot steering is poor, look at autopilot setup, heading data, rudder feedback, speed input, tuning, or track-control data. If hand steering is also poor, bring engineering and steering-gear support in early. If the issue only appears in track mode, review route data, ECDIS interface, cross-track settings, and whether track control is actually approved for use.

The biggest practical mistake is letting several vendors troubleshoot separately. The bridge vendor, steering vendor, gyro vendor, shipyard, and automation provider may each see one part of the system. Someone needs to own the complete fault picture.

A proper handover should help the next person understand the installed system without guessing.

Keep:

• system architecture summary,
• equipment and software baseline,
• heading, position, speed, and rudder source list,
• steering interface owner,
• control-station and transfer summary,
• heading and track-control capability statement,
• planned maintenance notes,
• test results and limitations,
• fallback and manual steering summary,
• vendor contacts and responsibility boundaries,
• bridge-team familiarisation record.

The useful note is not "tested OK." It is what was tested, where, by whom, under what conditions, and what was not tested. If the yacht only tested heading hold in calm open water, say that. If track control was not tested, say that. If source-loss behaviour was simulated, record what the bridge team saw.

A 70m yacht comes out of a bridge refit. During sea trial, the autopilot holds a heading and everyone is happy. A few weeks later, the captain reports that the yacht is wandering slightly and taking too long to settle after course changes.

It would be easy to blame tuning. But the better check starts wider.

Hand steering feels normal. The rudder angle indication is slightly delayed. The selected heading source is not the one the bridge team thought it was using. The old fallback source is still present in part of the configuration. The autopilot is doing something logical with the data it has, but the handover did not make the source selection clear.

The fix is not just changing a gain value. The team confirms heading-source priority, checks rudder feedback, updates the interface record, repeats steering tests, and briefs the bridge team on what the display will show if the primary source drops out.

That is the point of a good handover. It turns a mysterious bridge complaint into a controlled technical investigation.