Skip to content

step_info overshoot error #554

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

Closed
juanodecc opened this issue Mar 2, 2021 · 2 comments · Fixed by #555
Closed

step_info overshoot error #554

juanodecc opened this issue Mar 2, 2021 · 2 comments · Fixed by #555

Comments

@juanodecc
Copy link
Contributor

Hi, the overshoot calculate by step_info function is wrong for this transfer function:

import control as ctrl #control 0.8.3
import matplotlib.pyplot as plt #matplotlib 3.2.2

transferFunction = ctrl.tf([0.6287,37.74,774.4,5797,7515],[1.629,45.74,788.4,5809,7515])

time, out = ctrl.step_response(transferFunction)

plt.figure()
plt.grid()
plt.plot(time, out)

fig

ctrl.step_info(transferFunction)

{'RiseTime': 0.051990934709959705,
'SettlingTime': 0.4289252113571676,
'SettlingMin': 0.9121688025464874,
'SettlingMax': 1.1826717168233585,
'Overshoot': 29.748622946474416,
'Undershoot': 0.3859422958870473,
'Peak': 1.1826717168233585,
'PeakTime': 0.13430991466739592,
'SteadyStateValue': 0.9999984629917944}

@bnavigator
Copy link
Contributor

Thanks for bringing up the issue @juanodecc. I can confirm, although the plot is smoother with the new timevector calculation in 0.8.4 (#420), that the Overshoot value is still not what you would expect.

Figure_1

'Overshoot': 100. * (yout.max() - InfValue) / (InfValue - yout[0]),

yout[0] here is 0.386 instead of 0. Not sure, why this is referenced here. The step_response() of a system without any further specification of initial values should start from default initial value of 0.

@sawyerbfuller, do you think the response vector calculation should be adjusted or just the calculation of Overshoot?

@sawyerbfuller
Copy link
Contributor

This is a good catch. out[0] is not zero because this is not a strictly proper transfer function: the order of the numerator and denominator are the same.

My take on it is that the overshoot calculation has a bug that neglects this case. It should not depend on the value of yout[0].

@sawyerbfuller sawyerbfuller linked a pull request Mar 4, 2021 that will close this issue
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 a pull request may close this issue.

3 participants