I'm working on FLL mission and every time our team launches the robot (without changing the program, and we are making sure that it is starting from same location every time) it is not following the same turns and distance.
Any idea what is going wrong?
This is actually a fairly typical problem, with several possible causes.
The motors do not directly drive the axle, there is a gear train hiding inside the plastic casing. That gear train can be deflected without turning the motor.
The software controlling the motor maintains a last known position so that several move blocks can be run in sequence and the over/under at the transition between blocks is taken into account. This is typically a problem when the robot is picked up during an aborted run, and the program is rerun. The robot acts like it remembers the previous run and twitches to the left or right when it is restarted. There is a motor reset block to handle this problem.
Dirt/dust on the wheels can also cause issues, as can wheels not firmly positioned on the hubs. This year we spent a whole session trying to get the robot to go straight and ended up trading wheel/hubs until we found a pair that worked fairly well.
Some wheel/hub combinations slip. We spent a long time thinking some old yellow hub + shiny black wheels would work. What a mistake. The wheels didn't slip at first. After a couple runs that smacked into the wall and they loosened and nothing, not rubber bands, not different hubs, not ...
The big message isn't to find a combination that goes straight. Expect it to wander.
If you are using a wheeled robot, make sure that the wheels aren't disturbed in any way. If they move slightly on the axel or the tyre changes position on the rim, turns well be off and in a long program without calibration points, the problem vill propagate and get worse for each turn.
However, this should not affect distances.
We have this problem all the time too, very frustrating... We have found that the robot is very sensitive to the charging level of the battery. Keep the battery well charged at all time - seems to help...
Best solution is probably to use sensors to keep track of where on the FLL table you are.
In addition to the suggestions already mentioned, we discovered a very unexpected problem causing our inconsistency. Ultimately we found the problem was because the robot was moving a motor though there was no instruction to move the motor in the program at that time. During a turn, the medium motor pushed an arm down on the table, increasing the friction during the turn. Because the arm was already resting on the table, this change in pressure wasn't visible, but the result was significant, as the angle of the turn would often vary by 5-10 degrees. This movement of the arm was noticed only when the program was accidentally run while someone was holding it.
After deleting the program from the robot, changing the program then reloading it, the motor was not moving the arm and the turn was consistent again.
We found that after any accessory motor use (lift, or any motion other than wheels), we needed to unpair and re-pair the wheel motors. For whatever reason, that works! We are using Python so we made a function to do this automatically when we use the wheel motors. (You can do the same in block code with MyBlocks.) We still have issues after using the bot for about an hour... I just have to assume that's battery-related. It seems better after a charge. Maybe it is all in our heads though. We are not using the gyro as it is glitchy and inserts wrong values often enough that we won't use it. (Are all Spike Prime gyros like this? This is our first year with this bot). Maybe we just have to buy a new hub to get a new gyro... but YES, we have seen the motors do strange and unexplainable things at random moments. I guess that's why we get 3 runs in competition... to try to make your code just work! (I do miss the gyro! We had it working really well last year with the EV3.)
