Very inacurrate - but not linear...

[4920441]

Hi,

I set up your tool a couple of days ago and I am still wondering how to get at least "linear" inaccurate measurements. I am about 10 meters away from the road in approx 4 m height. After using the calibration mode I entered the numbers in the config file and started it again. The first car was measured with about 20 kph, which could be right.... after that another car (don't know how fast it really was, but 284 kph can not be achieved on my road, nor with a 1 litre Ford Fiesta... After that a couple of around 20 kph but several 50 kph cars were catched - After that I drove myself in front of the camera with GPS 20 kph and the cam got 54 kph...

Maybe I do not understand the calibration process, but even if I don't...why isn't the error at least linear?

BTW: I am using a Raspberry Pi 3 Quadcore , picam720 and a wide angle lens (but the red calibration box is only in the middle, were the distortion is not very big.

Thanks alot for your help.

Cheers 4920441

[pageauc]

I recommend you start with 320x240 stream to test and if OK try next higher setting. Contours can move around due to lighting or other factors especially with larger stream sizes. The smaller stream will give faster opencv response. Also this tracks the largest moving object so it might be possible that other movements are fooling opencv. You can also reduce the track trigger length. This will reduce the amount of time the object is tracked before triggering camera and recording speed. This can avoid some problems with longer tracks.

Give these a try first and see what results are. You will need to re calibrate for 320x240. You can also manually adjust calibration settings using a vehicle at known speed. I normally set cal_obj_px to my vehicle and make several passes at know speed and check if they are consistent then adjust the cal_obj_mm up or down to match recorded speeds. This can take a few more passes to confirm. Claude ...

[pageauc]

For Better performance Do Not run from Raspberry Pi Desktop with gui_window_on = True. Instead run from SSH console or Terminal Session with gui_window_on = False. This is the default

[pageauc]

Inaccuracy can be due to slower response due to larger stream image size of 720. I would not use this unless you have upgraded opencv to ver 3+ and still you may have some lagging issues. Especially if you try to display opencv windows on GUI desktop. I use 320x240 for best tracking performance but 640x480 should still work OK.

If objects are too close to camera and take up a larger portion of the view then opencv may not track the object in the same location but track contours at different locations on the objects. This could explain the erratic behaviour and this might be made worse by slower processing due to larger stream image that takes opencv longer. opencv ver 3+ might give a little better performance. That is what I am using.

Also upgrade to releaste 8.93 that fixes a sqlite3 logging bug in calibration mode. Use menubox.sh UPGRADE menu pick. config files will not be overwritten so you will not loose your settings.

Let me know how things are working out Your feedback is appreciated Thanks Claude

[BigDuke6nc]

I have struggled getting things calibrated as well. The config file has an explanation of what each setting is for but I think what will go a long way is an explanation of which ones should be changed in troubleshooting. Or, if things are not tracking how to interpret the log messages and make the necessary changes.

[pageauc]

I will take a look at the wiki and try to simplify the explanation.
Claude ...

[pageauc]

This is very important. If you are using a plugin then you MUST adjust calibration settings on the plugin file you specified in config.py. The plugin settings over ride the config.py settings. You can either edit the plugin file using menubox.sh or directly by changing to the plugins folder and using nano.

If No config.py setting is specified then the default config.py settings are used. This might explain your problem with calibrating if you are using a plugin. Let me know if this is your situation.

Claude ....

[pageauc]

Please note if you enable plugins. Then the plugin file settings will over ride the settings in config.py. Therefore you must edit the specified plugin file for things like calibration. plugins can be enabled or disabled so check config.py pluginEnable = and pluginName=

For details see https://github.com/pageauc/speed-camera/wiki/Calibrate-Camera-for-Distance

[BigDuke6nc]

It's not the plugins that are causing the issue. I understand the function of the plugins and I use them. When calibrating I update the parameters in the plugin files. What I was trying to convey is that the settings have a good technical explanation. When trying to fine tune the program I don't fully understand what the log messages are indicating that needs adjusting. I did a fresh install due to jacking up my whole python setup trying to upgrade to opencv. Out of the box, without any changes the application runs well and tracks. The resolution is pretty bad but I stick with it so I can tune as suggested. But as the user mentions above, I get unrealistic speeds sometimes. I captured a golf cart going 60 mph. Or, double images of a vehicle. One image is about right, 20 mph, and the camera takes a second image of the same vehicle and the contour it captured was going 48 mph. And then other times no captures at all. The vehicle was not going any faster than the other vehicles that were captures. It wasn't any longer. No real explanation other than it didn't seem to find the contour again. That's just a few things. Oh by the way, when I did a fresh install I had to run the upgrade immediately again as there were some files missing when using the curl command. The webserver file did not download using the command. I think there may have been other files too, but I know it did not download with the curl command.

Patrick

[pageauc]

I have released version 8.94 of speed-cam.py. Calibration has better instructions. Also non calibration mode verbose logging shows settings for obj_cal_px and obj_cal_mm. This might help.

For Calibration I recommend you pick specific type vehicles that have similar lengths. The calibration image should get you close but you will need to tune. You can first estimate speeds and adjust only the obj_cal_mm setting up or down to get close to the estimated speed. Then do actual speed test to see confirm setting. Adjust obj_cal_mm value up or down. Higher value increases recorded speeds and visa versa

I recommend you stick with the 320x240 stream size and move to higher stream size once you have the 320x240 working OK. OpenCV will have issues with lighting, trailers, long vehicles, two vehicles close together etc. per https://github.com/pageauc/speed-camera/wiki/Program-Description#accuracy-issues

I can still get erratic things happening sometime due to lighting, Raspbian doing things and missing tracking, Etc.
I will be updating the Wiki as well.

Let me know how you are doing. Claude ...

[pageauc]

Thanks. Programming is finicky sometimes. lost a space in the install bash script. I tested and it should work OK now.

Yes things can sometimes be erratic but I wrote this as a fun demo project and there are issues that exist. I may revisit my original design to see if there is a better way. Visually tracking things is difficult and errors do arise. Example are in the news with very expensive LIDAR and high end cameras for Autonomous vehicles as well as face recognition and other factors. These happen when systems leave the lab and go out in the real world. That's when issues will show up.

I have been running my little single core RPI B for a year of so and although it misses objects and sometimes tracks birds flying in front of the window, Etc It can track pretty well most of the time except when it is windy and trees, bushes confuse things or light reflections Etc. I can estimate the speed and the camera can report a similar value. Eg I know a car is going fast and the camera says the same thing. I often drive by at a specific speed and the camera does track pretty close. We are not on a busy street. There are problems with some vehicles since it tracks part of the vehicle and the contours can shift around and generate out of Range errors. Too close or too far from previous reported position. Sometimes you will see changes from L2R then R2L and back again but this is due to contours not staying on the same part of the vehicle. The background contrast and lighting can cause problems as well.. I have found that night tracking appears to be good since the car lights and dark background give good contrast.

Anyway Hope this explanation helps. Your Comments are appreciated Regards Clsude ...

[BigDuke6nc]

Oh, no worries. I know this is a hobby. And I know it can be a hit or miss. I'm not looking for it to be perfect. Just trying to learn how I can improve my accuracy without so much trial and error. Yes, I find night tracking much better too.

[4920441]

Hi, I tried it again, now with pluginName = "picam240" and all calibration done in the plugin file itself (as before, only with the other plugin file of course)

But the Problem stays... After calibration I drive with cruise control and GPS acurate 20 kph and get a reading at the speedcam of 19,1 kph - what's okay, I think. After that I am driving with cruise control and GPS EXACTLY 30 kph and I get 17.3 kph reading in the speedcam.... er...?!

real 20 kph) https://bit.ly/2u3YWA7

real 30 kph) https://bit.ly/2KM9ICh

