During the calibration the sled is moving and is tightening the belts. Unfortunately, after the tightening, the sled is sometimes moving a bit and a belt that was already tightened becomes loose again. I think the tightening must done twice to ensure, that all belts are tightened.
Can you take a video of the movement? Sometimes tightening the belts will move the sled a little early in the calibration but that should stop as the calibration progresses
1 Like
Which firmware version are you using? We did some work on improving this so updating might help
I am using the latest Version 0.83. A video was uploaded to my cloud: Nextcloud. This time, another belt was loose. The last time, the belt was on the ground.
Maslow-serial(14).log (16.5 KB)
If you could tell me where I can find the corresponding code, I can maybe improve it a bit by my own. I am also interested into the optimization step. I could not find it in the git by my own.
Another thing is: Within the maslow.yaml there i a threshold for minimal fitness of 0.45 for acceptable calibrations. But if I get a Fitness of 0.46, the calibration process stops. What is actually an acceptable value there?
I think I found the source code location. Within the Maslow.cpp at line 835 till 848. Only two belts are tightened because it is assumed that the other two belts which were pulling the machines are already tightened. But this is only the case if the first round of the calibration process is good enough which is in my case not true. Is it harmful to tighten all belts to be 100 % sure?
Ulmair wrote:
I think I found the source code location. Within the Maslow.cpp at line 835
till 848. Only two belts are tightened because it is assumed that the other
two belts which were pulling the machines are already tightened. But this is
only the case if the first round of the calibration process is good enough
which is in my case not true. Is it harmful to tighten all belts to be 100 %
sure?
that would be if it’s in the vertical mode (where it’s hanging from two belts,
so they will be tight)
I’ve argued that we should go around tighening all the belts twice, but nobody
has tried that.
David Lang
This is correct. Good parsing of what is going on!
There are a LOT of corner cases in the calibration process since it has to work on everyone’s setup and there is a LOT of variation between setups. At the same time it also needs to not break belts or do something harmful if it goes wrong.
Generally I’ve found that every time I change anything about the calibration process it messes something up for someone so we need to move carefully, but also we can 100% make it better and we should be continuing to improve it
I know exactly what are you talking talking about. The calibration process is always tricky, no matter what you are trying to calibrate. I am a computer scientist dealing with very expensive 3D scanners. These 3D scanners must be also calibrated. I does see two main parts that could be improved. First, the data acquisition and second the optimization. For the data acquisition step, do you see any potential harm by calling “pullAxis->pull_tight(calibrationCurrentThreshold)” for all 4 belts? I mean the “retract all” button could be safely pushed repeatedly, right? If this is the case, I will try to change it by my own.
However, I think the actual problem comes from a bad initial calibration using the 3x3 grid. I do now, that the optimization step is done by my laptop using java script. Unfortunately, I do not find the repository that created the “index.html.gz” file, that includes the calibration optimization code. I have to understand the “Fitness” definition as well which technique is used for the maximization. Maybe I could help to improve this step as well.
here is the index.html source GitHub - BarbourSmith/ESP3D-WEBUI: A Web UI for ESP8266 or ESP32 based boards connected to 3D printers / CNC
the fitness is roughtly 1 / average error in calculating where the anchors are.
When we start, we have no (trusted) information other than the belt lengths, and
since the anchor locations could be anywhere along the arc of the belt length
from the spindle (and we don’t know exactly where the spindle is), things are
very sloppy for the first few measurements.
Once we get the first four measurements, we do some calculations to get a guess
as to where the anchors are and then use that for the next set of measurements.
In early iterations, we were having problems with belts getting very loose as we
attempted to move around, so we now only attempt to move a short distance before
we tighten the belts and get another set of measurements.
David Lang
I think it should be safe, but it might not be the same every time. Any three belts can pull tight and define the sled’s position so whichever three belts have less slack in them will pull tight and then define the position while the fourth is still retracing. We might be better off going around and pulling all four tight, but one at a time in a particular order so it’s the same every time.
You can find that code here. Feel free to ask if you have any questions or concerns getting it up and running. The short version is that running the command gulp package -en will generate a new index.html.gz file which you can upload to your machine.
There is also this repo which has an offline version of the calibration code which might be easier to mess with:
Bar wrote:
I think it should be safe, but it might not be the same every time. Any three
belts can pull tight and define the sled’s position so whichever three belts
have less slack in them will pull tight and then define the position while the
fourth is still retracing. We might be better off going around and pulling all
four tight, but one at a time in a particular order so it’s the same every
time.
I don’t think it matters to the calibration exactly where you are on the sheet,
it doesn’t know the x/y coordinates, just the belt lengths, so even if the sled
were to move a couple inches, I don’t think it would matter.
David Lang
I understand your arguement. But, if the sled is moving and an already tightened belt becomes loose again, the belt length that was measured is not valid anymore.
Can anyone explain me the function
bool MotorUnit::pull_tight(int currentThreshold)
especially the line
retract_baseline = alpha * float(currentMeasurement) + (1 - alpha) * retract_baseline
I do not understand what is going on? Another question is, if the “stop()” function is called, the motor does not stear anymore, right? That may the cause, why one belt becomes loose again after the currentThreshold was reached. I think the current position should be read and the setpoint updated to use the recomputePID procedure instead.
Ulmair wrote:
I understand your arguement. But, if the sled is moving and an already
tightened belt becomes loose again, the belt length that was measured is not
valid anymore.
That is true, but I thought Bar changed the calibration routine a couple months
ago to prevent any movement from causing an already tight belt to loosen
David Lang
I think there is a bug in DCMotor.cpp. The “stop()” function as well the “highZ()” function is identical. Therefore, I doubt that the “stop()” function does hold the current position as expected.
Great question. Absolutely.
What that function does is to pull one belt tight (retract the belt) until it reaches the current threshold.
It’s actually looking at two different current thresholds. There is an absolute current threshold which is basically checking is the current reading now greater than X. There is a second dynamic threshold which is using a moving average to detect is the current now significantly higher than it has been in the recent past. If either of those are true then it is done pulling tight.
The reason for the dynamic threshold is that it does a better job of detecting sudden spikes like when the belt is fully retracted and the end of the belt hits the hard stop on the end of the arm.
This line is computing a moving average so that we can compare the reading of the current now to where it was in the recent past to detect spikes.
The stop function should fully power off the motor. It’s not being driven in any direction after stop is called.
Bar wrote:
The stop function should fully power off the motor. It’s not being driven in any direction after stop is called.
also note that the motors are not backdrivable (as a practial matter at least),
so when the motor is stopped, the spool is not going to move. There may be belt
movement (streching, sliding on the spool, etc) but the spool itself will not
move.
David Lang
1 Like
I have done some modifications and I think it is much more reliable (initial derived Fitness 0.85 → becomes now 1.4 if you click on “End”). However, I have done the changes without any comment. Buf if you would like include the changes in the released code, then I will refactore it and add some comments for you. Are you interested?
index.html (47.1 KB)
1 Like
I am absolutely interested!
How can I check out the changes?