Thanks!!
1 Like
Increasing as the belts are reeled in, and decreasing as they are reeled out. Is that what you’re asking?
1 Like
It’s not a distance in X or Y from the middle of the sheet?
Its factoring stretch for each belt, not in cartesian dimensions. Does that not work?
1 Like
Ahhhh I thought that we were trying to compute the different forces on different positions on the board.
Wouldn’t belt stretch just be a constant scalar? Like 1.001x the normal length?
We have a variable for the distance between the belt teeth, I think that is probably the right place to correct for stretch. Like if the teeth are normally 2mm apart and then the belt stretches they will will be 2.0001mm apart or something
Stretch is constant based on the force imparted on the belt, but the force on the belt increases as the machine nears the edges. At least that’s what it looks like from my data.
This is moving from 0,0 to 0,1200.
Moving from the origin to 600,0 and -600,0 also see an increase in force when nearing the edges.
2 Likes
Back to my initial post, I used those two coefficients to calculate the cartesian impact on the machine and the results were nearly identical to what I measured in the grid I drew. Granted, this is just moving along 0,0 to 0,1200. However, you can see that it’s not a linear scaling factor that we’d need and it also depends on the direction the machine is moving since the force is applied to the pulling belts. Moving from the edge back to the center flips everything. That’s why I think it might be easier to use those coefficients on the belts that are pulling.
3 Likes
I think that we might want to compute the tension in each belt independently. For example in the top left corner the tension is really high on the top left belt because there are basically three other belts pulling against it. The direction that the belts are each pulling in has a big impact on the tension.
Gravity also has a big impact on that in the vertical orientation.
I have some basic code to compute the tension in the upper belts for visualizing it that is like this:
var computeTension = function(x,y, tl, tr, bl, br){
const A = Math.atan((y-tl.y)/(tr.x - x));
const B = Math.atan((y-tl.y)/(x-tl.x));
const T1 = 1 / (Math.cos(A) * Math.sin(B) / Math.cos(B) + Math.sin(A));
const T2 = 1 / (Math.cos(B) * Math.sin(A) / Math.cos(A) + Math.sin(B));
That’s not right, but I think that we want a function something like that which returns the tension in each of the belts. Maybe we have a computeTensionTL() and a computeTensionTR()…then we could feed that tension into the stretch computation.
Does that seem right?
Another factor is that we are doing calibration on the same system that we are cutting on so our calibration measurements will be distorted in the same way. That leads to a bit of a chicken and egg problem that I’m not sure how to solve.
1 Like
YES 100%. Without digging into the code yet, I don’t think we really need to know what the actual tension is but how it changes which is what those coefficients do. The machine is going to start with some baseline tension in each belt and that’s going to change as the belt is reeled in and out. I don’t think it really matters how much it stretches when the machine is mounted at the origin and belts retracted since that’s the baseline, movement thereafter is what matters.
My guess is if we do it on the belt level then we don’t need to mess with trig functions to convert into cartesian forces.
I think some of my previous calculations aren’t quite right, so trying to fix that now.
1 Like
I think that the position of the anchor points is going to be important IE a frame which is square is going to have different forces at different points that a frame which is rectangular so I think we’re going to end up doing some trig 
1 Like
A bit of a tangent: While playing around with custom firmware, I noticed that there is a catch-22 related to the motion control logic of the belt motor.
The voltage (or better said, PWM duty cycle) applied to the DC motor is calculated based on the error (= the difference between the setpoint and actual position) by means of a simple PID controller. The PID controller only uses the “P,” which is the gain factor. The duty cycle is basically calculated as: error * gain.
When retracting a belt, more torque is required than when it needs to extend - comparable to controlling an elevator motor. So the PID controller has to handle different circumstances based on the direction of the belt. By changing the gain (P), one can tune the PID controller to be accurate at either retracting or extending, or mediocre at both.
Curious if having a second PID - so one per direction - will have a positive impact on accuracy. I’ll give it a try on my machine and report back if something useful comes out of it.
2 Likes
BTW, watch out for the number of significant figures if you try to push belt stretch into teeth per mm! Variables are stored with a finite number of significant figures.
1 Like
I love this questions so much!
I don’t have a definitive answer (I think that there is a lot of room for improving the PID system overall and tuning things)
I did play around with this idea a little bit and I didn’t find too much of a difference. We could also use the same PID controller and run it with different tuning in each direction.
I also played around a bit with having a velocity PID controller with a position PID controller on top of that.
My general take away was that I could tune the system to handle a particular situation better but then it couldn’t handle things like the switch from horizontal to vertical.
I am 100% sure that we can improve significantly in this area, but it’s going to take quite a bit of testing to get it dialed in.
Totally agree on that. The existing PID works, and is as simple as it can be (which is a big plus). The load on the motors is so diverse, combined with a variable dead zone (the torque needed to get the motor to move due to stiction), that there won’t be a magic number for P (and I, and D) that works well everywhere. Unless we do auto-tuning - it shouldn’t be too difficult to measure the breakaway torque and get a “good enough” value for P by simply moving each motor a few inches at different P values while the belt is under tension, in each direction. But this definitely bites with the “as simple as it can be” adage. But hey, still interesting to dive into 
1 Like