Python on Raspberry Pi: Production Motor Control Tips with SOLO

Brushless Motor Torque Control with Raspberry Pi and SOLO in Python | HALL Sensors Mode

Introduction

Most Python motor projects on a Raspberry Pi work fine on the bench, then fail the first week in the field. The script runs, the motor spins, the demo looks great. Then a USB cable jitters, the serial port drops one byte, and the whole control loop hangs. Nobody is there to restart it.

This guide closes that gap. You already know how to send a command in Python. Here you get the production tips for raspberry pi motor control with SOLO: a clean SoloPy setup, communication code that survives bad reads, a control loop that never blocks on I/O, and a deployment that auto-starts and recovers on its own. If you only want the basic position-control code first, start with our walkthrough on Raspberry Pi brushless motor position control with incremental encoders, then come back here to harden it.

SoloPy on Raspberry Pi: Setup

SoloPy is the Python library that talks to a SOLO controller. On a Raspberry Pi it runs on top of the same packet protocol you would use over UART or CAN, so the setup is mostly about the operating system and permissions, not the code.

Install it with pip into a virtual environment. A venv keeps the project’s dependencies away from the system Python that Raspberry Pi OS relies on.

python3 -m venv ~/motor-env
source ~/motor-env/bin/activate
pip install SoloPy

The part that trips people up is permissions, not the install. Reading and writing a serial or CAN device needs the right group membership, otherwise the script fails with a permission error only when you run it as a normal user.

• For USB-UART, add your user to the dialout group: sudo usermod -aG dialout $USER, then log out and back in. The port shows up as /dev/ttyUSB0 or /dev/ttyACM0.
• For USB-CAN, bring the interface up with sudo ip link set can0 up type can bitrate 1000000. The SocketCAN device is then can0.
• Free the primary UART if you wire directly to the Pi header. Disable the serial login shell in raspi-config so the kernel does not own the port.

One more tip: give the device a stable name. USB enumeration order is not guaranteed, so /dev/ttyUSB0 today can become /dev/ttyUSB1 after a reboot. A udev rule that maps the adapter’s serial number to a fixed symlink like /dev/solo0 removes a whole class of “it worked yesterday” bugs.

If you build the Pi image from scratch, our notes on running SOLO on Linux cover the same driver and permission setup at the system level.

Takeaway: most SoloPy setup failures are permissions and port naming, so fix those before you touch the control code.

Choosing the Link: USB-UART vs USB-CAN

The physical link between the Pi and SOLO shapes everything above it. Both work with SoloPy. They trade off differently.

As a rule, reach for USB-UART when you drive one motor and want the shortest path to a working system. Choose USB-CAN when you have several drives, longer cable runs, or a noisy industrial environment where a differential bus pays off. Both are stable on a Raspberry Pi once the permissions above are set. For picking and wiring the actual adapter, our accessory guide on USB-to-CAN and USB-to-UART converters goes into the hardware detail.

Takeaway: UART is the fast path for one motor, CAN scales to many on one bus.

Writing Robust Communication Code

The single biggest difference between a demo and a product is what happens when a read goes wrong. On a clean desk it never does. In the field it will. Plan for it.

Timeouts and Retries

Never issue a blocking read with no timeout. A motor controller can reset, a cable can wiggle, and a read that waits forever freezes your program. Set a short timeout on every transaction, typically 50 to 200 ms, and treat a timeout as a normal event, not a crash.

Wrap each command in a small retry helper. Two or three attempts with a brief pause clears most transient glitches without hiding a real failure.

def read_with_retry(solo, getter, attempts=3, pause=0.05):
    for i in range(attempts):
        value, error = getter()
        if error == solo.Error.NO_ERROR_DETECTED:
            return value, error
        time.sleep(pause)
    return None, error

Validating Responses

Do not trust a value just because a read returned. SoloPy gives you an error code with every call. Check it before you use the data. A speed reading of zero is very different from a speed reading that failed, and your control logic must tell them apart.

For commands that set a target, read the value back when it matters. If you command 1000 RPM, a quick read-back confirms the controller actually accepted it rather than dropping the frame.

Reconnecting on Failure

When retries are exhausted, the right move is usually to close and reopen the connection, not to keep hammering a dead port. Wrap the link in a small object that can tear itself down and rebuild on the same device path.

def ensure_connected(self):
    if self.solo is None or not self.solo.serial_is_open():
        try:
            self.solo = SoloMotorControllerUart(self.port, self.address)
        except Exception:
            self.solo = None
    return self.solo is not None

A reconnect loop that backs off, for example waiting longer between each failed attempt, keeps the Pi from spinning the CPU at 100% while a cable is unplugged. When the link returns, the program picks up on its own with nobody at the keyboard.

Takeaway: timeout every read, check the error code, and rebuild the connection instead of trusting a dead one.

Concurrency Without Blocking