Is my car too black? Despite that, I did never get a car which went faster than 28kph - what is hard to believe.

Maybe the view is not suitet for opencv... or the distortion of the wide angle lens is too strong, though....

Cheers,

UxG

[BigDuke6nc]

So this is a classic example of where I have trouble calibrating. This is attempting to calibrate picam720 plugin straight from the default settings. What can I do to get get this captured.?

2018-07-09 13:32:41 INFO speed_camera New - cxy(106,180) Start New Track 2018-07-09 13:32:41 INFO speed_camera Out - cxy(239,183) Dist=133 is >=35 px C=8 53x12=432 sqpx R2L 2018-07-09 13:32:41 INFO speed_camera Out - cxy(272,184) Dist=166 is >=35 px C=8 54x12=440 sqpx R2L 2018-07-09 13:32:42 INFO speed_camera Out - cxy(304,185) Dist=198 is >=35 px C=7 53x12=410 sqpx R2L 2018-07-09 13:32:42 INFO speed_camera Out - cxy(337,185) Dist=231 is >=35 px C=5 53x13=431 sqpx R2L 2018-07-09 13:32:42 INFO speed_camera Out - cxy(370,186) Dist=264 is >=35 px C=6 53x13=435 sqpx R2L

I assume increase the x_diff_max. However, the moment I begin increasing this value things do get track but the calculations begin to behave like 4920441 described.

