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.

ThanksJames

Last edited by JamesD on Fri Nov 14, 2008 10:43 pm, edited 2 times in total.

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.

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.

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

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.

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.

Thu Nov 13, 2008 5:16 am

JamesD

Novice

Joined: Sun Feb 04, 2007 12:48 amPosts: 69Location: Australia

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 3msNXT US : Can be read approx every 50msHiTechnic colour: Updates the internal registry every 10ms (3ms for each RGB reading plus 1ms overhead)

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 3msNXT US : Can be read approx every 50msHiTechnic 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

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

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.

Who is online

Users browsing this forum: No registered users and 2 guests

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