PyPilot Broken After Updates and Repair Process

PyPilot Broken After Updates and Repair Process - Printable Version

+- OpenMarine (https://forum.openmarine.net)
+-- Forum: OpenMarine (https://forum.openmarine.net/forumdisplay.php?fid=27)
+--- Forum: General discussion (https://forum.openmarine.net/forumdisplay.php?fid=28)
+--- Thread: PyPilot Broken After Updates and Repair Process (/showthread.php?tid=7018)

PyPilot Broken After Updates and Repair Process - chaddcurtis - 2026-07-11

OpenPlotter 4 / Pypilot repair notes: missing backend, RTIMULib incompatibility, linebuffer errors, and missing calibration graphics

TL;DR

I was able to restore Pypilot on two Raspberry Pi 5 systems running OpenPlotter 4:

A fresh OpenPlotter installation where Pypilot had never worked correctly.
An older, heavily configured installation where Pypilot had worked previously but stopped working after updates during spring 2026.

The problems were not caused by the IMU or its I2C connection. They involved an incomplete or inconsistent Pypilot installation, incompatible RTIMULib Python bindings, a broken or missing compiled

Code:
linebuffer

component, and a missing

Code:
pypilot_data

package that supplies the calibration window's 3D boat model.

On the older installation, the step that finally restored the Pypilot backend was:

Code:
cd /tmp

sudo rm -rf pypilot

git clone --depth 1 https://github.com/pypilot/pypilot

cd pypilot

sudo python3 -m pip install \

  --force-reinstall \

  ".[optimize]" \

  --break-system-packages

I then removed the cached IMU configuration and restarted Pypilot:

Code:
cd ~

rm -f ~/.pypilot/RTIMULib.ini

sudo chown -R pi:pi ~/.pypilot

sudo systemctl daemon-reload

sudo systemctl restart pypilot_boatimu

sudo systemctl restart pypilot

Afterward, Pypilot detected the ICM-20948, verified all IMU axes, loaded calibration, started the server, displayed the 3D calibration boat, and reported compass, GPS, wind, and true-wind modes.

Your mileage may vary. This is not my area of expertise, and this repair process was developed and worked through with the assistance of ChatGPT. I am sharing the symptoms, commands, logs, and results because they may help others who are experiencing the same problems. This should not be treated as an official or universal repair procedure.

Make a complete image backup of the SD card or NVMe drive before trying any of this.

System details

My system was:

Raspberry Pi 5
64-bit OpenPlotter 4
Code:
openplotter-pypilot 4.0.11-beta
Python 3.11
ICM-20948 IMU on a MacArthur HAT
Pypilot motor controller connected by USB serial

The exact versions and repository contents may change, so anyone trying this should record their own OpenPlotter, Pypilot, Python, and architecture details.

Symptoms

Across the two installations, I encountered several of the following:

The OpenPlotter Pypilot application would not open.
Selecting Enable IMU Only briefly activated the service, but it immediately returned to inactive.
Code:
pypilot_boatimu.service
repeatedly restarted.
The IMU appeared at

Code:
0x68
with

Code:
i2cdetect
, but Pypilot did not use it.
The OpenPlotter application reported missing RTIMU support.
Pypilot failed with an

Code:
MPU925xAccelFsr
error.
The calibration application was missing the 3D sailboat model.
The calibration application reported that

Code:
pypilot_data
was missing.
The older installation could not import

Code:
linebuffer
.
Pypilot appeared to contain a mixture of older and newer Python files.

Start with the logs

The graphical interface often showed only that the service was activating and then becoming inactive again. The system logs revealed the actual errors.

Check both services:

Code:
systemctl status pypilot_boatimu --no-pager -l

systemctl status pypilot --no-pager -l

Then inspect the logs:

Code:
journalctl -u pypilot_boatimu -b --no-pager -n 150

journalctl -u pypilot -b --no-pager -n 150

For live monitoring:

Code:
journalctl -u pypilot_boatimu -f

or:

Code:
journalctl -u pypilot -f

Confirm that Linux can see the IMU

Check that the I2C bus exists:

Code:
ls -l /dev/i2c*

Then scan bus 1:

Code:
sudo i2cdetect -y 1

My ICM-20948 appeared at:

Code:
0x68

That confirmed that the IMU was electrically visible to Linux.

Important distinction: Seeing the IMU with

Code:
i2cdetect

does not prove that Pypilot has a compatible RTIMU Python library or that its IMU service can use the device.

Someone can therefore have correct wiring and a detectable IMU while Pypilot still fails entirely because of a software problem.

Failure 1: missing or incomplete Pypilot installation

On the fresh OpenPlotter installation, the Pypilot package did not appear to leave a complete working backend.

Problems included:

Missing

Code:
python3-rtimulib
Missing

Code:
swig
No importable Pypilot backend
Incompatible RTIMULib bindings
Missing

Code:
pypilot_data
A failure in Pypilot's dependency-installation script

The dependency script failed with:

Code:
NameError: name 'wiringpi_dep' is not defined

An initial Pypilot source build also failed with:

Code:
error: command 'swig' failed: No such file or directory

The basic packages I installed included:

Code:
sudo apt update

sudo apt install -y \

  git \

  swig \

  pkg-config \

  libgpiod-dev \

  i2c-tools

I would not assume this package list is complete for every installation. The relevant error messages in the logs should determine what is actually missing.

Failure 2: incompatible RTIMULib binding

Installing Debian's

Code:
python3-rtimulib

package allowed parts of the OpenPlotter interface to work, but the binding was not compatible with the Pypilot source being used.

The service reported:

Code:
AttributeError: 'RTIMU.Settings' object has no attribute 'MPU925xAccelFsr'

I installed the newer RTIMULib2 Python binding:

Code:
cd /tmp

sudo rm -rf RTIMULib2

git clone --depth 1 https://github.com/seandepagnier/RTIMULib2

cd RTIMULib2/Linux/python

sudo python3 setup.py install

I verified that the required setting existed with:

Code:
cd ~

python3 - <<'PY'

import RTIMU

settings = RTIMU.Settings("RTIMULib")

print("RTIMU location:", RTIMU.__file__)

print("Has MPU925xAccelFsr:", hasattr(settings, "MPU925xAccelFsr"))

PY

The important result was:

Code:
Has MPU925xAccelFsr: True

If it reports

Code:
False

, Python may still be loading an older RTIMU module.

Failure 3: broken or mixed Pypilot files on the older installation

The older installation had an additional error:

Code:
cannot import name 'linebuffer' from 'pypilot.linebuffer'

The

Code:
pypilot_boatimu

service entered an automatic restart loop.

A normal installation using:

Code:
sudo python3 setup.py install

had helped on the fresh installation, but it did not appear to replace all of the conflicting files on the older system.

The repair that ultimately worked there was:

Code:
cd /tmp

sudo rm -rf pypilot

git clone --depth 1 https://github.com/pypilot/pypilot

cd pypilot

sudo python3 -m pip install \

  --force-reinstall \

  ".[optimize]" \

  --break-system-packages

In my case, pip removed Pypilot 0.70 and installed Pypilot 0.71. It also installed or replaced Pypilot's declared dependencies, including:

RTIMULib
Code:
pypilot_data
Code:
pyserial
Code:
numpy
Code:
scipy
Code:
zeroconf
Code:
ujson

This was a much more complete replacement than the earlier

Code:
setup.py install

.

It also modifies Python packages outside Debian's normal package-management process. That is one reason I strongly recommend making a complete drive image first.

Important testing trap: leave the cloned source directory

After installing Pypilot, I initially tested

Code:
linebuffer

while still inside:

Code:
/tmp/pypilot

Python imported the files from the cloned source directory instead of the installed package and produced:

Code:
ImportError: cannot import name '_linebuffer'

That result was misleading.

Before testing the installation, change to another directory:

Code:
cd ~

Then check where Python is loading each package from:

Code:
python3 -c "import pypilot; print(pypilot.__file__)"

python3 -c "import pypilot.linebuffer; print(pypilot.linebuffer.__file__)"

python3 -c "import RTIMU; print(RTIMU.__file__)"

python3 -c "import pypilot_data; print(pypilot_data.__file__)"

The installed Pypilot copy should normally be somewhere under:

Code:
/usr/local/lib/python3.11/dist-packages/

It should not point to

Code:
/tmp/pypilot

.

Resetting cached IMU detection

After installing the corrected packages, I removed the cached RTIMU configuration so that Pypilot would probe the IMU again:

Code:
cd ~

rm -f ~/.pypilot/RTIMULib.ini

sudo chown -R pi:pi ~/.pypilot

sudo systemctl daemon-reload

sudo systemctl restart pypilot_boatimu

Then I checked:

Code:
systemctl status pypilot_boatimu --no-pager -l

journalctl -u pypilot_boatimu -b --no-pager -n 100

Once IMU-only mode remained active, I enabled and checked the full Pypilot service:

Code:
sudo systemctl restart pypilot

systemctl status pypilot --no-pager -l

systemctl status pypilot_boatimu --no-pager -l

Failure 4: missing calibration boat and graphics

Even after the Pypilot backend and IMU were operating, the calibration window had another separate problem.

It displayed:

Code:
Vagabond.obj failed to load

No module named 'pypilot_data'

Did you add the pypilot_data repository?

This appears to be a problem others have also encountered.

In this condition:

The IMU may be working.
Calibration points may appear and move.
The 3D sailboat model may still be absent.

The boat model and related calibration assets are supplied by the separate

Code:
pypilot_data

package.

For a system where Pypilot is otherwise working, the missing model can be addressed separately:

Code:
sudo apt install -y \

  python3-opengl \

  python3-pyglet \

  python3-pywavefront

cd /tmp

rm -rf pypilot_data

git clone --depth 1 https://github.com/pypilot/pypilot_data

cd pypilot_data

sudo python3 -m pip install . --break-system-packages

Then verify the package from outside the source directory:

Code:
cd ~

python3 -c "import pypilot_data; print(pypilot_data.__file__)"

Reopen the calibration program:

Code:
pypilot_calibration

After installing

Code:
pypilot_data

, the

Code:
Vagabond.obj

sailboat appeared normally.

The full forced Pypilot installation:

Code:
sudo python3 -m pip install \

  --force-reinstall \

  ".[optimize]" \

  --break-system-packages

also installed

Code:
pypilot_data

on my older system. The separate procedure may therefore only be needed when Pypilot itself works but the calibration assets are missing.

Missing graphics versus an IMU failure

Calibration points do not appear or respond to movement

Investigate:

Code:
pypilot_boatimu.service
RTIMULib compatibility
I2C wiring and detection
File ownership or user permissions
The IMU itself
A stale

Code:
RTIMULib.ini
file

Calibration points move, but the boat model is absent

Investigate:

Code:
pypilot_data
Code:
python3-opengl
Code:
python3-pyglet
Code:
python3-pywavefront
The

Code:
Vagabond.obj failed to load
message

A missing boat image does not necessarily mean that the IMU or calibration data is failing.

GTK warnings

The calibration application also produced messages similar to:

Code:
Gtk-WARNING: for_size smaller than min-size

These appeared to be interface-layout warnings. In my case, they did not prevent live IMU data, moving calibration points, calibration calculations, or the 3D boat model from appearing once its files were installed.

Successful results

After the repairs, the logs showed messages including:

Code:
Detected ICM20948 at standard address

IMU Name: ICM-20948

IMU all sensor axes verified

calibration loaded

pypilot server listening

pypilotinit complete

The calibration interface showed live, moving points and the restored 3D sailboat model.

The Pypilot client also reported:

Code:
ap.modes = [compass, gps, wind, true wind]

This confirmed that the backend was running and exposing the expected steering modes.

What I believe this established

On my system, the repair established that:

The OpenPlotter Pypilot application opened.
The Pypilot Python package imported successfully.
The ICM-20948 was detected.
All IMU axes were verified.
Calibration was receiving live data.
The missing 3D boat model was restored.
The Pypilot server started and accepted client connections.
Compass, GPS, wind, and true-wind modes were available.

What it did not establish

This does not yet prove that:

Compass calibration is complete.
All magnetic interference has been eliminated.
The motor controller is fully commissioned.
The wheel drive has been safely tested underway.
Every command above is appropriate for every OpenPlotter installation.
A specific OpenPlotter update was definitively responsible for the original failure.

Pypilot worked on the older installation previously and stopped working after system updates, but I cannot identify the precise package or update that caused the breakage.

Conclusions

I encountered at least four separate but related problems:

The OpenPlotter Pypilot installation appeared to be missing required backend components or dependencies.
The available Debian RTIMULib binding was incompatible with the Pypilot source being used.
The previously configured system contained a broken or inconsistent Pypilot installation, including a

Code:
linebuffer
import failure.
The calibration window was missing its 3D boat model because

Code:
pypilot_data
had not been installed.

The key repair on the older installation was:

Code:
sudo python3 -m pip install \

  --force-reinstall \

  ".[optimize]" \

  --break-system-packages

The separate

Code:
pypilot_data

installation restored the calibration graphics when the backend and IMU were otherwise functioning.

Again, this is not my area of expertise, and this repair process was developed and worked through with the assistance of ChatGPT. I am posting it as a record of one successful repair and as a set of diagnostic clues, not as an authoritative or risk-free installation guide.

I would be interested to know whether others using

Code:
openplotter-pypilot 4.0.11-beta

have encountered these same messages:

Code:
MPU925xAccelFsr

Code:
cannot import name 'linebuffer'

Code:
No module named 'pypilot_data'

Code:
Vagabond.obj failed to load

Useful details to include in any comparison would be:

Raspberry Pi model
32-bit or 64-bit architecture
OpenPlotter version
Code:
openplotter-pypilot
version
Installed Pypilot version
Python version
IMU model
Relevant

Code:
journalctl
output

RE: PyPilot Broken After Updates and Repair Process - rdempsey - 2026-07-12

I have the same problem,.
Thanks for the deep dive.
Way beyond my current skill set though. I always end up breaking things .
Hopefully this will help with future versions !

RE: PyPilot Broken After Updates and Repair Process - rdempsey - 2026-07-12

I decided to try Anthropic Claude since I'm not a programmer.
Claude got pypilot up and running fine, but still couldn't see the imu.

It came up with this as the cause:

"That answers it definitively. Looking at the actual OpenPlotter pypilot GUI source, it directly does import RTIMU and calls RTIMU.Settings(...) — so this is a hard dependency, but it comes from a completely separate project: Sean D'Epagnier's own fork of RTIMULib2, not from pypilot's own repo (which explains why building pypilot's setup.py never touches it), and not from Debian's generic librtimulib7 package either (which pypilotPostInstall explicitly removes as incompatible, since it's the wrong fork)."

Here's the list of steps it gave me that solved this (I removed all the tests and stuff that didn't work, because it was LONG !)

1. Fixed the incomplete SignalK plugin install
npm install pypilot-autopilot-provider@1.1.2
(run from ~/.signalk — the app store had listed it as installed when it wasn't)

2. Fixed the missing swig dependency that broke pypilot's own build
sudo apt install -y swig
sudo apt install -y libgpiod-dev
sudo /usr/bin/pypilotPostInstall
(this rebuilt and installed the actual pypilot engine to /usr/local/bin/)

3. Enabled the systemd services so they'd start
sudo systemctl enable pypilot pypilot_web
sudo systemctl start pypilot pypilot_web

4. Removed the wrong RTIMU package (Debian's generic one conflicted with pypilot's expected fork)
sudo apt remove -y python3-rtimulib

5. Built and installed the correct RTIMULib2 fork with Python bindings
sudo apt install -y cmake libi2c-dev
cd ~
git clone https://github.com/seandepagnier/RTIMULib2
cd RTIMULib2/Linux
mkdir build && cd build
cmake -DBUILD_GL=OFF -DBUILD_DEMOGL=OFF ..
make -j4
sudo make install
sudo ldconfig
cd ../python
python3 setup.py build
sudo python3 setup.py install

6. Set the operating mode in the OpenPlotter GUI

OpenPlotter → Pypilot → Services tab → set mode to "IMU only" → Apply/Save

That last GUI step turned out to be the actual key to surviving reboots — OpenPlotter's own service manager was overriding the raw systemctl enable state based on its saved mode setting each boot.
Nice work sticking with this one — it was a genuinely deep stack of separately broken pieces. Fair winds with the pilot.

Everything works now !!!!
Hope this helps somebody else or points them in the right direction.
Cool