[pageauc]

720 will have a longer opencv processing time between frames. If you want faster tracking speed try the 480 plugin. Try increasing the following settings in the 720 plugin file if that is what you are using.

track_len_trig = 210    # Default= 75 Length of track to trigger speed photo
x_diff_max = 100        # Default= 35 Exclude if max px away >= last motion event x pos

track_len_trig will give you a longer distance to measure speed and should give better accuracy. You are probably having problems due to varying contour widths thus causing errors. I have not tested 720 plugin very much due to lag. You can try increasing trig len more but total track window x width is 900 - 380 or 520 px. I think 300 or even a bit more would be OK.

The problem you might have is timeout due to slower processing of larger image size in opencv In that case try increasing the event_timeout to allow more time between motion events.. Check out of range value log entries. Make sure show_out_range = True. If you get a lot of out of range log entries in track it could be due to multiple objects or other reasons. The x_diff_max setting is supposed to ignore these because the contour is to far away from last position.

Let me know results. I am currently testing my single core RPI and increased trig length to

[BigDuke6nc]

Thanks for your effort.

I have made the following changes and now nothing is getting captured. As a matter of fact very few vehicles are even getting tracked.

cal_obj_px = 345 # Length of a calibration object in pixels cal_obj_mm = 5890.0 # Length of the calibration object in millimetres

Crop Area for motion detection Tracking

=======================================

x_left = 380 # Default= 380 Exclude event if x less than this px position x_right = 900 # Default= 900 Exclude event if x greater than this px position y_upper = 230 # Default= 260 Exclude event if y less that this value y_lower = 460 # Default= 460 Exclude event if y greater than this value

Motion Event Settings

---------------------

SPEED_MPH = True # Set the speed conversion kph=False mph=True MIN_AREA = 200 # Default= 200 Exclude all contours less than or equal to this sq-px Area track_len_trig = 300 # Default= 75 Length of track to trigger speed photo x_diff_max = 100 # Default= 35 Exclude if max px away >= last motion event x pos x_diff_min = 1 # Default= 1 Exclude if min px away <= last event x pos track_timeout = 1.0 # Default= 0.0 Optional seconds to wait after track End (Avoid dual tracking) event_timeout = 2.0 # Default= 0.7 seconds to wait for next motion event before starting new track log_data_to_CSV = True # Default= True True= Save log data as CSV comma separated values show_out_range = True # Default= True Show Out of Range Events per x_diff settings below False= Off

