QPIDfirmware  v0.1
Object oriented firmware for autonomous motor drivers with encoder based PID controller and flexible interface
QPID firmware - Autonomous PID and encoder controlled motor driver

This is the QPID firmware framework for the Arduino IDE. It is built on the object oriented QPID class hierarchy for Arduino supported microcontroller platforms. The firmware acts as an autonomous, PID controlled motor driver for up to 16 units of a motor with rotary encoder and up to two endstops, which receives commands remotely from some master device. Typical commands are 'run to position x', 'run at speed y', 'run to endstop', or self-calibrate'.

The system is designed with maximum flexibility in mind. It is meant to be able to support any kind of sufficiently powerful µC with Arduino support (ESP32, ATmega...), any kind of communication protocol (I2C, ESP-now, SPI, UART, Bluetooth...), any kind of motor (DC, stepper, brushless motors...), any kind of rotary position sensor (quadrature or single pulse encoders, potentiometers, angular hall sensors...), and any kind of endstops (digital, pinshared analog, I2C io expander...). Of course, mileage may vary. The actually available features and performance will be limited by the specific combination of hard- and software. At the moment many of the mentioned variants are not implemented yet. However, others can be easily implemented by adding a newly derived class to the QPID class hierarchy.

Note
Under construction. Everything documented here is preliminary and subject to testing. For testing purposes, much that should be private is public, so do not expect to find all details explained. Much is already working, proof of concept for everything but the message/communication system is there.

QPID was created originally to develop an autonomous controller solution for the fischertechnik construction toy system (see this tread), but can be adopted for other usages as well.

Terminology
  • QPID system: a microcontroller running the QPID firmware which can control up to 16 QPID units.
  • QPID unit (implemented in class QPID_Unit): a combination of one motor driver, one rotary sensor and up to two endstops which is connected to a QPID system and can perform autonomous tasks like 'run to x' etc.
  • QPID subunit: A QPID unit's motor driver, encoder, or endstop. Usually, a subunit's hardware has to be implemented in c++ as a QPID class derived from one of the generic classes QPID_MotorDriver, QPID_Encoder, or QPID_Endstop.
  • Master: a device which sends command messages to a QPID system and receives status messages via any of the implemented means of communication (I2C, ESP-easy...).
  • Client/Slave: a QPID system receiving command messages and sending status messages.
  • Message: a byte stream with predefined format containing commands or status reports. Command messages sent from the master can be directed to the QPID system, one of its units or one of a unit's subsystems. Only the QPID system (not one of its units or subsystems) can send status messages back to the master.
Practical usage
  1. Adapt the firmware for your specific demands. Depending on the kind of motors, encoders, and endstops you plan to use, use existing subunit classes or add your own for subsystems not supported yet. Use an already implemented communication protocol or implement your own.
  2. Build and upload the firmware for your platform.
  3. Build your hardware setup: Connect motor drivers, encoders, and endstops to µC

Usage from the master's viewpoint is as follows:

  1. Establish a connection to the QPID system with one of the supported communication protocols, e.g. ESP-now.
  2. Send a message for each QPID unit to initialize. For each QPID unit, the system needs to be informed about the type of motor driver, encoder, and endstops it uses.
  3. Send a messge for each units' subunit to initialize/configure. Depending on the kind of hardware used, subunits need to be informed about which pins to use, or specific features like ticks per revolution for encoders etc.
  4. After that the system is ready to receive regular command messages like 'run to x' etc. which it will perform autonomously and send status reports as requested by the master.

    Todo:

    check private, protected, public for all classes

    check use of 'override' for all derived classes (because in c++ everything* that makes more fool proob is either optional or not available at all)

Author
Copyright (c) 2021 juh
License
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.

QPID logo courtesy of Muhamad Ulum, ID licensed under a Creative Commons Attribution 3.0 United States license