A control loop that shares one thread with slow serial calls is the most common reason a Python motor app feels laggy or stalls. The fix is to keep the loop that decides what the motor should do separate from the I/O that talks to the wire.

Threading vs Asyncio

For most SOLO projects on a Raspberry Pi, plain threads are the simpler choice. SoloPy’s serial and CAN calls are blocking, so a dedicated I/O thread fits the model naturally. You run the control logic on one thread and let the communication thread absorb the wait.

asyncio is a fine option if your wider app is already async, for example a web dashboard or an MQTT client. It is not required here, and mixing it with blocking serial calls adds complexity you generally do not need.

Separating Control from I/O

Keep the control loop at a fixed rate and never let it wait on the port. The pattern that works well on a Pi:

• A command queue: the control thread pushes targets, the I/O thread sends them.
• A shared state object: the I/O thread writes the latest measured speed, current, and faults; the control thread reads them.
• A timeout flag: if the I/O thread has not had a good response in, say, 500 ms, it sets a flag the control loop can react to, for example by commanding a safe stop.

With this split, a slow or failed read delays a status update by a few milliseconds. It does not freeze the loop that keeps your motor under control. That one change is what makes a Python app on a Raspberry Pi behave predictably under load.

Takeaway: run control and serial I/O on separate threads so a bad read slows a reading, not the whole loop.

Production Deployment

Code that survives bad reads still needs to survive a power cut, an SD card hiccup, and a reboot with nobody watching. This is the part most prototypes skip.

systemd Service and Auto-Start

Run your app as a systemd service so it starts on boot and restarts if it dies. This is more reliable than cron or an rc.local line, and you get logs for free.

[Unit]
Description=SOLO motor control
After=network.target

[Service]
ExecStart=/home/pi/motor-env/bin/python /home/pi/app/main.py
Restart=always
RestartSec=2
User=pi

[Install]
WantedBy=multi-user.target

Enable it with sudo systemctl enable --now motor.service. Restart=always means a crash brings the app back in two seconds, on its own.

Logging and Watchdog

Log to the journal so journalctl -u motor.service shows you what happened. Print every reconnect, every fault code, and every safe stop. When a unit misbehaves in the field, those lines are the difference between a five-minute fix and a guessing game.

Add a watchdog for the case where the process is alive but stuck, for example caught in a bad state where it no longer talks to the motor. The Raspberry Pi has a hardware watchdog. Pair it with systemd’s WatchdogSec= and have your loop ping it each cycle. If the loop stops pinging, systemd restarts the service. A hung-but-running process is then recovered automatically.

Read-Only Filesystem and SD-Card Wear

SD cards wear out, and a card mid-write during a power cut can corrupt the filesystem. Two habits cut this risk a lot.

• Mount the root filesystem read-only, or use an overlay filesystem so writes land in RAM. Raspberry Pi OS ships an overlay option in raspi-config.
• Send logs to RAM or the network, not to the card. Constant logging to the SD card is a top cause of early card failure.

For a unit that must come back after every power event, a read-only root plus a systemd service plus a watchdog is a combination that simply restarts and keeps working.

Takeaway: a systemd service, journal logs, a watchdog, and a read-only root turn a fragile prototype into a unit that recovers by itself.

Mapping to SOLO Commands

Your Python code talks to SOLO through a small set of control modes and setters. The exact call names live in the SoloPy reference, but the model is the same across links:

• Set the mode: torque, speed, or position control.
• Set the command type: analog or digital. For Python over UART or CAN you use digital.
• Write the target: a current, a speed in RPM, or a position.
• Read back: measured speed, current, bus voltage, and any fault code.

If you drive SOLO over CANopen and want the standardized CiA 402 drive profile, with its modes of operation and object dictionary, that is a topic of its own. Our guide to the CiA 402 profile with SOLO covers the state machine and objects so your Python code maps cleanly onto a standard motion profile.

Takeaway: pick the control mode, write digital targets, and read back the result every cycle.

How SOLO Supports Python on Raspberry Pi

SOLO controllers are built to be driven from a host like a Raspberry Pi, and the SoloPy library is part of that. It exposes the same control modes and feedback over UART and CAN, so the robustness patterns in this guide, the retries, the reconnect, the separate I/O thread, sit on top of a stable protocol. The controllers support DC, BLDC, PMSM, and AC induction motors with the same Python API, so you can reuse your deployment across motors instead of rewriting the integration. If you want the libraries, code samples, and documentation in one place, the SOLO resources page is the starting point.

Conclusion

Production raspberry pi motor control in Python comes down to four habits. Set up SoloPy with the right permissions and a stable port name. Write communication code that times out, validates the error code, and reconnects instead of trusting a dead link. Keep the control loop on its own thread so serial I/O never blocks it. Then deploy as a systemd service with logging, a watchdog, and a read-only root so the unit recovers on its own. Get those right and the same script that ran on your bench will keep running in the field. When you are ready to wire it up, the SOLO resources page has the SoloPy library and the code samples to start from.

FAQ