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

Adjust phase when close to target, allow read_position to work while in closed loop mode #41

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

PetteriAimonen
Copy link

This pull request has two small improvements:

  • Adjustable deadband in PID output, which works so that the phase angle is adjusted with output value is close to 0. This reduces oscillations when motor friction is low, especially in position control mode.

  • Allow read position command to work when closed loop mode is active. Instead of calling readEncoder() directly, use the latest value read by interrupt.

Currently the PID loop always uses either + or - maximum phase advance.
This means that when the PID output value is 0, there is no torque applied.
This causes the motor to zoom past the setpoint if there is no external friction
to stop it, which in turn causes a lot of oscillations.

This commit adjusts the phase angle when PID output is close to zero, which
acts to brake the motor and allows it to stop accurately between steps also.

if (u > -deadband && u < deadband)
{
pa = PA * abs(u) / deadband;
Copy link

@mmwolbrink mmwolbrink Jan 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a really nice idea, I was thinking of implementing like this myself, but It looks like you beat me to it.
It might be a good idea calculate inverse of deadband once where its defined, and multiply by this inversion. I think doing an expensive division every interrupt is not good practice (Armv6 doesn't have division instruction).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly true, but it is a float division so a float multiplication is only slightly faster.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry you are correct, I forgot about the lack of floating point hardware. Out of curiosity I will try both approaches and time the results.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry you are correct, I forgot about the lack of floating point hardware. Out of curiosity I will try both approaches and time the results.

I just had some time to test, your approach took 20uS, the inverted multiplication 12uS. The code seemed to work fine.

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.

2 participants