car speed checker with lcd display free sample

The system basically comprises two laser transmitter-LDR sensor pairs, which are installed on the highway 100 metres apart, with the transmitter and the LDR sensor of each pair on the opposite sides of the road. The installation of lasers and LDRs is shown in Fig. 1. The system displays the time taken by the vehicle in crossing this 100m distance from one pair to the other with a resolution of 0.01 second, from which the speed of the vehicle can be calculated as follows:

As per the above equation, for a speed of 40 kmph the display will read 900 (or 9 seconds), and for a speed of 60 kmph the display will read 600 (or 6 seconds). Note that the LSB of the display equals 0.01 second and each succeeding digit is ten times the preceding digit. You can similarly calculate the other readings (or time).

Figure below shows the circuit of the speed checker. It has been designed assuming that the maximum permissible speed for highways is either 40 kmph or 60 kmph as per the traffic rule.

The circuit is built around five NE555 timer ICs (IC1 through IC5), four CD4026 counter ICs (IC6 through IC9) and four 7-segment displays (DIS1 through DIS4). IC1 through IC3 function as monostables, with IC1 serving as count-start mono, IC2 as count-stop mono and IC3 as speed-limit detector mono, controlled by IC1 and IC2 outputs. Bistable set-reset IC4 is also controlled by the outputs of IC1 and IC2 and it (IC4), in turn, controls switching on/off of the 100Hz (period = 0.01 second) astable timer IC5.

The time period of timer NE555 (IC1) count-start monostable multivibrator is adjusted using preset VR1 or VR2 and capacitor C1. For 40kmph limit the time period is set for 9 seconds using preset VR1, while for 60kmph limit the time period is set for 6 seconds using preset VR2. Slide switch S1 is used to select the time period as per the speed limit (40 kmph and 60 kmph, respectively). The junction of LDR1 and resistor R1 is coupled to pin 2 of IC1.

For IC2, the monostable is triggered in the same way as IC1 when the vehicle intersects the laser beam incident on LDR2 to generate a small pulse for stopping the count and for use in the speed detection. LED2 glows for the duration for which pin 3 of IC2 is high.

The outputs of IC1 and IC2 are fed to input pins 2 and 1 of NAND gate N1, respectively. When the outputs of IC1 and IC2 go high simultaneously (meaning that the vehicle has crossed the preset speed limit), output pin 3 of gate N1 goes low to trigger monostable timer IC3. The output of IC3 is used for driving piezobuzzer PZ1, which alerts the operator of speed-limit violation. Resistor R9 and capacitor C5 decide the time period for which the piezobuzzer sounds.

The project is a speed checker system that can detect rash driving and any kind of speed violation on highways and alert the traffic authorities. The conventional system uses a handheld radar gun which is aimed at the vehicle to record its speed and if there is any speed violation, nearest police station is informed. This process involves a lot of time consumption. Hence the proposed system is used to check the speed by calculating the time taken to travel between two set points at certain distance.

An IR transmitter and a receiver are installed on the set points on either side of the road. A control unit calculates the time taken by the vehicle to travel from one set point to other and calculates the speed that is displayed on seven segment display. If the calculated speed limit exceeds the set speed, a buzzer is sound which alerts the road transport authority.

I appreciate your speed delivery of the components and all the other materials provided, but some of the components provided are not working. We assembled the circuit and started its testing and later we came to know that the adapter was not working. So I just feel that I have wasted my money. Now the circuit too is not working. I don"t know what to do with it as I have a presentation to give on this project. I want my money back, whatever the adapter"s charge is, or atleast compensation.

In this tutorial, you will learn how to use OpenCV and Deep Learning to detect vehicles in video streams, track them, and apply speed estimation to detect the MPH/KPH of the moving vehicle.

We feel almost powerless. These drivers disregard speed limits, crosswalk areas, school zones, and “children at play” signs altogether. When there is a speed bump, they speed up almost as if they are trying to catch some air!

In most cases, the answer is unfortunately “no” — we have to look out for ourselves and our families by being careful as we walk in the neighborhoods we live in.

But what if we could catch these reckless neighborhood miscreants in action and provide video evidence of the vehicle, speed, and time of day to local authorities?

