QuTech-Delft / QuTech-Delft/QMI

Make Pololu Maestro driver be possible to use in UART mode as well.

Open
#135 1 comment 0 reactions 0 assignees View on GitHub

@heevasti is already working on this.

Since Jan 5, 2026.

  • #175 by @heevasti — open
blocked enhancement
Dominant language
Python
Stars
25
Forks
9
PR merge metrics
No merged PRs in 30d

Description

Is your feature request related to a problem? Please describe.
The QMI Pololu Maestro device driver is now supporting the use of the device in Dual USB or Daisy Chain modes. These are not the default modes, but an UART mode is the default of the device. So, to use the driver, the manufacturer-provided GUI needs to be used first to change the mode.

First of all, this should be mentioned in our driver. The documentation should be edited to instruct the mode change for new devices. Secondly, we could enable the UART mode as well by selectively importing a separate class for UART control, or to make the driver smart enough to recognize or figure out which mode the device is on.

The original driver that was developed for Diamondos was based largely on the example of Maestro package's maestro.py. The umaestro.py is the UART version and looks very similar in function to the maestro.py.

Describe the solution you'd like
The UART control is rather similar to the serial-to-USB control through COM ports. We could create a special transport string that recognizes if we want to use the UART mode or not. Something like

if transport.upper().startswith("UART"):
    self._transport = busio.UART(board.TX, board.RX, baudrate)  # Possibly extract 'baudrate' from the transport string
else: ... # The current self._transport line

From the first look the existing _write and _ask functions could be used for both control ways without any or little modification. Probably the stumbling point here is the self._transport.discard_read() which does not exist in the busio.UART API. But we could extend the UART class in the driver to have this call OR use the reset_input_buffer with a little detour.

The board and busio modules, needed for this driver, should be "lazy imports" as we don't want more dependencies. They are part of a larger package, https://pypi.org/project/Adafruit-Blinka/.

Describe alternatives you've considered
Without digging deeper into the code, the assumption is that the rest of the driver API can stay the same. But if not, we can then make a base class Pololu_Maestro(QMI_Instrument) and derive the mode-specific classes from it Pololu_MaestroUsb(Pololu_Maestro) and Pololu_MaestroUart(Pololu_Maestro) and create in base class a selection method to which class to use when initialized. Specific selection of the child class should in that case also be allowed.

Acceptance criteria
The driver works also for the default UART mode, and only thing needed for that would be a modification of the transport string to start with "uart:" instead of "serial:".

Additional context
N/A

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the Pololu Maestro driver and its transport initialization, then inspect the existing _write, _ask, and discard_read handling. Compare the current serial path with busio.UART and the referenced maestro.py and umaestro.py examples. Done means the driver works in the default UART mode when the transport string starts with "uart:" and the existing API remains usable.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
embedded-iot
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.