fremme
Member
Hello all,
My name is Knut. I have been developing a custom sailboat autopilot system based mainly on Teensy 4.x, and I thought it was time to introduce the project here.
The project is called the KSF AI Autopilot suite:
https://sailingksf.com/?page=autopilot
This is not a general marine display or chartplotter project.
The goal is a dedicated autopilot platform for short-handed and offshore sailing, with strong emphasis on deterministic control, graceful degradation, and practical fault handling.
So far, the project has grown to more than 250,000 lines of code across the Teensy modules, plus about 27,000 lines for the native iPad app. At this point it is a fairly substantial embedded system, so I have had to be quite strict about module boundaries, message contracts, and failure handling.
Current architecture
The core autopilot box uses three Teensy 4.1 boards:
- Main CPU: NMEA 2000 handling, filtering, source arbitration, configuration, logging, and overall system orchestration
- AI CPU: steering logic, hazard handling, confidence/trust logic, and rudder output
- UI CPU: 800x600 display rendering, touch handling, menus, and operator interaction
These three nodes communicate over a private internal CAN bus.
Around that core I also use other Teensy-based nodes, mainly Teensy 4.0, for things such as:
- IMU/attitude modules
- blackbox logging
- alarm/voice functions
- timer and support modules
- weather-assisted advisory
The boat-facing network is NMEA 2000, while the internal control-plane traffic stays on the private CAN bus.
Design philosophy
A few architectural points that have been important to me:
1. One authoritative source of truth. The Main CPU owns the authoritative navigation/wind/system state. The UI does not independently recompute critical values. That keeps the operator display aligned with what the control logic is actually using.
2. Fail-operational behavior. If the system loses some inputs or one subsystem becomes degraded, the objective is to keep steering in the safest possible way instead of just dropping out immediately.
3. Deterministic embedded behavior, I try to avoid dynamic allocation in hot paths, avoid blocking in control-sensitive code, and keep bus/message ownership explicit.
4. Clear separation between vessel bus and internal bus. NMEA 2000 is used for integration with the boat, while the private CAN bus is used for internal binary messaging between Main, AI, and UI.
Current functions
At the moment the suite includes work on:
- heading mode
- wind-based steering
- track / route support
- waypoint workflows
- hazard and alarm handling
- onboard display UI
- native iPad UI
- logging and diagnostics
- weather-assisted advisory functions
The iPad side is a native SwiftUI app connected through an ESP32 gateway. It mirrors the main system pages and allows live monitoring and control without putting more load or complexity into the embedded display node.
Why Teensy
Teensy 4.x has been a very good fit for this project:
- enough CPU headroom for control, filtering, and UI split across nodes
- flexible I/O
- practical CAN support
- easy iteration cycle
- a toolchain that still feels lightweight enough for embedded development
For a project like this, that balance has been very useful.
To be honest, this project has been a great experience so far. I have learned a lot about Teensy, CAN, and embedded system design, and I have loved working on it every step of the way.
I would be very interested in feedback from other Teensy users, especially on reliability, CAN/NMEA 2000 integration, multi-processor architecture, and general robustness for marine use.
Best regards,
Knut
My name is Knut. I have been developing a custom sailboat autopilot system based mainly on Teensy 4.x, and I thought it was time to introduce the project here.
The project is called the KSF AI Autopilot suite:
https://sailingksf.com/?page=autopilot
This is not a general marine display or chartplotter project.
The goal is a dedicated autopilot platform for short-handed and offshore sailing, with strong emphasis on deterministic control, graceful degradation, and practical fault handling.
So far, the project has grown to more than 250,000 lines of code across the Teensy modules, plus about 27,000 lines for the native iPad app. At this point it is a fairly substantial embedded system, so I have had to be quite strict about module boundaries, message contracts, and failure handling.
Current architecture
The core autopilot box uses three Teensy 4.1 boards:
- Main CPU: NMEA 2000 handling, filtering, source arbitration, configuration, logging, and overall system orchestration
- AI CPU: steering logic, hazard handling, confidence/trust logic, and rudder output
- UI CPU: 800x600 display rendering, touch handling, menus, and operator interaction
These three nodes communicate over a private internal CAN bus.
Around that core I also use other Teensy-based nodes, mainly Teensy 4.0, for things such as:
- IMU/attitude modules
- blackbox logging
- alarm/voice functions
- timer and support modules
- weather-assisted advisory
The boat-facing network is NMEA 2000, while the internal control-plane traffic stays on the private CAN bus.
Design philosophy
A few architectural points that have been important to me:
1. One authoritative source of truth. The Main CPU owns the authoritative navigation/wind/system state. The UI does not independently recompute critical values. That keeps the operator display aligned with what the control logic is actually using.
2. Fail-operational behavior. If the system loses some inputs or one subsystem becomes degraded, the objective is to keep steering in the safest possible way instead of just dropping out immediately.
3. Deterministic embedded behavior, I try to avoid dynamic allocation in hot paths, avoid blocking in control-sensitive code, and keep bus/message ownership explicit.
4. Clear separation between vessel bus and internal bus. NMEA 2000 is used for integration with the boat, while the private CAN bus is used for internal binary messaging between Main, AI, and UI.
Current functions
At the moment the suite includes work on:
- heading mode
- wind-based steering
- track / route support
- waypoint workflows
- hazard and alarm handling
- onboard display UI
- native iPad UI
- logging and diagnostics
- weather-assisted advisory functions
The iPad side is a native SwiftUI app connected through an ESP32 gateway. It mirrors the main system pages and allows live monitoring and control without putting more load or complexity into the embedded display node.
Why Teensy
Teensy 4.x has been a very good fit for this project:
- enough CPU headroom for control, filtering, and UI split across nodes
- flexible I/O
- practical CAN support
- easy iteration cycle
- a toolchain that still feels lightweight enough for embedded development
For a project like this, that balance has been very useful.
To be honest, this project has been a great experience so far. I have learned a lot about Teensy, CAN, and embedded system design, and I have loved working on it every step of the way.
I would be very interested in feedback from other Teensy users, especially on reliability, CAN/NMEA 2000 integration, multi-processor architecture, and general robustness for marine use.
Best regards,
Knut
