Musings on a new design

The repeatability accuracy is quite high, so i’m not sure the linearity accuracy actually matters, it just means you would have to calibrate it first.
It’s still a $150-255 sensor though, and has analog output, so you’d need an adc to read it.

Yes. The difference in length between (ap1-ap2) and (ap1-a bottom corner-ap2) is about 26".
The total distance from ap1 to ap2 in my drawing is 150".
The total distance from ap1 to the bottom right corner to ap2 in my drawing is 176".
176 - 150 = 26

Yes. I think this is very workable!

This product is no longer available.

The repeatability accuracy is quite high, so i’m not sure the linearity accuracy actually matters, it just means you would have to calibrate it first.

you would have to calibrate it at many positions, and what is it that you are
going to be calibrating it against? how accurately can you measure a position to
detect a couple percent of error?

It’s still a $150-255 sensor though, and has analog output, so you’d need an adc to read it.

I would not trust anything that then needed an adc, that would add more
variability and room for inaccuracy.

David Lang

Surely there is something else then an expensive sting winder . What about 4 laser range finders with bluetooth attached to the sled pointed in 4 directions to an edge around the work area…

Another lurker here. Is there an inexpensive way to measure rope angle? If so and the ropes (EDIT: or even better, tape measure type spools) were fed into a ring or convergent pyramid pivot point suspended some fixed distance (12"?) above the sled surface and router, the angle of each rope relative to the sled (or the toolhead shaft) could be monitored in real time to calculate all four hypotenuses.

Measuring angle would be easier if the machine is only operated as a horizontal table to ensure all four ropes can use the same compensation for sag. Measurement could be done with a sufficient resolution optical encoder mounted on the rope, and a weight that ensures the encoder shaft always points down with gravity. If sufficiently sensitive encoders are too expensive, then add some small gear ratio between it and the weight.

Assuming enough accuracy can be derived from the rope angle, and the normal work surface to top-of-sled height can stay constant, you could get all the hyptotenuses to find position, and you also get ability to know if the sled has tipped or caught on something when the math doesn’t add up. Changing materials and work surface heights becomes easy to recalibrate because the two things you control (sled height and hypotenuse) can always be known.

Note I’m not suggesting those four ropes simultaneously be used to do all the motorized pulling. Perhaps that wouldn’t work because the sled could stall or tip over on the slightest work surface friction. I’m just saying you could have four (more?) ropes leading to a top ring, and measure angles of those ropes, rather than try to measure distances of rope pulled in or paid out.

3 Likes

Been following the project for a while. Great efforts so far. Some possible new design architectures to consider:

SCARA (Selective Compliance Assembly Robot Arm or Selective Compliance Articulated Robot Arm)

Pro

Good articulation
Small footprint
Fast movement

Con

Software effort, calculating inverse kinematics
Might be expensive

Parallel manipulator:

Pro

High speed
High accuracy

Con

Work area size, potential lockups (singular positions)
Software effort, calculating desired manipulation forward kinematics

Useful software for simulations:

https://sourceforge.net/projects/mekin2d/files/

3 Likes

In all of these designs, you depend on getting the angles exactly right. look at
what precision you would need for the angles to get 1/2mm accuracy at 3m of
distance. Then make sure that your joints and arms don’t have enough flex in
them to ruin your accuracy.

1 Like

Another lurker here. Is there an inexpensive way to measure rope angle?

no, think about how small the angle is that you have to measure to detect a
movement of 0.5mm at a distance of 3000mm

also think how much the rope can bend before your sensor arm moves.

Measuring angle would be easier if the machine is only operated as a
horizontal table to ensure all four ropes can use the same compensation for
sag.

going to a fully horizontal machine would make it take up so much space that
most people would not be able to have one.

the sag would only be the same if the tension and and lengths of all the ropes
is identical, as soon as either one varies, the sag will vary.

Measurement could be done with a sufficient resolution optical encoder
mounted on the rope, and a weight that ensures the encoder shaft always points
down with gravity. If sufficiently sensitive encoders are too expensive, then
add some small gear ratio between it and the weight.

we have far more than sufficient resolution on the motor position (to an
accuracy of better than 0.01mm). The problem is not with the encoder, but with
the fact that chain/rope is not a perfectly straight, inflexible, non-stretching
component, so measuring out how much you have fed out does not quite tell you
how far away the other end is.

David Lang

If you need to measure rope tension the 3 rollers plus a load cell and a HX711 chip could be useful.

I suggest the above without knowing the following:

What is the expected tension range?
What kind of resolution would be required on the tension measurement?

What is the expected tension range?

from < 3 pounds to 66 pounds

What kind of resolution would be required on the tension measurement?

we don’t know.

David Lang

somewhere in the ~100 grams ( 4 oz) / degree of measurement is probably a good place to start wthin the range we’re lookin at…

Rather than worrying about measuring angles better to use a zero backlash drive train like strain wave gearing.

I was looking at the firmware code and wonder how one would implement the use of an external encoder on, say, a pinch roller while the motor is attached to a spool that takes up/feeds out cable. I’m still learning, but it seems to me that if the motor mmPerRotation is different than the encoder’s mmPerRotation, then the PWM calculation will be wrong. For instance, if the encoderSteps setting is equal to 8000 and the circumference of the pinch roller is 80 mm, but the spool attached to the motor has a circumference of 320 mm, then if the pinch roller’s circumference is used to calculate the PWM then 4x the amount of the desired amount will be spooled out and, if the spool’s circumference is used, then 1/4th the amount would be spooled out. I understand that the purpose of the encoder is to provide feedback and I assume that adjustments would be made, but I expect this to result in a problem when its so far off to start with.

So if I’m right (and that’s a big leap at this point), do we need two difference mmPerRotation values in a design like this? Also, if the cable wraps upon itself, then the mmPerRotation can change as well… so is it necessary to avoid overlapping the cable?

1 Like

The angle ‘Hello’ idea looks like a great idea, add some aluminium rods with bearings and maybe some of these
https://s.click.aliexpress.com/e/ZnoFAyt

Why would you need 2 encoders per rope? Just use the pinch roller for the pid,m.
You could maybe use an encoder on the motor for safety, it should be about the same speed as the pinch (with a semi permanent multiplication factor) if it isn’t something is wrong and the machine stops.

Ps i should really get to reading this tread :slight_smile:

1 Like

That’s what I’m asking about… one encoder on the pinch roller. My concern/question is how wouldn’t work when the mmPerRot for the encoder is different than the mmPerRot of the motor.

Just ignore the one on the motor for the motorcontrol, only check it to see if there is a big difference to detect a problem.

1 Like

I’m assuming there isn’t one on the motor… I’m trying to understand how a pwm signal gets generated for a motor based upon a particular mmPerRot but the feedback coming from an external encoder has a different mmPerRot.

(mmPerRot for the motor being the circumference of the cable/wire spool and for the encoder, it’s the circumference of the pinch roller)

I don’t see the problem, when the motor feeds, the encoder on the pinch rollers will change almost instantaniously, it just takes some tweaking of the pid vallues, doesn’t it?
Maybe i’m way off, it’s been a long time since i learned about that stuff in school :slight_smile:

1 Like

Im in the same boat… 27 years ago I might have known the answer.

So this is the issue I see… The firmware calculates what duty cycle (frequency) to run the PWM signal that controls the motor and causes the motor to move… This value is calculated based upon how long the motor will run for that cycle (set to 10,000 microseconds) and how much it needs to turn, which is calculated by the distance of each step divided by the the circumference of the spool/sprocket/whatever. So a 10 mm move, divided by 63.5 mm per rotation (current sprocket size) results in a value of 0.16 of a rotation. So the PWM signal gets calculated such that the motor will turn 0.16 of a rotation in 10,0000 microseconds. The problem I see is that if the encoder has a much smaller circumference… for easy math, let’s say 6.35 mm. That means that the encoder will output a full rotation of steps within 1/10th the time and this will create a big error. So maybe all that needs to be done (and this is because I’m thinking it through responding to you) is that the encoderSteps value (steps per rotation) just needs to be changed to match the encoder, but the mmPerRotation value needs match the spool/sprocket?