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!
*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.
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. 
*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.
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?
*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.
*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
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.
*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.
*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.
*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.
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?
*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
*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
*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!
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.
Unless the PIC C compiler is really stange and unlike all others, short int is the same as int is the same as shortthe only thing smaller is char (-128 to 127) and unsigned char (0 to 255).
Yes, both the int and short int types are 16 bit. I ran them through sizeof() to confirm it as well.
I know that int is in fact a 32-bit variable on some systems/compilers, although apparantly not on the PIC.
*Originally posted by Anthony Kesich *
**Unless the PIC C compiler is really stange and unlike all others, short int is the same as int is the same as shortthe only thing smaller is char (-128 to 127) and unsigned char (0 to 255). **
I’m not sure what you mean here. On most 32 bit systems (meaning almost all desktops and a large percentage of embedded systems), the compiler will use a 32 bit value for int and a 16 bit value for short int.
The reason that int on the PIC is 16 bits is because it’s only a 16 bit system, so it doesn’t natively deal with a 32 bit value.
In C++ (and I assume C as well), variable types are defined as follows:
a) a short is at LEAST 16-bits
b) a long is at LEAST 32-bits
c) an int is no smaller than a short and no bigger than a long
By convention, ints are the same number of bits as the processor you are working with (which is 16 in this case), but that’s not a strict requirement.