ROBOTC.net forums
http://www.robotc.net/forums/

HiTechnic IR Seeker driver
http://www.robotc.net/forums/viewtopic.php?f=41&t=905
Page 1 of 3

Author:  mightor [ Sun Nov 09, 2008 1:41 am ]
Post subject:  HiTechnic IR Seeker driver

Hey folks,

I've quickly put together a driver for the HiTechnic IR Seeker sensor. Please note that this driver has so far not been tested with an actual sensor as I don't have one (yet).

You can download it here: http://robotc-drivers.googlecode.com/fi ... iver-0_1.c

Please let me know if it doesn't work.

Regards,
Xander

Author:  docilio [ Sun Nov 09, 2008 8:31 pm ]
Post subject:  Re: HiTechnic IR Seeker driver

this post earlier would be better =)

My driver is to slow =( i will try this a.s.a.p.

Thanks

Author:  JamesD [ Wed Nov 12, 2008 8:09 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Hi Xander,

Thank you so much for putting this together. I tested the HTIRReadDir(senIR) function and it gave some readings but my IR Ball was virtually flat. A couple of questions.

1) When you talk about setting up the sensor in the motors and sensors setup is that as a sensorI2CCustom? Is that the best one to use?

2) What is the difference between a buffer as you've defined and an array? It appears that your buffer is an array.

3) In regards to the fact that arrays can't be passed as parameters to a function or void: Is that because the developers haven't yet implemented it or is it a design choice they've made?

4) Have I called the function HTIRSReadAllStrength(tSensors _link, tBuffer &_oBuffer) correctly? Do I then just reference the various array points?

A suggestion you will hopefully agree with:
In trying to make sure the drivers for more complex sensors (ie you can read more than one value) are really user friendly and easy to use we should probably include a commented out main() function that displays all the different readings that can be obtained from a sensor on the NXT screen. Then, less able coders (um huhum) would have examples to work off.

Thanks
James

Author:  mightor [ Wed Nov 12, 2008 9:26 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Hey James,

JamesD wrote:
1) When you talk about setting up the sensor in the motors and sensors setup is that as a sensorI2CCustom? Is that the best one to use?

There is no dedicated sensor type for the IR sensor and I want to use the sensor in a generic manner with I2C calls.

Quote:
2) What is the difference between a buffer as you've defined and an array? It appears that your buffer is an array.

3) In regards to the fact that arrays can't be passed as parameters to a function or void: Is that because the developers haven't yet implemented it or is it a design choice they've made?

There is no real difference except I can pass a struct as a parameter to a function but not an array. I am not sure why this is. You get a compiler error if you try to pass an array.

Quote:
4) Have I called the function HTIRSReadAllStrength(tSensors _link, tBuffer &_oBuffer) correctly? Do I then just reference the various array points?

Yeah, you can access them as follows: _oBuffer.arr[0], etc.

Quote:
A suggestion you will hopefully agree with:
In trying to make sure the drivers for more complex sensors (ie you can read more than one value) are really user friendly and easy to use we should probably include a commented out main() function that displays all the different readings that can be obtained from a sensor on the NXT screen. Then, less able coders (um huhum) would have examples to work off.

No, I don't agree with that. The driver file should be just that, a driver. I am happy to include another example program in a zip file that shows how to use it. I've had problems with this before, so I'd rather keep things seperate. Use the #include ..... preprocessor statement to include the driver into your program.

Quote:
Here is your code that I've started to play with. Is my implementation of your code correct? It appears to work OK? Just see the task main() at the bottom.
Code:
task main()
{
  int nBallDist;
  tBuffer BSenValues;

  while (true)
  {
    nBallDist = HTIRReadDir(senIR);
    //nBallDist = SensorValue(senIR);  //This doesn't work, obviously I've misinterpreted Xander's comments above
    HTIRSReadAllStrength(senIR, BSenValues);

  }


}

To use the SensorValue() call you need to reconfigure the sensor as an UltraSonic sensor, or it won't work. I meant to say that if that is the only way you intend to use the IR Seeker, then that is the way to go, otherwise just use the HTIRReadDir() call.

Regards,
Xander

