- Try running two Motor blocks in parallel, rather than a single Move block. If it works with two Motor blocks, this is evidence in support of hypothesis that the PID algorithm on the Move blocks is getting bad encoder data from the "good" motor.
- Spinning the motors by hand that kids often do can lead to damage of the rotation sensor in the motors. Have them think about the 5 minute bot or one that has not sensors. Ask them to count the sensors on the robot, the usual response is, "There are no sensors on the robot." My next question is, "Then how does the robot stop using a Move Block set to 1 rotation?"
- The sync feature of the drive blocks slows down the other motor to match. If this is the case, the motor to check is the one that's spinning, not the one that's stopped. Hold the robot upside down with cable and look the "power" in port view, you can see that the spinning motor is reporting no speed or reduced speed.
- A veer of 1 inch per 1 foot of travel is not unusual. If you are really careful you can knock that down to about 1/4" per foot, but that requires a lot of care and attention to detail. One inch veer per 1 foot travel is a an alignment or steering error of only 5 degrees. You probably can't aim any better than+/-2 degrees, so half your error is eaten up by human fallibility. All motors veer at the start of a move. Even with perfectly matchedmotors and perfect weight distribution and symmetry there will be some sliding of the wheels, some hopping, some jerking. There goes another 2 to 3 degrees and we are up to five already. Add onto that changes in the conditions of the mat, a slight tipping of the table, a rough spot in the plywood, and you are soon off by 10 degrees or more. Even a change in battery charge will make a noticeable difference.
- I think the easiest way to do this on EV3 is run up to four motors for 60 seconds using the Unregulated motor block. The two motors closest to traveling the same distance are your best matched pair. Some teams swear by placing a pair of motors side by side and connecting them via an axle. When you command the motors to spin they will hop a little at the start and end of the move. The pairing that hops the least is the best match. I don't like this test because it takes a lot longer (four motors is 8 pairs, or 4 tests instead of one) and the evaluation is very subjective (Did the BC pair hop less than the CD pair? I can't remember).
- Connect the 2 motors together with 1 axle. A number 9 axle works good. Lay the connected motors flat on a table and then run both motors at the same time for a few seconds. Run the program at different speeds. 10, 20, 40, 60, 80, 100. Watch the motors when the program starts and look for one of the motors to jump. If one motor is starting before the other you will see the motor lift off the table a bit. Same if one motor stops before the other. You will see if they are not matched.
- Motor matching and wheel matching are band-aids that don't fix the underlying problem.
- Another idea is to take a look at the port view and see if one of the large motors is misidentified as a medium motor. I
- I would also like to remind teams that most of the time the robot game is won by a robot that doesn't go straight. A smart team realizes that there are things that cannot be controlled, and this includes going straight. Sure you can go straight on your table, but the tournament is not at your house and the table you run on may be about as flat as a potato chip and the walls as straight as a cork screw (exaggerations). A smart team doesn't waste time matching motors but spends that time designing solutions that work if the robot strays off course. Some of this is the mechanical design of the attachments. Some of this is the smart use of sensors. A lot comes from not always picking the most obvious way to solve every mission.
- Teams should try driving the robot forward and backward to find out which direction gives the best results. A high CG, a large mass and a high acceleration will shift a lot of weight from the front to the rear of your robot. Big weight shift means big change in traction which means more wheel slip and uncertainty. There's no reason the robot has to always drive forward.
- Run your robot one direction and then have it do the same coming back and check for patterns where things move off course.