CrossMgrVideo: New "Time in Frame" feature
Post date: Oct 19, 2017 3:49:07 PM
CrossMgrVideo now supports a "Time in Frame" feature. Requires upgrading to the CrossMgrVideo 2.10.2 and CrossMgr 2.10.43.
CrossMgrVideo captures frames of the finish line triggered by CrossMgr. It uses inexpensive USB cameras.
The program makes it easy to access and playback small videos of rider finishes. This is critical to check for close finishes as well as looking for interference.
Because it uses a frame buffer, it records a few second *before* and *after* the rider is detected.
It can output video, individual frames or a "finish strip" which is similar to the output of a scan-line camera.
CrossMgrVideo is particularly helpful when triggered by CrossMgr RFID.
Both active and passive RFID systems have a window of inaccuracy where chip times are reported randomly. Due to chip mount, orientation to the antenna etc, reported chip times vary from the "true" time. Close finishes must be checked visually.
The "Cadillac" solution is a high-speed line-scan camera, but these are very expensive.
CrossMgrVideo makes it easy to check close finishes with inexpensive usb cameras and a standard laptop. It is limited to 25 frames per second, however, there is no limit to the number of CrossMgrVideo cameras you can use.
In addition to capturing finishes, CrossMgrVideo has a number of analysis features.
Right-click on the finish strip to get to a frame. Then, click on the "speedometer" button and a wizard allows you to compute the speed of the rider in the frame.
To get the speed of a rider's finish, you must first identify the leading and trailing edge of the front wheel. This is important to get a reference dimension. It is convenient that bicycle wheels are all almost exactly 670mm in diameter.
After establishing the wheel edges, pressing Next shows the next video frame. Identify the front wheel edge in the new frame you can get the rider's speed:
Pressing "Next" shows a final screen where you can get the rider's time anywhere in the frame. A horizontal line is shown to make it easy to line up the wheel with where the rider would cross at the finish line.
This final screen allows you to get an accurate time of when the rider actually crossed the finish line.
Of course, this calculation relies and the previous two screens.
But... how accurate is it?
Of course this is not a real-time system. Here is my best guess reasoning about errors.
Wheel size estimation. As this is being done visually, it could be off by a pixel. If the wheel is 100 pixels on the screen (about 1/12th of the frame), that's a 1% error.
Wheel movement estimation. This is also done visually and could be off by a pixel. If the number of pixels moved between frames is 100 (by adjusting the number of frames used), and assuming +/- one pixel, that's another 1% error.
Speed up/slow down of riders between frames. If a rider was breaking hard or accelerating, the speed could change between frames. It would be reasonable to expect that a rider could change speed at 0.1 km/h every 1/25 seconds (frame rate).
Combining the errors, we get 2%, or about 1/50. This means that for speeds around 50km/h, it should be accurate to +/- 0.5km/h.(0.55km/h if we include uncertainties in the current acceleration/deceleration).
The accuracy of time in the frame is a bit more difficult. As the frames are 1/25 second apart, 2% of 1/25 is 0.008 seconds.
Of course, there are errors in estimating when the wheel hit the line in the frame. All in, an upper bound of +/-0.01 seconds of error seems reasonable (about 1/100th of a second).
With this system, finishes within 0.01 seconds of each other should be considered ties.
Not a fancy scan-line camera, but pretty good for the money.