Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the default encoder steps from 8148 to 8114 #496

Merged
merged 5 commits into from
Dec 15, 2017

Conversation

BarbourSmith
Copy link
Member

As identified in this forum thread the correct (or more correct) value for the encoderSteps variable is 8114.

Because this update effects a value stored in the users settings file not only does the default value in ground control need to be changed, but also the users .ini file needs to be updated.

The PR will detect if a user is using the old value and if they are the value will be updated and a popup will let them know that the change has been made.

image

As identified in this forum thread the correct (or more correct) value for the encoderSteps variable is 8114.

Because this update effects a value stored in the users settings file not only does the default value in ground control need to be changed, but also the users .ini file needs to be updated.

The PR will detect if a user is using the old value and if they are the value will be updated and a popup will let them know that the change has been made.
@krkeegan
Copy link
Collaborator

Should we recommend more strongly a calibration?

I don't really have a good feel for what the error someone would see if they didn't redo the calibration

So they would have a wrong motor distance, but this would be compensated for by the test cuts. Both of those are abstracted from the steps into dimensions. I think that is right?

In which case, changing the steps now probably improves their error, but a new calibration would improve it more?

@BarbourSmith
Copy link
Member Author

In which case, changing the steps now probably improves their error, but a new calibration would improve it more?

I think this is the case. I would expect that everyone will see an increase in accuracy, but the increase will be more if a calibration is done. I'm a little bit worried about giving people the impression that a recalibration is necessary for things to work which could be frustrating

@krkeegan
Copy link
Collaborator

which could be frustrating

Yeah, totally agree. While I think this is important, it doesn't seem like the changes will be earth shattering to most people.

Alright I think your note is probably sufficient.

@krkeegan
Copy link
Collaborator

Also, we might be able to use a decimal value 8113.7. I still haven't had the chance to track down where this goes wrong in the firmware. I should be able to this weekend, but off to Star Wars tonight!

@davidelang
Copy link
Contributor

davidelang commented Dec 15, 2017 via email

@BarbourSmith BarbourSmith merged commit 8893bb5 into master Dec 15, 2017
@BarbourSmith BarbourSmith deleted the Add-new-encoder-steps-setting-to-GC branch December 15, 2017 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants