Ours came in today, and we’re busy writing code to try and get it working as quickly as we can. We need the refresh rate for the application we’re writing. Does anyone know what it is? I couldn’t find it in the VEX Documentation,
It’s an analog sensor so very fast. (if you mean this sensor).
4.5KS/S (kilo samples per second) to perhaps 25KS/S depending on the language. (I forget the actual numbers)
It’s not something to really think about, every time you read it a new value will usually be returned.
Okay, we’re trying to find the average values it returns over the course of a second using a “for” statement. The code we were using (PROS) is below.
for (i = 0; i < 100; i++) {
colorSensor = analogRead(1);
working = working + colorSensor;
delay(20);
}
avgRed = working / 100;
working = 0;
I’m guessing the Cortex doesn’t actually read that fast. We had the delay in there so that we can make sure it actually works. 100 times is incredibly fast. Are you recommending that we go somewhere around 5,000 samples so that it actually gets a range of values?
A bit more background on the analog inputs.
The analog to digital converter is clocked at 9MHz.
The sample time is given as Tconv = sampling time + 12.5 cycles
where “sampling time” is the number of cycles per conversion and is a variable set by the firmware.
For ROBOTC, sampling time is 239.5 cycles
For EasyC, sampling time is 71.5 cycles
For ConVEX, sampling time is 71.5 cycles
Therefore, the conversion rate for ROBOTC is 1/9MHz * (239.5+12.5) which is 28uS. But there are 8 channels so the period that each channel is sampled is 8*28uS which is 224uS so 4.464KHz.
For EasyC and ConVEX the frequency using the same calculation is 13.392KHz
I think PROS is faster.
However, there is another factor to consider. The analog input has a simple low pass filter (I read somewhere, forget where). The cutoff frequency for this is given as 1/(2 * PI * R * C) where R is 10KΩ and C is 1nF in the cortex (again, I forget where these numbers came from). So the cutoff frequency is 16KHz, not much point in sampling at a higher frequency than that.
Edit:
I should add that in theory to correctly sample a 16KHz signal Harry Nyquist tells us that a sampling rate of 32KHz would be needed. The point I was trying to make is that the way we use analog sensors in VEX there’s not much to be gained from sampling that high unless the firmware can pre-process that data before presenting it to user software. The only sensor that we have for high school where this might be useful is the gyro and even then I’m not sure how much difference it would actually make.
Are you doing this for noise reduction or just because the value returned varies a lot?
Noise reduction is the goal. We’re playing with the idea of using ambient light to detect the colour of game objects (which I realize is possibly impossible), and the number is varying a bit depending on how the object rotates in our hands.
It’s possible that won’t be an issue on the field, but we figured it was something to take care of now.
Well, try the code you have (although that gives a 2 second average), see what happens. PROS also has some type of built in averaging I think, that’s how they do (I’m guessing here) the high resolution conversions, that may also help you. You probably also want to use a red or blue filter over the light sensor to help with object detection.
The delay(20) wasn’t bad. We decided to do 1000 samples with a (5) delay as a test, and that seems to be more accurate.
Out of curiosity, do you know what I could use to create a pseudo-light filter until the ones we ordered come in? I’ve got a bunch of code written, and if I could use something around the shop to actually test with, that would be great. Pieces from a VEX Flag, a coloured-over plastic bag, and the tape that came with the field to mark driver stations all didn’t work.
I can’t think of anything other than something like anaglyph 3d glasses.
I don’t know how well game object color detection will work, the ambient light falling on the light sensor may overpower the reflected light from the object, you may have to be quite close.
We have working code, now. It’s telling the difference between red/blue objects using ambient light. There’s a piece of masking tape coloured with red Expo marker on top of the light sensor. If anyone wants to see a picture, that along with the code will be on the website in about an hour or two. We may need to get an actual Red light filter later, but at the moment we’re fairly happy with it.
The code I’m uploading here works. I’m using this as a temporary repository. Feel free to take a look, but this isn’t exactly “correct” as far as conventions go. I’ll clean it up later.
Sensor.zip (1.07 MB)