PID on 2 motor Shooter Wheel

Technical Technical Discussion
#1

I’ve read a bunch of threads on PID, but have not found ideas/examples for controlling a wheel shooter with 2 motors using PID. I’m planning to use a belt to connect the motors to the shooting wheel. We are coding in Java.

Is it better to mount the encoder on the wheel, on the motor or it doesn’t matter that much? I’m leaning toward mounting an encoder on the wheel axle, as I think its easier. However I’m open to suggestions.

When controlling the motors should the on/off command be sent to both motor controllers or is there an advantage to slaving one motor to the other?

Dave
Build mentor, able to pass java code to the programming team in a single bound.

#2

If you use CAN talon SRX, you can control one with the internal PID and the other slaved to it. I’d say it would be best to have the encoder on the wheel shaft. It would be connected directly to the Talon SRX that is the master.

#3

Although I am not a programmer, my team mounted our encoders onto our main shaft. This way we didn’t have to deal with reductions in code (2:1 reductiom originally then ~4:1 later). I believe there are other benefits such as not having to use multiple encoders for multiple motors.

#4

Where you attach the motor is a matter of convenience and robustness. Putting it on the wheel will give better indication of the actual speed and require fewer gearing conversions, but on the motor may be better isolated from shock loads. You also need to ensure that you don’t exceed the maximum speed of your encoder’s capability, though with FRC hardware that’s less common than if you were using, say, arduino.

Before answering whether to slave/follow o drive directly, you need to decide whether the encoder signal comes to the RIO or the motor controller (most likely SRX, though Jaguar is another possibility). Sending the signal to an SRX is typically much easier to wire and more robust because (at your end) it’s simpler; no need to set up PID objects and manipulate them, just send relatively straightforward commands to the SRX telling it what you want it to do. If you do this, follower mode is definitely definitely the way to go. Why ask one SRX what it’s doing so you can give the other that bit of info when they can do it themselves?

If you’re having the RIO implement PID, it’s a matter of personal preference. Personally, I’d simplify the software and do follower mode or a PWM Y cable, so that there is less likelihood that somewhere one motor gets set and the other is forgotten.

#5

Slaving one motor to the other is the right way to go. It means only one Talon SRX is running the control loop and thus there’s no chance of a mismatch in signal between the two. You basically treat the 2 motor shooter exactly the same as a one motor for PID purposes.

Where the encoder goes doesn’t really matter as long as the system is all mechanically linked together. Motors geared to a common shaft will spin at the same speeds, so as long as you account for any reduction you’ll get an accurate result no matter where in the gear train you put the encoder. Just be sure you don’t saturate your sensor or anything.

#6

For the sake of conversation, say you don’t have an SRX and are doing the PID on the RIO.

Are there any concerns simply sending the same command to both motors (perhaps inside of usePIDOutput(), presuming you’re using the “extends PIDController” form in Java)? I think slight differences in motor controller/motor physics might lead to the same command meaning different torque/speeds… but if its all one mechanical member, what sort of adverse affects are we looking at?

What are the differences in control between the two mounting positions? The math to convert is usually trivial, but you still have to get it right. Gear lash probably also plays a decent role, mostly near zero speed (rare) or on impact loads (fairly common). Historically I’ve always told CAD/mechanical “just put it wherever you can fit it” and we’ll deal, but I’m not sure if there’s a better answer…

#7

Another thing to keep in mind while using slave mode is to check each motor individually to make sure both are running. We got slave mode working, but we had issues along the way with only 1 of the 2 running, making us wonder why only one of the motors were hot. Unplug the master and try to run the shooter using only the slave, then unplug the slave and try the master on its own as well. Since the slave motor spins the encoder plugged into the master, the slave should run on it’s own just like the master would. Although most of our issues we’re self-caused, it’s definitely something to check, and could save you a lot of heartache. (it would’ve saved me some :D)

#8

Another thing you need to consider is if you actually want both wheels going at the same speed. If you’re using two horizontal flywheels, then having them at the same speed is a must. You might even consider mechanically linking them to ensure it. However, one thing I haven’t seen mentioned here is that if you’re using two vertical flywheels you might want the bottom one to go slightly faster to give the ball some backspin. In that case, you can’t simply slave one Talon to the other. You can manually “slave” them (in the sense that you’re only running one PID loop) by getting the first Talon’s output %, multiplying that by some factor, (trimming to 100% if the factor is >1,) and sending that to the second Talon.

#9

Whether running at the same or a different speed, if you are NOT mechanically linking those wheels, use two encoders and drive the motor controllers with separate PID loops. Do not assume the two systems will behave the same given the same inputs; the internal and external variables beyond your control are, well, beyond your control.

#10

Very true, but that said, if you CAN mechanically link the two wheels (assuming they can always run at a fixed ratio to each other, 1:1 or otherwise) I would strongly recommend doing so.

Linking the wheels mechanically will ensure far greater relative consistency between the two wheels, and simplifies powering them since you could use a VersaPlanetary Dual-Motor input and just run the same power values to both motors. You would still need an encoder somewhere to maintain overall speed (though you could also use voltage control which many teams seem to swear by), but even that is far simpler than trying to have two separate motors try to match each others speed while compensating for slow-down associated with actually shooting an object.

#11

Ah yes. I probably should have said that more clearly.

#12

Hi All:
Thanks for the advice.

My team could use additional advice on slaving motors or should we just send the same command to each. We are expecting to have both motors mechanically connected. So if one has a little more power, my expectation is that it will do a little more of the work.

Found a link to this article, but this post is about independent screw position.
https://www.chiefdelphi.com/forums/showthread.php?t=134738&highlight=motor+slaving

Would a “Y” PWM cable from the RIO to each controller do this?
If we use CAN is everything handled in software?

Dave

#13

It’s been a while but as I recall using “Y” cables is still an accepted method for PWM control.

With CAN, assuming you’re using TalonSRXs, there’s actually a function in the default libraries that allows you to “slave” one of the controllers to another. There may also be a way to do it through the CAN interface on the RoboRIO but I’m not familiar with the specifics on this.

#14

If you use PWM, a Y cable will do exactly what you’re describing - you just send one signal out as if it was one motor and both motors will have the same voltage.

For CAN, you write a line of code setting 1 controller as a follower / slave to the other. Many examples of this in the Talon SRX guide.