Control Shooter RPM with a Counter

Technical NI LabVIEW
1

During GTR East, we at Team 1325 used only motor speed to control the speed of our shooter. This works when the batter is fully charged, but the actual shooter speed seems to fluctuate when our batter voltage starts to drop. We decided that we should use a sensor of some sort to set an RPM for the shooter instead of having to rely on the motor speed.

Since GTR East, we have attached a Honeywell 1GT101DC sensor on the front wheel of our shooter, and a piece of steel that rotates on the rear wheel. The magnetic sensor picks up the steel passing it, and with some simple counter code, I was successful at getting an RPM readout from the sensor on the DriverStation and Dashboard.

The datasheet for the sensor: http://sccatalog.honeywell.com/imc/printfriendly.asp?FAM=solidstate&PN=1GT101DC

I am now stuck on how to get the sensor to send a certain RPM to the motors. As an example, I want to send 2000 RPM to the “At Pyramid” preset, 2500 RPM to the “Half Field” preset, and 3000 RPM to the “Full Field” preset. I’m not sure exactly how I could achieve this.

Here is the code I have so far.

Begin vi for the counter: http://imgur.com/w9ReMQ1,30cMCXH#0

Custom Shooter Vi: http://imgur.com/w9ReMQ1,30cMCXH#1
Note that the output from the select functions in this vi go directly to the shooter motors, which were of the screen when I captured this screen shot.

Here are the direct links to the images, in case you cannot see them.
http://imgur.com/w9ReMQ1,30cMCXH#0
http://imgur.com/w9ReMQ1,30cMCXH#1

Any help would be greatly appreciated.

See you at the GTR West and St. Louis!

2

I’ll take a shot on answering your question, but I have two of my own first.

I’m not sure why you using an inplace element structure, the yellow box. That is a very advanced structure and isn’t really used very often. You are publishing the RPM as a single element array of numbers. I’m curious why you did these things?

To control the speed, I’d compare the sensor speed to the set point speed. If the measured speed is greater or equal to the set point, let the motor coast by selecting zero for the speed and ensure that the motor controller jumper is set to coast and not brake. If the measure speed is less than the set point, set it to a value that will accelerate the wheel – such as 1.0 or -1.0. If you want to search and read for more, this is referred to as bang-bang control since the motor control is accomplished with just two value responses.

Greg McKaskle

3

Thank you for your reply, I’ll take what you said into consideration. The inplace element structure was used to give the drivers a “custom override” of the shooter speed. If they wanted to change the speed to their own liking, they could use the throttle on the joystick to change the shooter motor speed at their own will. The elements inside the structure used to make the axis on the joystick range 0 to 1 instead of -1 to 1.

4

The inplace element structure is used when you want strict control of allocations. It allows you to swap out elements in a structure or array and avoid data copies being made. In reality, your usage should do nothing. I was just very surprised to see it.

Greg McKaskle

5

I believe what Greg is trying to say is: you’re not really using this to do anything. It’s just sitting there doing nothing, and you clearly don’t understand what it does (for the record neither do I, it’s really advanced). Your code would work just fine if that structure wasn’t there and the code would just have no border instead.

(Am I correct Greg?)

6

I have a complete different Idea on how I would approach this type of thing, so I figure I will outline it for you briefly, and you can let me know if you would rather look into this.

I have in my code a similar thing, expect that we change our speed with joystick buttons. However, the only difference is (and it is a big one) is that I use the CAN Serial port option to send the RPM values and use an internal PID on my shooter Jaguar. CAN, until you get used to it, is very very hard to figure out on your own. I could do my best to give tips and tricks, but no matter what, it comes down to how badly you want it to work. It works wonderfully on our robot, and we were sinking 90% of our shots once we got our feeder to work, but the hardest part comes down to the pwm is a hardware setup (you just have to run cables) and the CAN is a hardware (you have to run cables) and a software (you have to preset your jaguars) setup.

Another note on it, it only works with Jaguars, so if you have Victors, it wont help.

Lastly, if you used this option, it would be entirely different and there would be no need for a counter. The code for it however is a lot more simpler than what I see you were doing.

It all comes down to preference. If you want to make the switch to CAN, I will do everything I can to help, but it is a lot of troubleshooting until you figure out how it all works. I made the switch for just our shooter wheel this year, and I started on January 8th, and didnt have it all figured out until February. And still now, all the other people dont fully understand it yet, so at our first competition in Rochester for the Finger Lakes Regional, the Jaguars were not properly set up and I had to spend half an hour setting up the Jaguars.

The switch to CAN from PWM is hard, but I have found it quite useful, especially for wiring, because if you have the right encoders, you can put them into your Jaguar, and the only cable going across your robot is your CAN bus line cable.

7

A physical speed sensor of some sort is required to do closed-loop speed control, whether it’s done by the Jaguar with an encoder plugged into it or in the cRIO with either an encoder or counter plugged into the DSC.

The OP could have used an encoder, but he chose to use a simple counter instead, which is arguably a better choice for a unidirectional high-speed application like a shooter wheel.

8

There’s no way to have a Digital Sidecar do the same sort of offloaded closed-loop control that a Jaguar is capable of. The speed control would have to be done by the cRIO’s program, based on feedback from the encoder. You can’t read the encoder’s value without opening a Counter (or an Encoder, which uses a Counter unless you ask for 4x decoding).

9

The Jag executes its speed controller at 1000Hz, if that’s what you mean.

The speed control would have to be done by the cRIO’s program, based on feedback from the encoder.

To do closed-loop control of speed, you need a speed sensor. The OP has installed a counter for that purpose.

You can’t read the encoder’s value without opening a Counter

If that’s what TogetherSword8 meant when he used the word “counter”, then I can see how my post could be misunderstood. I will edit it for clarity.

10

Sorry about that, I did mean the counting in the code. I don’t know the exact model, but we use a magnetic tooth counter and feed that signal directly into the Jaguar.

As I said earlier, it is a matter of if you want to go through the crio or through the Jaguar. We decided to use the Jaguar because even with the loops on the CRio, you must put in a delay of some sort, and less response time equals more consistent settling speed when using a shooter wheel.

11

There was a thread a year or so ago about some teams struggling to get the built-in PID in the Jag working to control speed, and ultimately giving up.

You’ve obviously been successful. Would you be willing to post some detail about how your team went about tuning the Jag’s PID parameters to get robust and accurate speed control?

12

We decided to use the Jaguar because even with the loops on the CRio, you must put in a delay of some sort …

This implies there is no delay within the jag.

I would think the major control difference would be that the Jag runs the PID at 1KHz and the PWM signal can change the motor speed no quicker than 5ms, or at 200Hz.

The capability of doing control on the Jag is cool, but unless your flywheel is very light, I wouldn’t think that the control rate needs to be 1KHz. So you should be successful doing it either way.

Greg McKaskle

13