Go Back   AnandTech Forums > Hardware and Technology > Highly Technical

Forums
· Hardware and Technology
· CPUs and Overclocking
· Motherboards
· Video Cards and Graphics
· Memory and Storage
· Power Supplies
· Cases & Cooling
· SFF, Notebooks, Pre-Built/Barebones PCs
· Networking
· Peripherals
· General Hardware
· Highly Technical
· Computer Help
· Home Theater PCs
· Consumer Electronics
· Digital and Video Cameras
· Mobile Devices & Gadgets
· Audio/Video & Home Theater
· Software
· Software for Windows
· All Things Apple
· *nix Software
· Operating Systems
· Programming
· PC Gaming
· Console Gaming
· Distributed Computing
· Security
· Social
· Off Topic
· Politics and News
· Discussion Club
· Love and Relationships
· The Garage
· Health and Fitness
· Home and Garden
· Merchandise and Shopping
· For Sale/Trade
· Hot Deals with Free Stuff/Contests
· Black Friday 2014
· Forum Issues
· Technical Forum Issues
· Personal Forum Issues
· Suggestion Box
· Moderator Resources
· Moderator Discussions
   

Reply
 
Thread Tools
Old 11-28-2012, 07:12 PM   #26
Modelworks
Lifer
 
Modelworks's Avatar
 
Join Date: Feb 2007
Location: North Carolina
Posts: 16,237
Default

Vision sensors are the reason I haven't posted much in a while. I can tell you some of what I have learned in the past couple months. Machine vision is a really interesting field and open to a lot of methods to solve the problems, funding is also very very good in this area, hint: DARPA.

If you want to do human vision level of sensors you need to read some books on how the eye brain interaction works, the brain takes shortcuts that you can use when designing machine vision.

FPGA. There is no way around it. The information has to be processed in real time and FPGA are the easiest way to do it. You would need a 100 core cpu to do vision as well as 1 FPGA and a 1 core cpu. It isn't speed that is the issue, it is that the information from many different paths has to be present before the cpu can even begin to decode the information and FPGA excel at joining multiple sources into one. If you try to shift in information pixel by pixel for the cpu to analyze it becomes very hard to scale further because you soon reach processing limits that the FPGA can solve easily by 'chewing up the bits' so the cpu can better process the data.

If you can , get a copy of this book, sort of the bible of image processing.
http://www.amazon.com/Image-Processi...ssing+handbook
Modelworks is offline   Reply With Quote
Old 11-28-2012, 08:11 PM   #27
PandaBear
Golden Member
 
Join Date: Aug 2000
Location: Sunnyvale, CA
Posts: 1,360
Default

Do you have any more additional requirement throwing out here? I didn't know money is so tight that a mere $800 sensor would be a problem, let alone 4 of these $800 to cover 2 dimensional measurement of the object.

Also how much space do you have to install these sensor? I think if you have flexibility a simple 2 vertical sensor far enough to catch both the front and the rear of the smallest vehicle of interest (something you already have), and 2 horizontal sensor far enough for the same to measure both the width and height of an object (to exclude non interesting object like a shopping cart, animal, human, etc), should be able to get you started quickly.

IMO the key is still trying NOT to rely on reflectivity of any kind (i.e. have a sender on one end and a receiver on the other end) at least on one pair of the sensors, if you must do an overhead light curtain that is relying on reflectivity, at least do one break the beam type to verify any reading to eliminate false positive. From my experience you just cannot trust reflectivity if you are expecting random shape object (cars) and environmental condition (water, ice, etc).

This is regardless of whether you use radar, ultra sound, laser, light bulb, infra red, and what not.
__________________
(\__/)
(='.'=)
(")_(")

Happy with M since 2001

My Heat
PandaBear is offline   Reply With Quote
Old 11-28-2012, 08:18 PM   #28
PandaBear
Golden Member
 
Join Date: Aug 2000
Location: Sunnyvale, CA
Posts: 1,360
Default

Quote:
Originally Posted by Modelworks View Post
Vision sensors are the reason I haven't posted much in a while. I can tell you some of what I have learned in the past couple months. Machine vision is a really interesting field and open to a lot of methods to solve the problems, funding is also very very good in this area, hint: DARPA.

If you want to do human vision level of sensors you need to read some books on how the eye brain interaction works, the brain takes shortcuts that you can use when designing machine vision.

FPGA. There is no way around it. The information has to be processed in real time and FPGA are the easiest way to do it. You would need a 100 core cpu to do vision as well as 1 FPGA and a 1 core cpu. It isn't speed that is the issue, it is that the information from many different paths has to be present before the cpu can even begin to decode the information and FPGA excel at joining multiple sources into one. If you try to shift in information pixel by pixel for the cpu to analyze it becomes very hard to scale further because you soon reach processing limits that the FPGA can solve easily by 'chewing up the bits' so the cpu can better process the data.

