Summer Robotics Project #9 – Endless Rotation

As mentioned in my last post from well over a week ago, we were facing some serious issues with integrating the compass into our Turn function. We managed to find a fix for our problem and were able to get the robot to turn to face a preset direction, which represented a rotation of a set number of degrees. There is still some loss of accuracy in this, however, we’re hoping through proper calibration – which we haven’t yet been able to do – we should be able increase the accuracy in the rotations.

However, our problems with the compass really must be endless; the robot cannot seem to rotate to position 0 (it’s starting position) when facing in another direction.

In our code, we have written that when the target bearing is greater than the bearing being read at the present time, the motors should run clockwise and stop when this bearing is exceeded (vice versa for anticlockwise). This is explained further in my previous post. This works for all positions aside from position 0, which it takes as being 0 degrees. The problem with this is that whilst the robot is moving (in this case anticlockwise) – as there is a delay between when the motors stop rotating and when the robot stops moving – by the time the compass reads 0 degrees, transmits the command to the encoders and tells the motors to stop, the robot has already passed 0 degrees and gone onto 359 degrees. As the robot is now reading the current bearing as 359, it then enters another loop of the rotation to zero, and keeps repeating this process, without ever stopping. When rotating clockwise, there is a loophole in the code as the target angle 0 will always be less than the angle it’s currently facing and the motors don’t turn. But when we change the value to 360, we face the same problem as when the robot is asked to turn anticlockwise; it overshoots.

To be able to accurately determine how much the delay is, is something we’re not able to do. But through trail and error, we defined a new term in the code called compassError, and changed the values to see if we can account for the overshoot. We inserted this term into all of our code by writing another for loop within the existing for loop for the Turn function. This loop was written specifically for position 0.

void Turn(int pos, bool clockwise){ 
    Serial.println("Turning Right");
    if (clockwise){
        float(targetAngle) = positionArray[pos];
        
        //----- MOTOR COMMANDS -----//
            if (pos == 0){
                do{
                    setMotorSpeed(-120, 120); 
                } while(abs(encoder1()) < 10);
                
                do{
                    setMotorSpeed(-120, 120); 
                } while(getAngle() < (360 - compassError));
           }

            else{
                do{
                    setMotorSpeed(-120, 120); 
                } while(abs(encoder1()) < 10);
 
                do{
                    setMotorSpeed(-120, 120); 
                } while(getAngle() < targetAngle);
            }
    }
 
    else{
        float(targetAngle) = positionArray[pos];

        //----- MOTOR COMMANDS -----//
        if (pos == 0){
            do{
                setMotorSpeed(120, -120); 
            } while(abs(encoder1()) < 10);
 
            do{
                setMotorSpeed(120, -120); 
            } while(getAngle() > (0 + compassError));
        }

        else{
            do{
                setMotorSpeed(120, -120); 
            } while(abs(encoder1()) < 10);
 
            do{
                setMotorSpeed(120, -120); 
            } while(getAngle() > targetAngle );
        }
    }
    stopMotor();
    encodeReset();
}

 

We initially used the error in all the ‘do…while…’ loops, however this causing larger inaccuracies in our other turns. We started off with an error of 5 degrees which did work, but happened to be too much and reduced it to 1 degree. This was too little and the robot was still overshooting slightly. We then increased decided to increase it in increments of 1 degree but found that an error margin of 2 degrees did the trick, and robot was able to stop for position 0. Of course, this isn’t very accurate and the value would vary depending on the type of surface, so we will need to work on a slightly approach, which we’re hoping we will be able to do a lot more easily once semester starts and we can manufacture a better chassis.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s