Shop OBEX P1 Docs P2 Docs Learn Events
Advice On Building a Automobile Detector — Parallax Forums

Advice On Building a Automobile Detector

SmcneeseSmcneese Posts: 5
edited 2013-03-23 09:41 in General Discussion
I am looking for advice from all the Parallax experts. I am working on a project that uses License Plate Recognition technology to inventory a parking lot. LPR systems typically trigger recognition via motion detection or an external trigger like a loop detector or IR beam when a car passes in front of the space being monitored. In our solution, we have the LPR camera mounted on a golf cart. Using motion detection is rendered useless since motion is 100% of the time while moving causing the system to try and scan for plates on every frame of video captured - very slow.

When writing the software I included the ability to snap a picture and process for a plate. This works and is very fast but on a parking lot with 1500 vehicles it becomes very tedious to press a button that many times for each patrol of the lot. I can also trigger this snapshot to occur from an external IO switch and that is where I need some advice.

When scanning, the vehicle license plates are between 4-6 feet from the LPR camera. Typical space between vehicles is 2-3 feet. I would like to build a device that can sense when the LPR camera is behind the vehicle versus between or out in the open away from vehicles. My thought was to use the Ping ultrasonic sensor with a propeller or basic stamp microcontroller. Using the distance measurement to trigger a relay to close the switch to trigger the snapshot.

I am a software developer by trade and an amature electronic hobbyist. I have never used microcontrollers but believe this would be a perfect solution for our problem. Can someone recommend which microcontroller would be a good fit and/or a development board I should use? Looking though some code examples for both microcontrollers, I feel that I should be able to figure out the programming. I am proficient in C/C++, C#, JAVA and Basic.

Sorry for the long explanation but I hope someone can point me in the right direction.

Steve