In this tutorial, we will review the concept of VASCAR, a method that police use for measuring the speed of moving objects using distance and timestamps. We’ll also understand how here is a human component that leads to error and how our method can correct the human error.

From there, we’ll design our computer vision system to collect timestamps of cars to measure speed (with a known distance). By eliminating the human component, our system will rely on our knowledge of physics and our software development skills.

Our system relies on a combination of object detection and object tracking to find cars in a video stream at different waypoints. We’ll briefly review these concepts so that we can build out our OpenCV speed estimation driver script.

Finally we’ll deploy and test our system. Calibration is necessary for all speed measurement devices (including RADAR/LIDAR) — ours is no different. We’ll learn to conduct drive tests and how to calibrate our system.

Visual Average Speed Computer and Recorder (VASCAR) is a method for calculating the speed of vehicles — it does not rely on RADAR or LIDAR, but it borrows from those acronyms. Instead, VASCAR is a simple timing device relying on the following equation:

In order to utilize the VASCAR method, police must know the distance between two fixed points on the road (such as signs, lines, trees, bridges, or other reference points)

If they press the button late (first reference point) and then early (second reference point), then your speed will be calculated faster than you are actually going since the time component is smaller.

If you are ever issued a ticket by a police officer and it says VASCAR on it, then you have a very good chance of getting out of the ticket in a courtroom. You can (and should) fight it. Be prepared with Equation 1.1 above and to explain how significant the human component is.

Our project relies on a VASCAR approach, but with four reference points. We will average the speed between all four points with a goal of having a better estimate of the speed. Our system is also dependent upon the distance and time components.

This tutorial requires a Raspberry Pi 4B and Movidius NCS2 (or higher once faster versions are released in the future). Lower Raspberry Pi and NCS models are simply not fast enough. Another option is to use a capable laptop/desktop without OpenVINO altogether.

Our config.json file holds all the project settings — we will review these configurations in the next section. Inside Raspberry Pi for Computer Vision with Python, you’ll find configuration files with most chapters. You can tweak each configuration to your needs. These come in the form of commented JSON or Python files. Using the package, json_minify , comments are parsed out so that the JSON Python module can load the data as a Python dictionary.

We will be taking advantage of both the CentroidTracker and TrackableObject classes in this project. The centroid tracker is identical to previous people/vehicle counting projects in the Hobbyist Bundle (Chapters 19 and 20) and Hacker Bundle (Chapter 13). Our trackable object class, on the other hand, includes additional attributes that we will keep track of including timestamps, positions, and speeds.

This video is provided for demo purposes; however, take note that you should not rely on video files for accurate speeds — the FPS of the video, in addition to the speed at which frames are read from the file, will impact speed readouts.

Videos like the one provided are great for ensuring that the program functions as intended, but again, accurate speed readings from video files are not likely — for accurate readings you should be utilizing a live video stream.

A testing script is included — speed_estimation_dl_video.py . It is identical to the live script, with the exception that it uses a prerecorded video file. Refer to this note:

Note: OpenCV cannot automatically throttle a video file framerate according to the true framerate. If you use speed_estimation_dl_video.py as well as the supplied cars.mp4 testing file, keep in mind that the speeds reported will be inaccurate. For accurate speeds, you must set up the full experiment with a camera and have real cars drive by. Refer to the next section, “Calibrating for Accuracy”, for a real live demo in which a screencast was recorded of the live system in action.

The driver script, speed_estimation_dl.py, interacts with the live video stream, object detector, and calculates the speeds of vehicles using the VASCAR approach. It is one of the longer scripts we cover in Raspberry Pi for Computer Vision.

In some cases, I use JSON and other cases Python files. We could argue all day over which is easiest (JSON, YAML, XML, .py, etc.), but for most projects inside of Raspberry Pi for Computer Vision with Python we use either a Python or JSON configuration in place of a lengthy list of command line arguments.

The "confidence" value is the probability threshold for object detection with MobileNet SSD. Detect objects (i.e. cars, trucks, buses, etc.) that don’t meet the confidence threshold are ignored (Line 17).

As mentioned previously, we have four speed estimation zones. Line 23 holds a dictionary of the frame’s columns (i.e. y-pixels) separating the zones. These columns are obviously dependent upon the "frame_width".

