Turn Robot 90degrees

[Benn]

Hi all.
For my obstacle avoidance project, i want my robot to turn right or left for 90degrees.
I studied Admin's project, but i cannot understand how to figure it out.
My implementation was to give a turning command, wait for some time, and then stop, but this metod is not accuratley, so i need something else. Please help me. Thank you. I searched on the forum, but cannot found something clear.
Benn.

[waltr]

To have your bot turn exactly (or very close to) 90° does require encoders on the wheels so that the code can measure how far the wheels turned.

[Benn]

Yes, i thought of this. The problem is that i do not know how to read the encoders.
I did not find the datasheet or something helpfull. Here is the dc-motor i use in my project:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,403,625&Prod=MT-MOTOR
Please help me

[waltr]

Looks like a nice gear motor.
Did a data sheet with the connector pin-out come with the motor? I didn't see it on-line. A link to the data sheet?
Do you have the RKS kit? Are your using the H-bridge P ciruit?

The encoder is on the motor shaft which is before the gearbox so it will indicate the motor rotation and not directly the wheel's rotation (the motor is faster than the wheels by the reduction ratio).

The encoder probably has a quadature output (judging from the number of pins), A & B, but for just position and/or speed only one encoder output is needed. If you need to read the direction then both encoder outputs are needed.

The encoder would need power and ground (5volt? taken car of with the H-bridge P-circuit). Then the output is connected to an input on your processor (Sa or SB from the P-circuit). Write code to count the encoder pulses and a little math to calculate how far the wheels moved for x number of pulses.

[Benn]

Yes, i have the RSK Kit. But i found no datasheet for the gear motor. The only indication is the H-bridge Pmod:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,401,503&Prod=PMOD-HB5
And in his datasheet it's saying about senzor A and B.
So i need to connect the senzor A and B on the input capture module on my Pic, and the, on every input capture to count? I use the folowing developement kit:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,396,754&Prod=CEREBOT32MX4

[waltr]

That sounds correct. I do look at the documents for building their bot with those parts. The Pcmod H-bridge board seemed to have the A and B sensor outs connected to a cable going to the processor board. Any idea what they connect to on the processor?

You could also try emailing the company you bought this from for additional information. I do have a feeling that they do have code the use the encoders.

[Benn]

They provide standard P-mods to connect differnt kind of stuff to the uC. The board i am using, as you can see, has many of those conectivity options on it. It's very helpfull.

I'l try emailing to the company. thank you a lot.

[Pratheek]

If you are using differential steering, then try rotating 90 degrees by moving only one wheel forward and keeping the other wheel stopped. This will give you more accuracy and consistency than when truning the wheels in opposite direction to turn 90 degrees.

[Benn]

This is what i did until now, but i do not know what to do next:

main(void)
{
// Set RD9 as input, for reading encoder , RD9 coresponding to senzor A from H-bridge
trisSenzorSet = (1 << SenzorALeftMotor);

//Initialize timer 2, i will use timer2 as time base for Input Compare1
T2CON = 0x0;       // Stop and Init Timer
TMR2 = 0x0;       // Clear timer register
PR2 = 0x7000;       // Load period register
T2CONSET = 0x8000;   // Start Timer

// Init Input Compare1 for capturing senzorA input from
IC1CON = 0x8083;   //Enable Module, use timer 2,
            //Capture mode 1 (capture rising edge)

while (1)
{
    int cap_data;
    while( IC1CONbits.ICBNE ) // while data available in capture FIFO
    {
       cap_data = IC1BUF;
    }
}
}

now the problem is i do not know what to do with cap_data. I mailed to the company, and they told me they do not have datasheet for this dcmotor, but the 2 senzors generate 90degrees phased signal, 3 pulses/ rotation, and 1:19 gear ratio reduction.
Please help me. Thank you very much.

[waltr]

the 2 senzors generate 90degrees phased signal, 3 pulses/ rotation, and 1:19 gear ratio reduction.

That is a big help as you now have enough information for measuring the wheel motion.

First google quadrature encoders to learn what the 90° phased signal means. But since you are really only interested in how far the wheel rotated you only need one encoder output (A or B).

With 3 pulse per motor revolution and a gear ratio of 19:1 you will get 57 pulses per one rotation of a wheel.

Now calculate the wheel circumference and how far the wheel must rotate for the bot to turn 90° to determine how many encoder pulses must be counter.

[Benn]

Waltr, i did as you said, but after hours of testing, i found out that the robot is acting a little strange. I mean that, for the same number of clicks, sometime he turns more and sometimes less...i don't know why...but the error is not very big, maybe 10degrees much or less from 90degrees.
Maybe is because also of speed or weight.
Here is the code i did for robot to turn 90degrees.
To be mentioned that, i made one motor to go forward, and the other to go backward, result in turning.

void RobTurn90()
{
   int a = 0, b = 0, c = 0, cap_data1 = 0, cap_data2 = 0; // in variable a, i'll store the clicks from left motor, b for right
   RobSpeedMedium();
   
   while ((a < 30) && (b < 30))    // i found out that 28-30 click is for turning 90degrees
   {
      // Wait for Capture events
      while( !mIC2CaptureReady() | !mIC3CaptureReady());

      //Now Read the captured timer value
      while( mIC2CaptureReady() | mIC3CaptureReady())
      {
         
         if (mIC2CaptureReady())
         {
            cap_data1 = mIC2ReadCapture();
            a++;
         }
         else if (mIC3CaptureReady())
         {
            cap_data2 = mIC3ReadCapture();
            b++;
         }         
         else if (mIC2CaptureReady() & mIC3CaptureReady())
         {
            cap_data1 = mIC2ReadCapture();
            cap_data2 = mIC3ReadCapture();
            a++;
            b++;
         }
         
         if ((a >= 30) && (b >= 30))
         {
            RobSpeedStopped();
            for (c = 0; c < 10000; c++)
            {
               _nop();
            }   
         
         }
         else
         {
            RobSpeedMedium();
         }
      }
   }
}

[waltr]

for the same number of clicks, sometime he turns more and sometimes less...i don't know why...but the error is not very big, maybe 10degrees much or less from 90degrees.

Yep this is not unexpected. Most likely the error is due to slippage of the wheels on the floor and/or the not quite high resolution of the encoders. When you start counting encoder pulses how close is the first pulse, how far must the wheel turn to get the first pulse.
10° out of 90° is 11%
1 encoder tick out of 30 is 3.3% times two encoders = 6.6% plus slippage could be 10% so this all sounds reasonable.

I have gotten similar results on my bot. Moving the motors slower and with an acceleration and deceleration ramps helped but makes the code harder to write. Also keeping one wheel stopped and only moving the other wheel was a little better.

[Benn]

I see. That's it. Maybe i'll improve it later.
Waltr, thank you very much, you helped me a looot:)
Thanks.