Beta testing Holey Calibration

Troubleshooting
1

Hi @Joshua ,
I’m checking the RunHoleyCalibration.py for corner cases.

I use it on the 6 points pattern results of candidate Kynematics.cpp implementing stretch compensation.

I use the current GroundControl release (not yours) to operate the MaslowCNC.
Then I use your HoleyCalibration GroundControl version to run the optimisation python script.

I used it on measurments from two cases:
a) the machine is pretty well tuned (I know good chain tolerances and other parameters)
RunHoleyCalibration_fineTune.py (1.0 KB)
HoleyOnFirmwareStretchCorrectionCandidateAndKnownGoodValues.txt (1.9 KB)

b) Same except the machine has 0 chain tolerance values (default for new setup), And I used the slightly changed motor distance as proposed by a) results: 3500.2 mm. But then no solution:
RunHoleyCalibration_noResult.py (1.0 KB)
HoleyOnFirmwareStretchCorrectionCandidateAndDefaultValues.txt (1.9 KB)

I was carefull to set the right Starting point values as set into the controles and reported in GroundControl “maslow” and “advanced” settings window . In the second case, it looks like the optimisation does not go toward resolution.

I am not familiar with the optimisation algorithm you have put together. What do you think is happening?

3 Likes
2

I am not sure I understand what is causing this.

One potential cause is if one of the measured points ended up being off the board. When that happened, the kinematics.forward algorithm produced an error, and the optimization couldn’t move forward. This is a good point, an issue that could be easily fixed. We could set a flag that increased the size of the worksheet, so this problem wouldn’t happen.

1 Like
3

I work on preparing a pull request to implement the chain stretch compensation in the firmware.

For now I can say that:

  • the firmware with this improvement works fine on my frame and improves the center top vertical position without having anymore to cheat the motors distance parameter.
  • when using it to run the 6 point calibration it work fine.
  • When using the RunHoleyCalibration.py that settles fine when values are close to known good ones.
  • When reseting chain tolearances to 0, then redoing the 6 points calibration, RunHoleyCalibration.py failed to settle and proposed values are not usable (15% tolerance solution).

I would like to propose a call for beta test before a pull request is made so we can make sure it is robust enough. But until the RunHoleyCalibration works fine, then I can’t offer to beta testers to try the RunHoleyCalibration.py. It is only optional but I would like to get more people enjoy the improvement of chain tolerances and report about it.

Thus, toward adding each firmware features for the Holey Calibration, I shared all files in my previous post. Can you investigate it further? What can I try to help figure it out?

2 Likes
4

Could you provide information on which GC you were using when you had this problem? If I can reproduce the issue, I can tell for sure what went wrong, and may be able to come up with a fix.

5

By the way, thanks for all your work. I really appreciate everything you’re doing.

1 Like
6

Executed Gcode with the current GroundControl release.
Ran the RunHoleyCalibration.py in your GroundControl folder.
Was carefull to fill the python script header with the proper SP values.
Is that ok?

7

I downloaded the main GC fork, and ran the RunHoleyCalibration_noResult.py calibration. Looking at the measurements, measurements 9 and 10 are ~2000 mm, which are about 800 mm too long. I am thinking this was a typo, and I believe is the root-cause of the issue on this one.

This highlights the potential value of validating the inputs to the calibration. This is something that could be red-flagged, since the measurements are nearing double what they should be.

8

Thanks @Joshua !
I really was just so involved I missed the typo :slight_smile:
Fixing 1999 to 1199 mm then it all works fine. Not giving exactly the same result for the second case though: Should we propose to run the Holey Calibration a few times?

Yes we could have some range checking.
Could you add some range checking? Like ±10% aroud expected values?

I will prepare a call for beta tester volunteers.

Regards,

1 Like
9

all good today. the optimization Joshua did for me squared up 6 hole test. massive improvement. I will test top of board and send new 6 hole measurements tomorrow.

thanks, JR

1 Like
10

One thing that is important to know. The optimization result is dependent on both the initial machine parameters, and the measurements. So, if you change the initial machine parameters, and have the same measurements, you should expect to have a different calibrated result. I don’t believe a two-stage calibration is necessary, as long as the starting point is reasonable. I consider reasonable as being careful tape-measured distances, and chain-tolerances that are either 0 or the result of a previous calibration.

1 Like
11

For everyone’s information, I have begun development of the GUI for the Holey Six Point Calibration, with the intent that this can be merged into the main GC Trunk. I do have a few of the GUI templates defined, but nothing is functional or firm. I can post some screenshots pretty soon.

If anyone has a reason this should not be merged back to the main GC trunk, please speak up now. It could save me a bunch of work.

Given my current family circumstances (young children), it will be slow. Don’t hold your breath.

1 Like
12

Thanks for working on it. And I am even more impressed given the family obligations.

1 Like
13

are the links at the beginning of this thread still the most up to date version of GC and the firmware?

14

No. The one on the original Holey Calibration thread is.

Post 174 here: Holey Triangular Calibration