As shown in Figure 3, there are 49 feet between the edges of where cars will travel in the frame relative to the positioning on my camera. The conversion of 49 feet to meters is 14.94 meters.

The value has been tuned for system calibration. See the “Calibrating for Accuracy” section to learn how to test and calibrate your system. Secondly, had the measurement been made at the center of the street (i.e. further from the camera), the distance would have been longer. The measurement was taken next to the street by Dave Hoffman so he would not get run over by a car!

Our speed_limit in this example is 15mph (Line 29). Vehicles traveling less than this speed will not be logged. Vehicles exceeding this speed will be logged. If you need all speeds to be logged, you can set the value to 0.

The remaining configuration settings are for displaying frames to our screen, uploading files to the cloud (i.e., Dropbox), as well as output file paths:

Figure 4 shows an overhead view of how the project is laid out. In the case of Dave Hoffman’s house, the RPi and camera are sitting in his road-facing window. The measurement for the "distance" was taken at the side of the road on the far edges of the FOV lines for the camera. Points A, B, C, and D mark the columns in a frame. They should be equally spaced in your video frame (denoted by "speed_estimation_zone" pixel columns in the configuration).

Cars pass through the FOV in either direction while the MobileNet SSD object detector, combined with an object tracker, assists in grabbing timestamps at points ABCD (left-to-right) or DCBA (right-to-left).

Typically an object tracker works hand-in-hand with a less-efficient object detector. The object detector is responsible for localizing an object. The object tracker is responsible for keeping track of which object is which by assigning and maintaining identification numbers (IDs).

In order to track and calculate the speed of objects in a video stream, we need an easy way to store information regarding the object itself, including:

A dictionary of x-coordinate positions of the object. These positions reflect the actual position in which the timestamp was recorded so speed can accurately be calculated.

The calculated speed in MPH and KMPH. We calculate both and the user can choose which he/she prefers to use by a small modification to the driver script.

We will have multiple trackable objects — one for each car that is being tracked in the frame. Each object will have the attributes shown on Lines 8-29(detailed above)

Line 33 calculates the speedKMPH attribute as an average of the three estimatedSpeeds between the four points (passed as a parameter to the function).

The speed is converted and made available in the TrackableObject class as speedMPH or speedKMPH. We will display speeds in miles per hour. Minor changes to the script are required if you prefer to have the kilometers per hour logged and displayed — be sure to read the notes as you follow along in the tutorial.

Now that we understand the methodology for calculating speeds of vehicles and we have defined the CentroidTracker and TrackableObject classes, let’s work on our speed estimation driver script.

Using the Movidius NCS coprocessor (Line 52) ensures that our FPS is high enough for accurate speed calculations. In other words, if we have a lag between frame captures, our timestamps can become out of sync and lead to inaccurate speed readouts. If you prefer to use a laptop/desktop for processing (i.e. without OpenVINO and the Movidius NCS), be sure to delete Line 52.

Our speed will be based on the ABCD column points in our frame. Line 81 initializes a list of pairs of points for which speeds will be calculated. Given our four points, we can calculate the three estimated speeds and then average them.

Lines 122-124 initialize the frame dimensions and calculate meterPerPixel. The meters per pixel value helps to calculate our three estimated speeds among the four points.

Lines 134 initializes our new list of object trackers to update with accurate bounding box rectangles so that correlation tracking can do its job later.

Lines 148-159 filter the detection based on the "confidence" threshold and CLASSES type. We only look for the “car” class using our pretrained MobileNet SSD.

Columns B, C, and D use the same method to collect timestamps and positions with one exception. For column D, the lastPoint is marked as True. We’ll use this flag later to indicate that it is time to perform our speed formula calculations.

Lines 271-316 grab timestamps and positions for cars as they pass by columns D, C, B, and A (again, for right-to-left tracking). For A the lastPoint is marked as True.

When the trackable object’s (1) last point timestamp and position has been recorded, and (2) the speed has not yet been estimated (Line 322) we’ll proceed to estimate speeds.

Line 350 makes a call to the TrackableObject class method calculate_speed to average out our three estimatedSpeeds in both miles per hour and kilometers per hour (Equation 1.5).

At a minimum, every vehicle that exceeds the speed limit will be logged in the CSV file. Optionally Dropbox will be populated with images of the speeding vehicles.

