Fantastic sleuthing everyone! I feel like in the last few weeks we’ve crossed a threshold where my job has switched from leading the charge to doing what I can to help the people who are leading the charge. It’s so cool to wake up every morning and be impressed with all of the progress that was made during the night.
I’ve contacted Etonm and let them know about the slight discrepancy with the data sheet. I’m confident that all the motors are the same so far, but now they know to let us know if anything at all changes.
I think this quote deserves a second pass:
It IS pretty darn cool to hit the encoder steps dead on like that, and it only happens thanks to the work you’ve been putting into the feedback control system. That unexpected verification that your new feedback system is working so well is amazing! Great work.
Does someone want to make a PR and take credit for this fantastic effort or should I just make the change?
I should have said encoder steps not gear ratio there. We need to agree on whether it should be a fraction or not. It sounds like it should be. However, someone should figure out how we “push” this on users. I think this value is written into the ini file, so changing the default setting in GC won’t do anything.
I likely caused the fraction issue in the firmware, so I will track that side down.
Was just concerned that there might have been a 1-tooth change in one of the internal gears during production, resulting in a 279.3:1 ratio in some of the gear boxes, which would necessitate knowing which gearbox(es) are on a particular machine when it’s time to calibrate it.
If it’s a fraction that’s stored, you would do it with two new variables, correct? Therefore, the .ini file with the old variable name wouldn’t matter. Only people doing custom stuff would ever change the default values anyway, so basically just including a warning in the firmware release notes that say they need to recalibrate after update for improved accuracy should be good enough. Include it in the newsletter as well.
Great work with that test @krkeegan…
I hadn’t checked the forum in a while, but to answer your question, an alternative control strategy would have been when the velocity gets too low, hold it constant and let the control loop aim for position… If using encoder step timing works too, then I’d leave well enough alone.
I have created a pull request in #496 which I hope applies these changes in a responsible way.
The way it works is that when Ground Control launches it will detect if someone has the old value stored in their settings file, and if they do it will update the value to the new value, then display a pop-up to let the user know that their settings have been changed.
I think this is an important change so I wanted to make sure it got into the code. Does everyone feel good about the implementation?
Well, all I did was to try to figure out why my two measurements were off… with lots of prodding by @blurfl. I just figured out a way to illustrate the problem. You’re the one that figure out what caused it…
… I was fixated on rounding issues. Cheers to everyone!
by the way, we just found that the sprocket radius is hard-coded to an incorrect value in the kinematics code, look for 10.2 and change it to 10.1 and see if that accounts for the last of your error.