If you can , get a copy of this book, sort of the bible of image processing.
http://www.amazon.com/Image-Processi...ssing+handbook
You totally can do it with a DSP or other high performance processor. The algorithm design and tuning is the key. The implementation of the hardware and software, not as much. It is like saying you need to build a suspension bridge before you evaluate all the options (i.e. non suspension bridge, tunnel, ferries, or a road around the crossing) available.

Also IMO detecting whether there is a vehicle presence is a job that can be done much simpler than needing optical cameras and image processing. We are not trying to scan for criminal or terrorist here, we are just counting cars.
__________________
(\__/)
(='.'=)
(")_(")

Happy with M since 2001

My Heat
PandaBear is offline   Reply With Quote
Old 11-30-2012, 12:30 AM   #29
Jeff7
Lifer
 
Jeff7's Avatar
 
Join Date: Jan 2001
Posts: 39,050
Default

Quote:
Originally Posted by wirednuts View Post
i was under the impression the monitoring would only take place during certain hours, and the locations would change regularly (im thinking like youre a parking lot money collector or something?). im getting the hint now that this is 24/7 permanent installations?
The traffic occurs differently in different locations. Some places, there's a surge of traffic in the morning, then it's quiet until either lunch, or until quitting time.
Others, it's continuous throughout the day, such as at a multi-level parking garage for a Home Depot or a mall or something like that, so the system must be running continuously. So yes, this system needs to be designed to be running 24/7.


Quote:
Originally Posted by PandaBear View Post
Do you have any more additional requirement throwing out here? I didn't know money is so tight that a mere $800 sensor would be a problem, let alone 4 of these $800 to cover 2 dimensional measurement of the object.
There's the usual stuff though - our own costs, and then we also want to make a profit when selling the equipment.
Some installations don't want to throw much money at this sort of thing.


Quote:
Also how much space do you have to install these sensor? I think if you have flexibility a simple 2 vertical sensor far enough to catch both the front and the rear of the smallest vehicle of interest (something you already have), and 2 horizontal sensor far enough for the same to measure both the width and height of an object (to exclude non interesting object like a shopping cart, animal, human, etc), should be able to get you started quickly.
Some parking garages have low ceilings. I've seen as low as 5'10". And other facilities have ceilings that are 14' high.



Quote:
IMO the key is still trying NOT to rely on reflectivity of any kind (i.e. have a sender on one end and a receiver on the other end) at least on one pair of the sensors, if you must do an overhead light curtain that is relying on reflectivity, at least do one break the beam type to verify any reading to eliminate false positive. From my experience you just cannot trust reflectivity if you are expecting random shape object (cars) and environmental condition (water, ice, etc).

This is regardless of whether you use radar, ultra sound, laser, light bulb, infra red, and what not.
Some places can't use a receiver on the other end, if it's being fired sideways. Example....and without a top-notch MS-Paint diagram, this might be tough to describe. I'll try to add something tomorrow.
In some garages, one component could be mounted to a post by lanes of travel. Two problems then: 1) There are likely to be two lanes of travel present. 2) On the opposite side of the lanes of travel are more parking spaces, so there isn't anywhere to mount a receiver module where it would consistently get a good view.
And of course, ground-mounting an electronic device would be a problem. (Dirt, crushing weight, etc.)

Radar: There are sensors available that can be set to ignore anything beyond a certain set distance. So I could flip a switch on it, and it will ignore anything more than 4 meters from the sensor. But, this sort of sensor is good for motion, but many of them have problems with continuous presence detection of an object that stops in the field of vision.

But yes, you're dead on about the reflectivity issue. It's just so unpredictable that it can result in either missing the targets, or else false trips.



Quote:
Originally Posted by Modelworks View Post
Vision sensors are the reason I haven't posted much in a while. I can tell you some of what I have learned in the past couple months. Machine vision is a really interesting field and open to a lot of methods to solve the problems, funding is also very very good in this area, hint: DARPA.

If you want to do human vision level of sensors you need to read some books on how the eye brain interaction works, the brain takes shortcuts that you can use when designing machine vision.

FPGA. There is no way around it. The information has to be processed in real time and FPGA are the easiest way to do it. You would need a 100 core cpu to do vision as well as 1 FPGA and a 1 core cpu. It isn't speed that is the issue, it is that the information from many different paths has to be present before the cpu can even begin to decode the information and FPGA excel at joining multiple sources into one. If you try to shift in information pixel by pixel for the cpu to analyze it becomes very hard to scale further because you soon reach processing limits that the FPGA can solve easily by 'chewing up the bits' so the cpu can better process the data.

