Re: Motors in RVW ARE NOT perfectly matched
I've been able to test this and confirm that, under very slow speeds, the robot will veer to one side. I've talked to our Virtual Worlds team about this to see why it was doing this, and they've determined that is simply a result of necessary rounding off of values in the Virtual Worlds code. However, when using normal motor values (25 and above), this rounding error is dramatically decreased; the highest difference I saw in the two encoder values (from the very beginning of the table to the very end) was five counts at a motor power level of 25.
Anything less than this is not reliable on a real robot; power levels less than 25 may or may not provide enough current to actually move the motors and in many cases the robot will simply sit in one spot. When looking at the Virtual World code that runs the motor power levels, fixing the low-level rounding accumulated errors would instead ruin the high-motor power calibration. In this case, we wanted to keep the higher motor values as synchronized as possible as they are the values more likely to be used on a real robot.
For a quick fix, simply run the motors at a higher, more realistic value; when the motor power is increased from 25 to a more commonly used level of 50, for example, the error between the two encoders is reduced down to three counts (down from five counts).
Another, more complex option is to use three if statements to check the encoder values of each motor and slightly adjust whichever motor is lagging behind:
This code clears the encoders, then (while the target encoder count, in this case 4200 is not reached, will continually tweak the two motor values between 50 and 51 depending on which one has a higher encoder count. If both encoder counts are the same, the motors will run in tandem with a power level of 50. Once the target encoder counts have been reached by both motors, they are then turned off and the program ends.
I have used this code with both high-values (99-100) and low values (1-2) and the robot ran to the end of the table without any issues. You can alternatively run this code for a set amount of time by replacing the encoder condition in the while loop with a timer condition:
This will do the same thing as the previous code, but will run for 3000 milliseconds (3 seconds) instead of 4200 encoder counts.
Check out our Blog
! And our Facebook page
Need help? Take a look at our Wiki
and our Forums.I just met you,
And this is crazy,
But here's my code now,
So fix it, maybe?
~ Carly Rae Jepsen parody