How to track a football's position?

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: 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.

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.