Yeah something like that. If we think a float is good enough, let’s stick with it.
Getting everything set up now! I should just use the master branch of madgrizzle/firmware and the findCenter branch of madgrizzle/groundcontrol right?
Ran through the calibration and then it crashed on a method that I guess no longer exists 
Fix provided here: Fix crash by removing unused method · madgrizzle/GroundControl@e3b46b9 · GitHub
I ran through most of the calibration again (for -10,4 to 10,-7) and saved the values this time (since last time it crashed).
My y-values have some crazy periodicity across the horizontal lines
My x-values have a little bit of periodicity horizontally especially further from the center, but it’s not as pronounced as the y-values. I think this is a different issue than what you saw though since this is periodicity side to side – so the sled direction hypothesis doesn’t apply.
My columns had no obvious periodicity. See the doc for more detail.
I noticed a lot of chain slack variation especially near the edges. It seems my sled tended to stick to the board. I could see various levels of tension in my chain throughout the run. This could potentially account for some inaccuracy, though I’m not sure how it would account for the consistent periodicity in the Y-values though.
I generated coefficients then tried to send to controller, but got a controller disconnect. I wonder if this is related to my fix to make the firmware compile.
Sending: $O=30,13,0,0
Sending: $O=30,14,0,0
Sending: $O=31,15,42,42
Connection Timed Out
While waiting for the calibration to run I started designing a 3d printed camera holder I can fill with BBs to get to the same weight as the router (~6lbs). Here’s the Thingiverse link. I haven’t tried it yet. I think I’ll print it in PETG and go buy a bunch of BBs.
1 Like
Also, for fun, here’s a timelapse of the calibration process running (the first time – before Ground Control crashed)
That’s it for me tonight!
2 Likes
Thanks… That’s weird it was there… I don’t remember that routine and when I ran it, it didn’t crash but certainly looks like it would. oh well, thanks for fixing it.
I had made what I thought was a fix to that code section (sometimes I forget to do the push… sorry):
float readFullFloat(const String& str, byte& index, float& retVal){
String sub = str.substring(index);
sub.trim();
retVal = sub.toFloat();
return true;
}
I followed the way readFloat works and returned a true even though the return type is float.
The crash I think happens upon saving to the EEPROM. Even though it appears the values save, something happens (maybe in the EEPROM library) that causes the crash.
I’m not sure my periodicity was related to the motors… it could just be simple “hysteresis” (for lack of a better name). Getting periodicity along the Y axis is very interesting though.
I think some of what we are seeing can at least be associated with sled sticking… I have some HDPE to put under the sled to give it a try. The banner is not as smooth as the laminated blueprint, so that might be part of the issue.
I’m wondering if there is an issue saving so many bytes at once into EEPROM… like a watchdog resetting the board…
I see in GC that it resets the usb connection if it doesn’t get a message within 2 seconds. So, if it takes too long for EEPROM to finish the write of 1,860 bytes (31 columns x 15 rows x 2 bytes x 2 tables) then it will reset. Arduino reference says its 3 ms per put (which I assume is a single byte), so that puts it around 6 seconds… and the watchdog in GC will reset the usb. So that’s something we need to resolve… but I’m taking kids to movie 
1 Like
Can I get a link the the camera you are using?
Thank you
This is the one I have: https://amzn.to/2DDN3Ju ($18 720p USB endoscope)
But as mentioned above in the thread, the lens is a little off center, so possibly there are better ones out there. I love the pricepoint on these though.
1 Like
Great sleuthing!
Not quite… I looked further and a message should have popped up if that’s what happened… Funny thing is that now it doesn’t crash on mine. I’m not sure exactly why yet.
1 Like
@madgrizzle How well does curve fitting work if I’m only running the test pattern on part of the board? Do you think the curves will be sane in the other parts of the board also? That’s the blue line in the grid right?
Also, I noticed that the ‘Calibration Pattern Dimensions’ seems to only affect the width of the square. Should I add a couple more test boxes to calibrate the distance between squares based on measuring the test pattern? @EdFeeney’s point about water being hygroscopic is showing to be true, the test patterns measure significantly different in my basement then they did in the office.
I ran a comparison this morning and the results are difficult to interpret… some places the interpolation works better, other places the curve works better. At this point, I’d say they are comparable and probably would use the curve since they would tend to smooth out any anomaly…
Hmm… I’ll look at the code… I thought I did both.
These two lines should (I think) calculate independent corrections for x and y axis:
self.xD = dist.euclidean((tlblX,tlblY),(trbrX,trbrY))/self.markerX
self.yD = dist.euclidean((tltrX,tltrY),(blbrX,blbrY))/self.markerY
But, in reality, because we are homing in on the center of the square, I think being off a little in calibration doesn’t really make a difference. All it does it make it harder to home in on the square (you think you are off by 2 mm and tell it to move 2mm but you really are off by 2.3 mm… for example) and it affects when it stops trying to home in (it stops at 0.125 mm, but if the scale is off maybe it will really be 0.200 mm)… Those are minor impacts.
Those lines tell the homing how far to move to home in on the center of the square right? I want to adjust for the spacing between the squares being a little bit off. I’m getting as much as 1/8" error in the outer edges of my squares. Something like this (where X-Scale and Y-Scale could be something like 1.002) or something like that if measurements come up a little short.
Where 3 inch spacing is not really 3 inch spacing? Hmmmm… that’s a big problem if so.
Ok, now that I thought about it for a few seconds… maybe its not a big deal. Is it linear across the pattern?
Yeah it’s linear, I can probably just adjust the generated offsets in GroundControl based on the scale and the center point right?