Consistent Shooter Power

The PROBLEM: 

 During meet 1, we found that the shooter accuracy was very inconsistent. This made it hard to score rings in both Autonomous and Driver-Controlled portions of the meet. During the Driver-Controlled portion, the team could compensate somewhat if they saw they were shooting too high or too low, but we usually wasted a couple of rings determining how far off we were. 

The DIAGNOSIS: 

 Shooter accuracy appears to have been affected by at least two different factors.

 

1) The mechanism for feeding rings into the shooter wheel did did not consistently deliver the rings the same way every time. Sometimes rings would be tipped at a slight angle when hitting the wheel or hit the wheel at a different speed.

 

2) The speed that the motor itself is spinning seemed highly dependent on the battery power. During one match, we used a battery that seemed overcharged and had a higher voltage than the previous matches. During this match, the shooter tended to shoot much faster, harder, and higher. This was difficult for our team to adapt to on the fly (and impossible for autonomous to adapt). We'll talk about the changes to the feeding mechanism in a different entry. For now, let's focus on the variable motor speed (issue #2). 

The SOLUTION: 

During our post-match SWOT meeting, we discussed the possibility of writing code that could identify the battery voltage and alter the power applied to the shooter motor accordingly. Nathan did some research after the match and found a much simpler solution; one we should have been using from the beginning. 

First, a special shout-out to Game Manual Zero (https://gm0.org/en/stable/). We highly recommend it as a superb reference for new and experienced teams alike. Their documentation is much better organized and understandable that most of the official FTC documentation. 

Reading Game Manual Zero's entry on the different modes for DC Motors, it clicked. We have been using RUN_WITHOUT_ENCODER instead of RUN_USING_ENCODER. This is because we didn't REALLY understand exactly how RUN_USING_ENCODER works. 

For RUN_WITHOUT_ENCODER, you tell the motor what percentage of power to run at (e.g. 0.7 for 70%) with the setPower() command. 

For RUN_USING_ENCODER, you tell the motor what percentage of its max velocity to run at (e.g. 0.7 for 70% of the motor's max speed). The PID controller then uses feedback from the encoder to alter the amount of power being sent to the motor. Unfortunately, the command to set the desired velocity is also setPower(). This is why we didn't really understand it before. 

As our batteries drained while using RUN_WITHOUT_ENCODER, the system kept applying the same percentage of available power to the motor. This resulted in a slower motor as practice or matches continued. With RUN_USING_ENCODER, as the battery depletes, the system can push a higher percentage of the available power to the motor in order to keep a more constant speed. This is like cruise control on an automobile. You set the target speed and then the system will modify how much gas to give based on feedback about whether the call is slowing down or not. 

The PROGNOSIS: 

Upon making the change, we immediately started seeing odd behavior. The motor only seemed to either spin at max power or not spin at all, regardless of what target velocity we set. 

After quite a bit of troubleshooting, the answer was embarrasingly obvious. Since we had only ever been using RUN_WITHOUT_ENCODER with this motor, we never plugged in an encoder cable. As the PID controller tried to achieve the target velocity, it never received feedback from the encoder, so it continued to apply power until it was maxed out. 

Once we plugged in an encoder cable, we saw immediate improvement. All of our initial testing seems to point to a much more consistent shooter motor power. This is helping with Autonomous development as we're able to better plan what position the robot needs to be on the field. Match 2 is coming up fast; that will be the true test, but we are feeling much better now.