Hi there! My vex robotics team has been working on a flywheel launcher for some time now, and we have a competition coming up very soon… We have hovered at right about 50% accuracy, and would love to be more accurate than that… We’ve tried lots and lots of things, and nothing has really helped much. Here’s a quick list of some of the things I can think of:
-Shaft encoders to compensate for battery loss and ensuring that RPMs are the same every time
-Added two tracks for balls to roll into the shooter on to help ensure that the balls roll into the launcher the same way every time
-Added an LED so we know when the launcher has reached the ideal RPM
-Added support to both flywheels to make sure that they are stable
We’re kind of at a loss… Is there anything else that we can try before competition (10 days) that could potentially boost our accuracy up a little bit one final time? Thanks guys!
We are actually having the same problem as you guys. We have about 9 days left before our competition adn we are getting roughly 50% accuracy with no sensors. We are trying to use an IME and incorporate TBH, but we are having trouble coding that right now. I would reccomend using some kind of velocity control as many teams have drastically improved their performance by doing so. Hopefully we can get our TBH controller working tomorrow! Good luck to your team at achieving a higher accuracy!
Exactly. I can’t say enough how useful velocity control loops are. I had a perfectly tuned flywheel that was hitting 90% accuracy. Then we had to change it round and unfortunately i can’t seem to tune it properly.
PID. I’ve used it for years on various projects since the age of 11. This is the first one where i am using a derivative already as my values (velocity is the derivative of position with respect to time) thus all the problems i’m currently having.
So i am slightly biased in recommending PID, but from the looks of it TBH is a lot simpler to use. How do you mean it’s not working.
It really seems to work well, and I’m convinced that the RPMs aren’t the problem anymore, and that it’s some sort of mechanical issue… Any other ideas?
Well, if you can’t seem to find any fault with the mechanical system or the programming, then you might as well go back and check both.
Also, is that line copy pasted straight from your code? It seems a little iffy since it seems like you would be multiplying the actual value of the sensor by your constant before you found the error between “set” and “actual”.
Assuming that this is some sort of P controller, you probably also don’t want to use the “+=” operator as that seems to completely defeat the purpose of using a P controller in the first place.
That’s what it looks like, if you have any suggestions, let me know, I’ll gladly try them out…
I’m sorry, I don’t have any pictures of the robot and don’t have access to it at this time… I will be sure to get a picture posted to this thread on Saturday though!
^^ PixelToast is correct, never use the +=, you just made and integrator and that’s hard to get response out of, although it will give you an average. You want:
I’m not sure I understand what you guys are trying to tell me… I do think that it’s a little slow to respond and if we could speed that up, that’d be great… Would you mine implementing this into the code that I posted yesterday? Thanks!
This code is a PI controller with an additional constant for motor power. The only other parts needed are calculating the velocity and error, and finding the integral sum.
The integral sum looks like this:
integralSum += error;
Plug that in under your error calculation, then the above PI + C controller, and that is basically everything you need.
This is actually what we do! It seems to me to make sense, if you just ran it for one wheel, chances are one will be spinning quite a lot faster then the other, unless your gearboxes are somehow built perfectly identical…
Ok I’m close… I know how to calculate the error, and I’m assuming that “Out” means the power being sent to the flywheel? What is the i constant, and what is a good starting point here? Also, what does “C” mean?
The Ki value is what you multiply your integral by. Generally, your integral gets really large, so something like .01 is a good place to start. Another thing to add if you notice your flywheel doesn’t decelerate, and the integral is really big, is limiting the integral windup. Otherwise, your integral eventually can get to be large enough to maintain 127 motor power, regardless of how far beyond the target velocity (or position) you are.
The C constant is the power the motors receive when error is 0. Because it requires force to maintain the position, and P, PI, PD, and PID gravitate toward 0 power when error is 0, you need to adjust what motor power it is. I suppose with a PI loop, you might just need to tune your I really well, and you don’t need C then. However, I haven’t tried this. I use the letter C to refer to it because this is a constant, and it should only change when you change the target velocity. It is experimentally found, and that is one of the benefits of TBH; it finds what motor value it settles at eventually, although it takes longer.
