Talking to my boat… or just talking to myself?

[SkipperDon]

So I finally wired up the Voice Control app on OpenPlotter. Microphone plugged in, Pi humming along, and me standing at the helm like Captain Kirk.
Problem is… when I say “Open OpenCPN”, sometimes the boat listens, sometimes it just stares back at me in silence. My crew thinks I’m rehearsing Shakespeare, and the autopilot is clearly unimpressed.
Has anyone here actually successfully navigated with voice commands? I’m curious if you’ve managed to get beyond the “start logging GPS” stage without sounding like you’re arguing with Alexa.
Bonus points if you’ve tied it into Node-RED—because I’d love to say “Anchor alarm on” and have the boat respond like a loyal dog instead of a stubborn teenager.
Any tips, tricks, or funny fails welcome. At this point, I’m just trying to figure out if my boat is ignoring me… or if OpenPlotter thinks I need speech therapy.

[jim321]

LOL.. i got into this project because i was tiered of drawing on paper charts.chart plotters where out of my budget.
i am sure that it will go places i never thought of,ai and all.

[sebba]

I'm always sailing with voice commands, I don't like to text commands to my crew!
mostly, my voice commands are somehow recognized by the crew, especially "bring me some beer"
some issues when docking, especially crosswind, when more F*** commands are required!

cheers!

[SkipperDon]

I really like where this idea is headed. For me, the background on voice commands isn’t just about convenience—it’s about safety. I’m solo about half the time, and when you’re docking or navigating in current and wind, you can’t afford to be glued to a touchscreen. Eyes up, hands on the helm, ears open—that’s the reality.

What I’m after is a way to query OpenPlotter/OpenCPN without breaking situational awareness. Imagine asking, “What’s at the next port?” and having the system read back whether there’s fuel, a pump-out, or other services. That’s instant information, not something you have to dig for once you’re tied up. It’s like having a buddy onboard who can stream the internet or pull local data for you—except this buddy doesn’t get distracted working on their tan.

I’m new to sailing, so traveling between ports is still a learning curve. Having AI or voice integration as a co-pilot feels like a natural extension of what OpenMarine is already doing: making tech approachable and useful on the water. Curious if anyone else has experimented with voice layers on top of OpenCPN plugins, or if there are projects already tackling this?

[SkipperDon]

Chromium + Trixie + Touchscreens: The Bug That Tried to Mutiny During My OpenPlotter Rebuild

While rebuilding OpenPlotter on Debian Trixie to get proper touchscreen support (because who doesn’t want to poke their boat computer like it’s a misbehaving chartplotter), I ran into a repeatable crash that deserves its own caution label.

Here’s the short version:
If you’re running Chromium on Trixie with a touchscreen, and you dare to activate voice input, your system may decide it’s had enough and throw itself overboard. Touchscreen freezes, compositor crashes, the whole UI goes down like a dinghy in a squall. After digging into it, the culprit isn’t OpenPlotter at all — it’s the unholy alliance of:
- Chromium’s “still learning to walk” Wayland input handling
- Trixie’s shiny new Wayland compositor
- libinput touchscreen drivers that panic when audio wakes up
- PipeWire/WebRTC, which apparently negotiates audio by flipping every input device upside down just to see what happens
Put all four together and you get a perfect storm.
Not a bug — a feature, if you ask Chromium.
Why voice input triggers the chaos
The moment you say “Hey AI…” Chromium wakes up the microphone, Wayland panics, the touchscreen faints, and the compositor decides it’s not paid enough for this job. It’s like watching four subsystems argue about who’s supposed to hold the wheel. Workarounds that keep the ship afloat
- Run Chromium under XWayland, which is basically telling it “pretend it’s 2015 and calm down”:
chromium --ozone-platform=x11
- Turn off hardware acceleration (Chromium behaves better when it’s not trying to be clever)
- Use Firefox for anything involving voice input — it’s the grown‑up in the room
- Disable multitouch if you’re desperate (your touchscreen will sulk, but it won’t crash)
Why this matters for OpenPlotter users
If you’re rebuilding OpenPlotter on Trixie to get better touchscreen support, this issue is worth knowing about. The touchscreen works great — until Chromium hears your voice and decides to reenact a dramatic fainting scene.