The encoder provides a capability that I believe is not well understood in contr…ol systems. First some background:
- Control loops take in a commanded desired position or motion and read the current position (hopefully of the output shaft / joint rather than the motor shaft) then send commands to the motor driver (irrespective of the type of motor / driver) to correct the error; bringing the joint to the desired position or motion.
- Standard control loops, in order to accomplish this goal effectively, need to account for the physical attributes of the load, such as inertia, friction, etc... For example the I and D terms in the standard PID loop compensate for ongoing positional error (Integral) and future overcorrection (Derivative). Feedforward, input shaping, etc... all need to understand those attributes accurately in order to compensate for them.
- Robotics, especially, make understanding the physical attributes nearly impossible, because they keep changing. Picking up a load, changing orientation, etc... all completely rearrange the control system inputs making tuning a nightmare. This is true for many applications, but not all. e.g. input shaping is great for cartesian 3D printers because the load isn't changing. But on a router, the load when cutting is not the same as the load when doing a rapid.
- A control loop that doesn't need to understand the load is valuable. The Dexter robot appears to have that control system. It only has one primary adjustment. Although there are many other parameters which can be set for e.g. digital friction, max error, beta, etc... the only setting commonly used was the PID_P. And yet, the arm was able to accommodate a wide range of positions and loads with precision. When gain scheduling of the PID_P setting was enabled in firmware, the response was rapid. And yet, oscillation was avoidable.
## Good Tracking w/o Complex Control
Why don't the joints on the Dexter robot oscillate over a wide range of loads? Good question. I've spent years trying to understand it. I think there are two answers:
1. **Rate vs Force output** The output goes to a rate generator which steps a stepper motor. Most PID systems send a voltage to a DC motor. This represents a _force_ based control vs a _velocity_ based control. This makes the I term in the PID control redundant. The output as a velocity just regulates the speed of the correction; faster when the error is large, slower as the error decreases, but never going to zero until the position is perfect. Compare that to a force based output, where there is no force unless there is some positional error. This allowed lower PID_P settings, while still providing complete reduction of positional error.
2. **Encoder sensitivity** The need for a D term (derivative, prediction of the future) or other "thinking ahead" type compensations increases as the _time_ required for the control loop to react increases. If your control loop is slow, you need better predictions to avoid under or over compensation. But the converse is also true: If your control loop is fast, you don't need to rely on those predictions as much. You can compensate for an error quickly, before it gets out of control. I was told for years that the FPGA is what made that speed of correction possible, but recently, I've had a revelation: _The time it takes for a change in position on the joint to be reported by a low CPR encoder absolutely swamps any other time delays in the system._ It's the `encoder` having a stunning CPR (over 100,000 CPR) that speeds up the loop!
To validate (or disprove) this idea, I need a better physical rig for testing: One that has not only an encoder operated by hand, but a full joint with links to attach loads, a transmission, gearbox, motor, and motor driver. And if that's going to happen, there are some features I think it should have:
## Mechanical Design
- **Passthrough** Not a joint shaft, but a tube, with a space in the center to pass through wires, air, optics, or whatever. The larger diameter also helps with stability.
- **Enclosure** A strong metal box which the rotating tube passes through which can contain the encoder disk and sensing electronics which protects them from _electrical noise_, _optical interferrence_, _dust_, and _mechanical damage_. These are the weakest, most sensitive parts of the joint and the wires and disk were always getting damaged, gunked up, and the signals were noisy. This noise might be important, but controlling it is best; it can be added back on purpose if needed. This box would be easy to mount the lower link to and would need to hold the tube securely without mechanical slop in any dimension. Mechanical deformation and slop was a horrible problem on the robot.
- **Cross roller bearings** To mount the tube to the box, 45 degree "cross" roller bearings or needle bearings are important to avoid slop in any dimension. Standard bearings do not manage axial load well.
- **Flange** To attach the upstream link, the tube needs a strong, large, flange on either end.
- **Agnostic drive coupling** The method of driving the joint constantly changed during the design of the robot, but was always inbuilt into the design, meaning any change required re-design. Instead, the outside of the tube flange should support attachment of any of the following: Pulley, sprocket, cable spool, bevel gear, driven worm gear, etc... Outer mounting will make changing this simple.
- **Separate drive** Instead of including the electrically noisy, dirty, and heavy motor and gearbox in the joint box, they should be mounted in a separate metal box, which is easily attached directly to the joint box, or separately mounted along a link. This box should contain the motor, motor driver, power connections, control connector, gearbox and an output shaft with matching flange for all the above mentioned drive transmission possibilities.
These design requirements seem clear to me, and are based on many years of experience in the field; watching what goes wrong, and wondering why the obvious issues aren't addressed. Usually, a lack of time was blamed.
Having said that, these mechanical goals are (likely) beyond my ability. I am not an ME, and my fabrication skills are minimal. To that end, I would deeply appreciate any offers of collaboration. Either to help me understand why my goals are wrong, or to design and fabricate a working system. Coupled with the (now) working Ras Pi Pico based encoder design, I firmly believe this could be a game changer in robotics in general, and open source hardware specifically.