✨[FEATURE REQUEST] Momentary Motor Disconnect Resilience

[meisZWFLZ]

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

1. Use a while loop to tell the motor to spin at 127 every 10ms
2. Disconnect the cable and reconnect it
3. 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:

1. Send a different voltage to the motor every so often
   • ❌ This leads to the motor stuttering, at least for our catapult, and sacrifices power (vf post on this weird behavior)
2. 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.
3. 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.

[BennyBot]

I would rather this be a template than built into the kernel.

[Exortions]

why would it need to be a template? this fix doesnt look too hard to implement

[nickmertin]

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.

[djava]

Should this be closed as not planned?

[meisZWFLZ]

Yeah, although, I would like to point out that something similar is being worked on using timestamps instead to detect micro-disconnects: LemLib/hardware#5
This doesn't solve the problem described in this issue, rather it only provides a method of detecting it.

And it doesn't address the problem of this not belonging in the kernel, since it would still greatly complicate the motor handling code for what is mostly an edge case.