With regards to the bottom motors, my biggest concern with using external encoders is the possibility of a runaway condition where the motors spool out all its rope because there’s not enough tension on the rope to make the encoder spools turn. For example, in an upward move of the sled, the top motors will be reeling in rope while the bottom motors are letting out rope. But if the bottom motors let out more rope than is reeled in by the top motors, then slack could develop on the bottom ropes. If there is enough slack that there is no friction between the rope and the encoder spool, the encoder won’t turn and the PID controller will apply more power to the bottom motors, resulting in more rope being spooled out. I’ve seen this occur on the top motors when the encoder spool binds up and the encoders don’t turn… the sled drops real fast… fortunately, it stops when the time runs out on the move so I’ve never crashed into the floor. I believe the condition could easily happen (and maybe likely to happen) because the top motors need a lot more power than the bottom motors as they are supporting all the weight and the PID controller may not account for it.
So I’m considering the following possible solutions:
Use different PID values for the bottom motors so its slow to start and always develops/maintains some level of tension. Might be wishful thinking, but I was thinking that attaching a small piece of bungie cord at the end of the rope so that there’s always some tension might work and the error might be small enough to work with.
Use the motor encoders as well as external encoders and detect conditions when a certain number of turns of the motor doesn’t result in any turns of the external encoders. The teensy 3.5 has plenty of pins so this wouldn’t be an issue. But it might be challenging to figure out what to do… do you stop the motor briefly? Do you reverse the motor to pull in the slack?
Use only the motor encoders. This can be accomplished three ways:
a) Calculate how much rope is spooled based upon encoder reads. I’ve found a webpage that provides a mathematical solution to calculating the length of material wrapped around a spool in a spiral pattern. The exact solution requires an iterative function and the teensy 3.5 has a lot of horsepower (though not sure if enough).
b) If performing the calculations within the required time period is a challenge, then create a calibration curve to retain in memory using an external encoder. Basically, set it up to read both the motor encoder and external encoder, tell the motor to start spooling out cable and by hand (or some other setup) apply tension to the rope so it always turns the external encoder. Log the two encoder readings as the rope is spooled out and then store it. Use those values as a lookup table to eliminate the costly iterative math calculations.
My original plan was to do 3.a. but I worried that the encoder resolution would not be high enough because the spool’s diameter for even 1/16-inch rope, can get large (~100 mm). At 8113.7 ppr and ~ 314 mm circumference, each pulse = ~0.04 mm. We currently are using a ~0.008 mm per pulse value (I think I’m calculating this correctly)… about 5 times more resolved. This is why I went to external encoders for the top motors. It might be sufficient for the bottom motors, however, since all they are trying to do is keep the sled vertical. But both solutions require that the rope wraps neatly and consistently on the spool. Since there’s not a whole lot of tension on the rope (as is the case with the top spools), it might just do that.
- Use different spools on the bottom, perhaps with a level winder, that lets out a consistent amount of rope per turn. The spool would need to be shaped such that diameter is different at the top and bottom than it is in the middle to account of the difference in distance between the encoder spool and the rope’s spool as the rope winds up/down on the spool… if you follow. However, a constant diameter spool can be used if you come up with a calibration, like in 3B, or you account for it with math, like in 3A.
Anyway, that’s where I’m at and am trying to determine the best route (besides the alternatives of measuring sled orientation using an orientation sensor or something). I likely will start with Option 1, since its the easiest to implement, and see where it goes.