Our team is competing this weekend at the Michigan State Championship, i have been the programmer for about the last two years and i look to improve our shooter. The way we control the speed of the shooter is working well but we look to improve it by adding an encoder. I have played around with encoders on an old robot i had played with them and understand how they work. Although i need help using the rpm from the encoder to control the shooter speed
I currently use Labview as a programming language
What i am looking for is an example or VI that will automatically adjust the speed of the shooter to the desired rpm by using the information from the encoder. (if its going fast enough or to fast). I have looked at some of the PID Vi’s but i cant seem to find one that will work for the application im looking for. If you can help me or give me an example how to use the encoder to control the shooter that would be great. Thanks
I admire your passion for continuing to work on your code, but a word of caution is sometimes don’t over-complicate things. I am directing you to this thread http://www.chiefdelphi.com/forums/showthread.php?t=114366&highlight=Bang-bang to get started. It should get your feet off the ground. Know that your team has won two Michigan District Events so be careful when revamping code.
We use a bang-bang controller very successfully. It is very simple:
-
decide on the RPM you want for your shooter. Let’s call it DesiredRPM.
-
You have the RPM from your encoder. Call it ActualRPM.
-
Implement your LabVIEW code as follows:
if (ActualRPM < DesiredRPM)
MotorOutput = 1.0;
else
MotorOutput = 0;
The keys to this working well are:
-
Do NOT filter or use averaging of your RPM reading from your encoder.
-
Run it in the fast loop. We do it in a 30 ms loop and we get good results.
If you have any questions or want any help with setting it up or testing, come find me in our pit on Wednesday evening. I won’t be at the competition during the day on Thursday and Friday (I’ll be at work).
This particular algorithm scares me a bit. Did your robot shooter motors have issues handling the stress of constantly reversing its rotation?
First things first:
-
What model encoder are you using?
-
What motor(s) are you using?
-
What motor controller(s) are you using?
-
What is the gear ratio from your motor output shaft to the shooter wheel?
-
Where is you encoder mounted? (i.e. is it measuring the motor output shaft speed, or the wheel speed, or something in-between)
-
How are you decoding the raw signal from the encoder? (i.e. do you have it set up as a counter or an encoder, and are you reading counts or period)
-
What is your desired shooter wheel speed (aka “setpoint”)
Answering those questions will improve your chances of getting correct advice.
What do you mean by “constantly reversing its rotation” ?
This is classic Bang-Bang. Full power forward or coast. That’s it. No reversing in that code at all.
We use bang-bang on our shooter wheel, and it’s working pretty amazingly. But instead of an encoder, we have an optical sensor that is rigged as a digital signal, and set up as a Counter object in LabVIEW. We have the code running every 5 milliseconds in one of LabVIEW’s timed loops. The motor speeds back up to our desired RPM very quickly after a dropoff, and there is only a little oscillation when it reaches the RPM (not enough to affect the shot, even at full court). And Gluxon, we haven’t had any problems with our CIM or Jaguar, even running the algorithm at 200 Hz.
I had a brain hiccup while reading that code. Last time I worked on robot code, it was with a servo motor where 0 was backwards, 1 was full forward, and 0.5 was stop (weird, yes). Either way, that code is stopping and starting the motor at what I would guess to be a very high rate. I’d imagine some mechanical stress depending on the motor used, no?
If you have your speed controller jumpered into coast mode (there’s a jumper labeled “BC” for brake/coast), you shouldn’t be stressing anything. I implemented a Bang-Bang controller on last year’s shooter wheel for testing, and made some very scary-sounding repeated thunks from the wheel, but I think that was a chain re-engaging more than anything. We didn’t go for a Bang-Bang this season, instead opting for a PID controller. It has worked quite well, but it required some significant tuning. At our last competition, we retuned the controller a little, and shortened our initial spin-up time by about a second. We might be retuning it a bit this weekend as well. We’ll see.
The higher the rate, the better. The inertia of the wheel keeps the wheel speed steady in between command updates.
It’s not starting and stopping. It’s starting and coasting. One of the requirements of using bang-bang is that the motor controller jumper must be in the “coast” position.
I’d imagine some mechanical stress depending on the motor used, no?
It might, if there is excessive mechanical free play between the motor shaft and the wheel. That’s why I asked all those questions. Bang-bang works remarkably well, if you have the right mechanical design for it.
**
Check to make sure your Jags are not jumpered for voltage ramping.
Mechanical free play and bang-bang sometimes don’t go together very well. Direct coupling of motor shaft to shooter wheel is more amenable to bang-bang control.
I’m not much help with Labview code specifically, but I can help you setup the control and explain the bang-bang controller to you a bit at MSC if you want some help. Just swing by our pit and ask for Joe.
Yeah, the belt on our robot’s shooter doesn’t exactly like slamming between coast and full power. However the feed-forward we’re doing is giving us rpm control that stays within ~10 RPM of the set-point, without being hard on the belt.
You are already bang-bang controlling the motor anyway. That’s how pulse width modulation works.
If your bang-bang controller is running fast enough and your sensor input is sufficiently noisy (enough to cause many on-off transitions), then the bang-bang control method is no different on the motor than running it by PWM.
That’s not strictly true. If the motor accepts a PWM signal directly, then in some cases you may control it that way, but the speed controller is what receives your pwm signal, and it adjusts the voltage out in proportion to the PWM duty cycle, the motor never sees the pwm on-off cycles.
The motor controller receives PWM as an input signal, and it outputs a PWM voltage to the motor. That’s how it adjusts the output voltage… by Pulse-Width-Modulating the 12-volt battery power.
But there is a sense in which you’re right. The input PWM period (for the Jag) is 5ms (200Hz). The output PWM frequency (for the Jag) is 15,000Hz. 15,000Hz is fast enough that the inductance of the motor (for a CIM anyway) smooths out the current so there’s very little ripple.