Skip to content

fix windup issue #388

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

Merged
merged 4 commits into from
May 3, 2025
Merged

fix windup issue #388

merged 4 commits into from
May 3, 2025

Conversation

LeanMeanBeanMachine4774
Copy link
Contributor

No description provided.

Copy link
Contributor Author

@LeanMeanBeanMachine4774 LeanMeanBeanMachine4774 left a comment

Choose a reason for hiding this comment

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

Also works if the setpoint time is updated immediatelly in the retract rather than _force_retract. I beleive we can expect the same behaviour in the wrist where doing it on enable works or in tilt_to but not _tilt_to

Copy link
Contributor Author

@LeanMeanBeanMachine4774 LeanMeanBeanMachine4774 left a comment

Choose a reason for hiding this comment

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

Little bit of weirdness when implemented on wrist

@LeanMeanBeanMachine4774
Copy link
Contributor Author

Weirdness is cause by removing the wrist execute from disabled not by the change itself. @LucienMorey, @auscompgeek what was the reason for that execute in the first place, isn't it a little dangerous?

@LucienMorey
Copy link
Contributor

I am sceptical of this fix. I am not saying it doesn't do the bits, but moving the time reset effectively a few lines earlier doesn't make sense on its own. My observation of the robot is that it doesn't always happen, either, so maybe you're just getting lucky. Also, the bad behaviour happens a lot in test mode, which on_enable has no impact on.

@LucienMorey
Copy link
Contributor

LucienMorey commented Apr 28, 2025

Weirdness is cause by removing the wrist execute from disabled not by the change itself. @LucienMorey, @auscompgeek what was the reason for that execute in the first place, isn't it a little dangerous?

it was added in this pr: #104 I think it was originally part of the zeroing processes when we had to index. It isn't really dangerous on its own but it is a bit smelly. It can go now.

you are also marked as a reviewer on this one :P

@LeanMeanBeanMachine4774
Copy link
Contributor Author

I am sceptical of this fix. I am not saying it doesn't do the bits, but moving the time reset effectively a few lines earlier doesn't make sense on its own. My observation of the robot is that it doesn't always happen, either, so maybe you're just getting lucky. Also, the bad behaviour happens a lot in test mode, which on_enable has no impact on.

I understand, just testing in the sim, it seems to change the operation. Unsure why, but maybe we need to test and see

@LeanMeanBeanMachine4774
Copy link
Contributor Author

LeanMeanBeanMachine4774 commented Apr 28, 2025

I am sceptical of this fix. I am not saying it doesn't do the bits, but moving the time reset effectively a few lines earlier doesn't make sense on its own. My observation of the robot is that it doesn't always happen, either, so maybe you're just getting lucky. Also, the bad behaviour happens a lot in test mode, which on_enable has no impact on.

I would have to be very lucky for it to just be luck, given I tested it on off about 15 times. Although I do see no way of making it work without on enable.

@LucienMorey
Copy link
Contributor

I am sceptical of this fix. I am not saying it doesn't do the bits, but moving the time reset effectively a few lines earlier doesn't make sense on its own. My observation of the robot is that it doesn't always happen, either, so maybe you're just getting lucky. Also, the bad behaviour happens a lot in test mode, which on_enable has no impact on.

I would have to be very lucky for it to just be luck, given I tested it on off about 15 times. Although I do see no way of making it work without on enable.

How are you testing this?

@LeanMeanBeanMachine4774
Copy link
Contributor Author

I am sceptical of this fix. I am not saying it doesn't do the bits, but moving the time reset effectively a few lines earlier doesn't make sense on its own. My observation of the robot is that it doesn't always happen, either, so maybe you're just getting lucky. Also, the bad behaviour happens a lot in test mode, which on_enable has no impact on.

I would have to be very lucky for it to just be luck, given I tested it on off about 15 times. Although I do see no way of making it work without on enable.

How are you testing this?

In sim I enable in teleop, drop the intake, disable before it comes up then re enable after 5 seconds. I did this without the fix to confirm the extremely rapid retract. WIth the fix, I do the same and it retracts as expected

@LeanMeanBeanMachine4774
Copy link
Contributor Author

Also, can confirm issue remains in test

@LeanMeanBeanMachine4774
Copy link
Contributor Author

unknown_replay_2025.04.28-22.31.-.Trim.mp4

@LucienMorey
Copy link
Contributor

LucienMorey commented Apr 28, 2025

Also, can confirm issue remains in test

yea this is what I was interested in.

FYI:

robotpy/robotpy-wpilib-utilities#217
robotpy/robotpy-wpilib-utilities#218

@LucienMorey
Copy link
Contributor

this does the things properly now that my prs have been merged

@LucienMorey LucienMorey marked this pull request as ready for review May 3, 2025 08:38
@LucienMorey LucienMorey self-requested a review May 3, 2025 08:38
@LucienMorey LucienMorey merged commit 10b83f5 into main May 3, 2025
7 checks passed
@LucienMorey LucienMorey deleted the fix-windup branch May 3, 2025 08:39
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