as Hitechnic wrote, the calibration of my faulty color sensor was successful - they programmed the calibration with Lego Software.
The calibration with a RobotC program (as suggested above) was not successful , so we need a correctly working RobotC calibration program.

If I had one, I'd be happy to write one for you. However, I can't really afford to buy one now.

Regards,
Xander

thx Xander,
I think now it's up to the developers....

Ford, I have a color sensor and I have a little bit of free time over the next few days, so I can fiddle with this a bit. I assume you're ok with the way it reads the RGB values. Are you just looking for a way to 'calibrate' the detected colors?

What I'm envisioning is a program that you would run on your own. It would let you hold the sensor up to a variety of different items and show you the RGB values of each. When you like what you see, you would hit a button and have the points stored in a local file. Then, when you use the sensor later, the data file would be read. When the sensor values are polled, they would look to see which of the stored color points is closest to what it sees, and return that as the 'color' value.

Would that suit your needs?

hi avidprogrammer,
the problem WAS:



e.g.




the reason was that the calibration definetively was faulty, and I couldn't re-calibrate ist.
So I sent the sensor to Hitechnic, and THEA managed to re-calibrate it. As thea wrote, the sensor now should work correctly.

But for the future it's neccessary to have such a calibrating program, cause I won't want to send it each time from germany to the US just for recalibrating If this works with NXC, why shouldn't it work with ROBOTC?

I'm just guessing here, but I don't think NXC would be doing anything more than just directly reading the RGB and color values from the sensor. Are you saying that when you tried the code with NXC (before getting the sensor re-calibrated) that it gave back better RGB values than you were getting from the sample code in RobotC? (IE -- before sending your sensor back, RobotC had high blue values, but NXC didn't?)

In any case, I'm still having some fun fiddling with the color sensor for my own purposes. I'll post some code in a few days for those who are interested in giving it a try.

Ok, I think I figured out what you're looking for. Is it this? http://thenxtstep.blogspot.com/2006/05/ ... ement.html

Apparently, the sensor itself has (or had) a way to re-calibrate for white and black. I'll see if I can find out more. Hopefully, it will be as easy as setting a register value while holding up white and black pieces of paper and then you'll be all set.

More to come soon.

Edit: It definitely looks like the calibration routines are generally accessible. Lejos seems to have them available, so I'm going to work backwards from their code to figure out what needs to be done: http://www.stmarycss.ca/oconnor/ICE3M/1 ... ensor.html

Just more notes for people who are interested:

It looks like you set the configuration mode by writing to register 0x41 over I2C. (The HiTechnic specs refer to that as a 'command' register, reserved for future use.) Writing a 0x42 appears to enter 'black level' calibration. 0x43 is used for 'white balance.'

Code coming soon after I get a chance to test it.

[Edit:] Xander, sorry, it looks like you've already written code for this. I really should learn to read the whole thread before I get into things. Your code looks like it only does the white cal, though. I'm giving it a try and I'll add the black/ambient calibration as well.

Great, thanks. I had no idea that there was more than one command, but come to think of it, it kind of makes sense to have two calibration points, one at each end. Thanks for adding the extra code.

Regards,
Xander

hi folks,
actually white calibration should be good enough.
again, this is a note I received from Hitechnic:

but instead of 50-50-50 (red-green-blue) for "white" my sensor always showed 70-70-100. If the white calibration had worked correctly, there should have been at least something like 70-70-70 or 100-100-100 instead. Maybe it's because of passing an array of int?

Edit:
I only tried the sensor with RobotC, I don't use NXC or NXT-G so far.
The faulty colors have been detected by me only with my RobotC program (see above).
My problem is not reading, but calibrating.
A calibrating program for NXT-G exists, but I don't have NXT-G, so I cant use this program (and actually I hate NXT-G).

Because the RobotC calibrating program didn't work, I sent the sensor to HT, they calibrated it with Lego software, and now it works fine (as they said).

What do the developers say to this? Plz give them a chance to reply!

Mightor,

Out of curiosity, is there any good way to avoid bus errors? I've noticed, for example, that if I run your code without any modifications, it doesn't have any problem. If I wait, though, and display some text, then hijack the buttons and wait for a specific key press, there is a bus error after the key press.

But -- if I wait again between the key press and the I2C command, there isn't any bus error (~1/2 second seems sufficient).

Have you seen things like this before? Or am I just having a bad day with I2C?

There are no good ways to avoid bus errors, however, I am working on a driver that automatically recovers from this kind of thing without user intervention. It's all part of a frame work I am, well, working on. I am not sure why this error would occur. Perhaps you should submit it to the Mantis database with some instructions on how to recreate the error. Then Dick can have a look at it By the way, what speed are you using the sensor at? Normal, Faster or Fastest? Try the normal speed to see if the problem still occurs.

Regards,
Xander

my observartions:
Xanders 1st program used the sensor type: HitechnicColorSensor with intrinsic RobotC driver (high speed).
result: No I²C error (no buzz), and no calibrating.

My 2nd try was with sensor type I²C low speed (code see above)
result: I²C error (buzz), but also no calibrating.

I've done some testing with my color sensor and I think the calibration issue isn't so much a faulty sensor or factory calibration but more an issue of what was used to set the initial calibration. With my sensor, if I take readings on a standard white sheet of paper I get a 3 reading like the OP. If I take a reading on a glossy white surface I get a 17 as per spec. Thus it appears that a calibration may be required for various situations.

yes, you're probably right.

So it's much more important to have a correctly working calibration util.

... developers...?!?