Using a separate thread for a potentially time-consuming upload is critical so that our main thread isn’t blocked, impacting FPS and speed calculations. The filename will be the imageID on Line 383 so that it can easily be found later if it is associated in the log file.

I highly recommend that you conduct a handful of controlled drive-bys and tweak the variables in the config file until you are achieving accurate speed readings.

Ensure your camera has a clear line of sight with limited obstructions — our object detector must be able to detect a vehicle at multiple points as it crosses through the camera’s field of view (FOV).

It is best if your camera is positioned far from the road. The further points A and D are from each other at the point at which cars pass on the road, the better the distance / time calculations will average out and produce more accurate speed readings. If your camera is close to the road, a wide-angle lens is an option, but then you’ll need to perform camera calibration (a future PyImageSearch blog topic).

As shown in Figure 7and the video, our OpenCV system is measuring speeds of vehicles traveling in both directions. In the next section, we will perform drive-by tests to ensure our system is reporting accurate speeds.

Note: The video has been post-processed for demo purposes. Keep in mind that we do not know the vehicle speed until after the vehicle has passed through the frame. In the video, the speed of the vehicle is displayed while the vehicle is in the frame a better visualization.

Note: OpenCV cannot automatically throttle a video file framerate according to the true framerate. If you use speed_estimation_dl_video.py as well as the supplied cars.mp4 testing file, keep in mind that the speeds reported will be inaccurate. For accurate speeds, you must set up the full experiment with a camera and have real cars drive by. Refer to the next section, “Calibrating for Accuracy”, for a real live demo in which a screencast was recorded of the live system in action. To use the script, run this command: python speed_estimation_dl_video.py --conf config/config.json --input sample_data/cars.mp4

On occasions when multiple cars are passing through the frame at one given time, speeds will be reported inaccurately. This can occur when our centroid tracker mixes up centroids. This is a known drawback to our algorithm. To solve the issue additional algorithm engineering will need to be conducted by you as the reader. One suggestion would be to perform instance segmentation to accurate segment each vehicle.

You may find that the system produces slightly inaccurate readouts of the vehicle speeds going by. Do not disregard the project just yet. You can tweak the config file to get closer and closer to accurate readings.

Drive by the computer-vision-based VASCAR system in both directions at predetermined speeds. We chose 10mph, 15mph, 20mph, and 25mph to compare our speed to the VASCAR calculated speed. Your neighbors might think you’re weird as you drive back and forth past your house, but just give them a nice smile!

With a calibrated system, you’re now ready to let it run for a full day. Your system is likely only configured for daytime use unless you have streetlights on your road.

In the police world, this is known as Vehicle Average Speed Computer and Recorder (VASCAR). Police rely on their eyesight and button-pushing reaction time to collect timestamps — a method that barely holds in court in comparison to RADAR and LIDAR.

But of course, we are engineers so our system seeks to eliminate the human error component when calculating vehicle speeds automatically with computer vision.

To combat this, we measured carefully and then conducted drive-bys while looking at our speedometer to verify operation. Adjustments to the distance constant were made if needed.

Yes, there is a human component in this verification method. If you have a cop friend that can help you verify with their RADAR gun, that would be even better. Perhaps they will even ask for your data to provide to the city to encourage them to place speed bumps, stop signs, or traffic signals in your area!

Awesome app! My speedo broke on my truck during a long trip and i was able to set my phone on my dash with DigiHUD open to get me where i was going at the correct speeds. I had a few instances where the speed displayed was incorrect; bouncing between way too fast and too slow while driving around some curves in the mountains. After a few seconds, it was able to correct itself and display the correct speed again. Most likely the result of a poor GPS signal in those areas. Thanks for making this!

While driving, safety is the major concern that we often ignore when in hurry by speeding up our vehicle. To keep a tap on that Google has rolled out a new feature on Google Maps that will alert the driver instantly if she/he is over speeding. The feature launched on its Android version in 40 countries is called Speedometer and can be accessed on the “Settings” menu of Google Maps. It needs to be turned on manually. The feature has been launched after testing speed limit feature which was rolled out by Google some time back.

For the purpose, Google utilizes service of speed camera deployed on roads to check vehicle speed limit. When the speedometer is turned on, the speed will be visible on the mobile screen which will let the person driving know if he or she is driving fast by changing colors alerting if the person is breaking traffic rules. This will also be helpful in avoiding traffic and fines.

