You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several times in practice and comp, our catapult would just refuse to work because the cable was finicky and would sometimes disconnect momentarily while the catapult was retracting. Now, we have several safeguards for this including a good cable and a software safeguard. I was wondering if this software solution, or something similar to it, could be built in to PROS.
Generalized Problem
Observed Behavior
Motor does not resume spinning after being momentarily disconnected (meaning the motor disconnects then reconnects)
Expected Behavior
Motor resumes spinning after being reconnected
Steps to Reproduce
Use a while loop to tell the motor to spin at 127 every 10ms
Disconnect the cable and reconnect it
Watch in despair as the motor doesn't resume its spinning
Hypothesis
The brain optimizes the number of messages sent to the motor by only notifying the motor about voltage changes. The requested voltage is stored in some form of volatile memory on the motor, such that when the motor loses power, the requested voltage is erased.
So in our example, only the first iteration of our while loop sends the message to the motor to spin at 127 power, because the voltage changed from 0 to 127. Every iteration after that does nothing. When the motor disconnects, the motor forgets that it should be spinning at 127 power, and thus it will not spin until the brain tells it to again. And the brain will never tell the motor to spin again, because we never change the voltage except for the first iteration of the while loop.
Note
This is just my hypothesis that explains the behavior that I observed. There is a good chance its not correct or not the full story.
Attempted Solutions:
Send a different voltage to the motor every so often
❌ This leads to the motor stuttering, at least for our catapult, and sacrifices power
Sense motor disconnect and reconnect
❌ Does not detect very quick motor disconnects
❌ It takes a seemingly random amount of time for the motor to be capable of receiving power after reconnecting.
Check current is not 0
Essentially, if the motor is spinning, then it should be drawing some amount of current
So we can use this to ensure that the motor spins: If the motor current is 0 for longer than 50ms, then vary power sent to the motor until current is no longer 0
✅ This was the only method that worked for me. (My code)
What is the behavior that isn't addressed by the existing API?
Currently, PROS doesn't provide any safeguards for this momentary motor disconnect edge case.
Is this a problem that needs to be addressed by PROS? Probably not, as it is a small edge case, but it would be pretty cool.
Additional context
I believe this also occurs when radio disconnects and reconnects while field control is connected, but I have only heard this and have not tested it.
I'd be willing to submit a pr implementing this if I were given guidance on where and how, assuming its feasible for this to be built in to PROS.
The text was updated successfully, but these errors were encountered:
This feels like something which should ideally be fixed on the vexOS end; it knows when the motor has disconnected and should mark the saved motor command as "not saved" in that event. That would be the proper solution.
I agree that this shouldn't go in the kernel, or at least shouldn't be the default behaviour. The main issue I have with it is that it is a heuristic-based approach, rather than an actual fix to the logic, and it operates by modifying the command sent to the motor away from what user code requested. This adds a significant layer of complication to the motor behaviour, with lots of opportunity for bugs and unintended effects on performance. The fact that a fix to the logic cannot be done from the PROS or user code side is besides the point.
The problem that led me here
Several times in practice and comp, our catapult would just refuse to work because the cable was finicky and would sometimes disconnect momentarily while the catapult was retracting. Now, we have several safeguards for this including a good cable and a software safeguard. I was wondering if this software solution, or something similar to it, could be built in to PROS.
Generalized Problem
Observed Behavior
Motor does not resume spinning after being momentarily disconnected (meaning the motor disconnects then reconnects)
Expected Behavior
Motor resumes spinning after being reconnected
Steps to Reproduce
Hypothesis
The brain optimizes the number of messages sent to the motor by only notifying the motor about voltage changes. The requested voltage is stored in some form of volatile memory on the motor, such that when the motor loses power, the requested voltage is erased.
So in our example, only the first iteration of our while loop sends the message to the motor to spin at 127 power, because the voltage changed from 0 to 127. Every iteration after that does nothing. When the motor disconnects, the motor forgets that it should be spinning at 127 power, and thus it will not spin until the brain tells it to again. And the brain will never tell the motor to spin again, because we never change the voltage except for the first iteration of the while loop.
Note
This is just my hypothesis that explains the behavior that I observed. There is a good chance its not correct or not the full story.
Attempted Solutions:
What is the behavior that isn't addressed by the existing API?
Currently, PROS doesn't provide any safeguards for this momentary motor disconnect edge case.
Is this a problem that needs to be addressed by PROS? Probably not, as it is a small edge case, but it would be pretty cool.
Additional context
I believe this also occurs when radio disconnects and reconnects while field control is connected, but I have only heard this and have not tested it.
I'd be willing to submit a pr implementing this if I were given guidance on where and how, assuming its feasible for this to be built in to PROS.
The text was updated successfully, but these errors were encountered: