Maslow Home Maslow Community Garden Newsletter

Holey Triangular Calibration


#264

What was the number in GC and the FW when you ran the cut?

Also, have you updated your FW and GC since the change to the Chain Tolerance calculation?


#265

Here is the script to run it.
RunHoleyCalibration_jimr.py (1.0 KB)

Here are the results.
CalResults_jimr (2.6 KB)

I looked at the results. It looked like one measurement might have been off, because the calibration was 15 mm off on that measurement. It was the vertical measurement on the right side, from point 5 to point 6. I used the kinematics from before we inverted the chain-tolerance calculation. This is the revision.


#266

Update

I have done some work in preparation of a pull request. Unfortunately, git is new to me, and it hasn’t been as easy as I would have liked. Apparently I created a new repository, rather than forked the MaslowCNC repositories, which has made it more difficult than if I had known what I was doing. Further, there were conflicts in the Firmware Kinematics.cpp file.

I have created two new repositories in github under my username:

They are currently only used for preparation of a pull-request. They have not been tested, and should only be used if you wish to be the first to test it. If you would like a more tested version, the links in this post, 176 are the ones to use.

At this point, all the conflicts have been handled, and a pull-request is possible. I would like to compile everything and run it before actually doing that. That will not happen this weekend or the next, since I will be going to see the in-laws next weekend.


#267

In frame carpentry, this is called “burning an inch”

I would think this would only be relevant within a few inches of the pivot point, anything beyond will quickly approach a non measureable deviation.


#268

@WoodCutter4, thanks for doing this.

Because there are 12 measurements and only 4 parameters, there is quite a bit of information in the errors within the calibration. You would expect for the benchmark cut to be similar to the calibrated errors in the 12 measurements. I would expect the benchmark errors to be around 1 mm, and that is statistically supported by the fact that there is more data (12 measurements) than is necessary (4 measurements). Because you are seeing a difference between the accuracy from the benchmark and the accuracy between the calibration leads me to believe the machine is calibrated differently from the calibration inputs (and therefore outputs).

I would guess there is something misaligned between your machine setup and your initial calibration definition within the RunHoleyCalibration.py script (cal.SP_D, cal.SP_motorOffsetY, cal.SP_rotationDiskRadius, cal.SP_sledWeight, cal.SP_leftChainTolerance, cal.SP_rightChainTolerance, cal.SP_chainOverSprocket). The machine calibration in the RunHoleyCalibration.py script needs to match the calibration in Ground Control when the cut was run. You need to manage that yourself. To make it more confusing, the Firmware doesn’t always sync with the Ground Control settings when you think it should.

So, there are several things that we can do. First, could you explain what you entered into the initial machine parameters in the RunHoleyCalibration.py script? What were the machine parameters when you ran the calibration cut? Is there any possibility the Firmware didn’t sync with Ground Control before running the calibration cut?

If you are confident in all those numbers, then we’ll just have to wait for the GUI implementation. This should reduce the potential for differences between the Firmware and Ground Control.


#269

Hey @Joshua I’m happy to offer my services as Git wrangler if that’d be helpful :slight_smile: Shoot me a message if there are any questions you have or if there’s anything you need assistance with


#270

Thanks for the offer :smile: . I think I have mostly worked through my git issues. I now have exercised git commands from the terminal on my Ubuntu machine, merged all the conflicts, and pushed the changes back to a legitimate fork on GitHub. Ideally, the only thing I need to do is validate the functionality. If nothing goes wrong, I can create the pull-request, which I now know how to do.

What GUI do you recommend for git on Ubuntu? I used ‘gitg’, but the functionality was sparse. Also, I used ‘kdiff3’ to merge the conflicts, but it wasn’t great.


#271

I can’t make any recommendations as I’ve only used the command line tool


#272

I tried gitkraken, but the learning curve is to steep for an old man like me. It looks cool though.