FTC 2012 RobotC IR Sensor Programming and implementation

[JohnFogarty]

So as you all very well know we have another IR beacon challenge on our hands. I know there have been teams who have had varying success with the sensor before like team 2818 GForce though a far as I'm aware they use LabVIEW. Have there been any teams using RobotC that have successfully used the IR sensor to guide their robot towards a target.
I have looked over the included driver and test/example files with RobotC and I can't make heads or tails of it really.
I've been told that there is a 30 degree area of detection where the sensor reads a certain value. Which makes me think that it can't be that accurate on its own. Can some teams give some code examples of how your team used the sensor in the past years as well as how you placed it on your robot or if you used 2 sensors in combination.

[maths222]

I use this code: https://hprobotics.googlecode.com/sv...IRController.h to get a more accurate reading from the sensor. Additionally, I use two controllers with the following code:


dir=IRGetACDir(IRSLeft)-(10-IRGetACDir(IRSRight));
if (dir<0)
{
leftSpeed(-50);
rightSpeed(50);
}
if (dir>0)
{
leftSpeed(50);
rightSpeed(-50);
}
if (dir==0)
{
leftSpeed(50);
rightSpeed(50);
}

[l0jec]

Of course. The IR Seeker is actually extremely easy to use; a lot of ROBOTC teams who use it successfully, utilize Xander's 3rd Party Drivers (hitechnic-irseeker-v2.h to be specific).

As for placement, a lot of teams will place it at an angle to get the sweet spot between detectors such as zones 4 or 6. This has nothing to do with LabView or ROBOTC, but rather with the internals of the sensor.

See this student presentation for more details: http://stlfirst.org/LinkClick.aspx?fileticket=jNken9UOcfA%3d&tabid=263 &mid=876

[PhilBot]

To get the most out of the IR seeker, you need to use both types of data that the sensor provides.

These are:
1) The Beam Number
2) The signal strengths of the actual IR receivers (there are 5 of them)

9 detection zones are formed from the 5 IR sensors in the device.
These are either 60 deg wide or 5 deg wide.
For accurate tracking you need to use the 5 Deg ones. (Beams 2,4,6,8)
Once you turn your robot so you are in one of the narrow beams, you can look at the signal strengths of the two adjacent IR receivers. If the left receiver is stronger, the target is to the left of center, and if the right is stronger, the target is right of center.

Using this information you can drive towards the target and be within a degree or so. Plenty close enought to score a ring.

[smcmahon]

Phil,

We're using LabVIEW, and for us, the IR Seeker outputs two sets of data:

[1] is the Direction, which is an integer value, 0-9 (we think)
[2] is a Signal Strength array, with the five values

We discovered this later last night, so we won't be able to do any testing until tomorrow. So, if you know, what sort of data kicks out of that array? Is it just positive numbers, such as 0-10, or 1-100? How does it show it has ZERO signal strength?

I think we can do math on those values, as you suggested, but I'm just unsure what exact data is used to represent those signal strengths.

[PhilBot]

The signal strengths are positive numbers .. maybe in the 0-100 range.

You don't need to do any math per-se...

The only time you are interested in the 5 discrete sensor values is when you are ON a narrow beam (2,4,6,8).

Then all you do is look at the relative strength of the two adjacent IR sensors... this just tells you which side of center, the beacon is.


Here's what I did the first year we used the IR seeker...
Made a compass out of paper (with degree markings)
Mounted the compass and IR Seeker on a camera tripod so I could spin it.
Mounted an IR beacon on a wall in front of the tripod.
Wrote an NXT program to read the seeker and display the Beam number and 5 signal strenghts.

Sat on the floor and slowly rotated the tripod head and watched the numbers changing.

You can learn a LOT this way. We discovered the whole 5 Deg, 60 deg thing way before they published the white paper. We could auto aim and shoot wiffle balls into the spinning goal from the corner of the field.

I personally think Hitechnic missed the boat on this one, and should do a Seeker V3 that has 4 IR receivers centered on "forward" so the 5 Deg beam is centered, rather that 30 Deg off to one side.

[RRLedford]

This I/R detector makes no sense to me.

Issue #1 -What are the 9 "zones" and how does the 5-detector array define them. If the sensor "sees" 240 degrees, across five dector array zones, then is each detector handling 48 degrees of the the total 240 degree span, or do the individual detectors have wider overlapping views (maybe 60 degrees with 12 degree overlap?

Issue #2 - What causes the nine zones to have different "beam" arc widths (5 & 60 degree)? In fact why is the term "beam" even applied to the sensor, since the actual I/R energy beam is being sent from the beacon & no "beaming" should happen at the sensor? Is there some kind of prismatic beam focusing effect happening in the lens that slices up the incoming I/R energy such that it concentrates narrower slices (5 degrees worth of the 240 degree field) on the the radial midpoint axis between detectors, and it slices 60 degree slices of the 240 degrees of incoming I/R energy onto the radial central axis of each of the five detectors?

Issue #3 - If the sensor's central axis for zone 4 field view (located halfway between detectors 2&3 - with a 0-1-2-3-4 detector numbering scheme) is pointed straight ahead, and sensor is positioned at center of the bot, then when the data readout list indicates that the five detector array readings are coming from the zone 4 sector of the incoming I/R energy field (5 degree segment), then, when the bot is lined up centered in front of the beacon, shouldn't the detector array list of the five zone 4 direction array data values be showing that the highest number will be for the middle detector and the # values for the two adjacent I/R array detectors should be BOTH be somewhat less than the middle detector value, AND also nearly equal to each other?

Issue #4 - As the robot moves, what causes the I/R sensor to cycle through the zone numbers as it updates the data list with new values? Is it just that the sensor somehow determines that the peak energy is coming from that direction? How does the sensor ignore the incoming I/R energy from the other zones, and how does it decide which four to ignore?

I really don't understand how the sensor slices up the incoming 240 degree field of I/R energy into the 5 & 60 degree segments, and how the array knows what energy is hitting it from which slice of the 240 degree field?

Does the lens block incoming I/R energy from hitting the detector with some sort of staggered, variable angular width blinders that cast shadows on the detector, only allowing a certain sized (5 or 60 degrees) angular slice of the I/R energy reach the detector according to the directional line from the beacon to the sensor and the sensor pointing direction?

-Dick Ledford

[PhilBot]

Hey Dick.

Check out this doc from a few years back...

http://www.usfirst.org/sites/default...icsR2-rev2.pdf

The IR seeker is made using 5 discrete sense elements. Each element has an approximate 60 Degree sensitivity area. These also overlap each other by about 5 degrees to form a dusl sense area (beam). This overlap is usefull because it provide a narrow sense area, but there is not one that is centered on the "forward" direction of the seeker.

If you want to understand it beter, chek out some related IR seeker links here:

http://www.usfirst.org/roboticsprogr...ionalresources

[smcmahon]

We were able to find some sample code that shows the 5 signal strengths on the NXT brick. The values seem to go from 0-255. Strangely enough, they show some readings we didn't expect, like having a sort of 'dead zone' in what would be Direction 3.

Again, as a LabVIEW team, we're thoroughly confounded with using this thing for navigation. We're gonna keep plugging away though, and if we get some stuff that works reliably, we'll post the code here.