# triangulation

Hey, we were messing with the robot’s autonomous sequence and using the IR Sensors on top of servos. When we went to program in the triangulation, we realized we couldnt see how to do it. We know the distance between the sensors, and each servos angle relative to the front of the robot. Also the field isnt going to move, so we know that there 24’ between the IR sensors. From this we should be able to determine distance relative to the IR beacons (x and y) and relative angle to the line between the 2 beacons. If anyone could explain this out to us we would really appreciate it. Thanks

Well, the simplest way to only use one beacon. You will then have a triangle with 2 known angles (the servos) and one known distance (distance bettween servos). Try figuring out the math that way. If you still need help i’ll try and draw some things up to help you.

basically, given the sensors you have, you can do one of the following:

1. home both trackers on one beacon, then triangulate to know the distance and angle to the sensor from the bot. Note - you do not actually know the position of the bot, only the relative position of the beacon.

2. home one tracker on each beacon, then try to get one beacon behind you while the other is in front. again, you do not know the exact location of the bot itself, only a relative position.

You cannot triangulate absolute position this way. You only know one angle and one side of the big triangle (you dont know the distance from either of the beacons to you!). You will have to devise a way to compute the distance from you to the beacon (create another triangle that you CAN

triangulate) before you could determine absolute position.

for instance, if you had 3 servos, each with a mounted sensor-pair (two homing on one beacon, one on the other), you would have enough information to compute the trapezoid and thus compute your position on the field.

You can’t do absolute position because there’s no indicator for Red/Blue side, you’d have to put a “compass” in the bot. Not that that’s difficult.

Given that A and B are the lengths of the segments of the line between the beacons bisected by a perpendicular line to your robot of length C and the angles from that perpendicular to the beacons are given as T1 and T2.

A + B = 24

T1 and T2 are angles gleaned from finding the beacons.

TAN(T1) = A/C

TAN(T2) =B/C

Therefore:

C*TAN(T1) = A

C*TAN(T2) = B

CTAN(T1) + CTAN(T2) = 24

C*( TAN(T1) + TAN(T2)) = 24

C = 24/( TAN(T1) + TAN(T2)) - The distance away from the middle of the field!

A = C*TAN(T1) - The distance from the left side of the field

B = C*TAN(T2) - The distance to the right side of the field.

Be careful this gets a little flakey as you approach the middle of the field.

The compass is required to determine the perpendicular and to determine which side of the field you are on.

I’m a little rusty on my Trig. So correct me if I’ve made a mistake!

One problem you WILL run into is the fact that when you’re in the center of the field, the angle of the servos relative to the beacons will be 90 degrees (and the triangulation will fail, as you can’t divide by zero :yikes:

You’re trig is fine.

I’ve also been playing around with using the IR beacons to keep track of absolute position, and I’ve come up against a few … obstacles. So maybe you can help me.

It’s just that it’s not so easy to keep track of those two angles, T1 and T2.

At the beginning of a match, you know both your position and heading (because you know where you’ve put your bot). Hence you can quickly calculate T1 and T2, as well as A, B, and C.

(You may recall from your old trig class that this is the angle-side-angle triangle congruency theorem.)

If you go straight ahead, then you can still keep reading off T1 and T2 because the altitude constructed from your bot to the midline of the field is still in the same place.

In fact, as long as the bot is perpendicular to that midline, you can figure out exactly where you are.

If you turn somewhere along the line, you can still find T1 and T2 aslongas you know the angle from that altitude to a line parallel to your robot. This angle is your heading. You have a number of ways to keep track of heading – you can use a gyro to sense your angular velocity, you can mount encoders on your wheels to count revolutions, and so forth.

However, your absolute position (i.e., the values of A, B, and C) will only be as accurate as your heading; in fact it will be slightly less accurate because of the (presumably small) amount of error introduced by the IR sensors.

The upshot of all this is that if you want to know you’re absolute position, it’s probably a little easier and little simpler to just use gyros and/or rotary encoders, which in the above setup would be necessary anyway. My conclusion: that if your autonomous objective is to shoot towards the 10 point ball, use the IR trackers. You don’t even need any trig to do that; it’s easy to find your distance relative to one beacon or the other. But at this time (which is pretty late) I haven’t come up with any way to use the IR trackers to gauge absolute position.

I’m not saying it can’t be done; I just haven’t found a way. For now, I’m stuck with plain, old, dead reckoning. If any other team has a solution, I would be eager to hear it.

Correct me if I’m wrong, but each beacon sends out a unique time signature. From this you can point each servo at each beacon. Knowing the two angles that the servos form will give you enough information to complete the trapezoid. You have two lengths and two angles. It’s too late right now to go into details and it wouldn’t give you much of a competetive edge to know where your robot is on the field with absolute position. If so desired I could elaborate more.

the problem is that the two lengths you know are not necessarily parallel, which is required for a trapezoid. hence the reason one would need a compass.

Remember, there is no math library included, so you will have to make your own.

has anyone sucsesfuly tried using the standerd CPP math library by inporting it into mplab?

I doubt it, a standard library would be rather large. I made my own, its a little slow but it gets the job done.

Trig seems a little bit on the touchy side. You have the problem of the tracking, the angle, and the precision. Being off by a degree could send you very much where you don’t want to go. My team discussed this early on, and discarded it. An INS and a gyro chip will be much easier, although a bit pricy, and it’s a bit late in the season. Have fun with that. I don’t envy your programmer.

Shaft encoders are much simplier and probably just as acurate. Oh, and fast.

yeah like i (think i) said above, we used the banner sensors as shaft encoders and there smooth and awsome. now i just have to figure out how to hook them up to the inturpts… … … oh boy

We used the banner sensors in this manner last year and it was awesome. Good luck.