I have a team whose robot is turning very slowly when using the turn_to_rotation functions of the smartdrive class in autonomous. It’s a competition robot, so fairly heavy. It has a six-motor drivetrain with an inertial sensor and omniwheels. It drives and turns quickly and smoothly in user control mode, and in autonomous their drivetrain.drive_for commands are fast and accurate. With six motors, they had to set up the motor groups and smartdrive manually, but I verified that they did this right (all six motors are spinning the right way at the right time, and the accuracy of the drive_for commands tells me they correctly set up the motor types and external gear ratio. Track width and wheel base look right, but shouldn’t matter anyway with an inertial sensor, right? And the inertial sensor is working because the turns are reasonably accurate. )
Turning the speed up at all using set_turn_velocity makes the robot oscillate wildly. They have to set the turn velocity down to something like 5% to prevent the oscillations, and then it turns about as slow as it did by default. This surprised me: I thought the default turn velocity was something like 50% but maybe I was mistaken.
I’ve previously been impressed with the vexcode drivetrain and smart drive classes even if they’re not as good as the custom PID code my more advanced teams have. I saw a setTurnConstant function in the vexcode API and I was going to suggest they experiment with that, but it doesn’t appear to be available in the Python version. Has this team just reached the limits of what the built-in drivetrain code can do, either due to the six-motor drivetrain or the weight of the robot or something else? What factors can cause the smartdrive class not to turn as well?
correct.
any gearing between motors and wheels ? If so, is that setup in the smartdrive constructor ?
turns are done using a simple P controller, it will not work for every robot, it may be time to write something specific for this robot.
You could try increasing Kp using
void setTurnConstant( double kp );
default is 1.0, try perhaps 2.0, and now I see you are using Python, so that would be
drive.set_turn_constant(2.0)
if drive is instance of smartdrive.
but as you said.
Turning the speed up at all using set_turn_velocity makes the robot oscillate wildly.
that may just cause the same effect.
3 Likes
My oldest had a similar problem last season using the Drivetrain setup, and it came down the the gear ratio being backwards. Make sure you’re inputting the ratio in terms of gear teeth ratio, rather than input:output ratio. Once this got solved, the robot behaved much more like it should have.
For example, you might have a 60 tooth gear on a motor and a 12 tooth gear on a wheel or effector. This is technically a 1:5 ratio (input turns:output turns), but the Drivetrain definition is looking for 5:1 (60 teeth:12 teeth → 1:5).
If I weren’t on mobile right now, I would dig up the thread where this got discussed and I suggested that the VexCode interface be updated to help avoid that problem.
Thanks for the suggestions. It does have external gearing with 36-tooth gears on the motors and 60-tooth gears on the wheels, and the smartdrive is set up with a 0.6 gear ratio. (Just to make sure we weren’t confused about the direction of the ratio, we tried it with 1.667 and that made the turning even worse and messed up the drive_for distances.)
Using set_turn_constant to increase kp helped, and didn’t cause oscillations. The turns still aren’t snappy, but they’re good enough. Thank you!