QuTech-Delft / QuTech-Delft/QMI
Make Pololu Maestro driver be possible to use in UART mode as well.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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