I’m trying to come up with a solution to the problem of ambient light in my classroom due to flourescent lighting. The problem is that the VEX IQ color sensor sees the color green when the lights are on and bluegreen when the lights are off or even when I take it outside. I cannot find an area in my school, let alone my classroom, that doesn’t have the color sensor sensing some sort of green ambient light. This is causing a problem with the cubes. A simple challenge like make the robot stop on red and go on green is impossible, since the robot is already sees green. It will not wait for the green cube. It will immediately go, since it already sees green. My work around has been to have my kids substitute blue for green (stop on red, go on blue). However, this is going to cause problems with any challenge that involves the green cubes. Are these cubes useless? How is this problem been solved in competitions? For example, the High Rise Challenge uses green cubes, so that tells me that it is possible to detect green cubes. Any advice would be much appreciated.
I’m not sure if there is an easy solution in Modkit, but by using ROBOTC you can force the colour sensor to turn on the built in LED even when in hue colour mode. It is then possible to take values using this consistant light source which negates changes in ambient light type. However, it also makes your code a little more complicated than when using Modkit and you would need to calibrate your own hue values to represent each colour.
Thanks for the reply calvc01. We are using ROBOTC Graphical for programming. It is a beginning class and I’m hoping that the fix is not complicated. I’m a beginner myself as this is my 1st year teaching VEX IQ. It’s disappointing that the color sensor is returning this value with ambient light. I have extensive experience with Lego EV3 and their color sensor returns a value value of no color when there are no colors present. Makes things a whole lot simpler.
OK, so in that case you can write a program that uses the proximity sensor feature of the colour sensor so discard information until an object is close to the sensor. I would suggest trying a value of around 190 first but maybe raising up to 200 if you need it to activate a little closer. With this sensor, the smaller the number the further away the object. I just quickly tested this using the old style Highrise cubes (solid ones), the new clip together type might vary slightly. The blue cube is dected as bluegreen, but the red and green are as you would expect.
The attached program sets the touch LED to the correct colour based on the object it is seeing that is close to the sensor. For debugging, it also shows the sensor value on the screen all the time, regardless of proximity so you can see where the errors introduce.
The forum won’t let you upload a ROBOTC .rgb file so I’ve put it in a zip.
Edited to add, I guess the EV3 sensor filters out spurious data by using a proximity sensor feature by default rather than coding it in.
colourSensorTest.zip (1018 Bytes)
Thanks so much calvc01! That code helps me but my students will have difficulty understanding it. I’m looking for code that will make perfect sense to a beginner. Perhaps later when I build an advanced class we can roll out the if/else statements. I have done some work today and I have been using the ColorHue numbers instead of ColorName in the motors and sensor setup. I have a simple program that will displays the number that results from placing a cube in front of the detector. For example, red = 5, green = 109, and blue = 159 in my classroom’s ambient conditions. My students can copy that code and use the program to see the numbers that result from placing different colored cubes in front of the sensor. I can easily teach that code to my kids and have them understand that the color represents a number and that they may need to check that number from time to time due to changes in ambient light conditions. I have attached a simple program that I hope my students can create to get through the Red light Stop Green Light Go challenge using ColorHue instead of ColorName. I’m posting this just in case anybody who is reading this thread is looking for a simple solution to my problem. Thanks again for your reply you are awesome!
This setup is for the Clawbot IQ with Sensor.
!(upload://2pBQyOTxvZMKx7jCcvT7je7Kpjm.jpeg)
!(upload://2pBQyOTxvZMKx7jCcvT7je7Kpjm.jpeg)
I have been working some more to make this work as it is supposed to work. The program I used with my kids using color hue numbers work, but the kids were still having a bit of trouble with it. I just want to make it easy for them to grasp the concept of using the color sensor. The color hue number is a little too abstract for them. Furthermore, the numbers change as the period progresses because ambient light conditions change (I would have to cover all of the windows in my classroom to prevent that from happening. I decided to change the clawbot to have the color sensor facing downwards and to have the surface that the clawbot drives on to be yellow. I tried black (detected Blue Green), white (detected Blue Green), green (detected Green), and blue (detected Blue Green). Yellow was the only color without any traces of green in its detection (It detected Dark Yellow). I thought that would solve the problem, but nope. I ran the following program and the robot would not move forward (color sensor facing down to a Dark Yellow surface color sensor set to color name):
and if you are thinking put it in color hue mode. I tried that as well with the same result. My next step was to insert two lines of code to see what the color sensor was detecting and understand why it was not working. That code looked like this:
For this code the display read “Red Violet”, then unbelievably the clawbot began to move forward after 2 seconds. The rest of the program behaved as it should. Interesting. I removed the displaySensorValue block and just put a wait block for 1 second and the program works. Anybody have some insight on this?
My guess is the sensor takes a fraction of a second to intialise when the program starts so the first display happens before the sensor is ready. Try putting a wait 1 second at the very start of the program (before you print the value to the screen) and see if it then makes more sense.
I much prefer using the sensor in “reflective” mode so that the built in LED is always on because it pretty much eliminates the fluctuations caused by ambient light. However, you can’t do this in graphical as far as I know…
The color sensors are not very good. They pick up green on every surface we’ve tried, and in every lighting we’ve tried. So, the workaround for us is to not use green. We use only blue and red in three color mode. When we need a third color, we add violet and run it in 12 color mode. That works fine if we run over tape or construction paper, but id does render the green cubes useless.