[pageauc]

That is probably due to the time opencv takes to loop using a larger 720p image size. The RPI pipeline is only so big. If the object moves too fast it is probably out of frame by the time the loop is ready to read the next frame. Try using a 240 or 480 plugin. Resolution will be lower.

Upgrading opencv might help but I recommend you try a lower resolution stream to increase the speed of frame processing. You should get a lot more track events for slower objects and better tracking for fast objects. I have updated plugin settings and config.py to increase track trig len.

If you want to upgrade

cd ~/speed-camera
mv plugins plugins.bak
mv config.py config.py.bak

Run menubox.sh and run UPGRADE menu pick

cp config.py.new config.py

edit config.py and transfer your settings from the .bak file. eg calibrate = False and plugin variables etc. edit the plugin setting as well with the one in plugins.bak folder.

Test Claude ...

Seems like a lot of work but remember this was done as a demo programming learning experience for me. I know there are issues and the program is not an out of the box solution. You have to understand the algorithm and the reason for the various settings I used.

Close up objects are larger in the camera and therefore the contours are larger and can lead to larger errors due to contour width variations. Objects farther away are smaller in the camera view and therefore the tracking contours are smaller with less variation and the tracking speeds are slower due to the distance. This would give better results. I am thinking you are too close to large fast objects being tracked that are causing the problem.

Your feed back is appreciated. Claude ...

[pageauc]

Issued Release 9.00 of Speed Camera

I have reworked speed camera to use a track_counter instead of track_len_trig

I also now track the contour x position instead of the contour center position. This seems to do a better job although there are still a few cases where a contour will shift to another part of the object and throw the speed out. I will work on doing more tuning.

To upgrade run menubox.sh and run UPGRADE menu pick

This change will require the new config.py.

To update config.py perform the following

cd ~/speed-camera
cp config.py config.py.bak
cp config.py.new config.py

You can transfer any custom settings from the bak file to config.py

Note you can reduce pedestrian or bike images by setting max_speed_over. to a reasonable speed value. This can also filter for high speed traffic if desired

I would appreciate any feedback on this version

Your feedback is appreciated. Made me think about another way of tracking Thanks Claude ....

[BigDuke6nc]

I appreciate the effort for the update. I want to make sure I understand. You want me to attempt to use the PICAM720 plugin or use 720p to test?

[pageauc]

I would start with stock config.py with plugin turned off. If that works then move to a higher resolution. I have not updated the plugins so there may be some customization required for a few settings to make them similar to the new config.py. here is a list

720 suggested plugin setting changes

• x_diff_max = 40 but may need to be change up or down
• track_len_trig is no longer required. It will be ignored if left in otherwise it can be deleted.
• Track_counter will be read from config.py so no need to add it to plugin unless you need to customize.
• event_timeout can be set lower. maybe 0.4 or so to start depending on loop performance.
• MIN_AREA can be lower depending on contour area sizes you are seeing in logs and contour noise in camera view. Check the log c= entries. c is the total contours for that motion event. A single contour will be ideal. If the objects to track are far away from camera this needs to be smaller so it matches the area of the objects to be tracked. Too low and noise from bushes, lighting, Etc may be in motion stream.
• You can also try changing CAMERA_FRAMERATE lower or higher to see what effect it has. You are trying to match the camera framerate with the approx opencv looping speed. Faster is not always better. I have reduced the math in the loop so it should run a little faster but opencv functions still consume the majority of processing time and only way to improve that is to move to a later version of opencv.

Note The speed_camera() function is pretty long and I need to try to break it up into smaller function calls but currently it works.

Hope this helps I would be interested in results

Thanks Claude ...

[BigDuke6nc]

OK, I tried 720p with what I had in my previous settings. It was tracking much better but the image of the object was so blurry you couldn't even make out the make and model of the vehicle in most cases. I will try the OOB config for a day or so and then try the suggested 720 settings maybe on Friday.

