View unanswered posts | View active topics It is currently Tue Jul 29, 2014 12:41 am






Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
IR Seeker inaccuracy 
Author Message
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post IR Seeker inaccuracy
Have anyone try using the IR seeker? We have code that will track the IR beacon and approach it from across the competition field using PID control. It sort of work but it never go straight to it. Instead, it always go the the left side. When it gets closer, it will turn towards the beacon. But this will make the robot ended up approaching the beacon with an angle. This is what I suspect:

We asked the robot to keep the IR seeker DIR value (PID target) at 5 (which is the dead ahead value) but since zone 5 is a zone radiating outward from the seeker sensor. The farther it is, the bigger the zone. I think the robot is heading to the rightedge of zone 5. Since it was still zone 5, it kept on going until it gets closer where it crosses to zone 6 and it turns to face the beacon again. So essentially, it is traveling along the right edge of zone 5 reaching the beacon at an angle.

If this is really what's going on, then we can't use the IR seeker until it is really close. I should figure out how to use Datalog to log the data of the path to confirm this scenario. In the meantime, I would like to see how people use the IR seeker and if they also come to the same conclusion.

Thanks.


Wed Nov 24, 2010 2:31 pm
Profile
Rookie
User avatar

Joined: Mon Feb 23, 2009 12:40 pm
Posts: 27
Post Re: IR Seeker inaccuracy
Hi,

See this page on the USFIRST site for recommendations on how best to use the IR Seeker.

http://usfirst.org/uploadedFiles/Commun ... 2-rev3.pdf

If for some reason this link doesn't work, it is off the team resources / technical resources page.


Wed Nov 24, 2010 3:46 pm
Profile
Expert

Joined: Mon Oct 27, 2008 9:59 pm
Posts: 137
Post Re: IR Seeker inaccuracy
My teams have not yet attempted to use the IR Seeker with the beacon, however I have played with the IR Seeker and the IR ball from Hi-Technic during the off-season.
Your understanding of this particular challenge of the seeker is pretty accurate.

There are two basic ways I can think of off the top of my head for increasing the accuracy of the feedback you're using from the seeker:

1) Use two seekers as mentioned in the guide linked by SSI. This is really effective and I've even used it to give a robot a sense of distance via triangulation with the zones and intensities.

2) Combine the strongest zone with individual zone strengths. If you're using Xander's 3rd Party drivers, you should see a function called "HTIRS2readACDir" which tells you the strongest zone. I assume from your description that this is the method you are relying on... turning left/right to make sure this function returns 5. However, you can also check the strength of individual zones via a functions called "HTIRS2readACStrength" (read a particular zone) and "HTIRS2readAllACStrength" (read all zones at once).
The idea is that you could check the strength of zones 4(or 3) and 6(or 7) to see how close you are to the center of zone 5 and use this info to better dead-center the orientation of the robot to the beacon.


Wed Nov 24, 2010 4:44 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: IR Seeker inaccuracy
Thanks for the info. That's exactly what I was looking for. I think I will try to turn the IR seeker slightly side way to make use of the narrower zone 4 and see how well that works. If that still doesn't improve it satisfactorily, I may try two IR seekers. But that will use up two sensor ports. I am already using a sensor MUX but since I am also experimenting with line following with 3 light sensors, ports are going really fast. And we are using some other sensors too (accelerometer and sonar). That's one more port than I have. I will need to sacrifice something if that's the case.


Thu Nov 25, 2010 12:09 am
Profile
Expert

Joined: Mon Oct 27, 2008 9:59 pm
Posts: 137
Post Re: IR Seeker inaccuracy
My experience is that the narrow zones are harder to make use of & turning the sensor so that it is not zeroed with the front of your robot can make programing for it rather difficult when you end up approaching a target from other angles.
With the sensor in the default orientation, if you read Z4:0, Z5:99, Z6:42, then you would know that you're inside zone 5, but with the beacon on the right side of the zone so you would turn the robot slightly to the right. The trick is to make sure zone 5 is the strongest and get both zones 4 and 6 (or 3 and 7) to be within a set tolerance of one another. With the way the sensor zones are layed out, you will not often have a reading in just one zone (unless it is in the "corner of the eye" of zones 1 or 9).

I also found it extremely helpful to print the zone strengths to the NXT screen while debugging; you can find an example of how to do this in HTIRS2-test1.c.
Also note that I personally had trouble running two IR seekers of the same SMUX. For whatever reason, I ended up running one on the SMUX and the other directly off a sensor port...


Thu Nov 25, 2010 11:27 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3164
Location: Rotterdam, The Netherlands
Post Re: IR Seeker inaccuracy
Can you explain what kind of trouble it was you were having with the SMUX and two IR Seekers? If it's a bug, I'm keen to have it fixed, of course.