If you can , get a copy of this book, sort of the bible of image processing.
http://www.amazon.com/Image-Processi...ssing+handbook
FPGA: I have heard of them, and I know that they're quite flexible and capable. That's about as far as it's gone though. We looked at using them for embedded applications at work, but they're massive overkill for most of what we do. For the most part, a 28-pin PIC chip gets the job done. You know, super-high-tech stuff.

Thank you for the link though. Maybe some day it will indeed come in handy.



Quote:
Originally Posted by PandaBear View Post
You totally can do it with a DSP or other high performance processor. The algorithm design and tuning is the key. The implementation of the hardware and software, not as much. It is like saying you need to build a suspension bridge before you evaluate all the options (i.e. non suspension bridge, tunnel, ferries, or a road around the crossing) available.

Also IMO detecting whether there is a vehicle presence is a job that can be done much simpler than needing optical cameras and image processing. We are not trying to scan for criminal or terrorist here, we are just counting cars.
Yeah, you'd think so. We just haven't been able to find the ideal/perfect solution yet.

Thus far, doing it with the infrared light curtains has given pretty good results in most applications. But some of the really busy garages, with lots of pedestrian traffic especially, have proven to be challenging, particularly when the owners want 100% counting accuracy. The other issue is when people don't drive underneath the sensors - so lane delineation is needed to help funnel traffic to where it can be counted. In some garages, lane delineators, such as flexible posts, can get destroyed in a matter of weeks, which adds maintenance overhead.
I think the only option for 100% accuracy is single-space-detection, with a sensor in every parking location. The goal here is to deliver excellent accuracy without the need to undertake that kind of installation, and to also cut down on maintenance requirements.
__________________
.
"Homeopathy is what happened when snake oil salesmen discovered that water is cheaper than snake oil."

Last edited by Jeff7; 01-16-2014 at 12:29 PM.
Jeff7 is offline   Reply With Quote
Old 11-30-2012, 03:01 AM   #30
videogames101
Diamond Member
 
videogames101's Avatar
 
Join Date: Aug 2005
Location: 52375
Posts: 6,204
Default

Is there a reason you can't use a ground based sensor that trips from the vehicle's weight?

I mean, there's probably a reason you can't, or you'd have probably done it that way. ><

Well, here goes my simplistic solution:

In my head the image processing "idea" for finding a vehicle event doesn't seem that difficult, using one camera and some compute. Given that the size of a vehicle is fairly large compared to the size of a pedestrian, you could compare each frame of the video feed to a frame, from say 1 second ago, and find the number of pixels that have changed significantly between those frames. Any time you could more than X pixels that have changed significantly, you can register the vehicle event.

I have no idea how accurate it might be though.
__________________
3570K
HD7870 (Tahiti LE)
videogames101 is offline   Reply With Quote
Old 11-30-2012, 08:23 AM   #31
Modelworks
Lifer
 
Modelworks's Avatar
 
Join Date: Feb 2007
Location: North Carolina
Posts: 16,237
Default

Quote:
Originally Posted by PandaBear View Post
You totally can do it with a DSP or other high performance processor. The algorithm design and tuning is the key. The implementation of the hardware and software, not as much.

The problem isn't the speed of the processing, it is aggregating all the data so that the processor can begin working with the data. DSP are used after the FPGA . The FPGA doesn't make any determination on what the input data contains , people, places, things, that is for the DSP.
Modelworks is offline   Reply With Quote
Old 11-30-2012, 09:01 AM   #32
Modelworks
Lifer
 
Modelworks's Avatar
 
Join Date: Feb 2007
Location: North Carolina
Posts: 16,237
Default

Pressure activated sensor , tubing could be put on top of the road, like the bell that rings at gas stations. Tubing as small as 3/8" could be used to connect to pressure switches. The tubing might wear out over time but changing it out would be as simple as cutting another length of tubing and placing it over the road. Two sensors would give direction. Complexity is very low and a simple PIC or AVR micro could control the sensing. I bet you could build a prototype for under $20.

If the product is going to be used in harsh weather for months at a time I would go as low tech as possible.

Last edited by Modelworks; 11-30-2012 at 09:03 AM.
Modelworks is offline   Reply With Quote
Old 11-30-2012, 02:24 PM   #33
PandaBear
Golden Member
 
Join Date: Aug 2000
Location: Sunnyvale, CA
Posts: 1,360
Default

As Jeff7 said ground loop could have problem reading traffic up stair and down stair, and cutting ground loop into a concrete parking lot can be a bigger problem due to cost and building integrity.