Comments

  • kwinnkwinn Posts: 8,697
    edited 2013-03-19 20:23
    I would suggest using the propeller. While the basic stamp may be up to the task there is no question about the prop being able to handle the task. The ping range spec is 3 meters so 6 feet should be possible. The major concerns would be external noise interfering with the ultrasonic detector and centering the camera FoV on the license plate. Since vehicles vary quite a bit in width and parking position in the allotted space is somewhat imprecise it may be difficult to center the plate. How much leeway is there in positioning the plate in the camera FoV.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2013-03-19 20:30
    Smcneese wrote: »
    ... I would like to build a device that can sense when the LPR camera is behind the vehicle versus between or out in the open away from vehicles. ....

    Hi Steve,

    I'm certainly no expert but maybe consider that many license plates are highly reflective. Perhaps you can direct a kind of infrared strobe that can pulse the area in front of your camera and have an IR sensor that is calibrated for license plate reflections. It probably won't work 100% but it might be worth a try. I don't know if your camera has some sort of autofocus (which might use IR), so you would have to test the system under various situations.
  • SmcneeseSmcneese Posts: 5
    edited 2013-03-19 20:37
    The LPR camera has a wide angle and at that distance gets the entire width of a parking slot. I just need a sensor that can detect a large object (car) within 3-4 feet from the camera. I can align the sensor and camera to ensure that when it triggers the camera has the back of vehicle in view. The LPR algorithm scans the entire image for the reflective plate and then uses OCR to read the letters/numbers.

    After looking further at the Ping, I'm not sure it is a good choice because of temperature variations during operation. Maybe the laser ranger finder would be a better choice?
  • NWCCTVNWCCTV Posts: 3,629
    edited 2013-03-19 22:23
    I think the Laser Range Finder might be a better option, especially outdoors. Also, what LPR camera are you using? The ones GeoVision sell have software with them that is pretty amazing, even when moving. You might also try speeding up your FPS and, if available, the Sample Rate, this might help keep you from having to snap a picture of every plate.
  • GadgetmanGadgetman Posts: 2,436
    edited 2013-03-20 01:32
    This may not help all that much, but the Norwegian equivalent of the DMV, the Norwegian Public Roads Administration, has a similar system in use already.
    It scans license plates, checks the numbers against central registers and flags them if there's one that needs attention, in real-time.
    From what I understand, the system uses 'brute force' to find the plates in the video feed.
    No PING, no laser rangefinders, and yeah, it handles traffic at 50mph...
  • skylightskylight Posts: 1,915
    edited 2013-03-20 06:01
    I'm not a fan of the technology, are many car drivers? Not sure where the OP resides but if the plates are white ,yellow or whatever you could take a light measurement of the reflection and use this measurement to trigger when a plate comes into view.

    Edit: Sorry ElectricAye you beat me to this.
  • SmcneeseSmcneese Posts: 5
    edited 2013-03-20 06:20
    We are using GeoVision LPR cameras and yes their software does very well with the actual recognition. Gadgetman, the issue is not with the LPR camera itself. When the camera is mounted in a fixed position like over a highway, the motion detection algorithms built into their software work great. The algorithms use the static, unchanging background to detect motion within the frame, snap a picture and then process for the plate. If the plate is found anywhere in the image, it usually finds it, zooms in on it and processes the characters. The problem is our camera is moving and the vehicles/plates and static - non moving. This makes a big difference on how the motion detection functions. It can not longer us a static background for reference to other motion within the frame, the entire background is moving in our case. This causes every frame of video to be passed to the LPR for recognition and therefore bogging down. Eventually, everything scanned gets processed but it takes minutes for all of the video to process for a run of about 50 feet of vehicles. If you manually snap a picture that includes the plate, it processes the plate and returns the results in .2 seconds. So, the issue is how to trigger the snapshot without having to do it manually (button or keyboard) since the motion detection is rendered useless in our scenario.

    The device I need to build does not need to find the license plate - it just needs to detect a large object within x feet of the camera.

    Steve
  • skylightskylight Posts: 1,915
    edited 2013-03-20 08:37
    Metal detector?
  • bill190bill190 Posts: 769
    edited 2013-03-20 09:07
    Something related and interesting so far as parking goes...

    At the new Portland, Oregon airport (PDX) parking garage, there is an electronic sensor above EVERY parking space. If all the spaces are taken, then that parking level will show full to people entering the parking garage - thus they can bypass that floor and continue to the next floor. Here is some info on that...

    http://www.portofportland.com/Environmental/Envrnmntl_PDXPrkng.htm
  • stamptrolstamptrol Posts: 1,731
    edited 2013-03-20 10:09
    Instead of using the PING directly for its distance measuring capability, use two of them to tell you when each of them sees an object about the same distance away. Each would be mounted with the camera, one on the left, one on the right. Perhaps separated by a couple of feet. Probably they would be "toe-ed in" a bit toward the center.

    The Stamp or other processor would constantly compare the distance readings and trigger when "something" was seen by both sensors as being about the same distance away, but closer than 10 feet. If one sensor was seeing the slot between cars, nothing would happen. If both sensors saw the same long distance, that's an empty space.

    Cheers,
  • kwinnkwinn Posts: 8,697
    edited 2013-03-20 20:04
    You would think detecting something the size of a car would be relatively simple, and under some conditions it is. However doing so from 4 - 6 feet away from a moving vehicle with the cars parked relatively close together is not so easy.

    Magnetic sensing as used in metal detectors is probably out due to the distance.
    Magnetic sensing of the metal mass of the cars may not work due to the proximity of the other vehicles.

    One of the following methods might work:

    Laser ranging is most likely to work.
    Measuring reflected IR intensity.
    Ultrasonic ranging if there is not too much ultrasonic background noise.
    Microwave ranging.
    Magnetic sensing of changes to the earth's field.

    One of the range measuring methods seems like the best bet. By placing the camera 2 - 3 feet in front or behind the sensor and triggering it after a sudden increase in range is followed by a sudden decrease the license plate should be well within the camera FOV.
  • frank freedmanfrank freedman Posts: 1,983
    edited 2013-03-20 21:46
    If the software can handle video from an external source, consider just driving through all the rows with a video camera and just post process it if the software can capture on a frame by pressing a button. Tape, go to office, load tape, play. Each time a license plate is in view, click and repeat...

    Just an offbeat idea to try.
  • SmcneeseSmcneese Posts: 5
    edited 2013-03-20 21:59
    I like the suggestion by stamptrol of using two sensors placed some distance apart and triggering when they both detect the object within set range. This is how it is done for triggering detection on a moving vehicle entering a lot. You setup two or beams about 5-6 feet apart and trigger when they are both broken. This keeps from triggering when someone walks through the beams because the break one at a time.

    I think the laser range finder is better than the ping))) since we are dealing with temperatures ranging from the teens to well over 110 degrees F. If I use propeller, can you recommend a board or kit to use that will interface with the laser ranger finder board easily? Can you also give me an idea how the recommended board could trigger a relay to close the switch on detection.

    I appreciate all the discussion on this. It has helped me greatly.

    Steve
  • skylightskylight Posts: 1,915
    edited 2013-03-21 02:23
    What if the cars parked over a sensor in each bay that turns on a laser centered in the bay at a decent height to be safe and the buggy looks for the laser and when it sees it triggers the camera to take the picture. If the buggy sensor faced only toward the car's laser then hopefully there would be no false triggering by other lasers or a sensor in the buggys track lets the buggy sensor know which laser to read through modulated signals

    Or a cheaper solution is to have a soft foam rod hinged so that it actuates a microswitch when it hits a car and then springs back when the car is passed.you may have to drive closer to the cars for this to work (as long as the buggy driver doesn't drink alcohol you should be ok)
  • Heater.Heater. Posts: 21,230
    edited 2013-03-21 02:30
    Perhaps you need a radar. How about one of these: http://www.isee.biz/products/igep-radar-technology comes with a very capable credit card sized ARM processor board running Linux to do some processing on the reflections.
  • skylightskylight Posts: 1,915
    edited 2013-03-21 02:44
    what if the camera took a picture at each bay regardless of whether a vehicle was parked or not, the software would ignore the pictures without plates
    you could have a reflective disc placed at each bay that you drive over (or on a ceiling if exists) and the buggy reads the disc and triggers the camera

    Or if you want it only to take a pic when a car is parked in the bay, have the cars weight hinge the reflective disc into view of the buggy sensor ( might not work with trikes and three wheeled cars or drivers that park badly :smile:)
  • stamptrolstamptrol Posts: 1,731
    edited 2013-03-21 07:33
    Another technique would be to have a single distance sensor (ping, laser, IR) be mounted so it "leads" the camers by about 4 feet (about half the width of the parking slot) . As the survey buggy drives by, the sensor will generate a "rising edge" as it encounters the edge of the vehicle. The signal stays high until it drops when the sensor goes past the other side of the vehicle. At this point the camers is dead center on th ecar and the loss of the sensing triggers the camera.

    Cheers,
  • SmcneeseSmcneese Posts: 5
    edited 2013-03-21 19:48
    Thanks everyone for your thoughts and ideas. After thinking more about the problem I was able to solve the issue. It would have been fun to build this type of sensor but it turns out it was not needed. As I mentioned, the root of the problem was that I had full motion all the time causing the LPR engine to become over burdened trying to process the plates for EVERY frame of video taken. So, I thought if we are getting too much video and can't control that by limiting motion, limit the number of frames of video. I was able to configure the LPR camera to capture at 3 frames per second instead of 30 FPS. Even with constant motion, the system can handle the fewer frames of video and is very responsive. FYI
  • NWCCTVNWCCTV Posts: 3,629
    edited 2013-03-21 19:56
    I had mentioned speeding up the FPS in Post #5 but my thinking of your issue was flip flopped so yes, slowing the PS is a good solution.
  • skylightskylight Posts: 1,915
    edited 2013-03-23 09:41
    Good that you solved the problem, was going to suggest looking at Phil's project with IRED's here http://forums.parallax.com/showthread.php/146879-One-sensor-to-discriminate-Walsh-modulated-IREDs?p=1171544&viewfull=1#post1171544
Sign In or Register to comment.