Wow, have you built a ‘reverse synchronising’ firmware?
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.
Another video of it running actual gcode…It’s just a ~12 inch circle with a lead in…
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.
wow, that is impressive!
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.
This is phenomenal! I think this is exactly the right way to do things. I can’t wait to hear about what you learn!
Yes, those digitizer pads used to be the only option before you could digitize off an image.
Same here… lots to learn.
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.
I have been playing around with these exact same issues in my head and it is so cool to see you working through them in real life!!!
Here are my thoughts.
I was initially planing to do a single wrap around a capstan, but I think there may be a long term accuracy issue because the diameter of the cable is a factor in that equation, and the diameter may not be a reliable dimension. I am planning to experiment with two pinch rollers to measure the rope as it passes in a straight line so it’s width is not a factor.
For the issue of loosing tension and so the outer roller is not working I was thinking that a second encoder on the motor to monitor what was going on could be a back up plan, but I think measuring the motors current draw should be enough to work out if things are ok and throw an alarm. If we can see that the motor is drawing current in a reasonable range then it is working. When the sled is moving up and the lower motor is feeding out cable is the time when it would be hardest to detect an error and I think some testing would be needed to determine if a current measurement would be enough under those conditions.
Keep up the awesome work!! I’m hoping to start playing with hardware for something similar in a month or so.
I like the idea. I assume the cable would pass between “rollers” before and after the pinch rollers to make the segment where the pinch rollers are straight or did you have other plans?
hmm, i wonder if you could have a limit switch of some sort… so that if it tries to pull too hard on the bracket, it pushes in the limit switch and stops the machine.