I am wondering what are the popular and/or quickest to implement algorithms to get a single flywheel shooter to fire balls consistently. While prototyping our shooter, we simply set our motor to a certain power level, or ran it off of a joystick. Right now I’m thinking of using the TalonSRX’s velocity control mode with a quad encoder plugged into a breakout board on the talon for feedback. What other effective alternatives are there?
2 Likes
Check out this video https://youtu.be/KZX2-qx93VM
We managed a high level of accuracy with a good balls per second rate with a single 775 pro on a 3:1 reduction just setting the speed to 82.5 % in the code
My team isn’t very smart (in the programming department), so one solution is to simply gear your shooter such that your desired RPM can be acquired at around 60-75 percent power. Throughout the course of a 2:30 match with average robot current draw, I do not notice any significant decrease in shooter wheel speed.
If you’re shooting fast you also need to put a bigass metal flywheel on it to maintain speed between intermittent shots, however.
My team is using 2 775 Pros geared 2:1 running a 4" Colson. Although we haven’t had a lot of time to mess with our shooter and tune it, we have seen some good results. We have intentions on add an encoder but haven’t had the time yet to. We also add a 3.75" stainless steel flywheel which weighs about a pound to keep our shots consistent. We may try to rearrange how things mount so we can fit another flywheel. If there is one thing I’ve seen from videos so far, I think the key to shooting quick and consistent this year is having a flywheel to maintain speed.
Dual 775pros, BaneBots 4:1, 1:1 chain and sprocket run, and replacing the collar clamps between our 4" compliant wheels with spare steel Toughbox gears to increase mass.
(Full disclosure of the probably obvious: I work at AndyMark. We sell everything on that list, save for the 775pros.)
-Mechanical answer: more weight, less compression
-Simplest Software Answer (that I know of): hook up the encoder, read it every loop. Pick an RPM you want to run at. If the encoder reads slower than that RPM, run the motor at full power. If the speed is faster than the desired RPM, send zero command to the motor. (This is a bang-bang controller)
If you want to maintain a certain speed, the best way is to measure that speed, and do something to get it right. Other methods are fraught with pitfalls, but may work under certain conditions (as others have mentioned).
As far as software, the talon velocity closed-loop is probably the best way to keep the speed up. Just make sure you have the most up to date firmware (2.34), as there are some bugs in some older versions.
You can run a PID Loop in your code to mantain speed… Did that last year and worked neatly… You can even show the graph of the speed in the dashboard so you can see how it reacts…
Besides this, I would recommend using a flywheel (heavy mass in the rotating shooter), to increase inertia and thus keep the shooter from decelerating each time a ball is shot.
What is everyone’s thoughts on the “voltage mode” function of CAN Talons as a way to maintain shooter speed?
I was speaking to a team at a week 0.5 event who swore by it, and said that they didn’t have any issue with RPM loss because the response time was so fast. This seems like the simplest thing to do if, in fact, it works.
Better than just sending a command, not as good as actually measuring & controlling around speed.
For a constant load torque and temperature, Voltage determines the steady-state speed.
If your shooter has enough inertia this year, and you don’t put fuel in too fast, “constant load” could be assumed to be reasonably accurate. In this case, I think this would be a decent gain in performance for very little effort in writing/tuning software, and attaching new hardware.
Question for teams who have used bang-bang: Do any of you have any hard data (or, lacking that, qualitative observations) comparing coast and brake modes?
**
So maintaining flywheel shooter speed is a difficult task, especially when you have a lot of balls passing through quickly, as each ball lowers your speed slightly.
There are mechanical methods and programmatic methods to do this, and a good solution really requires both.
I’m more adept at the mechanical methods, so I’ll try to speak to those, whereas some people more intelligent than me can try to discuss different methods of speed control.
Something spinning at a speed has a rotational inertia, and balls passing through it try to slow it down. You can increase your rotational inertia by adding mass to your spinning object for example. By increasing the moment of inertia of the flywheel, it takes less of a hit to speed when a ball passes through.
In physics terms, you’re increasing your moment of inertia, I, by adding mass, m, at a distance away from the shaft, r:
Moment of Inertia of a Cylinder:
I = (1/2)*m*r^2
The ball applies a torque, F, at the outer radius of your wheel, R (not necessarily the same “r” as the r above for the moment of inertia equation, depending on how you weigh down your flywheel), generating a torque. Torque is also equal to the Moment of Inertia times the angular acceleration, w’
F*R = I*w'
So to reduce your loss in speed, you want to minimize the value of w’
F*R/I = w'
That could mean decreasing the radius, R, decreasing the force by decreasing your compression, or increasing I by adding mass at a distance from the shaft.
Other ways to increase I might be adding more motors to your system, which also can help decrease your spin-up time.
(Also people, please correct me if I’m wrong)
2 Likes
I have an idea what happens using a bang-bang controller in brake mode, and I’m too scared to actually try it. I’d use bang-bang with coasting any day, but brake mode? I don’t want to be rapidly switching between shorting the motor terminals and applying full Vbat to them.
From a thought experiment:
- Control systems will inevitably have delay
- When zero speed is commanded, coast mode will let the actual motor RPM spool down at a gentler rate than in brake mode
- By the time the control system catches up with reality and commands the motor back on, the actual RPM should stay closer to the target RPM.
- Therefore, coast is better?
BUT
- Presume the same delay for the rising edge of the RPM cycle (motor RPM < desired RPM, motor commanded on). This delay, combined with the physics of your flywheel/motor, will determine your actual RPM overshoot.
- The actual RPM will crest after the motor RPM turns off, and begin to decrease along some profile (depending on brake/coast, and the system physics)
- As long as the on/off delay is the same, to average out to the target RPM, you need your spoolup/spooldown rates to be the same
– If they are not the same, you will end up slightly above or below your setpoint on average
-Therefore, “it depends”?
Also, from a mechanical perspective, the delta-torque of brake mode while cycling on and off near the target RPM would be higher than using coast mode. This extra shock to the system could loosen bolts and wear on gearboxes faster… how much faster, I’m not certain.
All this being said, I too would still like to see data and others experiences.
Has anyone actually tried this? Please tell us about it.
Please clarify what you mean by “after the motor RPM turns off”. Once power is removed from the motor there will be no further increase in speed. The only overshoot is due to the period of your control cycle.
Well I can tell you that my former team (4908) has decided to solve the problem of this post (maintaining flywheel speed during shooting) by just using more motors. Right now they have 4 RS775 pros on a 3:1 reduction. They also added weights to the flywheel.
Edit: wording changed for clarity. Apologies to Ether
What does the pronoun “this” refer to? There’s no context in your post to disambiguate it.
Very poor wording on my part - I mean to say the RPM ceases to increase as soon as the driving voltage is no longer applied (which occurs some relatively-fixed time after the RPM actually crosses the target RPM).
How rapidly the actual RPM starts to drop after this event is again system-physics and brake/coast mode determined.
Much clearer. Thank you.
We aren’t shooting this year, but Last year with our shooter, the first thing we tried was bang-bang. We were using a Victor 888. The first time we tried it made the loudest, worst crashing/banging sound you can imagine. The speed also oscillated wildly, never quite reaching the setpoint (and If so very, very, briefly). It was consistently about 7 units (measured encoder speed, not really a standard unit) below our set point of 50. After we took out the jumper for brake mode to set it to coast, however, It became much better. It no longer sounded like it was going to explode, and it was staying within ± 2 of the set point. 
We achieved even better results after we decided to use Take Back Half Control instead of bang-bang. The measured speed consistently stayed within ± 1 of the set point, and it still came up to speed almost as fast as with bang-bang (It took around 3 seconds as compared to 2 with bang-bang). I would definitely recommend Take-Back-Half.