View unanswered posts | View active topics It is currently Fri Jul 25, 2014 8:02 am






Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next
HT Color sensor: -> calibrating? 
Author Message
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post Re: HT Color sensor: -> calibrating?
Ford Prefect wrote:
tfriez wrote:
You make the Macro definitions you want, and we'll include them in the next build.

This I unfortunately don't understand quite right, what shall I do, and what exactly will you do in the next build?

I am not sure I understand what you meant by these macro definitions either. Are you talking about different colours?

Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Fri Dec 12, 2008 5:06 pm
Profile WWW
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 614
Post Re: HT Color sensor: -> calibrating?
There is no known problems with the ROBOTC firmware implementation of I2C. Both the normal and high speed speed work "perfectly" with the HiTechnic color sensor -- i.e. no errors in 10**5 messages. I just reran the tests.

There were a few bugs with the I2C implementation and very long sensor cables that have been experienced with HiTechnic devices. This was traced to bugs in the original LEGO implementation of I2C -- i.e. the bug also exists in the NXT-G firmware. It has been fixed in the ROBOTC firmware but not in the NXT-G firmware. And HiTechnic and LEGO no longer support long sensor cables.

If you are experiencing problems with color detection and the HiTechnic color sensor, you should pursue with HiTechnic.


Fri Dec 12, 2008 5:27 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post Re: HT Color sensor: -> calibrating?
Dick,

You've seen the results of tests I have done with the HT Protoboard (I mailed you the results + test program a few months ago). I had 0 errors in test runs with 250,000 consecutive I2C transactions, at all of the speeds that RobotC supports.

I am pretty sure the errors we're seeing with the program I pasted above is due to me doing this off the top of my head and not having a sensor to test the results :)

Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Fri Dec 12, 2008 5:36 pm
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
I only referred to the mail of Steve from Hitechnic:
Quote:
In a number of instances we have found that reported sensor problems have been the result of this non-standard I2C speed so if you encounter any problems with any of the sensors the first thing to do is set the I2C speed to the LEGO standard.


The macros I mentioned should be macros for I²C access in a way Xander made it by his "I2C.h"

to get a value, you only should have to do 2 things:
- maybe send some bytes to the sensor port
- get the values from the sensor port

just like you do it polling analog or ultrasonic sensor values

and forget about all those
Code:
case NO_ERR:
      return;

      case STAT_COMM_PENDING:
         break;

      case ERR_COMM_BUS_ERR:
         PlaySound(soundLowBuzz);
         while (bSoundActive) {}
         // clear out any old buffers.
      clearI2CBus(_link);
         return;


But my problem now is:

is the calibration routine faulty or is the sensor faulty?
Hitechnic currently doesn't support RobotC, so who does?
I myself am neither a technician nor a software developer, and I'm living maybe more than 10,000 km away from New York.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Fri Dec 12, 2008 5:56 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post Re: HT Color sensor: -> calibrating?
Ford Prefect wrote:
The macros I mentioned should be macros for I²C access in a way Xander made it by his "I2C.h"

to get a value, you only should have to do 2 things:
- maybe send some bytes to the sensor port
- get the values from the sensor port

just like you do it polling analog or ultrasonic sensor values

That is why you have the different sensor types, they do this work for you. What you want to do, calibrate, does not fall under the category of regular sensor usage. Therefore you have to use raw I2C commands.

Quote:
and forget about all those
Code:
case NO_ERR:
      return;

      case STAT_COMM_PENDING:
         break;

      case ERR_COMM_BUS_ERR:
         PlaySound(soundLowBuzz);
         while (bSoundActive) {}
         // clear out any old buffers.
      clearI2CBus(_link);
         return;


But my problem now is:

is the calibration routine faulty or is the sensor faulty?
Hitechnic currently doesn't support RobotC, so who does?
I myself am neither a technician nor a software developer, and I'm living maybe more than 10,000 km away from New York.

The error checking I do is a necessary part of doing I2C transactions. Scrapping the error checking does not get rid of the errors. It merely makes them invisible.
The routine is most likely faulty but I have no way of checking that without a sensor.
RobotC can't possibly support every single command that all these sensors support. They do the most commonly used things and anything above that is up to the user to implement. The API is there for just that purpose.

Regards,
Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Fri Dec 12, 2008 6:04 pm
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
well. not that you misunderstand me:

