Chief Delphi - Yaw Sensor

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Motors (http://www.chiefdelphi.com/forums/forumdisplay.php?f=52)

- - Yaw Sensor (http://www.chiefdelphi.com/forums/showthread.php?t=25133)

Can someone tell me how to operate a Yaw Sensor?
Where is it hooked up on the robot controller. Digital or Analog.
We did printf's to see what settings were occurring as we rotated it around, but the code only ever showed 135.....

Help.

Thanks,

Phil

the yaw sensor is an analog device - and you have to supply it with power on its +5V pin - you should see it sitting at 127 or 128 when the bot is not turning, and go up to 254 and down to 0 if you turn the robot fast enough

also, make sure you know the axis of rotation for the sensor - it only senses rotation on one axis.

Quote:

Originally Posted by KenWittlief

None of the FIRST-supplied Yaw Rate Sensors I have had the privilege to play around with have had different neutral outputs. Some have been upwards of 140, while others have been below 110. If you want to effectively utilize any of these Yaw Rate sensors, you'll have to find out what the neutral output is, and use that as your static state. This will limit the sensing ability of the sensor in one direction, while increasing the sensor's ability in the opposite direction (however slightly, in either case, depending on the deviation from "normal").

Also, the Yaw Rate Sensor supplied for the 2003 season has a higher angular rate capacity than the sensors provided in previous years. The 2003 sensors had a theoretical (according to the datasheet) maximum of 75deg/sec, while previous years' had a theoretical maximum of 64deg/sec.

But even with the sensor reading 137, when we move the sensor in ANY direction, tilting up/down, or rotating left/right, no change in the 137 value.....

Thanks,

Phil

If you're patient enough, you can take the sensor off the control system and supply it with 5V, connect GND, and use either a multimeter or an oscilloscope to watch the output to see if it changes at all, or even if the normal output is around 2.66V ((5/254)135).

On the other side of things, you can try to determine whether the analog input to the control system is working properly. You can connect a regular potentiometer to the analog input, and see if the read value changes respectively. If that fails, I would check to make sure that the potentometer works properly, etc.

Hope this helps.

Quote:

Originally Posted by Phil_Lutz

What part are you using?

the yaw rate sensors are analog, and you need to call Get_Analog_Value() on the variable in order to get the actual value. reading it directly won't work (and it looks like that's what you're doing).

also, remember that the analog inputs on the rc are now 10-bit, so without moving the sensor, you should get a reading around 512.

hope that helps.

Quote:

Originally Posted by Phil_Lutz

But even with the sensor reading 137, when we move the sensor in ANY direction, tilting up/down, or rotating left/right, no change in the 137 value.....

Thanks,

Phil

As a double check here is the test code we used on the EDU controller.
Hold the gyro level and twist it quickly 90 degrees or more in the horizontal plane.

Code:

// this assumes in User_Initialization() at least...

IO1 = INPUT;

Set_Number_of_Analog_Channels(ONE_ANALOG);

 

 

 

// in Process_Data_From_Master_uP():

 

unsigned int gyro;

static unsigned long gyroSum=0;

static unsigned int counter=0;

 

/* This sample assumes a 26.2ms loop */

gyro = Get_Analog_Value(rc_dig_in01);

gyroSum += gyro;

counter++;

 

if (counter > 40)

{

        gyroSum = gyroSum/counter;

        printf(" gyro = %d \n", (int)gyroSum); /* values are in the range 0-1023 */

        counter = 0;

        gyroSum = 0;

}

[edit] Fixed small bug in printf. We use different print functions, Sorry.

Quote:

Originally Posted by Mark McLeod

As a double check here is the test code we used on the EDU controller.
Hold the gyro level and twist it quickly 90 degrees or more in the horizontal plane.

I will test this code out tonight.
Boy am I new to this stuff.
Coding no problem, but a Robot isn't a Database. :)

Thanks,

Phil

Here is the code from team 492's current robot. It uses the ADXRS150 evaluation board. They are available from Future, but I got ours as samples directly from Analog. The basic code works for any gyro, you just need to adjust the various #defines.

Wiring is simple too. The evaluation board is a 20pin dip. You need to connect two pins to ground and two to +5v and one pin is the output. A standard three conductor servo cable is all you need. I put ours on a bit of breadboard + a socket along with some other stuff.

Note, our code is called at 100hz. The Gyro has a bandwidth > 40hz so you want to sample it much faster. It wouldn't hurt to sample at 200-400hz, but 100 seems good enough. 38hz (the 26.2ms loop rate for IFI) is too slow.

Also note, below, that our observed scale was more like 200deg/sec range vs the specified 150. The scale changes with temperature, so if you want really accurate results you need to use the built in temperature sensor to compensate. I am going to just calibrate at the competition and trust that the temperature will be reasonably constant over the day.

Code:

/********************** Gyro Task ***************************************

    Gyro output is from .25 to 4.25 volts/5v range.  ADC is 10 bits.

    Full scale output is +/- 150 deg/sec.  Sampling rate is SYSCLOCK hz.



    Adjust FULLSCALEINPUT & OUTPUT to match the observed values

    so that when the robot is turned 360 deg the reported angle is

    360.  Double check by returning robot to starting position and

    verifying angle is 0.            

    

    Note: The gyro reading is 10bits, but I shift it over 4 to get a 16 bit value.

    This allows a fractional "offset" value which, when integrated over time

    will give a more accurate "zero" value.

*/



#define FULLSCALEINPUT (203.0 * 2.0)

#define FULLSCALEOUTPUT (1023.0 * 16.0)

#define PERIOD (1.0/GYROCLOCK)



#define GYROSCALE (FULLSCALEINPUT * PERIOD / FULLSCALEOUTPUT)



// GyroTask called at the primary loop rate of 100hz.  Delay 1.28 seconds before

// setting the basic gyro offset.  Gyro seems stable enough to last the 2 minute

// match without drifting significantly. Only high speed turns will mess it up.



#define GYRODELAY 128



int InitGyro = GYRODELAY;

int GyroOffset;

int iGyroTheta, iGyroRate;                // These are Zero at boot time

long temp;



float fTheta = GYROSCALE;



void Gyro_Task(void)

{

    int GyroVal = GetADC(Gyro) << 4;



    switch(InitGyro)

    {

        default:            // Delay until stable reading

            InitGyro--;

            temp += GyroVal;// Get average ADC value over 1 second

            break;

        case 0:             

            InitGyro = -1;

            GyroOffset = temp / GYRODELAY;

            break;

        case -1:

            iGyroRate = GyroVal - GyroOffset;

            fTheta += (float)iGyroRate * GYROSCALE;

            iGyroTheta = fTheta;    // Make integer version available.

            break;

    }

}

only thing I disagree with on your post is the sensor has a bandwith of 40Hz or so, but your bot is heavy enough that IT wont have a bandwith anywheres near the 26mS sample loop

your motors will not be able to spin the bot around so quick that you need to worry about the bandwidth of the sensor

if your bot is jittering and twitching at 38Hz, you've got more problems to worry about than using a gyro :c)

Get_Analog_Value in an ISR

I want to sample some analog inputs at 4ms.

The first way I tried this was to set up a timer interrupt at 4ms and in the ISR, set a tic4ms flag. Then in the polling loop, whenever the tic4ms flag was set, I'd clear it and run the sampling code. The problem with this is that my main processing, which runs every 26ms, uses about 9ms and I miss some of the 4ms tics.

Next try was to read the analog inputs in the ISR itself. I hoped that doing
#pragma interruptlow InterruptHandlerLow save=PROD, section(".tmpdata")
would save enough context, but it evidently does not - I am getting a smattering of wild data now in the main polling process. First I thought this was because I was calling Get_Analog_Value in the ISR as well as in the main process. Get_Analog_Value uses some SFRs, and they are not saved across the interrupt, so this would be expected to at least give some bad samples if not worse data mangling. But I moved all the analog sampling to the ISR so Get_Analog_Value would be called from only one thread. This did not eliminate the problem.

Anybody have suggestions?

Also, my assumption is that Get_Analog_Value only runs a few tens of microseconds (15-30 or so) so I can do many of them in a 4ms ISR w/o an overrun problem. This is what it looks like in the pic datasheet. Can anyone confirm this?

Thanks for any help.

Bill

Re: Get_Analog_Value in an ISR

Quote:

Originally Posted by WizardOfAz

...
Next try was to read the analog inputs in the ISR itself. I hoped that doing
#pragma interruptlow InterruptHandlerLow save=PROD, section(".tmpdata")
would save enough context, but it evidently does not - I am getting a smattering of wild data now in the main polling process. First I thought this was because I was calling Get_Analog_Value in the ISR as well as in the main process. Get_Analog_Value uses some SFRs, and they are not saved across the interrupt, so this would be expected to at least give some bad samples if not worse data mangling. But I moved all the analog sampling to the ISR so Get_Analog_Value would be called from only one thread. This did not eliminate the problem.

Anybody have suggestions?

Also, my assumption is that Get_Analog_Value only runs a few tens of microseconds (15-30 or so) so I can do many of them in a 4ms ISR w/o an overrun problem. This is what it looks like in the pic datasheet. Can anyone confirm this?

Thanks for any help.

Bill

According to the C compiler manual you need to save additional context when calling functions that return values. Specifically, for 8 & 16 bit return values you need to save 'PROD'. I believe it is page 28...

Team 492 samples the ADXSR150 at 100hz (10ms). Our basic logic is a 1khz timer that increments a byte counter (atomic operation). In the fast loop of the IFI code we check that counter and do stuff when it increments.

The fast loop is called often enough to sample the timer directly (e.g. no interrupts) but we used them anyway in case some code in the Autonomous routines took longer than a milli-second to run.

Code:

void Process_Tasks(void)

{

    static char GyroTimer = 0, PrintTimer = 0;



    Poll_Rx1();                                // The fast loop runs > 100khz

    Poll_Tx1();                                // Poll rather than interrupts

    Poll_Rx2();

    Poll_Tx2();



    while (MsTimer)                                // Incremented by TimerInterrupt.

    {

        MsTimer--;                        // Section.



        if (++GyroTimer == 10)                // 100hz

        {

            GyroTimer = 0;

            Gyro_Task();

        } // END GyroTimer



        if (++PrintTimer == 100)                // 10hz

        {

            SysTimer++;                        // General timer for system

            PrintTimer = 0;

            TetherTask(STDIO);

        } // END Print task

    }// END Tasking

}

Here is a snipped of our interrupt code

Code:



/*******************************************************************************

* FUNCTION NAME: InterruptHandlerLow

*

* If you want to use these external low priority interrupts or any of the

* peripheral interrupts then you must enable them in your initialization

* routine.  Read p. 28 of the "MPLAB(R) C18 C Compiler User's Guide" for

* information on context saving.

*

* Because this handler calls something, it must save ".tmpdata".  If the called

* routine returned a 16 bit variable, "PROD" would need to be saved as well.

*******************************************************************************/

#pragma code

#pragma interruptlow InterruptHandlerLow  save=section(".tmpdata")/* You may want to save additional symbols. */



void InterruptHandlerLow ()

{

    If (INTCONbits.RBIF)                       /* INTERRUPTS 3-4 (RB4, RB5, RB6, or RB7) changed. */

    {

        DecodeQuadrature(PORTB);         // Read PORTB and clear IF to

        INTCONbits.RBIF = 0;                // clear interrupt

    }

    if (PIR1bits.TMR2IF)                 // timer 2 interrupt?

    {

        PIR1bits.TMR2IF = 0;         // clear the timer 2 interrupt flag [92]

        MsTimer++;                // Increment millisecond timer

    }

}

Just a heads up... You cant use the gyro from last years kit (very clear... see the QA id's #341, 346, 190). Therefore, you have to use a different one under the custom electronics pricing. The only real viable option is the ADXRS series from Analog Devices, and if you need more then 150 deg/sec, then it will get much harder (the Evaluation Board version of the 300 deg/sec model is just barely over the price limit... you will need to mount 300 deg/sec yourself). Nobody made it very clear in the previous posts, and I didnt know what gyro you were using to begin with.

We were going to use last years gyro at "custom electronics cost" but it is a none issue now as we have gone another route.

Dead rec with timing loop on the turn.

Thanks,

Phil