Preferred Flywheel Programming Method?

After watching countless videos of flywheels, seeing them at tournaments, and running one myself, i’m curious to see how people go about improving their accuracy of the flywheel in the programming aspect. There are plenty of threads about improving them physically, but what about programming?

If you have a flywheel, do you just run it at a specific motor speed and hope your battery dos not run low, do you use a PID, or do you use some other method? My team is working on a PID, but at the moment we just have an LCD that displays the speed of the launcher (encoder ticks/50 ms) and we wait until it gets to the “right” speed to launch the ball.

I’m curious to see how other people have decided to program their flywheels, and what has worked for them :slight_smile: I have seen many very accurate flywheels, but would like to know how people choose to set their launcher speed and motor power. Is a PID really the best way to go here?

To determine motor speed you would just make a PID loop I think but where the code gets tricky is what speed the flywheels are supposed to go. There are two strategies that I can think of: testing certain spots, and making a code that knows where the robot is and derives how much to turn and wheel speed from those coordinates. The first idea is more practical and will probably have better accuracy provided your driver can drive the robot perfectly into the preprogrammed spots. The second method is faster but more difficult to achieve accuracy but with a lot of fine tuning you can do it.

so really, to have an accurate shooter, one could safely say you need a PID loop to keep the launcher speed the same to even be able to launch from pre-programmed spots? Is a PID really the only way to go? or is there another way to keep your launcher at a specific speed without a PID loop?

Programming… :slight_smile:
Heres my 2 cents on this :stuck_out_tongue:

So the easiest way to do it is just to set motor speed. Then theres PID, which I’m personally still experimenting with, so results are mixed with that.

Honestly, seeing what else is out there for controlling velocity, i’m not sure PID is the best solution at all. Im not saying its a bad way of controlling the velocity a flywheel (or anything) runs at, but I don’t think it’s by any means the best (although thats a bit subjective).

Have a play round with a few different techniques (jpearmans TBH velocity control is pretty sweet xD) and see what works for you. Also, feel free to ask questions about PID or velocity control here on the forum, there are plenty of people happy to help :smiley:

I think one would safely say you need velocity control. I mean you could go with a


if(battery level > threshold1 && battery level < threshold1)
set launcher speed to launcher speed1
else if(battery level > threshold2 && battery level < threshold2)
set launcher speed to launcher speed2

To return to my original point, not necessarily PID. But something of the like is probably preferable to missing shots because your battery loses charge/ runs out :frowning:

What is jpearman’s tbh velocity control?

A quick google will solve your problems :stuck_out_tongue: anyway:
https://vexforum.com/t/flywheel-velocity-control/29892/1

TBH = “Take Back Half”
There was some discussion about this technique starting at #9 on this thread:

https://vexforum.com/t/team-929w-early-season-robot-reveal/29823/1

I’m starting to implement the TBH code (big thanks to EvolvingJon for pointing that out! and of course to Jpearman for making it!) and am just wondering, has anyone tried it with their flywheel yet and received good results? besides the jitter that could be removed with filtering, are there any other drawbacks to this method that you are aware of?

Both our team uses TBH, thanks to jpearman. Our coders are still tweaking the code and gain. Our two team together scored 222 in last saturday’s competition(one of the robot can only store 2 ball at a time). Encoder log certainly shows a lot of jitter. I think what my coder did to deal with it is to increase the sampling time from 20 ms to 100ms to average out the jitter. Does anybody think if that is desirable or not. How about filtering. Anybody has a good suggestion or code to do it.

I have seen it work really well for a few teams, but you will definitely have to do some tuning! Apart from that it is a very effective way of controlling the velocity of a flywheel. :smiley:

I’ve been doing some testing with TBH for the past week, and I have to say results are consistent and good. Tuning is also relatively simple.

However, it lacks something I am searching for: Recovery time. Recovery time is still relatively slow and I wished it could be much faster, but I can’t seem to improve the recovery time.

This week, I will be trying out a PD Loop and see if that helps. But TBH should be enough for now (at least until Worlds)

We are using PID control that has given us a large improvement over just setting motor speed, I plan to look at the TBH algorithm, and see if that is better

for anyone who has used the TBH code, did you mess with the gain at all? my problem is that it overcompensates. I want it to run at a target of 200 rpm, and the first two shots are perfect, but then it starts to overcompensate as balls are quickly launched (speed drops more, code tries to raise it higher, another ball goes threw dropping it again, making the code think it still needed to go even higher yet) and so all of my shots after the first two usually miss. Any advice for fine tuning that aspect of the code? how can i try to prevent this overcompensation? the code works amazing at keeping it at 200 rpm, until i launch balls in rapid succession, and then it overcompensates.

Did you use the gain straight from jpearman’s code? You need to tweak the gain to your system. We ran in to same problem as you in the beginning. What is your sampling speed. We think jitter is an issue with high sampling speed. Where did you attach the encoder to. Is your encoder out of range? TBH will decrease your recovery time, but you can’t feed the system faster than the recovery time. An encoder log will tell you what your recovery time is.

My encoder is geared up a little bit from our slowest gear, as you can see in the attached picture. And no, i have never used the gain straight? could you explain what this is, i have never heard of it! I run it at .55 motor power (70/127) and that puts me at about 200 RPM. After i launch a few balls, it continually raises the motor power higher and higher, and is over-correcting too much. I tried messing with the gain but really have no idea what to set it to?:confused: thanks for any help! (also, i am using turbo motors and i made sure to change that in the code)
IMG_20151026_210401846.jpg
IMG_20151026_210406009.jpg

From your experience, do you think jitter affects the shots? I did a bit of testing and it did not seem to affect.

We have issue with over compensating after shooting ball like the post above. It seems to work better after we increase the sampling interval time to 100ms which basically smooth some of the jitter out. We are not hundred percent sure if the jitter is an issue. We are still tweaking the code. Currently we have attached the encoder directly to the motor shaft. We will be moving the encoder to the next gear up to increase the sampling and see if that help.