Robot can not turn properly after changing Gear Ratio

Hi guys, we are confused by the VEXcode Block. Since we updated the driving base gear ratio, from 1:1 to 5:3, the robot can never turn correctly with the program, even with the Gyro sensor. Before programming, We updated the gear ratio and other settings, but If we program a 90-degree turn, we may get a 75, or even more than 360 degrees. Just so confused. Please help.

30 PM
With Gyro

1 Like

Do you have a block to calibrate the gyro? At the very beginning of your program, use the Gyro Calibrate block and put a wait after that. It should help fix the problem.

Could be a few things, could you post a screenshot of your code?

Have you tried entering the ratio as 3:5? Or entering 1:1 and seeing what happens?

Without Gyro

Sure, pictures updated, with and without Gyro.

If my program is on drivetrain, not the 2 motors separately, it seems I cannot calibrate the Gyro.

I am running into a similar thing on mine. 60 tooth gear on motors, 36 on wheels to get some additional speed out of the bot. Unfortunately it is not getting accurate distance (resulted in 6" rather than 10" i told it to go). And turning it just kept turning (though maybe that was some glitch with low battery as it started to blink).

Is your distance of travel resulting in accurate dimensions?

I tried 1:1 and it went 16.7 (which is what i expect given the gear ratio), and 3:5 resulted in closer to 25" (didnt measure as i knew it was going to not be what i wanted).

Interesting. It sounds like the gear ratio is being ignored in calculating distance to travel.

Have you tried converting the distances to axle rotations? That seems like it might be cleaner, just need a handy formula. Though working that out in the EN would probably impress the judges :slight_smile:

1 Like

According to another string they have a glitch in the software for the 5:3 ratio. The person indicated the Blocks team is working on it.

That is the thing! Thank you so much for your help!

Ooooh! Glad to see this! We were having a similar problem but I didn’t have time to get to the bottom of it before school split up. I think we were 1:3 Ratio, though (speeding up). Kept turning ‘forever’, with or without Gyro. Didn’t add a Calibrate Gyro block at the beginning (but that wouldn’t explain the problems without Gyro).

Unfortunately, unable to get back into school (Coronavirus), so unable to check any solutions for a while. However, I’ll keep an eye on this Chat :smiley:

The specific issue with gear ratio is as I explained in the other topic, the gear ratio was being applied twice by mistake, once on the motor and again on the drivetrain, an error with code generation inside the blocks program. The practical effect of this was to this was to apply a gear ratio that was the square of what was entered. Although a bug, this should not have the effect of causing turns to rotate forever without ending and should have no impact when doing turns with the gyro. My point is that its unlikely to be the cause of all issues.


Sorry: ‘forever’ was a lazy approximation - the turn did indeed complete eventually (usually one motor before the other), probably close to the square of the turn (as it was in degrees). However, we did experience the same problem with / without Gyro. There was no ‘Gyro Calibrate’ Block used, but it was registering reasonably well when checked as a Device on the Brain.

Will there be an update to Firmware / Software to deal with this?

Thanks for super fast response: I’ll look for the other thread…

yes, it should be fixed in the next blocks release, I can’t give a specific date (that’s determined by the blocks team) but I would expect it to be sometime before the end of Feb.


@jpearman any idea when this bug was introduced? I feel like our distances were correct at one point, but now we are seeing similar issues in distances not being the same.

As far as I know it was introduced in the December update, I could get that data but really the important thing at this stage is to get a fix out.


@jpearman that’s good enough, thanks! When an update happens, will there be any proactive notification of the fix? My only concern is we code it now to work in the current state(bug), it gets fixed and then we have to go back and change our distances if we touch any code again after the fix, which means we would have to make changes before state/world (if were even that lucky).

So the real question, is the safest workaround right now just to set it 1:1 and measure distance per that setting so we wouldn’t be affected by the fix when it comes?

This is a concern for us.
There are two pretty serious bugs that would change the way an IQ program using the drivetrain will work. This one that affects the calculation of the number of wheel revolutions needed when gear ratio is used. The second bug was explained a couple of weeks back, the wheelbase setting is not being correctly turned into code, this affects drivetrain turns when gyro is not being used.

safest way to not have the update change any code behavior is use 1:1 gearing.

next would be to set gearing so that distances are correct and then make a one time change after the update to the actual gear ratio. for example, if gearing is physically 5:3, that’s supposed to be an internal ratio of 1.667, but we are using the square of that, entering a ratio that was square root should (and I didn’t test this with a robot) allow correct distances to be entered, in this case 4:3 would be close or 129:100 even closer. (1.29*1.29 = 1.664 which is approximately 5:3)


This should be fixed now with the 1.0.9 VEXcode release.