[pageauc]

Are you using a pi-camera. If so you can try different settings for the framerate. Not sure if up or down would be better but I would think higher framerate would be better. Would be interested in knowing. Claude

[pageauc]

Updated speed-cam.py to 9.01 to add tenth of second to sql idx field to avoid unique error. Also updated plugins. See wiki for details on how to force updating of plugins by deleting/renaming existing plugins. These should be OK as a start point. Tested 720 on RPI3B+. Had to increase x_diff_max to reduce out of range. Needs more testing Claude ...

[BigDuke6nc]

I've tried the latest update on 720p. Out of the box everything tracks great but the speeds are inaccurate as you would expect without calibrating. Once I enter my vehicle's length and pixel length that's when things get off. Things simply do not track or does not get captured for various reasons. I assume I'm just too close to the road. It's ok at a lower resolution. I was just hoping for some more clarity on the images. The ultimate goal I have is to pull down your source and add Cloud API for vehicle recognition so I can match up potential repeat "offenders" of a certain speed. I was thinking a higher resolution image would be most helpful.

[pageauc]

Inconsistencies are due to contours that move around relative to the object motion. If you look at images contour rectangles you can see they sometimes lock on part of the vehicle and can shift between start and finish. I am working on some way to compensate for contours moving. I am thinking of doing something with the contour widths since those change when the contour moves. This is a common problem with tracking in real time with opencv. I have a x_diff_max variable to ignore large jumps. The new track_counter and contour xy method is better than previous tracking using contour center points and track_len_trig. Anyway it is a fun challenge and there are lots of problems in life that have similar challenges.

Thanks for your feedback It is appreciated Claude ...

[pageauc]

I have released speed-cam.py version 9.03.
To try to reduce the effects of shifting contours I have take a slightly different approach. The new way calculates speed for each individual track segment and stores result in a list. After the speed_counter is triggered, the average speed is calculated from the speed_list entries.
This is different from the previous method of just recording the start, end times and pixels start,end positions and calculating the final ave speed base on total time and pixels traveled. The previous method displayed interim cumulative speed results so the final counter speed was always the same as the End speed. I believe the new speed_list approach will dampen a contour shift that results in a higher or lower speed than the other results. The new method displays actual speed for each track segment. These are the values stored in the speed_list. You may want to increase the track_counter from 3 to maybe 4 or 5. Just be careful since the object may move past the end buffer and the speed_counter will not reach the trigger point. In that case reduce the speed_counter variable.

This approach seems to work better. I would appreciate your feedback on your testing.

You can upgrade using the menubox.sh UPGRADE menu pick. Configuration settings will not be overwritten.

Thanks Claude ...

[BigDuke6nc]

I tried the new changes over the weekend. Albeit the conditions were rather windy and I picked up a lot of background tracks, the speeds were wildly inaccurate. I had minivans motoring along at 147 MPH and kids on bikes doing 58 MPH. I tried all combinations of parameters and could never get anything reliable. A lot of changes would either cause the object not to track or would essentially give crazy results. All of this was attempting to use 720p. I have gone back to 480p and will let you know how that goes.

[pageauc]

There are algorithms for tracking that use optical flow or openTLD. These use the contour dimensions and point data to smooth and or reject readings. I don't believe RPI has enough processing to implement efficiently but I will give it a try. If you take a look at the data for a track you will see the widths change for Add logging events. This can cause the position data to be out and a small pixel difference can change the speed calculation. I have been working on tuning the stock 320x240 config and it seems better but as you know sometimes you can get some wild results. This is an interesting problem but not unique. That is why several optical flow and other algorithms were developed but these take processing power. Trying to do things in real time is a challenge. Post processing video would give better results but would take time. eg Trigger a video on first motion and save contour data until no further motion is detected, then do post processing in a background thread using a good optical flow method while continuing monitoring for motion in original thread.

