Hello, I am trying to work with the integrated motor encoders because my team would like to substitute them for the shaft encoders. I am trying to figure out how these values work, but they aren’t making sense(EX: one rotation would be a value of 627.2(FOUND HERE),
When I tested it, it was far below(around 595, spinning at a value of 15-20.) Is there any explanation on how I could get an absolute way to make the motor spin a certain amount based off the encoder value, or do I have to guess-and-check as I work along?
Here is the current code I have just to test it(I manually input the motor value through the debugger):
#pragma config(I2C_Usage, I2C1, i2cSensors)
#pragma config(Sensor, I2C_1, iEncoder, sensorQuadEncoderOnI2CPort, , AutoAssign )
#pragma config(Motor, port1, motor1, tmotorVex393_HBridge, openLoop, encoderPort, I2C_1)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
/*
"The 2-wire 393 motor measures 627.2 counts per revolution of the output shaft in its default high-torque configuration and
392 counts per revolution of the output shaft in its modified high-speed configuration."
*/
float iEncoderValue;
short motorValue = 0;
task main()
{
resetMotorEncoder(port1);
iEncoderValue = nMotorEncoder[port1];
while(iEncoderValue <= 590){ //Try to get one rotation
iEncoderValue = nMotorEncoder[port1];
motor[motor1] = motorValue;
}
}
Are you asking why it’s reading less ticks than you’re expecting for one rotation? If so, it’s not programming, as you can only read the sensor one way. What are you using to measure the exactness of your motors rotation relative to the ticks? Have you tried other motors? Also, if you want much more precision, I suggest the external encoders.
Also, if you’re judging where the axle stops moving when the code sets the motor to 0, you need to consider the momentum it can carry when stopping. Although small, it can still exist, and might be causing your “error.” This is why many people use PID if they need very accurate and consistent results.
Try rotating the wheel by hand and see what you come up with. You may be going for a bit, and then cutting the power and momentum carries your forward.
As I understand it, the optical shaft encoders measure ticks as light passes through small slits in the rotating disk, while the integrated motor encoders measure motion by reading the color (white or black) of the modified internal gear as it spins. These segments span much larger degree values than the ticks of the external encoders. perhaps the issue is that margin of error present due to the large range of possible positions the motor could be in when it stops within one of these sections. I would suggest optical shaft encoders for more precision.
Yes, in general you want to measure closer to the source with motors and gear trains because there is always slop in a gear train to some extent. So for the IME, you will be measuring the second gear from the motor and that is pretty darn close. You are measuring what you can control here.
Momentum carrying your robot forward will still transmit back to the IME and it will still register movement after the power is cut.
So the trick is to have the motor slow down and reduce the slop from motor to wheel to a minimum so the robot can repeat its path over and over again and minimize the overshoot/undershoot.
Relating to the image of the integrated encoder wheel, am I correct in saying that if a motor began at position C, and then rotated, the encoder would read the same value if it stopped spinning completely at point B rather than point A? And I apologize for the poor image quality.
Yes. It would not change, but that would be a fairly small for each step from white to black.
For the torque and speed gears, it is less than one degree of movement. Turbo gears, has 261 ticks per rev so a bit more than one degree from white to black. So in any of the cases, it is really small movement per IME step.
