0

I'm starting to look into tracking a football (soccer ball in the US) and I could use some advice on what approach would be the more reliable and efficient.

The ball needs to tacked to determine if it goes between goal posts or not and roughly which side would that be if it's a goal (centre/left/right/top right corner/etc.)

Initially I was thinking about an embedded Inertial Measurement Unit (IMU, a fusion os sensors such as accelerometer/gyroscope/magnetometer and sometimes GPS) capable of Bluetooth Low Energy (BLE, version 4.0 which has a greater range then Bluetooth Classic) to get the ball's absolute position, so that could be an option. Since I'm not very experienced with IMUs yet, some tips on the DOs and DONTs would be handy.

Another option is to use a camera behind the goal post. With a 2D camera, I was imagining a setup like this: camera setup proto Hopefully the camera will be fast enough because I assume motion blur will one of the challenges, as the shape and colours will appear distorted when the ball is in fast motion.

In terms of detection I was thinking of a naive approach based on some assumptions:

  • segment the background since it's static (and mostly green)
  • try Hough Transform for circles and ellipses
  • segment moving objects and filter based on bounding box size (looking for smaller, ball like objects)

I am also considering training a cascade for football detection, but I would like to check if this is overkill or not beforehand.

nils
  • 2,424
  • 1
  • 17
  • 31
George Profenza
  • 50,687
  • 19
  • 144
  • 218
  • What's *BLE* and *IMU*? – nils Jul 20 '15 at 13:36
  • 2
    Are you sure that one camera will be enough? Did you take a look at [goal-line technologies](https://en.wikipedia.org/wiki/Goal-line_technology), e.g. [GoalControl](https://en.wikipedia.org/wiki/GoalControl) (14 high speed cameras)? – nils Jul 20 '15 at 13:37
  • BLE is Bluetooth Low Energy (4.0 which has a greater range then Bluetooth Classic) and IMU is Inertial Measurement Unit (a fusion os sensors such as accelerometer/gyroscope/magnetometer and sometimes GPS) to compute the absolute position and orientation). Thank you for pointing me to goal line technologies. It could be multiple cameras, a depth camera like kinect v2, a stereo pair like bumblebee, etc. Ideally something that wouldn't be to complicated or expensive in terms of setup. – George Profenza Jul 20 '15 at 13:58
  • It really depends what you are trying to achieve, one camera maybe enough for a fun weekend project, but if you want to make a commercial application you will need multiple, probably at least 3, 1080p 60fps cameras located strategically around the net. This cameras will be connected to a powerful workstation that will be connected to power cameras too needs to be connected to power, all this equipment have to be delivered to the field for every game, and we have not even started talking about quality of the results. Next cameras move slightly but they move, you will have to update homography. – ivan_a Jul 21 '15 at 15:52
  • With 3 HD streams and continuously updating homography, just copying all this data on the bus will be slower than real time (try to copy uncompressed video file on your computer) and that without even starting to processing of data. After processing the earliest you would be able to determine a goal will be couple minutes after it happened. – ivan_a Jul 21 '15 at 15:56
  • Good point @ivan_a ! I should've made that clearer in the question. The fun weekend project sounds closer: I won't need a huge amount of detail in terms of the ball's exact position. If I can figure out if the ball is within the posts or not and if so, roughly which area (left/right/top/etc. ( 3x2 grid would more than suffice)). Ideally a setup that is simple and not costly would make more sense at this point. This not going to be an accurate solution for commercial use like goal line technologies, but any techniques that could adapted/downscaled might be interesting to explore – George Profenza Jul 21 '15 at 16:04

1 Answers1

1

You could use a cheap Kinect camera with a simple algorithm like this one:

  1. detect blobs in the RGB data (resistant to blur)
  2. do an Euclidean clustering in the point cloud where you detect blobs, with a threshold/bounding box about the size of the ball you play with (the depth data has absolute measurements)
  3. calculate the centroid of the ball
  4. calculate the distance of the centroid from the camera center on the view ray
  5. see if the distance is less than the distance between camera and the goal on the same ray

These operations are simple enough that the algorithm should run in real-time on commodity hardware, in my opinion.

The only thing you have to be careful about is that the precision of Kinect after a certain distance goes to about crap, so you have to tinker with it a little to make it work. Or you might have to use more than one if it cannot cover all the goal.

aledalgrande
  • 5,167
  • 3
  • 37
  • 65