Let's Make Robots!

Basic Triagulation Positioning System

3 Friends and I are building an autonomous tennis ball collecting robot for a 4th year design project for our undergrad.

We need a way for the robot to keep track of its position on the tennis court (in doors) and we are thinking of using 2 beacons to emit signals with a receiver on the robot. Has anybody done something like this before? Has anyone heard of pre-packaged solutions that do just this? A USB module would be ideal (we are using a netbook to control the robot), but we are not at all opposed to building the positioning system from scratch. 

We've read a bit about robot triangulation systems that rely on IR and Sonar, any idea what the better option would be?

Any help would be much appreciated.

Thanks very much!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

If it's in a static environment, why do you need triangulation? A few sonars, a map and encoded wheels would be easier. You will be using a hunt and gather routine for the tennis ball behavior, a seek and dump to get rid of the payload and then go home to end the loop.



As MechGeek mentioned you could probably just use wheel encoders and basic obstacle avoidance sensors for navigation. I assume there will be a 'home base' for emptying tennis balls and recharging batteries. If you set this base up with an IR beacon or similar the bot can navigate there based on the encoder readings, and then 'lock-on' at close range using the IR beacon for final docking procedures.
Encoders are very easy to use but will the accuracy will diminish over time. If the location of the home base is fixed however, you can use this as a reset/calibration point to ensure long-term accuracy of your system.

Triangulation is an attractive concept on paper, but you have to beware of your beacon signals being blocked or reflected by various objects in the environment. Also, unless you can detect the angle from the bot to each of the beacons accurately, two beacons will give you two possible locations on your 2D map that the bot could be sitting at. You'll need either quite an accurate beacon finder system, or at least three beacons to get a fixed location reading.

Like what was said above. If you make 90 degree turns and know the size of the room use encoders to keep track of where you are using a grid system. Since it will eventually get a little off use localization (when your sonar says you are near a wall you know you are at one end of the X or Y axis). You also have fixed known points such as where tennis balls come from or go.

Ok, I think you guys are right, triangulation would be over-doing it for this project..

I like the idea of encoders and sonar to detect wall (at ends of X and Y axis).

There is going to be a "Home Base" where the balls will be dumped. IR lock-on sounds like an excellent way to do this. Do you know of any posts on how IR beacons could be implemented?

Do you think exclusively performing 90 degree turns is the way to go here? I've never tried to keep track of position using encoders in such a large physical space as a tennis court. We are using a web cam + blob detection to go after the largest clusters of tennis balls. 90 degree turns might make this slightly more difficult (vs just rotating until we see the biggest yellow blob and driving straight for it), but I have a feeling this extra difficulty in ball hunting will be worth the increased ability to accurately keep track of position. What do you think?

Thanks again! 

If you make turns other than 90 degrees it is harder to keep track of you position on a x,y coordinate plane. 45 degree turns would be feasible but you have to keep track of them as a 90 degree turn folowed by exactly 12 inches of movement = 1 foot and 1 coordinate update to the graph for location. If you turn 45 degrees you have to travel the square root of 2 inches to move to a new coordinate where both x and y will change depending on the direction you turned.

If you throw in many different angles you have to use sin and cos to determine how far to travel to get to a new grid location and keep track of exaclt where in the grid you are since you won't be moving to a new 1 foot square but maybe in between 2 squares. If you really need to do random turns you need to shrink the size of the square to maybe 1 inch by inch. Keep in mind the array for the roommap will take up a LOT of memory. 144 entries per 1 foot square!

Limiting your movements to 90 degree turns surely simplifies the navigation code, a lot.

Reading about the task at hand and about the plan to use visual detection of targets, makes me think you don't really need any localization at all. There are basically two modes of operation:
1) search and collect balls: just chase the big blobs
2) go home and dump the loot: find base using one or two IR omnidirectional beacons

Admittedly, navigation is much more exciting and I would love to see someone build a decent triangulation solution using unidirectional beacons!

I just encountered this: http://letsmakerobots.com/node/12538#comment-35991 . It's called the Hagisonic Stargazer system.

It is adding a load complexity and burns a hole in your budget. But it would work.

one good example of triangulation is http://www.convict.lu/Jeunes/beacon.htm

but how will you find the balls, Camera ?

Yes, currently the plan is to use a web cam. Just a simple USB cam. We'll be plugging it into a tablet PC and probably using some open-source blob detection algoithms with Microsoft Robotics Studio.

This is just an idea that I haven't fully thought through. Since tennis courts are usually nice dark surfaces with bright white lines painted, you may also be able to encorporate some line following into your navigation routine. This can help keep your bot on the court and confirm where you are against your calculations. For example, you should have known positions where you cross foul lines.