Author:  docilio [ Wed Nov 12, 2008 9:43 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Xanders, can you tell me how many reads per second can you get?

with my code i get about 300 per second, and you?

[try to test it like this:]

int c=0;
ClearTimer(T1);
While(time1[T1]<10000)
{
//Get the values here
c++;
}

//Divide c by 10, and let us know...

Author:  mightor [ Wed Nov 12, 2008 10:05 am ]
Post subject:  Re: HiTechnic IR Seeker driver

docilio wrote:
Xanders, can you tell me how many reads per second can you get?

with my code i get about 300 per second, and you?


Like I said in my original post, I don't actually have one of these sensors :) I wrote this based purely on the specs given on the HiTechnic page and some code sent to me by HiTechnic. 300 sounds about right for the standard sensor mode. Check out my article on I2C speeds on the NXT with RobotC: [LINK].

Regards,
Xander

Author:  docilio [ Wed Nov 12, 2008 10:46 am ]
Post subject:  Re: HiTechnic IR Seeker driver

that's not good =(

the built in programs to Color and Compass from Hitechnic sensors can do something like 1400 by sec...

Author:  mightor [ Wed Nov 12, 2008 11:02 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Docilio,

The RobotC firmware does not allow for sub-millisecond I2C transactions, so I think there might a mistake in your calculations. The most transactions per second is about 500, by transaction I mean request and reply of equal to or less than 2 bytes. There are some internal dependancies on the ms clock ticks.

Also I think you'll find that the firmware on the sensor does not update the values of the registers more than every 10ms. I have verified this with HiTechnic and this refresh rate applies to both the colour and compass sensor.

Regards,
Xander

Author:  JamesD [ Thu Nov 13, 2008 5:16 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Hi Xander,

Thanks for responding to each of my points and explaining the option of using it in USonic mode, if all I want is direction values.

Apologies to labour the point, but, just to confirm. To use the full power of your drivers, users should set up the sensor as
sensorI2CCustom? (And not sensorI2CCustomFast or sensorI2CCustomFastest)

I can also see your point regarding a driver being purely a driver. And as such, I (and I’m sure others in the future) would love to take you up on your offer to include a little file that displays all the different sensor values on the NXT screen. Hence, relative beginners and novices can pick up your drivers and see them in action first, and then start to decode their usage. (IMHO: This would be really helpful for growing the community)

Thanks again for sharing your great work.

Author:  JamesD [ Thu Nov 13, 2008 5:18 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Hi Docilio,

Regarding the speed of reading the sensors:
You can read a light sensor many times per ms, but you will generally be re-reading the same value many times. You are really only interested in re-reading that sensor after the data in the sensors firmware has been refreshed.

My understanding of the sensor refresh speeds are:
NXT light sensor: Updates the internal registry every 3ms
NXT US : Can be read approx every 50ms
HiTechnic colour: Updates the internal registry every 10ms (3ms for each RGB reading plus 1ms overhead)


See Dick Swan’s post as it was really useful for me:
http://www.robotc.net/forums/viewtopic.php?f=1&t=87

Author:  mightor [ Thu Nov 13, 2008 5:46 am ]
Post subject:  Re: HiTechnic IR Seeker driver

JamesD wrote:
Hi Xander,Apologies to labour the point, but, just to confirm. To use the full power of your drivers, users should set up the sensor as
sensorI2CCustom? (And not sensorI2CCustomFast or sensorI2CCustomFastest)

That is correct. The Fast and Fastest speeds are not officially supported by HiTechnic or Lego for their sensors, although YMMV. When you use a sensor as a very specific subtype, like Ultra Sonic, you are telling the RobotC firmware to poll it using a hidden task. When you use the sensorI2Custom type, you're basically on your own to try and wrest the data from the sensor :)
The Fast and Fastest speeds are great for homebrew sensors. Dick Swan advised me not to bother with the Fast speed and just use Fastest. It makes quite a difference, too. 140 readings per second for a normal sensor, 333 for Fast and 500 for Fastest. You can read more about that here: [LINK].

Quote:
I can also see your point regarding a driver being purely a driver. And as such, I (and I’m sure others in the future) would love to take you up on your offer to include a little file that displays all the different sensor values on the NXT screen. Hence, relative beginners and novices can pick up your drivers and see them in action first, and then start to decode their usage. (IMHO: This would be really helpful for growing the community)

I will add a test program but I'll need you to actually test it since I don't have a sensor to play with.

Quote:
Thanks again for sharing your great work.

Thank you for the kind words :)

Quote:
Regarding the speed of reading the sensors:
You can read a light sensor many times per ms, but you will generally be re-reading the same value many times. You are really only interested in re-reading that sensor after the data in the sensors firmware has been refreshed.

My understanding of the sensor refresh speeds are:
NXT light sensor: Updates the internal registry every 3ms
NXT US : Can be read approx every 50ms
HiTechnic colour: Updates the internal registry every 10ms (3ms for each RGB reading plus 1ms overhead)

This is correct and I have confirmed the HT sensor info with one of the engineers from HiTechnic. It would be like speed reading the same page of a book 10 times. It might look impressive but it's not going to get you to the next page any quicker :)

Regards,
Xander

Author:  mightor [ Thu Nov 13, 2008 6:34 am ]
Post subject:  Re: HiTechnic IR Seeker driver

You can now download driver 0.2 + a test program here: http://code.google.com/p/robotc-drivers/downloads/list

Regards,
Xander

Author:  docilio [ Thu Nov 13, 2008 6:56 am ]
Post subject:  Re: HiTechnic IR Seeker driver

Thanks for the explanation.

And yes, i was getting a mess between the speed of program and the speed to get new values with any relevance.

Author:  JamesD [ Fri Nov 14, 2008 10:38 pm ]
Post subject:  Re: HiTechnic IR Seeker driver

Hi Xander,

Amazing work given you don’t have the sensor! Thanks for including test program to assist with usage.

One minor correction, which is simply an oversight because you couldn’t test the code. In the test program change the following from a string “place holder”, %s” to “%d”. Other than that it looks like great work.
Ie
Code:
// Get the direction of the IR object and display
    _ballDir = HTIRReadDir(HTIRS);
    nxtDisplayTextLine(1, "Dir: %s", _ballDir);
is changed to
Code:
    // Get the direction of the IR object and display
    _ballDir = HTIRReadDir(HTIRS);
    nxtDisplayTextLine(1, "Dir: %d", _ballDir);
in both places it is used.

Couple of questions:
Code:
#define MAX_BUFSIZE   32  // hard coded limit of buffer struct

1) Why do you make the buffer size 32 when there are only 5 sensors to read?

2) Why would each sensor element be identified on the NXT screen as 41236: followed by its value?

Relates to
Code:
    HTIRSReadAllStrength(HTIRS, _senValues);
     for (byte i = 0; i < 5; i++) {
      nxtDisplayTextLine(3+i, "%d: %d", i, _senValues.arr[i]);


Note to other users:
I had to use RobotC v1.46 as I couldn't get this code to work with v1.40.

This sensor may be tricky to use with the soccer ball, for distance calculations. This is because the readings fluctuate wildly depending on whether the IR LEDs inside the ball are pointing directly at the 5 internal sensors or not, as the ball rolls around.

Author:  mightor [ Sat Nov 15, 2008 2:17 am ]
Post subject:  Re: HiTechnic IR Seeker driver

JamesD,

Thanks for the typo spotting. I will fix this in the next version and upload to Google code.

Quote:
Couple of questions:
Code:
#define MAX_BUFSIZE   32  // hard coded limit of buffer struct

1) Why do you make the buffer size 32 when there are only 5 sensors to read?

2) Why would each sensor element be identified on the NXT screen as 41236: followed by its value?

1) It was a standard piece of code I use in all my sensor drivers. I intend to take all the common functionality out of them and put it in a deeper header file shared by all drivers.

2) This is due to RobotC's inability to convert bytes to something you can print. I have a wrapper function to handle this. I will fix that in the next version.

Thanks for testing this driver! I'll be sure to upload the next version as soon as possible. I will put a post on the forums when it's up.

Regards,
Xander

Page 1 of 3 All times are UTC - 5 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/