IR Scanning Method Of Object Recognition

[davidthefat]

This would require 2 cameras, 2 IR diodes, 1 servo and 2 prisms. Essentially, the IR beam would be broken up into a horizontal line using the prism. The IR light band will spread across the bottom of the robot and the camera will pick up the image, it would show the IR light. The image can be process to get the distance of the object. Since the distance from the IR diode and the camera is known, and the angle of the camera would be known. then you can use trigonometry to find the hypotenuse (since its a right triangle) and the distance of the object. So the angle of the object's vicinity is known, then the other IR diode mounted on a servo will create a vertical beam then another camera can pick that up then the info can be processed into a 3d image. Know this is a theory on my part, but I am sure it would work, since that is how laser scanning works. But the 2nd IR setup is to just get the angle of the object compared to the robot, so it does not need to scan everything else.

Now I think this is the way I can achieve full automation: http://www.chiefdelphi.com/forums/sh...ad.php?t=84797

Approximately how effective do you guys think this is? I wish I had a diagram for this...

Once you convert the data into an image, you can get the edges for shape detection

[davidthefat]

http://www.youtube.com/watch?v=SPywg...eature=related
http://www.seattlerobotics.org/encod...110/vision.htm
http://www.societyofrobots.com/senso...pirrange.shtml
Those 3 ideas combined

[Radical Pi]

Let's see if I have this right (see attached image as well). We know one leg, the relative height of the camera. The IR system sends out the beam across everything in LoS. The camera picks up on this, and determines the angle of the object from the camera (simple y-coordinate conversion). Do a bit of trig, and we end up with the length of the IR beam; the distance to the object from the robot.

Assuming that's your idea, we can expand on this a bit more. We not only have the Y-coordinates of the object in the camera, but also the X. With the X, we can calculate the angle of the object from the camera, giving us 2D vectors of the object.

Honestly, I think the entire 3D idea is a bit over the top. There are only a few things to expect on the field at any point in the game: balls, robots, and static field elements. With such a small sample of things to expect, it shouldn't be that hard to differentiate between those things (static elements will span large areas, balls will be relatively small (IR reflection length), and robots can easily be detected by the camera because of the GDC's convenient bumper requirements. A 2D field is plenty for the AI to work with, and in some ways easier too. It's not like we're ever going to be able to track balls in the air in real-time.

I see a few problems though. Because of the camera's limited FoV combined with physical obstructions such as the bumpers, there are going to be areas that the camera cannot see objects in front of it, breaking this entire system. However, one could argue that those areas are right up next to the robot, and possibly could even be detected by the lack of any IR beam in the areas it covers. Being so close to the robot, the plotting becomes less useful compared to just knowing it is there.

Also, as the object gets farther away, the change in angle for a given unit curves to eventually near-zero, and the accuracy of the reading will follow the trend too. Since the cameras are obviously not perfect in their detection, longer-distance objects will most likely start to return erratic values, diminishing the system's usefulness.

[davidthefat]

Originally Posted by Radical Pi

Let's see if I have this right (see attached image as well). We know one leg, the relative height of the camera. The IR system sends out the beam across everything in LoS. The camera picks up on this, and determines the angle of the object from the camera (simple y-coordinate conversion). Do a bit of trig, and we end up with the length of the IR beam; the distance to the object from the robot.

Assuming that's your idea, we can expand on this a bit more. We not only have the Y-coordinates of the object in the camera, but also the X. With the X, we can calculate the angle of the object from the camera, giving us 2D vectors of the object.

Honestly, I think the entire 3D idea is a bit over the top. There are only a few things to expect on the field at any point in the game: balls, robots, and static field elements. With such a small sample of things to expect, it shouldn't be that hard to differentiate between those things (static elements will span large areas, balls will be relatively small (IR reflection length), and robots can easily be detected by the camera because of the GDC's convenient bumper requirements. A 2D field is plenty for the AI to work with, and in some ways easier too. It's not like we're ever going to be able to track balls in the air in real-time.

I see a few problems though. Because of the camera's limited FoV combined with physical obstructions such as the bumpers, there are going to be areas that the camera cannot see objects in front of it, breaking this entire system. However, one could argue that those areas are right up next to the robot, and possibly could even be detected by the lack of any IR beam in the areas it covers. Being so close to the robot, the plotting becomes less useful compared to just knowing it is there.

Also, as the object gets farther away, the change in angle for a given unit curves to eventually near-zero, and the accuracy of the reading will follow the trend too. Since the cameras are obviously not perfect in their detection, longer-distance objects will most likely start to return erratic values, diminishing the system's usefulness.

That picture is exactly what I am saying, but you are correct, its only effective to a certain range, but do you think that its really a disadvantage? ID based on the game next year, we can theorize where to go by making a map of the field and tracking the location of the robot and making decisions based on that info. Like in starcraft, there is the Macro and Micro part, micro is the scrimmages that happens, that can be applied to this robot

