Failed piston design: ODrive + pneumatic ballast

I've been playing with piston deigns for my planned Stewart platform motion sim. This was put together a few years ago, but I thought I'd share so others might learn from my lessons.

The final result after the final test: (not everything is in one piece)

I wanted to use readily-available and inexpensive strut channel for sliding components and a pneumatic ballast (think elevator counterweight in air form) to offset the static load on the piston so the motor (primarily) doesn't need to spend energy keeping the user up in the air.

I started with a brushed DC motor, an encoder, and a RoboClaw:


But ended up switching to an ODrive, a BLDC motor, and a CUI encoder.


I also added some big caps to smooth out power draw and added some diodes to keep regenerated power from backfeeding the power supply:


The trolley design was a pain. It needed to be strong, fit well, and slide well inside strut channel and there's not a lot of room to fit things in there. It went through a number of iterations:


BTW, do not ever let a ball screw come off the end of the assembly. It is an amazing pile of a royal pain to put back together. If the retention ring at the end doesn't really seem like it's retaining right, it probably isn't. (The groove was too narrow, so it didn't do its job.)


There were two main pieces of strut channel. One housed the ball screw and rode the ball screw nut. The other held the fixed end of the ball screw.


The ball screw I was using is longer than I want for my final project, but the exact length for testing wasn't too important.

Real pistons are expensive, so I made my own. I just needed a relatively simple single-acting piston.


Piston at about 100psi:


By the way, don't use PVC for pressure vessels like this! If it ruptures it can send sharp plastic shards flying at you! Use a different material!

Careful smoothing of the 3d-printed plunger (including sanding and then acetone-smoothing the ABS) before adding the o-rings really helped the seal. And o-ring grease really helped it slide well. It was fairly simple and worked pretty well.


Using a somewhat complicated setup of bolting the piston to my climbing wall, along with some wire rope and pulleys, allowed me to load test a single piston in isolation.


This image is from an earlier iteration before changing to a wire rope and some other tweaks, but it helps show the test layout:


And I did some testing (iteratively, in fact, with other things mentioned above).

Notes/things learned from testing:

• Strut channel has terrible tolerances, and that's a problem when you need things to slide smoothly within.
• Inside strut channel is small, and is hard to design a strong trolley for. Using metal for the core strength was good.
  
• Strut channel is noisy. Dragging a bolt along the back from my prototype trolley design certainly didn't help.
  
• A 1605 (5mm per rotation) ball screw is too shallow for my goals (~1m/s). You need a really high RPM, and, even with an appropriate motor, vibration may start to become an issue.
• DO NOT LET YOUR BALL SCREW NUT COME OFF.
• Customizable firmware is nice. I was able to add firmware-level e-stop support to the ODrive. I also fixed some issues with the regenerative braking and shunt resistor. Too bad ODrive, I hear, has decided to abandon openness...
• ODrive PID tuning is a pain and even when it's decent it's not quite what I'd like. And the "write Python code to do a move" interface is quite a pain.
  
• Despite its shortcomings, the ODrive and BLDC motor did fairly well.
• Even unloaded, the ODrive, brake resistor, and BLDC got fairly hot or hotter, though! Unloaded!
• Force imbalance is bad. The piston acted at the side of the ball screw, producing a torque on the the device as a whole. At pressure you could see things bending from the forces.
• Having a functioning e-stop, even at this early stage, is good to have. Also, convenient.
• Don't buy parts for everything until you have a good design nailed down. You just might want to redesign everything (again).

After a number of tests, decided to give it a try with my full weight. Nominally, one piston on a Stewart platform would handle roughly handle 1/6 the load, but I decided to go big. With the air pressure set right, there "shouldn't" be any big difference to the motor except during accelerations.

Anyhow, I tried moving up and down with successively harder and harder accelerations until part of my testing rig tore apart, ripping three t-nuts out of the OSB climbing wall. It then proceeded to bean me in my PPE-covered face, drop me a few feet to the floor, then, without a load, the pneumatic piston blasted the arm up into the end bearing, ripping it to shreds.


To quote GLaDOS regarding test results: "Results were highly informative: [It] could not."

How were you switching the pnematic pressure ?

What did you use to track actuator position ?

There's no automated air handling at all for this test build, I set the compressor up to output my target PSI and opened a valve by hand. (Pretend the blue compressor hose is attached to the fittings on the white pipe in the image below.)


Automatically adjusting the pressure and disconnecting the ballast for getting on/off is the sort of thing I put off for the "real" build.

It's a small little encoder made by CUI Devices that fits around the motor shaft. Specifically, it's an AMT132S-V. You can see it in a few of the pictures above, just in front of the red BLDC motor. The ODrive takes the encoder signal directly. (And wiring the connector on the encoder is kind of a pain.)

I was reading through my notes on the motor current and forces. Hehe, I forgot about this:

- 10A->32kgf
- 30A->100kgf
- 60A->202kgf
- 65A->220kgf
- 120A->Snapped the rope, but I think it read over 500kgf at one point

So, that's why I switched from a general purpose rope to a wire rope.

For reference, the BLDC motor is (I believe) 250kv, and that's with a 1605 (5mm per turn) ballscrew.