If you have some code that can reproduce the issue, I'm all ears. You have my email address, it's at the top of the driver files :)

- 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 25, 2010 12:12 pm
Profile WWW
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: IR Seeker inaccuracy
IOJec,
Thank you for the suggestion but there are only 5 IR sensors in the seeker. I believe the internal seeker firmware is already interpolating the 5 IR sensors into 9 zones. So if I read the strength of each sensor, the strength is for each sensor and not for the zone. I believe by reading adjacent sensor strength to determine whether I am in the middle of a zone or towards the edge is exactly what the seeker firmware is doing to create zone 2, 4, 6, 8. Unless I believe there is a bug in the firmware, there is no reason to not trust the ACDir value computed by the firmware. That's why I believe the narrower zone 4 may help.

Having said that, I did find something to improve my algorithm. I found that the ACDir will occassionally give me a value 0. According to the documentation, this is because the seeker did not find enough IR strength to believe the beacon was present. This has a bad effect on my PID algorithm because when I got a zero, PID will compute a large error and will turn left hard. Even when the next ACDir value is non-zero and possibly 5, I am still maintaining the left heading since I am still within zone 5 until I hit zone 6 then I will correct myself by turning right. But by now I will be off-axis and approaching the beacon at an angle. I changed my algorithm such that I will always remember the previous non-zero ACDir value. If I ever read a zero ACDir, I will use the prev AC value instead, so essentially ignoring the zero value altogether. After this change, the PID control will maintain course if I point the robot straight ahead at the IR beacon to start with. But the large angle of zone 5 will come back to play when I get closer to the beacon. If the robot was really perfectly aligned with the beacon, it will be perfect. But if not, it will eventually trigger zone 4 or 6 and cause the robot to turn and again approach it at a wrong angle. Therefore, the culprit is still the large angle of zone 5. So if zone 4 is really a narrower angle, this should improve things in theory. I will try that out after Thanksgiving.


Thu Nov 25, 2010 3:12 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: IR Seeker inaccuracy
I turned the seeker completely sideway and used zone 2 as the straight ahead zone. It does work much better. I think this is good enough for us.

Thanks.


Sat Nov 27, 2010 3:23 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: IR Seeker inaccuracy
I am very happy with my new algorithm. Not only it is using the more accurate narrower zone, it also interpolates in between the narrow zone to give an even more accurate heading by comparing the relative strengths of the adjacent sensors. So if it is slightly off from the center point of zone 4, it will give me 3.8, 3.9 or 4.1, 4.2 etc.


Sat Nov 27, 2010 5:22 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3164
Location: Rotterdam, The Netherlands
Post Re: IR Seeker inaccuracy
MHTS,

Care to share?

- 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 27, 2010 5:44 pm
Profile WWW
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: IR Seeker inaccuracy
Sure, here is the code. I am still trying to improve the way I calculate the "proportion" in between. But for now, it is good enough. If you can suggest a better way. Let me know.

Thanks.
Code:
float IRGetACDir(tSensors link)
{
    static float prevDir = 0.0;
    float currDir;
    int acS[5];
    int idx;

    idx = HTIRS2readACDir(link);
    currDir = (float)idx;
    if (idx == 0)
    {
        currDir = prevDir;
    }
    else if (HTIRS2readAllACStrength(link, acS[0], acS[1], acS[2], acS[3], acS[4]))
    {
        idx = (idx - 1)/2;
        if ((idx < 4) && (acS[idx] != 0) && (acS[idx + 1] != 0))
        {
            currDir += (float)(acS[idx + 1] - acS[idx])/
                          max(acS[idx], acS[idx + 1]);
        }
        nxtDisplayTextLine(0, "Idx=%d,Dir=%5.1f", idx, currDir);
        nxtDisplayTextLine(2, "S1=%d,S2=%d", acS[0], acS[1]);
        nxtDisplayTextLine(3, "S3=%d,S4=%d", acS[2], acS[3]);
        nxtDisplayTextLine(4, "S5=%d", acS[4]);
    }
    prevDir = currDir;

    return currDir;
}


Sat Nov 27, 2010 5:50 pm
Profile
Expert

Joined: Mon Oct 27, 2008 9:59 pm
Posts: 137
Post Re: IR Seeker inaccuracy
MHTS wrote:
IOJec,
Thank you for the suggestion but there are only 5 IR sensors in the seeker. I believe the internal seeker firmware is already interpolating the 5 IR sensors into 9 zones. So if I read the strength of each sensor, the strength is for each sensor and not for the zone. I believe by reading adjacent sensor strength to determine whether I am in the middle of a zone or towards the edge is exactly what the seeker firmware is doing to create zone 2, 4, 6, 8. Unless I believe there is a bug in the firmware, there is no reason to not trust the ACDir value computed by the firmware. That's why I believe the narrower zone 4 may help.


