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

this post earlier would be better =)

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

Thanks

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

Hey James,


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


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.


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


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.


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

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...

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

that's not good =(

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

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

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.

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

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].


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.


Thank you for the kind words


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

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

Regards,
Xander

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.

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
is changed to
in both places it is used.

Couple of questions:

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


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.

JamesD,

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


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