We finally got proper movement on our cable driven 3D-printer. Next we’re going to finetune the settings and calibrate the frame as good as possible.
Eventually, we need to figure out a way to put some torque on the wires opposite to the pulling wire to ensure tight wires at all time.
The current firmware doesn’t support yet a constant torque in position mode, right?
In an older thread I saw a workaround to address this with two motors in position mode, one of them pulling in direction X trying to reach setpoint Y (let’s say point zero +100), while the other motor is pulling to the opposite direction of X trying to reach setpoint Z (point zero -100). The equal torque on both motors should keep the line (somewhat) steady at point zero while having the lines tensioned, if I understood it correctly.
The other workaround was to have one motor in position mode and the other in torque mode pulling against the first one. This option is unfortunately not possible for us at the moment since eiwe can’t connect all Odrives to Duet by UART.
The question is, if that theoretical approch with two opposite and offset positions would end up at a position which is half of the distance between both setpoints? In theory it might work, but I’m concerned about the accuracy.
Sure, best would be a mix of position and torque mode directly in the firmware. Any plans to implement something like that?
What do you mean? If the torque were constant, then how could it hold position?
You can have a constant torque limit in position mode, that is, if the motor is forced out of position slightly, then the torque it applies will be constant, equal to the torque (current) limit.
The issue here is that there is a region in the middle where the position is not controlled, because neither drive can reach its position setpoint. However, as long as you make this region smaller than the amount of stretch in the cables for the torque limit, it should be controllable and the real position should be exactly halfway, provided the cables have identical spring constant. (although they have different lengths so maybe it would present a problem, but nothing that can’t be calibrated out)
I still don’t understand what you mean by “a mix of position and torque mode”. You can (in existing firmware) have position with a torque feedforward value, if that’s what you mean?
I think (torque) current limit is something else. We need to move a quite heavy mass of +10 kg as fast as possible. This mass is suspended and restrained by cables running in four directions. In XY-plane the end effector is pulled by ABC-cables (3 sets of two cables). Those will be spooled on drums with a helix groove.
Now, let’s say cable set A is pulling the end effector with a certain speed, while spools B & C wind out cable according to the kinematic algorithm. Torque is applied mainly on motor A up to the current limit. As for motors B & C they rather spin more or less free, but since no build matches exactly the plan, there will be always some slack in the cables. That’s something we would like to avoid under all circumstances, since it leads to positional inaccuracies and potentially mechanical issues.
My idea was to let motors B & C pull gently to keep the cables tight, but not to interfere too much the positioning done by motor A. I imaging this like a master-slave setup for the motors. I might be, that this must be controlled by Duet.
Have you taken a look at the ‘mirrored’ controller mode in ODrive?
It makes one axis follow the other, with a positional offset. It’s similar in a way to the “Electronic camming” feature of industrial drives
cool project! I think your problem is quite typical for cable-driven parallel robots and is one we had in our work as well.
Unlike classic connecting elements, cables/wires can only take force in one direction. So they can only be loaded on tension and not on compression. I could not see exactly how your setup looks like, but I assume that because of that you are using more motors than degrees of freedom. Such a redundant rope robot is able to move independently from external loads, but it also brings problems. Especially if you use a position control for each drive separately. Inaccuracies (e.g. in the kinematic model or in the motor control) then cause the cables to either work against each other (in the worst case up to the limit of the motors, cables or mechanical components) or that individual cables are not tightened.
Finetuning and calibration can certainly improve this. But it will never be perfect.
Your idea of applying constant force to a cable is a very simple workaround that can work in principle but may also lead to problems.
What you could alternatively consider is a control in central workspace coordinates. For this, you would need a higher-level controller that compares the nominal position and the actual position and calculates a global force that is then distributed to the individual cables. ODrive would then no longer be used to control the angle but to control the cable force, i.e. the motor torque.
Good luck with your further development. If you have any questions, feel free to contact us.
I’ve seen your video on Youtube at some point.Totally forgot that you were using also Odrives. Really cool those examples of passing the hand movement on to the CDPR on the video.
We are using a Duet 2 for higher level control and for kinematics calculation, but sadly the board doesn’t have enough UART port to communicate with all Odrive. For now we are using only step/dir signals, so most of the Odrive functionality is out of scope for now.
Would be nice to learn from your experience and share ours. Can I reach out to you by mail or so?
Yesterday we managed to fix remaining issues with ground loops by adding TI ISO7762 breakout board to the Odrive step/dir signal input. Now we have finally a ready and foremost stable system.
And it is pretty darn fast
Max. travel speed 1800 mm/s before hitting velocity limit. I’m starting to believe that even +2000 mm/s is possible by ramping up the speed limit.
