Page 1 of 2

How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 08:25
by amenzar
Hi, I'm new to robotics (started one week ago) and I'm having some trouble using the Color Sensor provided by the LEGO kit.

I have to develop a program with Java for Lego Mindstorms, LeJOS NXJ v0.9 but firstly I need to calibrate the Color Sensor to distinguish 6 color categories: BLACK, RED, BLUE, GREEN, YELLOW and MAGENTA. This is the part I'm having trouble to do, also I read from Wikipedia (http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT_2.0) that the CS doesn't distinguish MAGENTA, a color that I'm explicitly asked to recognize!

Maybe I'm not looking at the right place but it seems like there's no much info about it. I went to the LeJos API documentation and found http://goo.gl/ANq3E but I think this class works only for HiTechnic CS (which identifies up to 18 colors, much more than the one I'm using). Nevertheless, I kept looking and found this http://goo.gl/ebnDY which seemed the class I was looking for. The problem is that I don't know how to use these functions to perform the calibration, last time I tested using the getColorNumber function (because with getColorID didn't compile) against a Black surface returned me 7 which means Orange (my guess is that a returned value of 7 in a CS which distinguishes between six colors means "Color unrecognized" or something like that).

I'm really confused by this and I'm probably doing something wrong, so any kind of suggestion would be appreciated.

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 12:58
by hassenplug
Not sure I can answer the question, but maybe I can point you in the right direction.

You can't really change the calibration of the sensor. It will only return values for the predefined colors.

However, you can also get values for red, green, blue, and ambient light. With these values, you should be able to write software to identify other colors.

Hope that helps.

Steve

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 17:00
by amenzar
Thanks for responding so fast, and from what you said I think I understand now.

Basically what you told me is to forget about the getColorNumber() function and start to "play" with the functions getRed(), getGreen() & getBlue(). So when I put the CS in front of a green surface and e.g. get this output ( R=34; G=139; B=34; ), then I should configure my program to distinguish that RGB combination as Green (with the proper Color Tolerance).

That leaves me with the question, why is even necessary the getColorNumber function anyway?

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 17:42
by linusa
amenzar wrote: why is even necessary the getColorNumber function anyway?
A simple approach, when you are in a hurry or when you don't need fancy color recognition. Or for users who are not familiar with the concept of RGB colors. Think about the target audience of LEGO products :-).

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 18:16
by hassenplug
amenzar wrote:Basically what you told me is to forget about the getColorNumber() function and start to "play" with the functions getRed(), getGreen() & getBlue().
right. Make sure to test your values under different lighting conditions, because the lighting in your room *WILL BE* different from the lighting in front of the professor. (or, where ever you show this off)
amenzar wrote:That leaves me with the question, why is even necessary the getColorNumber function anyway?
It's useful for MOST people who have only been doing robotics for a week.

Steve

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 19:10
by afanofosc
What I might recommend is using the color number for the colors that it works for and then if it returns a value that you know is what it returns for both RED and MAGENTA (or whatever) then if you get that number back start doing your own calculations using the raw RGB values that you can read from the sensor. It might save you some coding as well as run faster since you let the firmware do some of the calculations for you.

John Hansen

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 17 Aug 2011, 19:59
by amenzar
Thank you very much for your responses.

I'll be doing the calibration on Friday (when the lab is available) bearing in mind your advices.

I'll keep you posted.

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 18 Aug 2011, 07:35
by timpattinson
hassenplug wrote:right. Make sure to test your values under different lighting conditions, because the lighting in your room *WILL BE* different from the lighting in front of the professor. (or, where ever you show this off)

+1
My fist color sorter (which i built for school) had heaps of problems with that

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 18 Aug 2011, 07:50
by mindsqualls
getColorNumber() is for working with the colored balls that comes with the NXT 2.0 retail box. It works just fine for them.

If your needs is more advanced than this, then you will have to do something along the lines of what hassenplug suggests. However this will show down the reading because you now will need tree readings compared to one, and you will also need to turn on the various light’s of the sensor.

You mentioned the HiTechnic Color sensor. Just to clarify: This sensor is a completely different beast from the NXT 2.0 color sensor. This means that API code that works for one will not work for the other. In more technical terms: the HiTechnic-sensor is a “digital sensor” and the NXT 2.0 is a “passive sensor” and this means that any API will need to treat them completely different from each other.

Re: How to calibrate NXT 2.0 Color Sensor?

Posted: 18 Aug 2011, 13:33
by mattallen37
I think there is a way to access the values while it is running in normal (RGB) mode. I don't think you have to switch to just red, green, then blue to get the RGB of it (I haven't tested this, but I have heard you can access them all at once).

The HT color sensors are I2C (which is digital), but the Lego 2.0 color sensor is also digital (just not I2C). Lego seems to have used a custom protocol to fit the bill. It does require the ARM to use it's ADC on a digital pin (I forget if it's 5 or 6), but I don't think that would make it qualify as passive.