your I2C Header is really fine, and the error checking is undeniable,
but end-users should be able to use I2C commands without having to use those low level routines (if they don't want or are at a beginner level),
just pack them into a library so that they can be read (just like you did).

I know that one needs those low level libraries and headers, but end-usesr should have some short single-line interface macros to access (read and write!) I2C sensor/device commands.

It's like with the NXT-G blocks: a black box with easy access, but the far more complicated stuff behind it can be kept unvisible.

Got what I mean?


PS:
@Xander:
looking through your code...
are you sure you can parse an array to a function?
Code:
#define MAX_ARR_SIZE 16
typedef byte byte_array[MAX_ARR_SIZE];
//...
byte_array _data;
//...
writeI2Cvalue(_link, _data, 0);



but back to my last question.
Quote:
is the calibration routine faulty or is the sensor faulty?
Hitechnic currently doesn't support RobotC, so who does?
I myself am neither a technician nor a software developer, and I'm living maybe more than 10,000 km away from New York.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sat Dec 13, 2008 5:44 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post Re: HT Color sensor: -> calibrating?
Ford Prefect wrote:
It's like with the NXT-G blocks: a black box with easy access, but the far more complicated stuff behind it can be kept unvisible.

Got what I mean?

I understand and I guess it would be possible to write wrapper functions to handle some of the intricacies of the I2C sub system. I think you are confusing "macro" with "wrapper function". Macros are precompiler commands that don't offer the same level of flexibility as a normal wrapper function.


Quote:
PS:
@Xander:
looking through your code...
are you sure you can parse an array to a function?
Code:
#define MAX_ARR_SIZE 16
typedef byte byte_array[MAX_ARR_SIZE];
//...
byte_array _data;
//...
writeI2Cvalue(_link, _data, 0);


I got this byte_array trick from the NXTCam library code, which uses the same method, except there it's an int_array. The fact that the compiler didn't puke gave me hope. Trying to pass a normal array without this trick makes it very sick. I just tested it with the following code:
Code:
#define MAX_ARR_SIZE 4
typedef int int_array[MAX_ARR_SIZE];

void blah(int_array &foo) {
  for (int i = 0; i < MAX_ARR_SIZE; i++) {
    nxtDisplayTextLine(i,"foo[%d]: %d", i, foo[i]);
  }
}

task main() {
  int_array baz = {10, 11, 12, 13 };
  blah(baz);
  while(true);
}

This works as advertised. However, I had to use int_array here because RobotC doesn't print bytes properly and I didn't feel like copying and pasting my byte to int function into this program.

Quote:
but back to my last question.
1 - is the calibration routine faulty or is the sensor faulty?
2 - Hitechnic currently doesn't support RobotC, so who does?

1 - There is no way to tell without a sensor in the hands of someone who knows how to program I2C routines in RobotC. You heard Timothy, they don't have any working sensors at the RobotC HQ atm and I don't even own a broken one.

2 - I can't speak for RobotC or HiTechnic, but RobotC does support this sensor, just not all of the functionality. I think having support for functionality that 100% of the people *need* but not the stuff that only 2% of the people *want* is more than fair. It is a common trade-off when writing (commercial) software. HiTechnic supports their sensors in NXT-G, they are a fairly small company and simply do not have the in-house knowledge or capacity to support anything else besides NXT-G. They rely on 3rd parties to write the code needed to make the sensors work in their language of choice. The development team of RobotC and many others such as myself to do this kind of thing. They're often happy to provide you with technical details to accomplish the task, such as the calibration command for the camera (value of 0x43 to register 0x41). Using the technical details of the IR Link sensor, I wrote the PF motor driver with PWM abilities. They don't support it, so if it doesn't work, you're out of luck and you have to ask me to fix it.

Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Dec 13, 2008 6:34 am
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
to the I2C-black-box: yes, you're probably right, what I meant is more a wrapper function.


to the malfunction of the sensor....
well, I see it from another point of view, for it's more a legal problem:

1.) I bought RobotC in a German Lego online shop, this supposed to mean RobotC is provided and supported by Lego and the RobotC company .
2.) I bought the HT Color Sensor in a German Lego online shop, this is supposed to mean the HT sensor is provided and supported by Lego and the HT company.
3.) Buying a commercial product, I have due to European laws 2 years of guarantee and warrantee (correct words? Germ.: Garantie/Gewährleistung).
4.) the sensor is working faulty, as reported, so I have warrantee claims (correct word?)
5.) HT says, it's not their legal responsibility (correct word?) , because it's a RobotC program, and they don't support RobotC as it's no Lego Product.
6.) RobotC says, it's a third party sensor, and so it's the legal responsibility of HT to fullfill warranty claims.
7.) After all, I don't even know if it's a hardware or a software or a firmware problem, so who is responsible for the malfunction of the sensor?
8.) and if HT should be responsible for the malfunction: should I return it to th U.S. for refund? But what if they (HT) send it back and say with NXT-G it works correctly, the bluish colors are the fault of RobotC?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sat Dec 13, 2008 7:19 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post Re: HT Color sensor: -> calibrating?
Ford Prefect wrote:
to the malfunction of the sensor....
well, I see it from another point of view, for it's more a legal problem:

1.) I bought RobotC in a German Lego online shop, this supposed to mean RobotC is provided and supported by Lego and the RobotC company .
2.) I bought the HT Color Sensor in a German Lego online shop, this is supposed to mean the HT sensor is provided and supported by Lego and the HT company.
3.) Buying a commercial product, I have due to European laws 2 years of guarantee and warrantee (correct words? Germ.: Garantie/Gewährleistung).
4.) the sensor is working faulty, as reported, so I have warrantee claims (correct word?)
5.) HT says, it's not their legal responsibility (correct word?) , because it's a RobotC program, and they don't support RobotC as it's no Lego Product.
6.) RobotC says, it's a third party sensor, and so it's the legal responsibility of HT to fullfill warranty claims.
7.) After all, I don't even know if it's a hardware or a software or a firmware problem, so who is responsible for the malfunction of the sensor?
8.) and if HT should be responsible for the malfunction: should I return it to th U.S. for refund? But what if they (HT) send it back and say with NXT-G it works correctly, the bluish colors are the fault of RobotC?

Just because you buy two products from the same shop, doesn't automatically imply compatibility with each other. That would be like buying a 24V power adapter and a 6V operated MP3 player and expecting them to work together because they were bought at the same shop.

RobotC does not sell sensors, they sell a programming environment that has limited support for 3rd party sensors made by companies such as Mindsensors and HiTechnic. It works as advertised (bugs aside). There is no legal obligation for them to write drivers for every single sensor out there nor for all the functionality these sensors provide. They do, however, provide you with all the tools to extend and enhance its functionality through low level I2C API calls and other functions.

The colour sensor was specifically made for NXT-G. If you were to test it with NXT-G, I am sure it would work fine. So it also works as advertised. If it does NOT work properly under NXT-G, you have the right to return it, within a certain amount of time. This may vary per country.

Robotics is all about compensating for shortcomings in hardware (and sometimes software). Are you sure there is no ambient light that is causing this problem? Did you test it under different lighting conditions? Did you try it outside, under fluorescent lights, standard incandescent?

I am really not sure you have as much legal entitlement to support as you think you have. Test each product under the conditions it's supported at, if you see problems there, then you have a case.

Regards,
Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Dec 13, 2008 8:16 am
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
due to European law, the merchant is responsible for warranty claims.
But as you said, only for verified hardware malfunctions.

I doubt that the sensor works without bluish color detection by NXT-G, but even if it does: who can help with RobotC?

as HT says: it's up to the RobotC company to make the products work together ...

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sat Dec 13, 2008 9:22 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post Re: HT Color sensor: -> calibrating?
Ford,

Surely you have a copy of NXT-G? It would take no time at all to test this :) If it still doesn't work, you complain with renewed fervour to the HT people! If it *does* work then it might be a problem with the colour definitions in RobotC :)

Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Dec 13, 2008 9:50 am
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
no unfortunately I don't have NXT-G, I only bought single Lego parts, and RobotC, and no Mindstorms Kit.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sat Dec 13, 2008 9:57 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
to my specific problem with my sensor, I received a mail from Hitechnic:
Steve/Hitechnic company wrote:
Just drop the sensor in the mail (normal airmail) and we will airmail it back to you as a gift or sample so there will be no customs or other charges.
Regards,
Steve

That's really kind and very generous! Any other company may take this as an example for an excellent customer service :bigthumb:

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Mon Dec 15, 2008 7:54 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
@tfriez:
tfriez wrote:
You make the Macro definitions you want, and we'll include them in the next build.


I don't understand what you want to say:
What shall I do or make?
Do you already have a solution for calibrating?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Wed Dec 17, 2008 8:42 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: HT Color sensor: -> calibrating?
hi, would you plz explain what you said?
That the calibrating function will be available in the next release?
Is this the 1.47?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Thu Dec 25, 2008 5:20 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.