Looking for help with programming encoder!

Hello, we are FTC team Da Geese of Freedom #18312 from Arizona! We are currently going through some encoder issues. We are using two hex motors with encoders to shoot our rings from our launching mechanism. In our autonomous code, we have programmed the motors to reach a velocity of 1200 RPM (revolutions per minute). It takes ~20 seconds to reach the RPM. our issue is that we would like to reach this speed much faster, does anyone happen to have any experience with this? How do you and your team program your encoders to quickly reach your desired RPM?

We would appreciate any help or advice you can offer,
Gaby H. & Natali R.
Da Geese of Freedom
Honk honk

1 Like

Here is the code our team (4152) used for our FRC shooter. Different motor controllers but the logic should be the same:
Shooter code

Shooter Rev command

1 Like

I’m definitely not an expert in ftc code but I would love to help. I’m a little confused about your setup though.

Are you using two motors with two encoders both mechanically driving the same output or are they separated?

How do you get to that rpm? Manual control/bang-bang? PID? Motion magic or motion profiling? If you are using pid, you could try adjusting your constants. A higher P term should make it respond more aggressively.

What speeds are you geared for? If 1200 is at the very high end of the speed you are capable of reaching it may just need a lot of time to accelerate.


Thank you for the response!
Answer to the motor question: we have two motors with two encoders, they are separate (the values are separate). (the wheels spin in opposite directions). We don’t know how to access the variables - for the FTC library, the code is given and the controller is already set up for us. We have the ability to reach higher RPMs, but we chose 1200 because it works with the angle and distance that we’re shooting at. :slight_smile:

  • nat. ^^

They gave you a PID controller and no access to the coefficients? Time to make your own. (It’s not hard.)

1 Like

We’re gonna attempt to set PID variables using (view below)

Has anyone used this function and/or have advice for when we start tuning?

Can you graph the output? I know little about FTC, but the FRC controls tutorial is incredibly helpful. This link takes you to the beginning, but they go through the whole process. It gets complex quickly, but it is helping us a lot. We are just learning too.

If your needing to tune the pid coefficients you will definitely need to graph you target velocity to your measured velocity.
The FTC software ecosystem doesn’t natively provide you the ability to graph it. However you can use FTCDashboard which provides the capabilities to do this.

FTCDashboard link: Overview | FTC Dashboard

1 Like

I would first figure out what your F value should be. A rule of thumb that you can use is F = 32767 / MAX_TICKS_PER_SECOND. MAX_TICKS_PER_SECOND for the core hex motor is ~600 if I remember correctly but consult the REV website to double check. Going with my bad memory for one moment… 32767/600 = 55.5 = F. This should get you pretty close.

Next Configure P. The rule of thumb that I use for this is to start at 10% * F. Increase P if you want a system that is more responsive but also more unstable. Try this and see how it goes.

Hi @Natali!
Two questions:

  1. Could you please post your code here? That would be appriciated so it’s easier for us to help you!

  2. Have you tried applying 100% power directly to the motors? If so, and it’s still taking 20 seconds to reach that RPM, then no PID is going to help you. A PID isn’t going to magically give your robot more juice. You’re going to have to find a mechanical fix by reducing the mass of your shooter wheels or changing the gear ratio and thus target RPM. I can look tomorrow to see what our team is currently using.

We found the PID controller without constants to actually we quite effective with our shooter. Unless you have experience with the FTC PID’s yourself, I think it’s bold to automatically start telling people they should custom make their own.

The problem is not efficacy. It’s the fact that the library prevents the tuning process, which is crucial hands-on learning about how a PID controller actually works. In my opinion, that is one of the most useful things one can learn from programming robots.

Secondly, a single-tuning PID controller can only go so far. It would work for many FTC cases, but were I in this scenario, I would likely begin to treat it as a magic bullet. This is a dangerous assumption, especially for an algorithm that is so dependent on its constants.

Furthermore, the ability to specify PID constants per motor does alleviate some of that concern, but it seems to be a somewhat major structure change to make after finding out that the default PID controller doesn’t do well enough.

1 Like