we were programming our autonomous today, and after many hours of work, we finally got the autonomous down. However, all these hours went to waste after we changed the battery. Even though we are using many sensors, like quadrature shaft encoders, the robot suddenly started moving very fast, faster than we had programmed it to. This affected all our turning code, causing it to turn more than it was supposed to, even with the shaft encoders on the chassis. Is there any way to avoid this problem, wether it be with mechanical solves or something in the program?
I have a solution. First, unplug your battery. Next, plug in a charged one.
Of course I’m being facetious, but changing the battery every few runs is probably your best bet. I’m imagining that you turned more because the robot had momentum and overshot whatever distance you set it to. Regardless, you really should just change your battery every few runs. There’s not really another solution.
Our team prefers to put in fully charged batteries to be consistent, or at least as fully charged as possible for the beginning autonomous. We found charging to be more efficient as well due to the fact that the batteries put back on the chargers between rounds are nearly charged, and take much less time to charge for the next use. We understand that this may be harmful to the life of the battery, so being sure to fully cycle the batteries every now and then would help. For us, this happens naturally with our other teams using them and such. Just be sure to stay fully charged when programming autonomous! A battery every couple autonomous runs kept it pretty consistent for us, and the extra punch a fully charged battery supplies can be nice during the match.
You are seeing momentum carry your bot after the sensor value is reached. As mentioned, PID will solve the issue. A quick potential fix would be to lower the power sent to the motors in your program. Despite the option of 127 power, motors turn at max speed when set to 90. Most drive bases can move at 40. Try something like 60 and see what happens.
Different specific batteries definitely behave differently. Last year on NbN, before each tournament we would have to go through each of our 10 batteries on our flywheel, test them connected with the online window, and see what power it would take to get balls from the starting square to the net. The answers ranged from, say 48 power to 56 power, which is a big difference, and difficult to calibrate one’s autonomous. So we would test all 10 before each tournament, find the 5 that were most similar in terms of power-needed-to-net, and label those 5 for our flywheel, and the other 5 for our chassis, and make pairs of flywheel/chassis to rotate through at the competition.
So you may want to charge up all of your batteries, and without changing your programming, run your existing autonomous code with each battery connected to your chassis (in case you’re using a power expander, and have certain systems controlled by each battery). Take note of the results, and see what the variability of your batteries are. It’s a variable that we did not even know really existed as something to be aware of until NbN when we had a flywheel that needed to be calibrated sensitively.
Believe me, we tried really really hard to handle this problem via programming. We had a double-flywheel, and its speed decreased so dramatically when a ball went through it that there was no combination of PID factors that could make it catch up to a preset RPM for rapid-fire ball shooting. By itself, it would take 4 seconds to get back up to speed after a ball went through, and PID could only do so much, and it was not enough. Had that worked, then yes, we would not have had to do all of our battery testing. (However, we did learn that batteries are a variable that should not be discounted.)
A double-flywheel was NOT the way to go last year, but that’s a whole 'nother story. We ended up using a limit switch to give it an extra (short, large) boost of power after the switch sensed a ball leaving the flywheel, which worked really well as a low-tech solution. We were using easyC; perhaps RobotC could have done a better job, but we tried for about 4 months to get it to work (no joke) and just could not do it with a highly-geared double flywheel with high-speed motors using easyC. In retrospect we should have been using Ports 1 & 10 and might have had a fighting chance.