Pressure sensor is the most reliable one if you don't mind replacing it once every few months / years. I've seen them back in Hong Kong with non stop traffic (probably tens of thousands of car a day at up to 80km/h) and they last for a couple months. For parking lot it may be durable enough to keep replacing it.

Another option I can think of if side way installation of sensor is not possible: an array of low tech overhead sensor that together can have enough resolution to detect an object of your size (car), yet still see stationary object. I'd agree with Jeff7 that a radar type of sensor would have problem in places with lots of traffic (cars behind each other and stop and go). An array of low tech sensor would work the best over a motion based sensor like radar also for cars not driving on the lane you expected (delineation).

Now regarding to the types of sensor, I'd say if you can get something that is induction / capacitance based it would be ideal, as large metal object would be easy to distinguish especially if most of them are steel and aluminum. You can put an array of them on a composite frame big enough to cover the lanes. I'm not familiar with large size capacitance sensor, and you may have other problem like magnetic field or AC interference if you want large enough clearance, but it would give you the best of reflective sensor (no need for opposite side receiver) and break the beam sensor (not affected by shape and surface reflectivity of the object).

Also: will people be pushing pallets of item through the path? If so will you need to worry about it?
__________________
(\__/)
(='.'=)
(")_(")

Happy with M since 2001

My Heat

Last edited by PandaBear; 11-30-2012 at 02:38 PM.
PandaBear is offline   Reply With Quote
Old 12-02-2012, 09:56 PM   #34
Pulsar
Diamond Member
 
Pulsar's Avatar
 
Join Date: Mar 2003
Posts: 3,539
Default

Quote:
Originally Posted by Modelworks View Post
The problem isn't the speed of the processing, it is aggregating all the data so that the processor can begin working with the data. DSP are used after the FPGA . The FPGA doesn't make any determination on what the input data contains , people, places, things, that is for the DSP.
What on earth are you talking about?

A mediocre laptop by today's standard running OpenCV can do 640x480 image processing on a scale of hundreds of frames per second.

I know this because we've written applications for targetting objects in OpenCV.

As someone else said - it's about the algorithm! Masking, color thresholding, etc all removes the load on the processor. Spotting a moving vehicle hardly needs 640x480 resolution either, especially if you have the luxury of place the camera close to the avenue of travel so the vehicle fills nearly the entire picture.
Pulsar is offline   Reply With Quote
Old 12-04-2012, 03:17 AM   #35
PandaBear
Golden Member
 
Join Date: Aug 2000
Location: Sunnyvale, CA
Posts: 1,360
Default

Quote:
Originally Posted by Pulsar View Post
What on earth are you talking about?

A mediocre laptop by today's standard running OpenCV can do 640x480 image processing on a scale of hundreds of frames per second.

I know this because we've written applications for targetting objects in OpenCV.

As someone else said - it's about the algorithm! Masking, color thresholding, etc all removes the load on the processor. Spotting a moving vehicle hardly needs 640x480 resolution either, especially if you have the luxury of place the camera close to the avenue of travel so the vehicle fills nearly the entire picture.
What he and others were saying is latency, and I agree with you, that if you use 320x240 resolution in B&W you can use a PC to do it let alone a real DSP or GPU.

The problem they have is they can't even find the right sensor yet. If they spend the same amount on signal processing of the analog input of the light curtain, induction loop, radar, or the combination of these, they'll find that processing these will be significantly easier to detect the car than using a vision camera.

The fact that they haven't even found out a way to disable the light curtain reboot on non moving object or water puddle means they haven't even get their existing sensor to the full potential yet. If they can't even get the sensor vendor to let them access raw value for their own internal processing, they won't know what to do with a camera (or 2) with an FPGA.

The key is they need to get raw value of any analog sensor (any sensor is analog reading based before processing) they use, and come up with an algorithm that can separate the target (car on the right floor) from the noise (animal, human, shopping cart, car up or down stair, water puddle).
__________________
(\__/)
(='.'=)
(")_(")

Happy with M since 2001

My Heat

Last edited by PandaBear; 12-04-2012 at 03:19 AM.
PandaBear is offline   Reply With Quote
Old 12-04-2012, 08:19 AM   #36
PsiStar
Golden Member
 
Join Date: Dec 2005
Location: Westport, CT
Posts: 1,180
Default

Quote:
Originally Posted by PandaBear View Post
What he and others were saying is latency, and I agree with you, that if you use 320x240 resolution in B&W you can use a PC to do it let alone a real DSP or GPU.

The problem they have is they can't even find the right sensor yet
.
.
.
I totally agree with that entire post.
PsiStar is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 05:55 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.