When we run our shooter command, the motors aren’t running smoothly at the speed they’ve been set to.
The command is just setting the two motors to 100% power.
But when run, the motors flicker, as in they turn on and off.
In test mode, the motors run smoothly.
Does anyone know what the issue could be? Is there any particular code that might be useful to see?
Is your shooter on a 40a or 20a breaker? If you’re running it on a 20a breaker and its a full CIM than you could very well be tripping the breaker.
Additionally, ensure all cables (ethernet, power, etc) are tight because the vibration from your shooter wheel may be causing the cables to wiggle out of their places.
If this is still causing issues, replace the fuses that the wheel is connected to.
If you’re still having issues, replace the CIM and double check wiring.
E/ good info for people whose motors aren’t consistently working. Not for you.
Add debug outputs in everything thats calling the shooter motor (including the initialize and finished methods of the shooter command) and post the output + code
Team 2481 is running in to a similar issue. We are in the midst of debugging it but when running a command from the dashboard the following is happening.
Initialize is called.
Interrupted is called.
Initialize is called.
Interrupted is called.
Initialize is called.
Command executes as expected.
When this occurs the button on the SmartDashboard is flickering.
The initialize/interrupted cycle occurs 0 to n number of times before the command finally executes.
We will be doing more debugging on Thursday and report back here with our findings. The only current theory we have is that the command is somehow interrupting itself. This our 4th year using command based and we have never seen anything like this before.
I had this problem last year on our tote lifter chain. I think I just set it too .99 instead of 1 and that fixed it.
If that fixed it, it sounds like a calibration issue with the motor controller, or possibly using the wrong motor controller object in code.
@OP - A couple years ago my team had an issue and the root cause was 2 commands fighting each other. If you are using a command based architecture this may be your issue.
We determined the root cause of our problem. I’m not sure if the cause is the same for the OP or not but I said I would report back so here goes.
This call was in TeleopPeriodic instead of RobotInit where it should have been.
SmartDashboard::PutData(new RotateToAngleCommand(45));
We eventually figured this out by placing a printf in the constructor of RotateToAngleCommand. When the log filled up with statements very quickly it was obvious the SmartDashboard::PutData command was likely in a periodic function.
In the end we had 100’s of instances of the RotateToAngleCommand in memory. Given enough time I’m sure we would have run out of memory. When invoking the command from the dashboard several of the instances were being scheduled at the same time and causing the stuttering.