To get speed limit alerts and See how fast a person is driving and know when he or she reaches the speed limit one can simply turn Speedometer in following steps

However, on its support page, Google has advised that its speed limits functionality is provided for “informational purposes only” and given how unreliable GPS or internet speed can be.

Apart from the speedometer feature, Google Maps has also launched new navigation features which will not only warn users about natural disaster along their route but will also alter their route avoid. This new feature is an expansion to their existing SOS alerts feature, which provides the basic information related to a natural disaster like what is happening, emergency helpline numbers and Twitter updates from local authorities, etc.

At Roadside Technologies Ltd we offer a range of products for either hire or sale. This can aid and assist community speed watch groups in reducing vehicle speeds in residential areas. By installing a pole mounted Vehicle Activated Sign (VAS) or Speed Indication Sign (SID), it has a proven positive effect on slowing traffic down entering entrances to villages. All items are simple to use and can allow users with no previous experience equipment to monitor, measure and enforce any speed limit using similar products to what the police and councils use. We have worked with numerous CSW groups across the UK to provide traffic surveys to highlight areas of concern. Data captured in an industry standard format can then be passed on to Local Authorities for action. Take a look at our most popular options below which are all available for either hire or sale.

Our PR-1000 Speed Radar Gun is a compact, digital, simple point and shoot unit which is operational within 5 seconds of powering up. Available for either hire or sale, the user simply points the speed radar gun at traffic and the speed will show up on the LCD display fitted on the rear of the PR-1000 for the user to read. The PR-1000 will measure approaching vehicle speeds of 7-325mph at up to 400ft away from the user, making it one of the safest models available and the most popular choice for monitoring roadside speeds with community speed watch groups. The PR-1000 is ideally suited due to it"s low price point and simplicity of use. It has a recall button to show the previous 10 speed captured for data recording purposes.

The VAS-300 range is a cost-effective Vehicle Activated Sign/ Speed Indication Sign for improving road and site safety and reducing vehicle speeds on entrances to villages. Proven as an effective method to reduce traffic speeds, the VAS-300 will continually track an approaching vehicle from up to 100m away. The VAS-300 simply bolts on to a lamppost or similar object and measures and displays the approaching vehicle’s speed. Housed within the Vehicle Activated Sign is a maintenance free battery meaning it doesn’t need mains power to be operational. All units can either be powered using an existing mains supply or we can offer a solar-powered version which can keep the unit operational continuously throughout the year. The VAS-300 range has one of the most in-depth data recording facilities on the market, with the ability to covertly collect passing vehicle data, it is a very popular choice.

The SDB-18 Vehicle Activated Sign will continually track, measure and display the approaching vehicle"s speed form up to 100m away. The SDB-18 is a light weight portable Vehicle Activated Sign (VAS)/ Speed Indication Sign (SID) that can be pushed in to location by a single person. Housed within the framed work is a high intensity 12" LED Display which continually tracks and displays the approaching vehicle"s speed. Should the approaching vehicle break the speed limit, a SLOW DOWN module will illuminate to remind the driver, all the while the passing vehicle data is being covertly recorded for download at a later date. The SDB-18 collects data including the fastest and worst offenders complete with a time and date stamp. Housed within the lower part of the SDB-18 Speed Indicator Sign is a battery and solar panel which will reliably power the unit all year round without ever needing mains recharging.

The Speed Spy is a road traffic vehicle data recorder designed to covertly monitor and measure traffic flow on the highways. It simply mounts to a post or similar street furniture and measures vehicle data to show traffic flow, average speeds, 85th percentile and also the worst offending vehicles including time and date stamp.

The Speed Sentinel is the ultimate in monitoring device for measuring and recording vehicle speeds through a village. The ANPR device is fitted with a Tatille ANPR camera, once a vehicle is measured over the user selected speed limit, a picture will be taken and stored locally on the trailer or streamed over the internet to a secure file for the user to process and review. The images can then be passed to the police for review and further action. The ANPR Speed Sentinel doesn’t have H.O.T.A (Home Office Type Approval) and can"t be used as evidence. Housed within the trailer are batteries and a solar panel system to keep the trailered powered for 3-4* days.