View unanswered posts | View active topics It is currently Wed Jul 30, 2014 4:47 am






Reply to topic  [ 36 posts ]  Go to page 1, 2, 3  Next
HiTechnic IR Seeker driver 
Author Message
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

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


Sun Nov 09, 2008 1:41 am
Profile WWW
Expert

Joined: Sun Sep 09, 2007 10:12 am
Posts: 116
Post 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

_________________
http://www.apcsguarda.com
My Project: http://www.robotc.net/forums/viewtopic.php?f=15&t=712


Sun Nov 09, 2008 8:31 pm
Profile
Novice

Joined: Sun Feb 04, 2007 12:48 am
Posts: 69
Location: Australia
Post 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


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



Wed Nov 12, 2008 8:09 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

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


Wed Nov 12, 2008 9:26 am
Profile WWW
Expert

Joined: Sun Sep 09, 2007 10:12 am
Posts: 116
Post 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...

_________________
http://www.apcsguarda.com
My Project: http://www.robotc.net/forums/viewtopic.php?f=15&t=712


Wed Nov 12, 2008 9:43 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

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


Wed Nov 12, 2008 10:05 am
Profile WWW
Expert

Joined: Sun Sep 09, 2007 10:12 am
Posts: 116
Post 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...

_________________
http://www.apcsguarda.com
My Project: http://www.robotc.net/forums/viewtopic.php?f=15&t=712


Wed Nov 12, 2008 10:46 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

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


Wed Nov 12, 2008 11:02 am
Profile WWW
Novice

Joined: Sun Feb 04, 2007 12:48 am
Posts: 69
Location: Australia
Post 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.


Thu Nov 13, 2008 5:16 am
Profile
Novice

Joined: Sun Feb 04, 2007 12:48 am
Posts: 69
Location: Australia
Post 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


Thu Nov 13, 2008 5:18 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

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


Thu Nov 13, 2008 5:46 am
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

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


Thu Nov 13, 2008 6:34 am
Profile WWW
Expert

Joined: Sun Sep 09, 2007 10:12 am
Posts: 116
Post 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.

_________________
http://www.apcsguarda.com
My Project: http://www.robotc.net/forums/viewtopic.php?f=15&t=712


Thu Nov 13, 2008 6:56 am
Profile
Novice

Joined: Sun Feb 04, 2007 12:48 am
Posts: 69
Location: Australia
Post 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.


Fri Nov 14, 2008 10:38 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3165
Location: Rotterdam, The Netherlands
Post 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

_________________
| 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 Nov 15, 2008 2:17 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 36 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron



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