|
|
|
 The closest thing to "Senior Mentor" we have is "Team Grandma". :) - Alan Anderson [more] |
 |
|
|||||||
|
||||||||
Able to identify target and range to it, even with obstacles / distractions in the way.
(I knew those bright blue coats would come in handy)
Discussion
view entire thread
19-01-2014 00:07
otherguy
Re: pic: Found It!
Would you describe the algorithm you are using to detect the ball?
19-01-2014 00:23
jmartin
Re: pic: Found It!
I too would be interested in what algorithm is being used. More specifically, since you seem to be using a Kinnect, are you using the point cloud data to help identify the ball?
I know I'm really excited to use ball tracking to try to do some automated catching. I had though about using a Kinnect, but I don't think the raspberry pi we're using for onboard vision processing would be able to process fast enough using the Kinnect. What cool things are you going to do with your ball tracking?
19-01-2014 10:08
mwtidd
Re: pic: Found It!
Where you could probably get the kinect working with some linux distribution, I'm not sure if some the of the features of the kinect sdk are readily available from the open kinect projects and such. Specifically the ability to map color pixels to depth pixels.
I simply used the straight microsoft c# sdk, and used the KinectExplorer example as a basis.
My theoretical setup would include a nuc, an arduino and a kinect. My thinking was that I would use the arduino to relay the target's x, y, and depth back to the crio. Avoiding any of the issues that may occur passing this data through the network.
The algorithm should be able to be reproduced, and is not perfect. The first thing I put it through is a blob area and color threshold.
The color threshold is a max red, max green, min blue, and max average color.
For area, essentially I find a pixel that meets the color threshold, and then recursively fan out from there, finding any neighboring pixels, and checking them too. Each returns 1 or 0 to indicate whether the pixel is hot or not. As its recursive I can get the area of the connected blob.
I then calculate the distance to the center of mass of that blob.
The center of mass is often not the actual center of the ball, so I then you the depth sensor to find neighboring pixels, to find the closes pixel to the camera. My minDepth function also only accepts values that are > 90% of the current minDepth. Which helps to avoid any foreground items.
I then maintain a 5 frame running average of x and y, and use that for the position. Downside to this right now is that if I get a false positive it could take several frames for the target to reacquire.
It's far from perfect, but I do like the idea of being able to find the center of the ball based on depth as opposed to color. I am considering trying to get a kinect v2 developer kit, to see if I can get something put together for next season. Kind of like the startings of a wpilib type thing for the kinect.
The biggest issue is weight and power. I would personally prefer powering the nuc and arduino off a 19v battery than the power supply. Something like this: http://www.xpalpower.com/energizer/xp18000a.php. I guess I could resell it and make it a cots item:
http://www.newegg.com/Product/Produc...82E16856102001
But i'm not sure that nuc sale price will stick around for long. I also would prefer having the nuc with the i5 for obvious reasons. I guess if I come up with it, I'll just have to find a more FIRST friendly way of providing voltage boosters.
It's also probably around 5 pounds for the set up... Certainly more than most teams would be willing to spend.
view entire thread
Tags
loading ...