Quick Question

[Burgabot]

Ok, the documentation of this year's EDU-RC says that the analog inputs are 10-bit rather than 8-bit this year. Therefore, if we were using last year's gyro to practice with, would it return a value between 0 and 1023? If this is the case, would it even return values that aren't multiples of 4 (since last year's resolution was only 255)? Also, are there any obscure two-byte data types in C? It seems like a waste of space to use an int to store this value. Thanks!

[Dave Flowerday]

Originally posted by Burgabot
Therefore, if we were using last year's gyro to practice with, would it return a value between 0 and 1023? If this is the case, would it even return values that aren't multiples of 4 (since last year's resolution was only 255)?

Yes and yes. The gyro puts out an analog value, so it's resolution is essentially infinite. It's the microcontroller that rounds it off to some finite amount. The old controllers rounded the value to 8 bits, the new one rounds to 10.

Also, are there any obscure two-byte data types in C? It seems like a waste of space to use an int to store this value. Thanks!

It's not obscure, really. The keyword is short int. On most compilers this is a 16 bit value. I haven't checked yet with the PIC C compiler if this is the case with it, though.

[Burgabot]

I should have clarified what I meant by "obscure." In my mind, an obscure data type is anything that I don't bother to use when programming on a computer because the RAM is essentially infinite.

[Dave Flowerday]

Originally posted by Burgabot
I should have clarified what I meant by "obscure." In my mind, an obscure data type is anything that I don't bother to use when programming on a computer because the RAM is essentially infinite.

Hmm... I suppose it wouldn't be used much in desktop programming. We use it in embedded software development all the time, especially when you need to interact directly with the hardware.

[Burgabot]

Actually, I do have another question. Originally, I was going to measure angular velocity by integrating angular accleration, obtained from two linear accelerometers placed a certain distance apart. I did this because the gyro can only measure angular velocities of ±75 degrees/second or less, and runs into trouble at anything higher than that. However, I realized that this will be far less accurate than using a gyro sensor.

Basically, what it comes down to is that there's a tradeoff between accuracy (the gyro) and range (the two acclerometers). Therefore, I came up with a compromise that I hope will work. In every program cycle, I'll get the angular speed as determined by the gyro. If it turns out to be 75 degrees/second (which I'm assuming is what it'll return if the speed is higher than that), I'll use the accelerometer data instead of the gyro data to determine the angular velocity. That way, I'll have the accuracy of the gyro at normal speeds and the range of the accelerometer arrangement at high angular speeds. Think this will work? Anything I have to watch out for?

[Dave Flowerday]

Originally posted by Burgabot
If it turns out to be 75 degrees/second (which I'm assuming is what it'll return if the speed is higher than that), I'll use the accelerometer data instead of the gyro data to determine the angular velocity. That way, I'll have the accuracy of the gyro at normal speeds and the range of the accelerometer arrangement at high angular speeds. Think this will work? Anything I have to watch out for?

That sounds like it has potential. The biggest problem I see would be caibrating the two so when you switch from using the gyro to the accelerometers you're still integrating the same value. Also you'll need to build in some hysteresis so that if your velocity is right at the point of switching from the gyro to the accelerometors, you don't rapidly toggle back and forth between them. To do this, you would only switch away from the gyro if the velocity is >= 70 deg/sec, but you wouldn't switch back to it until the value fell below 65 deg/sec.

[Chris Hibner]

Originally posted by Burgabot
Actually, I do have another question. Originally, I was going to measure angular velocity by integrating angular accleration, obtained from two linear accelerometers placed a certain distance apart. I did this because the gyro can only measure angular velocities of ±75 degrees/second or less, and runs into trouble at anything higher than that. However, I realized that this will be far less accurate than using a gyro sensor.

I would contact Future and buy an Analog Devices angular rate sensor ("gyro"). They have one that can measure +/- 300 degrees/second.

-Chris

[Andrew]

For those of you who have used the gyro on FIRST robots, how much of a limitation is 75 degrees per second? Have you seen your robot exceed that value?

I would think that the errors introduced by scaling the value between 0...255 would introduce more overall error in the integration than the robot turning faster than 75 dps.

It also depends on what you're doing with the gyro. If you're doing odometry, seems like you're going to have errors from wheel slip and integration of gyro which will require an on-the-fly recalibration regardless.

If you're just using the gyro for closed loop control, the 75 dps limit shouldn't make as much difference as the sample rate limitation and the quantization limitation.

[seanwitte]

Originally posted by Chris Hibner
I would contact Future and buy an Analog Devices angular rate sensor ("gyro"). They have one that can measure +/- 300 degrees/second.
-Chris

Just a note on that part. There are two models, the ADXRS150 and the ADXRS300. The number corresponds to the max degrees per second. There is an evaluation board available at Future and Arrow that includes all the caps in the sample application in the datasheets. The part number has an -EB appended to it. Those devices are about the size of a pencil eraser and are a ball-grid array so you can't solder them by hand. The EB parts look like a basic stamp and can be pushed into a regular 20 pin IC socket.

[Chris Hibner]

Originally posted by Andrew
For those of you who have used the gyro on FIRST robots, how much of a limitation is 75 degrees per second? Have you seen your robot exceed that value?

I would think that the errors introduced by scaling the value between 0...255 would introduce more overall error in the integration than the robot turning faster than 75 dps.

For the first question: Our robot typically turns at around 180 degrees per second. Due to this, the 75 degree/sec GyroChip is pretty much useless to us. If you want to use it for a different application, this limitation might not be a problem. You should also have some margin for unexpected occurances. For instance, our robot can turn at 180 deg/sec on its own, but when we get hit by another robot, it might be able to turn much faster. Therefore, the 300 deg/sec part gives us a little margin.

For the second part: Quantization of the signal (using 256 discrete values instead of infinitely many values of an analog signal) is not that much of a problem, especially if you have enough random noise with peaks above 1 A/D count. This will also be less of a problem with the new PIC micro since it has a 10-bit A/D (1024 discrete values, instead of 256 with the 8-bit A/D).


Random noise at the A/D can improve the apparent resolution of your A/D converter. This could actually be an entire whitepaper. If there is enough interest, I'll try and find time to write it up.

[Greg Ross]

Originally posted by Chris Hibner
Random noise at the A/D can improve the apparent resolution of your A/D converter. This could actually be an entire whitepaper. If there is enough interest, I'll try and find time to write it up.

That seems like a counterintuitive statement. I would like to see that white paper.

[Burgabot]

So, you'd recommend that I use last year's gyro for speeds less than 75 degrees/second, one of Future's for speeds greater than 75 and less than 300, and accelerometers for any thing greater than 300?

[Chris Hibner]

Originally posted by gwross
That seems like a counterintuitive statement. I would like to see that white paper.

Greg,

I just finished the white paper and submitted it. It will be up soon (once it is approved).

-Chris

[Chris Hibner]

Originally posted by Burgabot
So, you'd recommend that I use last year's gyro for speeds less than 75 degrees/second, one of Future's for speeds greater than 75 and less than 300, and accelerometers for any thing greater than 300?

Sorry for two posts in a row...

I would use last year's gyro for speeds less than 50 deg/sec, the 300 deg/sec gryo for less than 200 deg/sec. If you know absolutely, 100% FOR SURE what your worst-case speed is, you can reduce the margin (like use the 75 deg/sec gryo up to 65 deg/sec). Just be sure you account for getting bumped by other robots.

Also, I don't know if I would ever recommend using accelerometers. Our team actually thought of doing this last year (before we found the 300 deg/sec part), but we found a lot of potential problems. We decided that if we had to, we would be better off building an old-fashioned mechanical gyroscope and measuring the gymbal angle with a potentiometer.

If you do go with accelerometers, be sure you select the G-range appropriately. In other words, calculate out how much acceleration they will see in normal usage, then apply a little margin, then buy accelerometers in this range. Most accelerometers you'll find will be like +/- 50 G's. This will give you WAY too little resolution. You'll probably need a low-G accelerometer (like +/- 5 G), which you will pay an arm and a leg for.

-Chris

[KevinB]

Originally posted by Chris Hibner
I just finished the white paper and submitted it. It will be up soon (once it is approved).

Excellent White Paper! Thanks for posting it!