1
$\begingroup$

I'm currently programming in RobotC, for a Vex 2.0 Cortex. I'm using encoders to make my robot go straight.

This is my code:

#pragma config(I2C_Usage, I2C1, i2cSensors)
#pragma config(Sensor, dgtl2,  ,               sensorDigitalIn)
#pragma config(Sensor, dgtl7,  ,               sensorDigitalOut)
#pragma config(Sensor, I2C_1,  ,               sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_2,  ,               sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Motor,  port1,           RM,            tmotorVex393_HBridge, openLoop, reversed, encoderPort, I2C_2)
#pragma config(Motor,  port10,          LM,            tmotorVex393_HBridge, openLoop, encoderPort, I2C_1)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

/* Port 1 is right motor*/

//all functions expect no reverse motors (in port menu)
//**GLOBAL VARIABLES**
int buttonSTATE = 0;

//**MOVE FUNCTIONS**
void goforwards(int time)
{
    int Tcount = 0;
    int speed1 = 30;
    int speed2 = 30;
    int difference = 5;


    motor[LM] = speed1;
    motor[RM] = speed2;
    while (Tcount < time)
    {
        nMotorEncoder[RM] = 0;
        nMotorEncoder[LM] = 0;

        while(nMotorEncoder[RM]<3000)
        {
            int REncoder = -nMotorEncoder[RM];
            int LEncoder = -nMotorEncoder[LM];

            if (LEncoder > REncoder)
            {
                motor[LM] = speed1 - difference;
                motor[RM] = speed2 + difference;    
            }
            if (LEncoder < REncoder)
            {
                motor[LM] = speed1 + difference;
                motor[RM] = speed2 - difference;
            }
            wait1Msec(100);
        }
        Tcount ++;
    }
}

//**CONTROL STRUCTURE:**
task main()
{

    goforwards(1);
}

When I execute the code, the Robot's encoder values are very close, but the robot quickly starts to veer to the left. What are possible causes of this? Is it something in the code?

$\endgroup$
  • 1
    $\begingroup$ Can you log and read the left and right motor speed values? If the speeds are close to each other, the remaining drift can be because of the vehicle itself. The CG, tire frictions, etc. $\endgroup$ – Gürkan Çetin Apr 14 '17 at 19:59
1
$\begingroup$

Lets suppose, that left wheel is blocked, so nMotorEncoder[LM] is constantly zero, while nMotorEncoder[RM] counts something. Correct behavior is for right motor to effectively stop (or jumping little back and forth the same lenght).

Now LEncoder is 0, REncoder is negative, LEncoder > REncoder so

            motor[LM] = speed1 - difference;
            motor[RM] = speed2 + difference;

left motor slowes, right motor goes faster. This is not, what you want, in next step nMotorEncoder[RM] goes positive again (nMotorEncoder[LM] is still zero), right motor tries to move faster, while left motor tries to be even slower. Soon left motor is going backward full speed, right motor going forward full speed, no stabilizing.

Usually the motor are not totally equal (and usually they turn one way better, than the opposite way), so it is possible, that your left motor is a little slower/weaker, than right. Even if it is not much and can be compensated for, the way you are doing it is making it more and more visible.

Try to remove the minuses on

        int REncoder = -nMotorEncoder[RM];
        int LEncoder = -nMotorEncoder[LM];

of change the direction of comparing LEncoder > REncoder

BTW: I am not sure, but you probably also should limit the maximal/minimal speed

$\endgroup$
1
$\begingroup$

There are 4 possibilities:

  1. One of the wheels' centre is displaced slightly.

  2. Wheel encoders are not properly positioned and this is causing issues (like wheel pausing at odd positions while microcontroller 'thinks' it has achieved the right position)

  3. One of the wheels' radius is lesser than the other one.

  4. As per @GurkanSetin 's comment, friction might be causing some issue.

It is better to timestamp every count (some counts are getting missed probably) and post logs here and use some sort of feedback; preferably imaging and using some sort of minimal localisation to correct that; preferably something like this https://www.ais.uni-bonn.de/papers/ICRA_2008_Orthogonal_Wall_Correction.pdf . Even visual SLAM can be used. Some 'basic' tutorial can be found here: https://ocw.mit.edu/courses/aeronautics-and-astronautics/16-412j-cognitive-robotics-spring-2005/projects/1aslam_blas_repo.pdf (Some people place one camera sideways - orthogonal to motion of robot for monocular vision and just use template matching/image-difference)

$\endgroup$
0
$\begingroup$

You can troubleshoot, send some value which lock at certain speed to left motor and read the speed, Send same vlaues to right motor and again read the speed again. Compare results,Watch for current draw in both the cases.

Try switching the channel of motors on bridge.

If the values are same and you get different speed, then there should be problem in hardware.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.