After many, many long months, lots of reworks, failed attempts, yada yada yada, I finally got my self-contained sled design using four motors running “half-decently” (i.e, only two motors are connected…so half). The premise is that by using motors at each corner of the sled, you can:
Keep the sled vertical, thereby allowing simplified math using quadrilateral kinematics
Improve performance in bottom left/right corners because there are motors pulling it into the corner.
I don’t have the two bottom motors connected because:
One of my motors has a damaged gear and I’m trying to find where I put the spare gears I bought.
I’m afraid I’ll rip the machine apart accidentally by turning the motors the wrong way.
I’ve spent a lot of time working on getting external encoders to work and there’s plenty of improvements that need to be made. I tried to do everything with laser cut MDF and COTS items like bearings, D-shafts, etc. I’m thinking that the mounts that hold the encoders might need to be cut from metal or something stronger than MDF as I’m not sure how well the MDF is holding up under the enormous stress I’m applying to it.
PID tuning I believe will be a challenge as the current design has spools that change their diameter as cable wraps up on it. I try to keep the cable wrap neat (single layer on top of each other) but the forces are so high that it warps the 1/4-inch MDF resulting in an uneven wrap. I might switch to a different spool design and see how it works.
The video below shows the sled moving “5-inches” around a square. The machine isn’t close to calibrated, so it could be 10 inches for all I know. And if curious, that big 18-inch circle that is attached to the sled is an old stock sled that I use to help the machine move. It’s terribly unbalanced without the bottom two motors attached.
I thought about that trying to do that where the wires mount to the frame brackets for testing purposes… There’s a great deal of tension on the wires… you can strum them like a guitar.
When I do hook up the bottom motors, I plan to add some bungee cord between the carabiner the wire is tied to and the bracket/mount (I use the old quadrilateral L-brackets) so if this start to go bad, it’ll stretch for a bit and maybe avoid ripping something apart.
What do you mean? The only real changes to the firmware (besides working with a teensy 3.5) is that it handles four motors and uses a simplified quadrilateral kinematics calculation which assumes the sled is perfectly vertical.
That if you move down, the 2 top motors are synchronised with the 2 bottom ones, just that they are reversed in direction.
I first thought of 4 motors with 4 chains
Guess the concept is more 2 motors for coordinates and 2 for keeping the sled horizontal?
It’s designed such that all four motors turn such that the amount of cable extended from each puts the sled in the correct position and aligned vertically. Each of the four “chain lengths” are calculated separately. But in the actual implementation of it, I think you are correct. What I suspect really happens (or will happen) is that the top two motors will position the sled and the bottom two motors will align the sled. I say this because all the weight rests upon the top two motors as the frame is vertical. If the frame was horizontal, then all four motors would be involved in positioning the sled.
I have wondered about a setup where the top two motors position the sled, and the bottom two motors are connected to some sort of force measurement. The bottom motors then just try to maintain an appropriate level of tension. That would mitigate concerns about pulling the sled apart.
I don’t know if I can ever achieve a high level of accuracy/precision with this setup. It’s very experimental.
As it depends upon keeping the sled vertical, the lengths of the bottom two motor wires are just as critical as the top two. I had bought an MEMS orientation sensor to hookup and was thinking about writing code that would adjust the position of the bottom motors such that the orientation remained vertical. But as I dug into it more, I found that the accuracy of these things was actually pretty poor in a dynamic environment… +/- 2 to 4 degrees… that’s a lot of error for a quadrilateral arrangement. Fine for a drone maybe, but not so for Maslow. I’m hoping just calculating the wire lengths work better. If all fails, I can do an arrangement like Maslow Mark II and mechanically constrain it to be vertical.
Another approach was proposed by @slomobbile. I had wanted to test this idea out, but have not gotten to it. It would still suffer from some of the issues at the top center and bottom corners.
Wed, 03 May 2017 17:44:37 Quadrilateral had the biggest error under 4mm for me over this 15 squares.
I was thinking of balancing the sled with 1 additional motor moving a 3rd weight horizontal left/right to keep the sled horizontal. But that would move the bit to a different position. The tilt of the sled was calculated in the firmware and that was before we had chain sag and chain stretch.
Yeah… I think the move to triangular kinematics was intended to overcome the complexity of calculating what the sled tilt was. I imagine it was one thing in a static environment and something else in a dynamic environment.
I’ve been off the site for a bit because we got a timing belt gantry router that has been getting all the love. But when I got this notification, it got me thinking of ways to test(quantify) improvements to accuracy. Not necessarily on a per unit basis, but to compare code improvements or geometry changes. What we need is efficient accurate position feedback.
Remember those big old electronic drafting boards with the mouse that has crosshairs inside a coil? There is a grid of wires inside the drafting board that picks up induced current from that coil to get pretty accurate realtime feedback. They were often used to digitize paper blueprints by clicking on a bunch of points on the drawing. I forget what they are called, digitizer maybe. Haven’t seen them used for an age but I have one in the barn. Not sure if it works and the mouse is AWOL. I’ll dig it out if anyone has interest.
If someone else has one, route a spot in your sled for the mouse and lay the board on your spoilboard to bet feedback.
For those interested in how the external encoder is implemented, this is the current design of the pillar (top right pillar has been done this way and will be changing all other pillars to match):
The 1/16-inch spectra rope wraps around the inner part of the spool… I ‘textured’ that part to help it bite… this might not be needed in reality, but better safe than sorry. My first attempts involved wrapping the rope around the spool two complete times (like a capstan) but the results were horrendous… the rope kept overlapping on itself binding everything up. I spent months (on and off) trying to combat that and finally realized that all it needed to do was turn the spool and just a partial wrap works fine…
My biggest concern right now is the longevity of the 1/8-inch MDF spool parts. Though everything is laser cut, the D-shaft slot is not perfect and there’s a little wiggle room… which I think will likely expand over time. So I gorilla glued it in place, filling up the gaps as I can… I’m hopeful the strength of the glue will give it the support it needs.
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.
