1st EDIT
So I found someone who asked this same question and here is the response:



That sounds great and all, but the motors aren't actually matched. If you run a simple move forward program (included below) at a very low power such as 1, the robot will gradually veer to one side, hence why I wanted to use nSyncedMotors in the first place. When I ran the code below on the metric utility mat the robot veered to the right to the point of half hanging off the table (pictures below).


PICTURES:
START

END


2nd edit:
Here is some more info. The table shows the gradual difference between the encoder values of motors c and b as the robot gets slower and slower. Values obtained from motor decoder window using same code as above.

Power of Motors:Final Encoder Values(B/C)
100:4096/4096
50:4094/4096
10:4092/4103
1:3091/3183 (At this point the robot fell off the side)

3rd edit:
So I had the idea that maybe since motorC was being activated first in the while loop every time before motorB, the third wheel in the back would gradually angle towards the right. However, even when running code that starts with motorB and then switches the starting order every loop (show below), motorC still always has a higher encoder value, with a more pronounced effect the lower the power.



ORIGINAL QUESTION
So in the Virtual Worlds simulation, the nSyncedMotors and corresponding nSyncedTurnRatio commands don't seem to do anything at all. When the following code (the main() section of the nSyncedMotors example code include with RobotC) is run on the metric measurment utility mat, the robot just turns left, as if the commands weren't doing anything and only the B motor was running.

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.