OpenServo software feature requests

As the OpenServo platform develops, we hope to bring more features for a more diverse application use. This is a partial list of features requested in the OpenServo forums. This list is by no means a roadmap or a list of features likely to be implemented.

Input:

• PWM

  • Allow R/C PWM input to control the OpenServo. -Implemented and Completed 12/01/07

• Analogue

  • Analogue 0-5v input for control of OpenServo

• CAN
• Serial control

Sensors:

• Encoders (single)
  • Used for servos modified for continuous rotation. This is useful when the Potentiometer is not used.
• Quadrature encoders

  • Allows a phased quadrature input to set the position of the OpenServo .

• Hall Effect sensors.
  • Similar to encoder input, but instead of being an optical solution, is a magnetic solution. One proposition is to attach a Hall Effect Sensor to the motor in the servo, and measure the pulses.

encoder discussion:

• "encoder support: wrapping up my quadrature encoder modification for OpenServo".

• Hobby-Servo Encoder Retrofit

• servo motors with sensors

• Position Sensor Location

• Encoder support

• OpenServo controlling Gear Head Motor

Bootloader:

• Stop from defaulting to bootloader.
  • Change the bootloader structure to not boot directly into the bootloader
• change from any data to interrupt to magic cmd interrupt.

  Currently the OpenServo interrupts into the bootloader mode when any data is written to it. In the case of broadcast packets, and automated control systems, this is a bad idea. The bootloader should only interrupt when it is addressed at a specific register address

• Shared I2C address

General:

• bezier speed control -Implemented and Completed 12/01/07

  • Motion control profiles using bezier curve points. This will allow long motion profiles that control precise servo movements.
• broadcast multi servo sync

  • Allow OpenServo to initiate movement commands on certain broadcast packets to allow for uniform movements. -Currently in -dev branch. Slated for next major release

• scripting

  • Allow small scripts to be uploaded to the OpenServo platform. This could be as simple as performing actions given certain contraints, like current sense.

• Auto tuning PID. "PID auto-tuning" discussion thread; "the system is nonlinear" discussion thread; "how to tune a PID controller".

• test mode http://openservo.com/Forums/viewtopic.php?t=100

• servo corruption checker
  • A watchdog process that checks for data and eeprom corruption. Reverts back to safe known values on corruption.
• data sanity checking
• Motor current cutoff

  • Cuts off or throttles PWM to the servo when current reaches a programmable threshold (KevinBlack: presumably not the instantaneous current? - (Barry Carter - No, the average current which is sampled over 70ms or 7 samples)). -In -dev branch awaiting shakedown and tuning

• programmable PWM slew rate
  • Allows the servo to get up to speed in a sensible way, without destroying any hardware in the process.
• temperature sensing

  • Checks for MCU and motor temperature. Implemented in Version 3 hardware. In -dev branch. Slated for next major release

• User writable “identity” word. -In v3 dev branch. Slated for next release

• Writeable, stored values for parameters of the OpenServo board. For example this would include: board version, clock frequency, voltage regulator (5V vs. 3.3V), voltage divider resistor values, etc.

• Continuous running averages for measured values (e.g. battery voltage and current)- for example the average over the last 2 seconds every 100ms (sensible periods to be determined, although this may be parameterised). Computing these values should not require the vast amount of storage that might initially be supposed. Possibly implemented as new registers, so that existing values can still be accessed.

Running current average in current codebase.

• Power consumption measurement (this might have to be estimated from congruent measurements of voltage and current).
• Voltage, current and power values returned as “real units” (e.g. 4980 for 4.98 volts): needs stored parameters above. Possibly implemented as new registers, so that existing raw values can still be accessed.
• NOTE: A possible caveat of using real unit values is the issues that could arise from having different values for some components on the board. For example, 10K or 20K ohms for R6 on the V3 board. However, this is overcome if the "configuration" can be stored on the servo and updated by the user, as described, but it would require the user to do this to ensure correct operation.

Communication:

• I2C checksum - I2C checksum is already in code base but needs more development

see also

* Hardware Feature Requests