Closed konzty closed 10 months ago
The switch in direction is due to a contour shift on the tracked object. This can be due to lighting, reflection or some other reason. This is more of a problem when the object takes up a larger proportion of the camera, like in your case. Also due to higher MO_MAX_X_DIFF_PX. I will change L2R and R2L to use the first and last track points rather than the prev track point. This should fix your problem. Will let you know when ready
If you would like to help me test, since my setup is different. You can change a line and let me know results. Make sure you are running latest code for speed-cam.py ver 13.13
# set calibration for direction of travel
if end_pos_x - prev_pos_x > 0:
travel_direction = "L2R"
at line 1400 change prev_pos_x to start_pos_x
# set calibration for direction of travel
if end_pos_x - start_pos_x > 0:
travel_direction = "L2R"
Test and let me know result Claude ....
ver 13.14 is on GitHub that makes the change. I tested without problems.
You can do a menubox.sh UPGRADE.
Let me know your results.
Thanks Claude ...
Hi Claude,
you're too quick for me :D I was just in the process of upgrading to 13.13 and testing after the major reorganisation of config.py when your post about 13.14 reached me.
13.14 is running at the moment and I'll keep an eye on the logs; looks good so far.
Hello Claude,
my direction error rate is now down to 1.12% which is good enough I'd say.
Thanks!
Hi Claude,
I'm experimenting with your nice project and I'm really happy with it. Setup and calibration worked fine and I'm currently running the software and watching the logs for any strange behaviour - which i found:
2023-10-14 10:34:05 INFO speed_camera MO_TRACK_TIMEOUT_SEC 0.50 sec Delay to Avoid Tracking Same Object Multiple Times. 2023-10-14 10:34:12 INFO speed_camera New - 0/4 xy(30,40) Start New Track 2023-10-14 10:34:12 INFO speed_camera Add - 1/4 xy(46,40) 37.39 kph D=16/50 C=2 65x44=2860 sqpx L2R 2023-10-14 10:34:12 INFO speed_camera Add - 2/4 xy(62,40) 37.49 kph D=16/50 C=2 65x45=2925 sqpx L2R 2023-10-14 10:34:12 INFO speed_camera Add - 3/4 xy(77,40) 37.39 kph D=15/50 C=2 65x45=2925 sqpx L2R 2023-10-14 10:34:12 INFO speed_camera Add - 4/4 xy(44,40) 37.49 kph D=33/50 C=2 32x44=1408 sqpx R2L 2023-10-14 10:34:12 INFO speed_camera Saved 960x720 media/images/speed-20231014-0706/speed-37-20231014-1034129.jpg 2023-10-14 10:34:12 INFO is_SQLite3 Success: File is sqlite3 Format /home/pi/speed-camera/data/speed_cam.db 2023-10-14 10:34:12 INFO db_check Success: sqlite3 Connected to DB /home/pi/speed-camera/data/speed_cam.db 2023-10-14 10:34:13 INFO speed_camera SQL - Inserted Data Row into /home/pi/speed-camera/data/speed_cam.db 2023-10-14 10:34:13 INFO make_rel_symlink Saved at media/recent/speed-37-20231014-1034129.jpg 2023-10-14 10:34:13 INFO speed_camera End - R2L Ave Speed 37.5 kph Tracked 14 px in 0.256 sec Calib 65px 4789mm
I assume the direction of the last (4/4) tracking event defines the direction? I have it relatively often that the last and/or first direction is wrong.
Could you Implement some kind of majority vote for the direction?
My setup is
The close distance lead to very fast objects on the closer road side, objects where moving much faster than the initial MO_MAX_X_DIFF_PX allowed. I had to raise it up to 50, that fixed missing objects for me.
Objects move quickly through the relatively narrow (fisheye => distorted edges, avoid these) area of detection, I can only use 4 track events. Very fast vehicles seem to generate not enough track events when detection area is narrow and/or MO_TRACK_EVENT_COUNT is high.
Cheerrs and thanks for the great work you've done with this project.
Konzty