Add Events Log Legend D= px travelled/x_diff_max C= Total contours processed contour width x height = contour area in pixels Travel direction R2L = Right To Left or L2R = Left To Right

Claude ...

[BigDuke6nc]

So I have tested this for a while. This is a behavior that I see constantly. When using the 480p I get several images for a vehicle. There is one image that seems to calculate the speed correctly (26mph). I then have 3 additional images that calculate wildly inaccurate (97mph, 65mph, and 165mph). This is with everything set to default and the only thing changed is the obj length in mm and the pixel length. I have tried adjusting but nothing really seems to help. But I question what I am adjusting since the first image captured correctly. Sometimes, I only get one image per vehicle but the outrageous speed is captured.

[jmspswny]

I'm seeing a similar problem running in 720 mode. When I dig into the logs, it seems to be driven by some interesting shifts in the directional assessment. From a test run I did at 20, I get:

2019-01-19 14:09:11 INFO speed_camera Add - 1/5 xy(396,1) 16.59 mph D=47/2000 C=5 106x18=1283 sqpx R2L 2019-01-19 14:09:11 INFO speed_camera Add - 2/5 xy(231,1) 19.61 mph D=165/2000 C=4 126x19=1326 sqpx R2L 2019-01-19 14:09:11 INFO speed_camera Add - 3/5 xy(171,1) 21.90 mph D=60/2000 C=4 132x26=1971 sqpx R2L 2019-01-19 14:09:11 INFO speed_camera Add - 4/5 xy(112,1) 21.02 mph D=59/2000 C=4 138x27=2211 sqpx R2L 2019-01-19 14:09:11 INFO speed_camera Add - 5/5 xy(181,1) 7.84 mph D=69/2000 C=4 84x71=1637 sqpx L2R

That last entry, where the direction shifts from R2L to L2R is something I'm seeing crop of periodically, with HUGE swings in that value, both up and down. It is that swing that seems to be creating the inaccuracies, at least in my setup. I'm working through some tweaks that disregard directional changes that might help. I'd be interested if anyone else has poked at similar solutions.

[pageauc]

Did you install from github repo easy install script. This auto installs all dependencies and files. You will have problems if you just clone project. Also what raspbian version are you running or something else You could try running menubox.sh upgrade menu pick on raspberry pi and this might fix things.

Copy of actual error messages would be useful

Claude

On Wed, Mar 27, 2019, 11:25 PM conan785 notifications@github.com wrote:

I am hitting a issue getting this up and running. I have everything installed but when I run the speed-cam-py i am getting a odd errror File "./speed-cam.py", line 1413, in speed_camera() # run in main speed camera processing loop.

then a few that are SQLite related. what did I screw up??

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pageauc/speed-camera/issues/30#issuecomment-477432586, or mute the thread https://github.com/notifications/unsubscribe-auth/AFr1ZK6eiAXGjcZcmOLOZxNHHebKGoY-ks5vbDYzgaJpZM4U98X5 .

[conan785]

Thanks for the response. I ran the install again then ran the update from menubox. That fixed the issues.

On Thu, Mar 28, 2019, 8:45 AM Claude Pageau notifications@github.com wrote:

Did you install from github repo easy install script. This auto installs all dependencies and files. You will have problems if you just clone project. Also what raspbian version are you running or something else You could try running menubox.sh upgrade menu pick on raspberry pi and this might fix things.

Copy of actual error messages would be useful

Claude

On Wed, Mar 27, 2019, 11:25 PM conan785 notifications@github.com wrote:

I am hitting a issue getting this up and running. I have everything installed but when I run the speed-cam-py i am getting a odd errror File "./speed-cam.py", line 1413, in speed_camera() # run in main speed camera processing loop.

