Making a test joint to validate control loop improvement

[JamesNewton]

The encoder provides a capability that I believe is not well understood in control 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.

[cfry]

Just a nit pick:
"the load when cutting is not the same as the load when doing a rapid."
should probably be
the load when cutting is not the same as the load when doing a rapid motion.

[JamesNewton]

Ideas for test hardware:

• "Cheese plates" are basically cheap, little optical breadboards for camera gear. An easy and portable platform for building.
• Plumbing "faucet extension adapters" are available with threads on the outside and about a 1/2 inch hole in the middle. They also have flange(ish) nuts which should work to hold the encoder disk and perhaps pack the cross roller bearings into the sides. I also found these generic extender pipe adapter parts "BSP 1/2" 14mm ID, 20mm OD, but only from the one source. I think these flange nuts will work with that stock very nicely. Not sure how to keep them centered in the bearings; a "ramp" on the ID of a nut which drives into the center of the bearing? A 3D printed adapter might not be horrible, if it's not thick. I can't seem to find an industrial source for a tube (not a rod) threaded on the outside. McMaster has "Hollow Threaded Stud" but the threads stop in the middle.
• Crossed Roller Bearings are /crazy/ expensive. It might be worth starting with bushings, but I really want to avoid stiction as it messes up the graphs. Perhaps the best option is combining a standard roller bearing with a flat thrust bearing as these are not terribly expensive. For example, these flat needle bearings should fit the generic pipes mentioned above. And 20mm ID bearings are common e.g. these should also fit and are low cost.

[cfry]

"Crossed Roller Bearings are /crazy/ expensive." Is this due to current supply chain issues or that's always been true? If the former, not so bad for a few to experiment with but long term, you know I like low cost.

…

On Sat, Dec 21, 2024 at 1:55 PM JamesNewton ***@***.***> wrote: Ideas for test hardware: - "Cheese plates" are basically cheap, little optical breadboards for camera gear. An easy and portable platform for building. - Plumbing "faucet extension adapters" are available with threads on the outside and about a 1/2 inch hole in the middle. They also have flange(ish) nuts which should work to hold the encoder disk and perhaps pack the cross roller bearings into the sides. I also found these generic parts <https://www.ebay.com/itm/186674139277>, but only from the one source. Not sure how to keep them centered in the bearings; a "ramp" on the ID of a nut which drives into the center of the bearing? I can't seem to find an industrial source for a tube (not a rod) threaded on the outside. McMaster has "Hollow Threaded Stud" but the threads stop in the middle. - Crossed Roller Bearings are /crazy/ expensive. It might be worth starting with bushings, but I really want to avoid stiction as it messes up the graphs. Perhaps the best option is combining a standard roller bearing with a flat thrust bearing as these are not terribly expensive. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJBG7NNQNQ3SQBKZ6VOCUT2GW2QVAVCNFSM6AAAAABTU4AGWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGIYDIMRSGA> . You are receiving this because you commented.Message ID: ***@***.***>

[JamesNewton]

Thanks to the promise of a kind donation, I've ordered the bearings listed above. I'm looking for a local supplier of the ebay threaded tubing and flange nuts, but I'll probably just order those as they are not expensive and /sometimes/ stuff from China comes quickly, but if I order it now, it will get here before the end of time.

I'm still looking into components for the box. Some of these "cheese plates" have holes on the /edges/ which means they could be attached as the /sides/ of a box made with a cheese plate bottom.
https://www.amazon.com/CAMVATE-Cheese-Monitor-Mounting-Socket/dp/B0918YTKLS/ref=sr_1_25

Here is another, larger, one, which could be the base plate, but with holes on the side where a smaller regular plate could attach to make the sides. 
https://www.amazon.com/dp/B06XXLWYK7/ref=sspa_dk_detail_3 

And then maybe just a sheet steel or clear plastic cover on top. For the final product, it should be a closed up box to avoid light pollution and dust, but for a demo / development version, it's fine if it has holes and lets some light / dust in. The holes won't admit electrical noise (faraday cages are often just metal screens). 

[JamesNewton]

The "Generic Pipe Adapter" has an OD slightly larger than the ID of the bearings, so to grind down those threads, the old trick of spinning it with a drill while grinding with a dremel is used. Chucking the pipe isn't possible in a simple drill, or drill press (it would need a lathe chuck) so a 3D printed spindle adapter can be used:

Note that the fn parameter is reduced on the outer diameter to provide high points which can be mashed down, and set to 6 on the inner diameter to mate with a hex drive. Then a philips or star bit can be inserted with the hex drive in the plastic, and the (round) bit shaft in the drill chuck.

// title      : Tube Turning Spindle
// author     : James Newton
// license    : MIT License

var len = 10
var dia = 14.65
var taper = dia * 3/100 //percent taper
var fudge = 0.16 //width of extrusion.

function main () {
  return difference(
      cylinder({
          r1: (dia+taper)/2
        , r2: (dia-taper)/2
        , h: len, center: true
        , fn:20 //reduce resolution to provide compression ridges
        })
    //use this one for a hex drive
      ,cylinder({r: 7/2+fudge*2, h: len, center: true, fn: 6})//.translate([0,0,len/2])
    //and this one for a smooth shaft drive
    //  ,cylinder({r: 7/2+fudge*2, h: len, center: true})//.translate([0,0,-len/2])
  ).translate([0, 0, len/2]);
}

I ended up using a wood bit with a round shaft and a hex end which chucked nicely and allowed me to support the cylinder at both ends with the bit in the workbench. That combined with the dremel to get it close and a flat file to finish. Video in the photo album:
https://photos.app.goo.gl/QqwU3tJMakaB3hPU9

Next is to get some cheese plates and figure out how to drill out the larger holes for the tube / shaft.

[JamesNewton]

I've realized that finding a cheese plate with a hole large enough to support this tube is not going to be possible, so I'm switching to using pillow bearings. These have a nice set screw and are the same size ID.
https://www.amazon.com/dp/B0BTNCJV47
I think I can more easily hack out the slot in the bottom of this cheese plate so the encoder disk can dip down into it
https://www.amazon.com/dp/B06XXLWYK7
or raise these a bit with something on the side, like these maybe:
https://www.amazon.com/dp/B01NCK79G2
by hacking them up into smaller blocks and stacking them.

I really wish there was a competent fabricator in the area who could work with metals. I don't want to use plastics because plastic is plastic, and I want something stiff to ensure I'm really reading the position of whatever link I connect and not the deformation of the joint mount.