search

gregtinkers / carspeed.py

Record the speed of cars passing in front of the Raspberry Pi Picamera
368 stars 124 forks source link

Wrong speed measurement on LEFT_TO_WRITE moves #13

Open BugRaptor opened 6 years ago

BugRaptor commented 6 years ago

Sorry if I say something stupid, I only just read the code and it seems line 277 might be wrong:

abs_chg = x + w - initial_x

x + w is the x position of the right (front) edge of the vehicle but initial_x was the left (rear) edge of it when starting tracking.

As the speed measurement is based on the abs_chg value it will be exaggerated (oversized) on left to right moves.

I would simply change it to:

abs_chg = x - initial_x

measuring the speed based on the left (rear) side of the vehicle on left to right moves.

Other solution, if you want to track the front side of the vehicule, you should store the initial_x_plus_w value when starting the tracking

initial_x_plus_w = x + w

and then compute the abs_chg value on left to right moves this way:

abs_chg = x + w - initial_x_plus_w

Am I right ?

gregtinkers commented 6 years ago

Under most conditions the program tracks the front of the vehicle the entire time. For left to right moves, the contour expands from the left edge of the tacking area until the vehicle is entirely contained. During this time, the x value doesn't change, but the w increases. Once the entire vehicle is within the tracking area, x begins to change and w remains constant. The front of the vehicle is always located at x+w until the vehicle exits the tracking area. Initial_x should be the same as upper_left_x (the position of left edge of the tracking area.)

But, you are correct that there are circumstances when initial_x is the rear of the car and not close to the front. If the vehicle is traveling so fast that the entire contour is contained within the tracking area when motion is initially detected, the initial_x would be the rear of the vehicle and the speed would be off by w. The program was designed for low speed vehicles so this issue didn't occur in testing.

The initial_x_plus_w solution is a good one for correcting the program for higher speeds.

Thanks for taking the time to examine the code in detail.

BugRaptor commented 6 years ago

Oh, I understand ! Yes you're right. The tracking starts as soon as the vehicle partly enters the tracking area ! At this time w is small, but the "visible" part of the car inside the tracking area should already be big enough to trigger the tracking (found_area > MIN_AREA), that means w is small but not 0 and initial_x is not far but to the left of the initial front edge of the vehicle. This imply initial_x is not accurate to represent the initial front edge position which is actually located at initial_x + w, even for low speeds with left to right direction. It will imply an unaccuracy of the computed speed which will be slightly overestimated in left to right speed measurements.

Maybe another improving fix would be to trigger the tracking only when the vehicle is completely included inside the tracking area. This means when x > upper_left_x + MARGIN and x + w < lower_right_x - MARGIN. Where MARGIN is a constant defining the minimum number of pixels between the front or rear edge of the vehicle and the border of the tracking area to trigger the tracking. Added with the initial_x_plus_w correction this would make the speed measurement more accurate on left to right moves and will allow to set a greater MIN_AREA value (in order to trigger the tracking for vehicles only and not for smaller moving objects or animals eventualy entering the tracking area).

I will test these fixes. I'm currently preparing a Raspi 3 to make my own experimentations in front of my house.

Thanks for your explanations.

pageauc commented 6 years ago

I have had issues with contours shifting around on objects when tracking for my speed camera https://github.com/pageauc/speed-camera I already had a lead and end buffer area in the camera crop rectangle to ensure the object was well within the rectangle before starting tracking. The problem was contours would shift around during tracking resulting in skewed speed results since I just recorded start and end position and time to give a final average speed. My New method triggers for a set number of valid tracks rather than the old method of triggering on a trigger length. Recently I have changed the calculation method. speed is calculated for each individual valid track segment and stored in a list. For the final speed the list is used to calculate an average speed. That way if there is a contour shift during tracking, that results in a higher or lower speed it will be buffered by calculating the average from the individual track speeds stored in the speed_list. Still testing but seems to result in more consistent results. Occasionally I get a truck and trailer go by that results in two tracks because the truck goes past the buffer while the trailer is still in view. I have found the two speed results are reasonably close. Currently I have my speed_counter set for 4 rather than the default 3. If the speed_counter is set too high the object will be past the speed buffer before the trigger count is reached.

Just thought I would explain my recent changes. You can check out the code on the repo.https://github.com/pageauc/speed-camera/blob/master/speed-cam.py

Note the speed_camera() function is pretty long. My plan is to break it up into smaller functions but for now it is functions.

Regards Claude.

On Wed, Jul 11, 2018 at 10:21 AM, BugRaptor notifications@github.com wrote:

Oh, I understand ! Yes you're right. The tracking starts as soon as the vehicle partly enters the tracking area ! At this time w is small, but the "visible" part of the car inside the tracking area should already be big enough to trigger the tracking (found_area > MIN_AREA), that means w is small but not 0 and initial_x is not far but to the left of the initial front edge of the vehicle. This imply initial_x is not accurate to represent the initial front edge position which is actually located at initial_x + w, even for low speeds with left to right direction it will imply an unaccuracy of the computed speed which will be slightly overestimated in left to right speed measurements.

Maybe another improving fix would be to trigger the tracking only when the vehicle is completely included inside the tracking area. This means when x

upper_left_x + MARGIN and x + w < lower_right_x - MARGIN. Where MARGIN is a constant defining the minimum number of pixels between the front or rear edge of the vehicle and the border of the tracking area to trigger the tracking. Added with the initial_x_plus_w correction this would make the speed measurement more accurate on left to right moves and will allow to set a greater MIN_AREA value (in order to trigger the tracking for vehicles only and not for smaller moving objects or animals eventualy entering the tracking area).

I will test these fixes. I'm currently preparing a Raspi 3 to make my own experimentations in front of my house.

Thanks for your explanations.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gregtinkers/carspeed.py/issues/13#issuecomment-404187413, or mute the thread https://github.com/notifications/unsubscribe-auth/AFr1ZL6cU00CCaaK5T26Z8I16hAqo6idks5uFgnogaJpZM4VKjpR .

-- See my YouTube Channel at http://www.youtube.com/user/pageaucp