then a few that are SQLite related. what did I screw up??

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/pageauc/speed-camera/issues/30#issuecomment-477432586>, or mute the thread < https://github.com/notifications/unsubscribe-auth/AFr1ZK6eiAXGjcZcmOLOZxNHHebKGoY-ks5vbDYzgaJpZM4U98X5

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pageauc/speed-camera/issues/30#issuecomment-477548946, or mute the thread https://github.com/notifications/unsubscribe-auth/AuvfZOHUTvvP7q8PPBPoqPkIWYafYWptks5vbKGAgaJpZM4U98X5 .

[conan785]

I do have a follow up question for you. I am getting some odd results and I think it has to do with the distance from the camera to the road. I am about 160 feet from camera to road. I have the capture field fairly wide and what I am seeing is a good capture at say 27 mph and then another capture moments later at something outrageous like 116 mph. I am tinkering with a smaller capture field, track timeout, and event timeout. Any suggestions so I don't have to do it with trial and error?

On Thu, Mar 28, 2019 at 10:03 AM Todd Lambert conan785@gmail.com wrote:

Thanks for the response. I ran the install again then ran the update from menubox. That fixed the issues.

On Thu, Mar 28, 2019, 8:45 AM Claude Pageau notifications@github.com wrote:

Did you install from github repo easy install script. This auto installs all dependencies and files. You will have problems if you just clone project. Also what raspbian version are you running or something else You could try running menubox.sh upgrade menu pick on raspberry pi and this might fix things.

Copy of actual error messages would be useful

Claude

On Wed, Mar 27, 2019, 11:25 PM conan785 notifications@github.com wrote:

I am hitting a issue getting this up and running. I have everything installed but when I run the speed-cam-py i am getting a odd errror File "./speed-cam.py", line 1413, in speed_camera() # run in main speed camera processing loop.

then a few that are SQLite related. what did I screw up??

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/pageauc/speed-camera/issues/30#issuecomment-477432586 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AFr1ZK6eiAXGjcZcmOLOZxNHHebKGoY-ks5vbDYzgaJpZM4U98X5

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pageauc/speed-camera/issues/30#issuecomment-477548946, or mute the thread https://github.com/notifications/unsubscribe-auth/AuvfZOHUTvvP7q8PPBPoqPkIWYafYWptks5vbKGAgaJpZM4U98X5 .

[conan785]

I was looking at your code. to figure out the speed ou use this,

px_to_kph = float(cal_obj_mm/cal_obj_px *0.0036)

where does the 0.0036 come from?

On Thu, Mar 28, 2019 at 2:25 PM Todd Lambert conan785@gmail.com wrote:

I do have a follow up question for you. I am getting some odd results and I think it has to do with the distance from the camera to the road. I am about 160 feet from camera to road. I have the capture field fairly wide and what I am seeing is a good capture at say 27 mph and then another capture moments later at something outrageous like 116 mph. I am tinkering with a smaller capture field, track timeout, and event timeout. Any suggestions so I don't have to do it with trial and error?

On Thu, Mar 28, 2019 at 10:03 AM Todd Lambert conan785@gmail.com wrote:

Thanks for the response. I ran the install again then ran the update from menubox. That fixed the issues.

On Thu, Mar 28, 2019, 8:45 AM Claude Pageau notifications@github.com wrote:

Did you install from github repo easy install script. This auto installs all dependencies and files. You will have problems if you just clone project. Also what raspbian version are you running or something else You could try running menubox.sh upgrade menu pick on raspberry pi and this might fix things.

Copy of actual error messages would be useful

Claude

On Wed, Mar 27, 2019, 11:25 PM conan785 notifications@github.com wrote:

I am hitting a issue getting this up and running. I have everything installed but when I run the speed-cam-py i am getting a odd errror File "./speed-cam.py", line 1413, in speed_camera() # run in main speed camera processing loop.

