Is there any way to get Take Back half to settle quicker around no error in a flywheel? We are trying to improve the fire rate, and this has helped, but still suffers. Our flywheel goes through the TBH process, and reduces the speed, but then takes ~20 seconds to get a reasonable speed to get into the net, and then it takes ~3 seconds to recover. Our gain is currently .00075. I can post code if that helps. Also, should I average RPM?
Did you try a higher gain?
I’ll try it soon. We are having some base and intake issues. Our base is drawing more current than the flywheel. Thanks for the help!
Can you log the results and share a graph too across different gain settings? You will see the oscillations/waves of the velocity settling back differently as you adjust the gain values.
I think you will then have some additional questions we can help you with further in tuning it.
I will try to get it logging the motor set pwm, actual pwm, rpm, tbh and set rpm variables all time stamped. I will try to place them in excel to graph so I could show the results. We just got our intake working better today so it doesn’t stall or jam.
Regarding filtering your data, we’ve been trying out some PID and for that, we were calculating the RPM of the flywheel itself (rather than the drive gear like the @jpearman ‘s TBH code does). The jitter was insane despite the fact the code already was using the average of the last 5 RPM calculations (we were using Collin Stiers’ PID).
Since tuning the PID loop has been really hard (and unsuccessful), I think we’re going to go back to TBH for our next tournament. However, I’m probably going to implement some form of an exponential moving average for the last 5 or 10 RPM measurements to help with consistency.
Ok some advice on using the PID loop from my experience with it, The jittering you have, is because you Kd is too high, I’ve had the same problem before and lowering Kd will fix it. The problem with tuning the PID is that as people go, they increase constants, and If they run into problems, they keep going higher, but you may need to go lower.
I also recommend using and exponentially moving average, I use one that takes into account the last 10 values, this has helped a lot.
Next is that I recommend you use RobotC’s new data logging feature. Log velocity, then graph it and look. If you go back and look at my PID tutorial, it now includes how to tune PID loops using this data, it is called the nichoals - zigler method if you want to look it up (I think I spelled the names right). If you need more help with the PID and want to keep working with it, you can private message me, or you could try the TBH, that’s also a good way to go.
@Collin Stiers When I said jitter, I meant that, within the oscillations of the PID loop, the RPM data was not particularly steady. I’ve been graphing the data for a while using a quick little Google Sheets Add-on I through together to parse what’s essentially CSV data (it’s easier than uploading the CSV file to Google Drive, opening it, etc., because there’s only one file to keep track of). I uploaded a picture of one of the graphs here:
So, as you can see, there are the oscillations of the PID, and within those, there’s the jitter in RPM measurements.
I have some other thoughts, but in the interested of not taking this thread entirely off-topic, I think I’ll just PM you about those.