Tom
The cable robot is running G-code that tells it the location of the pickup, and then it goes and builds that stack of cans that was pre-programmed into the robot. The cool thing here is that you can get an idea of the repeat-ability of the robot and control. There are three cable hoists actuators that are controlled using EMC2 software.
Here is an early video showing the actuators up close.
A couple of key take away's from the initial development.
* Stepper motors are awesome, I love stepper motors. The one thing to remember is that the torque drops off as a function of speed and does so pretty quickly. I geared the hoists for more torque, to be able to lift heavier objects. By gearing down that requires that motors to run faster, and running faster means they have less torque. So did I really gain anything with my gearing selection, I don't know.
* Run high voltages on the steppers, I started off with 12VDC then swapped to 36VDC. Higher voltages allows for higher speeds.
* I used my own drivers, based on the SLA7078 chipset. These are cheap ways to drive stepper motors but if I were to continue to use stepper motors I would choose a driver than can change micro stepping on the fly. Faster moves would be nice to do half step or full stepping.
* I think this a good application for servos, my goal is to use servos on the next generation. The problem is interfacing the servos to EMC2 software is more difficult than using steppers.
* The point where the three cables come together is very important. You can put a big triangular rigid structure in there because then it will want to rotate. The points all have to come together as one for the solution to work out. I used a neat technique to provide stability that I will share in another post.
* The top of the envelope has alot of unusable space. It is all about the angles of the cables, they have to have sufficient angle to be able to work decent. Also the edges of the envelope don't work well either.
* The actuator design is key to only allow one wrap on the drum to be able to keep track of the distance.
The actuator design is essential for good control of the robot. You need to ensure that you get only one wrap of cable on the drum to maintain accuracy. Here are some details regarding the actuators.
I used a green rubber band so that it is more visable. The white piece slides along the two aluminum shafts and wraps the cable evenly on the copper drum. I plan on doing a design with some 3D printed parts to simply the design. The distance per revolution becomes a thinker, it is one revolution of the drum + the distance traveled by the wrapping mechanism. All of the shafts are sequenced using a chain drive. I would recommend using GT2 timing belt since it is so readily available and GT2 timing pulleys.
Lastly one of the key things that I have not seen done elsewhere is wrapping two cables on the drum at the the same time. What this allows is to have 6 cables go down to the actuator to allow for stability. Otherwise I found that any payload swings like crazy.
ThunderSqueak
Val
Irene Sanz
Duane Degn
Cool project!
To overcome the drudgery of making a pour over coffee every morning -- I made a cable robot to do the job.
https://drive.google.com/open?id=16OG39bJUZj3CQKuV_7KI9TRT9vnNs2vX
The x and y movement of the coffee mug is not very extensive in the video because not much movement is needed to brew a good cup of Joe. It's the slow pour and the waiting for the coffee to "bloom" that makes the coffee tastie. (But the x y movement is robust and accurate -- friction of the actuator's sliding can cause difficulty. )
The machine's movement is achieved with a Raspberry Pi Zero controlling three 28BYJ-48 steppers / ULN2003A Darlington driver chips, 3-D printed pulley gears, a sewing machine bobbin as an actuator and common button thread as the "cable."
Instead of G-code, a bash script calls a series of Python scripts that coordinate the steppers' movements. This allows all of the software to be run on a Pi Zero. This approach might help your endeavors to "embed" the code -- no LinuxCNC, Universal G-code Sender, etc.
The Python scripts requires that each movement be entered line by line, not unlike writing your own G-code. But for simple repetitive movements, this is not a particularly difficult task. This of course is only 2-D movement.
I'm of the opinion that the z travel should be handled independently of the x and y movement's mechanism in cable robots. Imagine a Hang Printer with a print bed that lowers, or one in which pulley mechanisms may be raised (and lowered) as a unit? This removes the z limit and keeps the machine operating in the x an y's optimum range.