Robomagellan 2012 Build Diary - Day 28

Days 1 - 7

http://buildsmartrobots.ning.com/profiles/blogs/robomagellan-2012-b...

Days 8 - 16

http://buildsmartrobots.ning.com/profiles/blogs/robomagellan-2012-b...

Days 17 - 27

http://buildsmartrobots.ning.com/profiles/blogs/robomagellan-2012-b...

My day job has kept me extremely busy.  I have been putting in 12 and 16 hour days for the last 2 weeks.  I have not had much time at all to work on the robot.  I did get a few hours tonight to finally test the speed sensor circuit and software. You can read about how I built the speed sensor, and a general theory of operation in the comment section here: http://buildsmartrobots.ning.com/profiles/blogs/robomagellan-2012-b...

The speed sensor consists of a IR LED and IR transistor mounted opposite of each other through holes I drilled in the gearbox.  There were already holes in the gear.  The IR LED emits an IR beam.  The gear has evenly spaced holes in it.  The IR beam is "interrupted" by the gear, and allowed to pass through via the holes in the gear.  Every time a hole in the gear passes between the IR LED and IR transistor, the IR transistor turn on, conducting to ground.  When the IR transistor get no IR light, it shuts off, and an external pullup resistor pulls the signal to VCC.

 

Speed sensor output at full speed (signal at collector)

 

Speed sensor output at approximately 1/7 full speed

 

Speed sensor output post MSP430G2553 internal comparator

 

The scope shots above were taken from the collector of the IR transistor, and the output of the MSP430G2553 (pin 15 - CAOUT).

As the scope shots show, as the hole in the gear go past the sensor, the signal goes to zero.  The signal peaks represent the plastic between the holes in the gear, blocking the IR beam between the IR LED and the IR transistor.  

Notice how the internal comparator of the MSP430G2553 can be used to condition the signal, squaring it off and cleaning it up.  

 

The software takes advantage of the comparators edge interrupt capabilities.  On each rising edge, a comparator interrupt is triggered.  In this interrupt a counter is incremented.  

 

 

The robot is too big for my bench so I have to work on the kitchen table.  i have a very understanding wife.  the white plate under the robot is lifting the wheel off the ground for speed sensor testing.

 

 Unfortunately, I just missed the speed sensor test setup in this picture.

 

 

 Testing the speed sensor.  Not the scope connected to P1.7

 

The linear pot (blue rectangle) adjust the LED current.  The blue and white pot adjusts the collector bias on the IR transistor.  All the real work is done inside the MSP430G2553 on the TI Launchpad.

 

void RoboMagellan_InitVelocityLoop(void)
{
        CACTL1 = CAREF_2 + CARSEL + CAON + CAIE;
        CACTL2 = P2CA0 + CAF;

        P1DIR |= 0x80;
        P1SEL |= 0x80;
        P1SEL2 &= ~0x80;

        TA0CTL = 0x02e2; // SMCLK(16Mhz), /8, continuous, overflow interrupt

        Desired_Velocity = 0;
        Edge_Counter = 0;
        Current_Velocity = 0;
        OverFlow_Counter = 0;
}


void RoboMagellan_SetVelocity( signed char Velocity )
{
       Desired_Velocity = Velocity;
}

unsigned short RoboMagellan_GetVelocity(void)
{
       return( Current_Velocity );
}

#pragma vector=COMPARATORA_VECTOR
__interrupt void CompA (void)
{
      ++Edge_Counter;
}


#pragma vector=TIMER0_A1_VECTOR
__interrupt void Timer0_A1 (void)
{
     volatile unsigned short ta0iv;

    ta0iv = TA0IV; // Reading TA0IV clears it

    if( ta0iv == TA0IV_TAIFG )
    {
        if( ++OverFlow_Counter > 3 )
        {
             OverFlow_Counter = 0;
             Current_Velocity = Edge_Counter;
             Edge_Counter = 0;
        }
   }
}

 

 

Views: 167

Tags: IR, LED, Launchpad, PI, PID, RoboMagellan, TI, autonomous, control, motor, More…speed, transistor, vehicle

Comment by eric gregori on July 22, 2012 at 6:34am

Devantech CMPS03 Magnetic Compass Module

http://www.robot-electronics.co.uk/htm/cmps3tech.htm

Pin 4. The PWM signal is a pulse width modulated signal with the positive width of the pulse representing the angle. The pulse width varies from 1mS (0° ) to 36.99mS (359.9° ) – in other words 100uS/° with a +1mS offset. The signal goes low for 65mS between pulses, so the cycle time is 65mS + the pulse width - ie. 66ms-102ms. The pulse is generated by a 16 bit timer in the processor giving a 1uS resolution, however I would not recommend measuring this to anything better than 0.1° (10uS). Make sure you connect the I2C pins, SCL and SDA, to the 5v supply if you are using the PWM, as there are no pull-up resistors on these pins.

 

 

Comment by eric gregori on July 25, 2012 at 11:58pm

Results from a closed loop motor control test.  The system starts at half speed, then goes to full speed, then drops back down to half speed.  The red line represents the measured speed using the optical encoder.  The blue line represents the velocity setpoint.  In the perfect world, the red line would match the blue line exactly.  I definitely still have some gain tweaking to do and possibly a bug.  There were two speed measurement outliers of 77 and 25 (I reduced the 70 to 30 for graphing purposes).  The 77 has to be a bug.  It's impossible for the motor to turn that fast.  I have to do more testing to determine if it's an actual speed measurement bug or a communication bug when logging the data.

Two other interesting things to note; the amount of time it takes to get from half speed to full speed, and the amount of time it takes to get from full speed to half speed.

When going from full speed to half speed, the velocity goes to zero.  This is caused by a bug in the code I just found from analyzing this data.  The code is supposed to reset the servo speed to a baseline when changing directions.  The bug is causing the code to reset the servo speed to baseline when changing speeds as well.  An additional if() statement fixed the bug and eliminated the zero velocity when going from full speed to half speed. 

The time it takes to go from half speed to full speed is directly proportional to P gain.  A higher gain will decrease the time it takes to get up to speed but it will also increase the oscillations.  This is where the I component of a PI controller comes into play.  I have the I code tuned off now.  When turned on, the I component will decrease the ramp up.  It will also add overshoot and decrease stability.

You may also note the measured velocity does not reach the full setpoint.  This is due to the battery getting low.  The battery voltage limits the max rpm of a motor, thus limiting the max velocity. 

Comment

You need to be a member of buildsmartrobots to add comments!

Join buildsmartrobots

EMGRobotics

© 2013   Created by eric gregori.

Badges  |  Report an Issue  |  Terms of Service