Looks like I confused the zones and the sensors in my previous post. Sorry about that; must have had wires crossed in my head.
I meant to recommend comparring the neighboring sensor strengths, not zones. Just comparing the strengths of sensors 2 and 4 when you're in zone 5 is all I needed to make fine-grain adjustments within the large zone 5.
Thinking through this, it may have worked much better for me as I was using an IR ball (multiple IR leds) rather than a beacon (single IR led). I did some testing with rolling the ball across the front of the robot and recording the individual sensor strengths similar to the spreadsheet from FIRST:http://usfirst.org/uploadedFiles/Robotics_Programs/FTC/FTC_Communications_Resource_Center/2009_Archive_Assets/zones.zip. What I observed was a much larger overlap for the sensor ranges, effectively showing that zones 4 and 6 are much larger than what you see here: http://usfirst.org/uploadedFiles/Community/FTC/Team_Resources/IRSeekerV2characteristicsR2-rev3.pdf. Reflecting back, this may have been a result of the many leds on the IR ball which hit sensors 2 and 4 in addition to sensor 5 better than a single led such as the beacon.

If the strength dropoff for the sensors is as sharp and the overlap as narrow as I believe it to be with a single IR led, then your approach of using the narrow overlap as the relative "zero" mark makes a lot of sense. The only other good alternative is using multiple IR Seekers as their placement gives you a customer intersection of sensor strengths.


Tue Nov 30, 2010 11:00 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: IR Seeker inaccuracy
I don't know about the IR ball, but with the IR beacon, the seeker is giving values very similar to the spreadsheet FIRST published. Zone 4 is very narrow. In fact, if you look at the numbers in the spreadsheet, you can see that if you are in zone 5, only sensor 3 has readings. The other sensors have zeros. So you can't use the adjacent sensors to tell whether you are slightly to the left or right of zone 5. From looking at the spreadsheet, I'd bet the seeker's internal firmware is returning zone 4 only if both sensor 2 and sensor 3 are non-zero. Therefore, I can compare the relative strengths of sensor 2 and 3 and be able to tell whether I am closer to sensor 2 or sensor 3. This gives me finer position in zone 4 but not zone 5. Therefore I have decided to utilize the narrower zone 4 with the algorithm I have in my previous post to give me more accurate reading.

In reality, I am actually using zone 2, not zone 4 because it is a lot of trouble to mount the seeker 30-degree off axis. It is a lot easier to mount it 90-degree sideway to the right. I have tested the algorithm and it works exceptionally well.


Tue Nov 30, 2010 3:10 pm
Profile
Rookie

Joined: Wed Feb 24, 2010 11:43 pm
Posts: 34
Post Re: IR Seeker inaccuracy
I would also point out that the edge between two zones is incredibly repeatable.

The team I'm coaching (FTC2848, the Techno Guards) used that edge and a mechanical alignment mount they built to follow the goal last year (Hot Shot) using that alignment. They found that from 5 feet away (the corner of the FTC field) the edge was repeatable to within 1/2 inch.


Tue Jan 11, 2011 7:46 pm
Profile
Rookie

Joined: Fri Oct 21, 2011 11:14 pm
Posts: 9
Post Re: IR Seeker inaccuracy
For the part of your code that says this :
Code:
    else if (HTIRS2readAllACStrength(link, acS[0], acS[1], acS[2], acS[3], acS[4]))
    {
        idx = (idx - 1)/2;
        if ((idx < 4) && (acS[idx] != 0) && (acS[idx + 1] != 0))
        {
            currDir += (float)(acS[idx + 1] - acS[idx])/
                          max(acS[idx], acS[idx + 1]);       }
        nxtDisplayTextLine(0, "Idx=%d,Dir=%5.1f", idx, currDir);
        nxtDisplayTextLine(2, "S1=%d,S2=%d", acS[0], acS[1]);
        nxtDisplayTextLine(3, "S3=%d,S4=%d", acS[2], acS[3]);
        nxtDisplayTextLine(4, "S5=%d", acS[4]);
    }
    prevDir = currDir;

    return currDir;
}


the max(acS[idx], acS[idx + 1]); returns an "undefined procedure" error. What is that meant to do? Also, what is the purpose of this
Code:
idx = (idx - 1)/2;
        if ((idx < 4) && (acS[idx] != 0) && (acS[idx + 1] != 0))
        {
            currDir += (float)(acS[idx + 1] - acS[idx])/
                          max(acS[idx], acS[idx + 1]);

what is the meaning of subtracting 1 and dividing by 2, etc.

Thanks!


Sat Nov 26, 2011 4:18 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 16 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 2 guests


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:  



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