then a few that are SQLite related. what did I screw up??

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/pageauc/speed-camera/issues/30#issuecomment-477432586 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AFr1ZK6eiAXGjcZcmOLOZxNHHebKGoY-ks5vbDYzgaJpZM4U98X5

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pageauc/speed-camera/issues/30#issuecomment-477548946, or mute the thread https://github.com/notifications/unsubscribe-auth/AuvfZOHUTvvP7q8PPBPoqPkIWYafYWptks5vbKGAgaJpZM4U98X5 .

[BigDuke6nc]

I struggled with accuracy as well. The behavior you experienced is the same as I encountered. However, my distance was shorter. Around 60 to 75 feet to the street. I eventually stopped tinkering as nothing I changed seemed to stabilize the results.

[conan785]

Thanks for the input. I'll keep tinkering as that's what I do. Can you enlighten my where the 0.0936 came from?

On Thu, Mar 28, 2019, 3:24 PM BigDuke6nc notifications@github.com wrote:

I struggled with accuracy as well. The behavior you experienced is the same as I encountered. However, my distance was shorter. Around 60 to 75 feet to the street. I eventually stopped tinkering as nothing I changed seemed to stabilize the results.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pageauc/speed-camera/issues/30#issuecomment-477737522, or mute the thread https://github.com/notifications/unsubscribe-auth/AuvfZLJLmYvAqchGHK9iqH8a1uaSJVH3ks5vbRcGgaJpZM4U98X5 .

[pageauc]

..0036 is the conversion value from mm/sec to km/hr

1 hr = 3600 seconds 1 km = 1000x1000 mm or 1000000 mm

Hope this explains conversion value

On Thu, Mar 28, 2019 at 3:20 PM conan785 notifications@github.com wrote:

I was looking at your code. to figure out the speed ou use this,

px_to_kph = float(cal_obj_mm/cal_obj_px *0.0036)

where does the 0.0036 come from?

On Thu, Mar 28, 2019 at 2:25 PM Todd Lambert conan785@gmail.com wrote:

I do have a follow up question for you. I am getting some odd results and I think it has to do with the distance from the camera to the road. I am about 160 feet from camera to road. I have the capture field fairly wide and what I am seeing is a good capture at say 27 mph and then another capture moments later at something outrageous like 116 mph. I am tinkering with a smaller capture field, track timeout, and event timeout. Any suggestions so I don't have to do it with trial and error?

On Thu, Mar 28, 2019 at 10:03 AM Todd Lambert conan785@gmail.com wrote:

Thanks for the response. I ran the install again then ran the update from menubox. That fixed the issues.

On Thu, Mar 28, 2019, 8:45 AM Claude Pageau notifications@github.com wrote:

Did you install from github repo easy install script. This auto installs all dependencies and files. You will have problems if you just clone project. Also what raspbian version are you running or something else You could try running menubox.sh upgrade menu pick on raspberry pi and this might fix things.

Copy of actual error messages would be useful

Claude

On Wed, Mar 27, 2019, 11:25 PM conan785 notifications@github.com wrote:

I am hitting a issue getting this up and running. I have everything installed but when I run the speed-cam-py i am getting a odd errror File "./speed-cam.py", line 1413, in speed_camera() # run in main speed camera processing loop.

then a few that are SQLite related. what did I screw up??

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/pageauc/speed-camera/issues/30#issuecomment-477432586

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AFr1ZK6eiAXGjcZcmOLOZxNHHebKGoY-ks5vbDYzgaJpZM4U98X5

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/pageauc/speed-camera/issues/30#issuecomment-477548946>, or mute the thread < https://github.com/notifications/unsubscribe-auth/AuvfZOHUTvvP7q8PPBPoqPkIWYafYWptks5vbKGAgaJpZM4U98X5

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pageauc/speed-camera/issues/30#issuecomment-477736062, or mute the thread https://github.com/notifications/unsubscribe-auth/AFr1ZMkixNnid8RQVaMS30-h_A6p4UXcks5vbRX2gaJpZM4U98X5 .

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