Close

Speed detection tool

Like to see something in a future release? Post your suggestions here.

Moderator: Staff

no avatar
Anjo206
 
Posts: 8
Joined: Mon Dec 22, 2014 6:40 pm

Speed detection tool

by Anjo206 » Wed Mar 23, 2016 9:55 pm

Sighthound already offers the ability to detect crossing boundaries, a nice tool to have is to be able to detect the time it takes an object or a car to cross 2 boundaries to be able to calculate an approximate speed of an object.

no avatar
JT!
 
Posts: 19
Joined: Tue Nov 17, 2015 3:06 am

Re: Speed detection tool

by JT! » Mon Mar 28, 2016 9:58 pm

This would be so much fun. Even if something could be built in so that you can enter in a distance so it could show you object velocity as soon as the object has passed the boundaries.

User avatar
Semper Vaporo
 
Posts: 331
Joined: Sat Oct 09, 2010 11:51 am

Re: Speed detection tool

by Semper Vaporo » Tue Mar 29, 2016 11:33 am

I have some observations to contribute on this idea. I must say that I think it would be a neat thing to add to SightHound, but I seriously doubt if it would be all that worthwhile, because it would have inherent inaccuracies.

I wrote a computer program some time ago that I use to determine the speed of trains seen on some of the Internet Web Cams that view RR tracks, and at a place where I go to watch trains (live).
My program is totally outside of SightHound. It runs in Windows 95 through Windows 10 with no problems, but being developed in Visual Basic 5 it comes with some legacy libraries (.dll’s and a .tlb) that some might consider junk on their PC.

I use Google Earth to determine the distances involved. For the webcams and for where I park to watch (live) trains, I draw lines using Google Earth's drawing tool from the camera's known location (or where I park) to two landmarks (utility pole, signal post, etc.) in the view where the train will pass. Then I use the drawing tool to measure the distance between where these two lines cross the tracks.

On my program, I have a textbox where I enter the distance determined with Google Earth. When a train is passing through the scene, I can Click a button on my program's window when a particular point on the train passes one landmark and again when it reaches the other landmark and the program displays the speed (MPH or KPH)

I can also enter the length of a train car (or multiple cars) and measure the speed using the car(s) passing a single landmark.

It does work, but has some inherent inaccuracies that must be accepted (i.e.: probably cannot use it in a court of law as proof of speed violations except maybe in extreme speed indications).

Minor inaccuracies are: my ability to measure accurately using Google Earth. Depending on the resolution of Google Earth and my ability to click the position with precision, and the speed and distances involved, an error of a few feet could be a major error in the speed calculation. Longer distances and slower trains reduce the percentage of the error in distance and timing of the start and stop commands. e.g.: an error of a couple of feet out of a mile is insignificant, but that same measurement error over a distance of 10 yards is very significant. An error of 1 second over an hour is also insignificant, but that same error in 10 seconds is very significant.

The greatest source of error in my program is my ability to click the mouse button at consistent and precise times. A minor portion of that error is in how long it takes the Windows operating system to recognize the click and pass the information on to my program (the latter can be significant if the CPU is busy with other things at the moment… newer PC’s with multi-core CPUs improved that a lot over the years I have been doing this!)

I have also noticed that the speed of trains is not as constant as one would expect… at least not in the areas where I have used my program. They tend to change speed often and over long timing durations (such as measuring the speed using the length of 10 rotary dump coal cars in a unit coal train) this results in only an “average” speed, not a peak speed. (I often see them bleed off 10 MPH in that 10 car string passing a single landmark.)

Now to translate the above to use it in SightHound:

You would still have the errors because of poor distance measurements and the significance of those errors.

There would be additional error induced if you are measuring something that is not confined to a specific path (such as a train track). Cars on a street, especially a residential street with no clear lane markings, could vary in distance from the camera by as much as 30 ft. Consider a camera view with a 45-degree angle formed between the two landmarks being used and the camera location (the apex of the angle). My street is 50-ft from my camera and it is 26-ft wide. Consider that my landmarks are at a 45-degree angle. Thus, the distance between the sightlines to those landmarks is 70-ft in the near lane and 103-ft in the far lane. The view is nearly horizontal so it is hard to tell which side of the street the car is. A car traversing those distances in 2-seconds is traveling 35-FPS if in the near lane and 51.5-FPS if in the far lane… the speeds are 23.8-MPH to 35-MPH, respectively; a difference of 11.2-MPH, which I feel is a significant error. Granted, if the car were to take only 1 second to traverse that distance (which I have seen) then the speed would be twice what I have shown above and either one would be clearly above the 25-MPH speed limit on a residential street.

SightHound would reduce the error caused by my physical reaction time to click the mouse button (which I have found to be excessive!), but I think there would still be an error that would need to be understood. SightHound is receiving information at a rate of 10 frames per second (minimum). Thus if an object were approaching a landmark it could take up to 1/10 of a second before it could be detected crossing the landmark. That 1/10-second error would be possible on both ends of the distance, thus there could be up to 1/5-second error in the timing. That is up to 10% of the timing in a 2-second event!

Additionally, I don’t think that SightHound is making decisions based on just one frame of the video so it could be even longer. If you watch a video clip with the “bounding box” feature turned On you can see the small “+” in the center of the box and it does not move smoothly with the object. Variations in contrast and lighting as an object moves tends to vary the size and shape of the bounding box around the object and the center of that bounding box is jittery, thus the “trigger” to start and stop the timing would also be jittery.

I would still like to incorporate the feature in SightHound, but I feel the accuracy and inconsistency would be excessive for anything more than satisfying idle curiosity of the speed of vehicles on the street.
Semper Vaporo,

no avatar
Walt Dockery
 
Posts: 30
Joined: Thu Apr 24, 2014 2:55 pm

Re: Speed detection tool

by Walt Dockery » Tue Apr 12, 2016 11:05 am

This would be a nice feature. Not useful for most but I would like it.

no avatar
mosheldon
 
Posts: 28
Joined: Sun Jul 02, 2017 1:25 pm

Re: Speed detection tool

by mosheldon » Sat Jul 08, 2017 12:49 am

+1


Return to Feature Requests