[kamocat]

Fun!
I like that method of getting around the "laser" regulation.
It's not as dangerous as a laser, but it's just as useful for short-range operations.

I work for a company (linked in my sig) that does Stereo Cameras. Stereo cameras allow machines to do exactly what you're hoping to do with this custom laser jig, but all in one nice and tight package. Here's a simple breakdown on how it works:
1. You know the distance between your camera's two lenses.
2. You can "measure" the distance between two features in an image.
3. Since you know the distance between lenses, the the distance in pixels between two features, through calibration you should be able to identify and quantify the distance between features. One "difference" is called a Disparity.
4. Using a nifty, already developed piece of software called SVS (credit to this goes to SRI's vision lab, more specifically Kurt Konolige, my boss), you can lay out an image that plots all Disparities in color to represent the depth and distance. A good example can be found here http://www.videredesign.com/index.php?id=65 if you're curious.

Vision is awesome, and can do just as much (if not more!) than some laser systems.

If you're hooked on lasers, go check out Hokuyo Automation's products. We use some of their laser rangefinders for our SLAM bots. They're a little pricy for FIRST, but man oh man are they cool.

[davidthefat]

Originally Posted by CraigHickman

I work for a company (linked in my sig) that does Stereo Cameras. Stereo cameras allow machines to do exactly what you're hoping to do with this custom laser jig, but all in one nice and tight package. Here's a simple breakdown on how it works:
1. You know the distance between your camera's two lenses.
2. You can "measure" the distance between two features in an image.
3. Since you know the distance between lenses, the the distance in pixels between two features, through calibration you should be able to identify and quantify the distance between features. One "difference" is called a Disparity.
4. Using a nifty, already developed piece of software called SVS (credit to this goes to SRI's vision lab, more specifically Kurt Konolige, my boss), you can lay out an image that plots all Disparities in color to represent the depth and distance. A good example can be found here http://www.videredesign.com/index.php?id=65 if you're curious.

Vision is awesome, and can do just as much (if not more!) than some laser systems.

If you're hooked on lasers, go check out Hokuyo Automation's products. We use some of their laser rangefinders for our SLAM bots. They're a little pricy for FIRST, but man oh man are they cool.

I would LOVE to use lasers, unfortunately, its too expensive and its against FIRST rules, so I am trying this ghetto cheaper alternate using IRs

Originally Posted by davidthefat

I would LOVE to use lasers, unfortunately, its too expensive and its against FIRST rules, so I am trying this ghetto cheaper alternate using IRs

A few Sonar sensors on a gimbal ought to return enough range data to define the outlines of other robots... Pretty sure there's articles on the tubes about how it can be done.

Keep thinking outside the box!

[davidthefat]

Originally Posted by CraigHickman

A few Sonar sensors on a gimbal ought to return enough range data to define the outlines of other robots... Pretty sure there's articles on the tubes about how it can be done.

Keep thinking outside the box!

I was thinking of using sonar on the other sides of the robot and use it for general collision avoider type of thing, not sure how well thats going to work after the other team finds out that the robot moves away if they get too close... May be I can put an "aggressive" mode that chases every robot and rams into it for fun...

[davidthefat]

30 Milliwatt Continous Infra-Red Laser Module from http://www.amazing1.com/infrared-lasers.htm seems perfect for the job

[taichichuan]

The way we did this was to use one of the Sharp long-range IR scanners to find an object within range of the sensor. Basically, start at the far left angle of your servo (IR sensor is mounted on the servo) and jump every 5 degrees looking for something whose range indicates that it's close (uses an Analog channel for the voltages coming back from sensor and a formula to convert to distance). If you find something in range, start backing up until the distance falls off by a ball radius (this is the leading edge of the object). Then jump forward and do the same thing to find the training edge of the object.

Knowing the leading and trailing edges of the object as well as the closest distance (the closest face of the ball), you can use trig to calculate size of the object. If it's within the approximate size of a ball, then write the angle and distance to a message queue to be read by the robot control code to go kick it.

The whole detection is pretty fast (1.5-2 seconds) and could be made faster with multiple IR sensors scanning smaller sweeps. And, it is pretty good at being able to tell the difference between balls, robots and miscellaneous junk on the field. The code can be found here for your perusal...

http://www.chiefdelphi.com/forums/sh...ad.php?t=85509

Mike

[purduephotog]

One thing to think of is a Friend or Foe discriminator. An IR diode (s) emitting a certain frequency or IR reflective tape could be applied to alliance members.

Any camera with IR sensitivity (literally, anything) can discriminate that. If it can't, yank off the IR cutoff filter and slap in a piece of opticast IR plastic. In fact there are some IR goggles out at Target that are 50$ or so and excellent for IR. Identify the frequency and you know if the thing you're looking at is a Friend or Foe.

Of course, this also brings up ECM type opportunities- an IR emitter with sonar to 'jam' recognition. But I digress....