Ir range finder

[Wragie]

Have been working on a IR range finder with a twist. It is on a object moving at fairly high speed ~150m/sec and is used to trigger a airbag about 2-3 meters before impact. Due to the speed and where this needs to work I can't use the usual sharp ir range finder (way too slow) but have had to use a paired 500mw ir emitter and a filtered ir sensor in the 950nm ir range. Filter is setup to filter out daylight/sun or lights (60hz/50hz). The problem I have been having is that I'm not sure which mcu really will work for this. My experience is mainly 8051 and some of the smaller pics but I'm not sure if any of those are fast enough to do the range calculations at that speed. In theory a 8 or 10 bit a/d reading gives me a usable accuracy for this. I'm debating if the correct way to do this is an series of accurate readings at the longer ranges of the sensors (in theory about 25m) and then used a timed offset or try to do this as a threshold ie constantly watching the range reading until it looks correct.

Thats the basics of the project. It is  a one time use thing so it has to be cheap but it has to be as accurate as possible. I haven't had to do any assembler in a while but I can't see it working without doing it that. Because it is cheap I'd also like to eliminate anything like a external crystal and so on to save on the cost. So what I'm curious is anyone has any good suggestions for a mcu and language that might make this work.

TNX!

W

[overl0ad3r]

Have been working on a IR range finder with a twist. It is on a object moving at fairly high speed ~150m/sec and is used to trigger a airbag about 2-3 meters before impact. Due to the speed and where this needs to work I can't use the usual sharp ir range finder (way too slow) but have had to use a paired 500mw ir emitter and a filtered ir sensor in the 950nm ir range. Filter is setup to filter out daylight/sun or lights (60hz/50hz). The problem I have been having is that I'm not sure which mcu really will work for this. My experience is mainly 8051 and some of the smaller pics but I'm not sure if any of those are fast enough to do the range calculations at that speed. In theory a 8 or 10 bit a/d reading gives me a usable accuracy for this. I'm debating if the correct way to do this is an series of accurate readings at the longer ranges of the sensors (in theory about 25m) and then used a timed offset or try to do this as a threshold ie constantly watching the range reading until it looks correct.

Thats the basics of the project. It is  a one time use thing so it has to be cheap but it has to be as accurate as possible. I haven't had to do any assembler in a while but I can't see it working without doing it that. Because it is cheap I'd also like to eliminate anything like a external crystal and so on to save on the cost. So what I'm curious is anyone has any good suggestions for a mcu and language that might make this work.

TNX!

W

Hello Wragie,

I recommend using one of the PIC18F MCUs from Microchip, and programming in C language (Microchip C18 Compiler), they're cheap and very good.
Many of them have internal oscillators of up to 16 MHz, not needing an external crystal.

You can use the Microchip Product Selector Tool to find which one is the best for your case (if you need UART/I2C/SPI, internal EEPROM, etc)
http://www.microchip.com/productselector/MCUProductSelector.html

[dbcv]

I think you can find some useful circuit related sensor at http://www.explorecircuits.com/cir_m_n_i_sensors.htm

[solutions]

You have about a nanosecond or three to do all this. That's 300MHz to 1GHz if you use a counter.

Save yourself a lot of headaches - use a fast FPGA or CPLD. 

CPU is TOO SLOW to give you distances you need, let alone consistent results. A 16 MHz counter can only resolve +/- 60 ns or about +/-10m. Writing in C only makes the realtime problem WORSE. Accuracy? Forget it.

IR may not be a good choice.  Any "glint" of daylight, or a strong IR source might trigger the airbag.

What is this "object" and what kind of mass does it have?

[oldvan]

Could this be simplified and cost lowered by using a photobeam broken by the
object at the correct trigger distance?

[bobcat1]

Hi

As far as i remember elektor use to have a circuit diagram in one of the summer issue for measuring speed using IR and FPGA or CPLD - don't remember  the issue year or number

All the best

Bobi

[Elmer]

To avoid the complexity of an FPGA, you could use a time-to-digital converter from ACAM, accompanied by a microcontroller. For tight timing from a microcontroller, you could go with a dsPIC33 which has a 16-bit hardware MAC and is an easy step up from smaller PICs. An ARM Cortex-M4 would double both the clock speed and the bitwidth of your MAC compared to the dsPIC33. I can't really see what you would need too much math for thou, especially considering latency as a priority. You don't need to convert time to meters in order to react, just set your threshold as time instead of meters...

[Alienbeing]

Just curious as to why you need to trigger 3 meters before impact? Airbags are designed to be deployed at the moment of impact. Usually triggered by a accelerometer at 5 g's. I know this because I worked at a vehicle crash facility for 15 years. Also if you are running the crash indoors and using high speed video at 1000 frames/sec you will need very bright lighting. We would use 100 or more 1000 watt halogen lamps which give off quite abit of IR. This would probably flood any IR sensor and make it useless. Same goes for out doors as the sun is an emitter of IR itself. You can block visable light with a filter but that wouldn't make any difference because the sensor is most sensitive to IR and adding a filter would still pass the IR from the sun. Again use an accelerometer to trigger an airbag. It is the way it's been done for many years and has proven to be a very reliable method.

Alienbeing 

[SpaleKG]

Or if you want to measure distance between vehicle and some object, use ultrasonic or radar sensors and then calculate speed with distance. I suppose that you want to open airbag before impact (that mean accelerometers in airbags will not detect impact but you will activate them).

[Elmer]

Or if you want to measure distance between vehicle and some object, use ultrasonic or radar sensors and then calculate speed with distance. I suppose that you want to open airbag before impact (that mean accelerometers in airbags will not detect impact but you will activate them).

As I see it, opening the airbag before impact holds some really problematic aspects in safety. I concur with Alien that accelerometers are proven for this job, and the reaction causing the airbag to inflate is oh-so fast you don't have to start inflating it before you crash.

(yeah, and oh-hey; seems I missed the "quote" button by a millimeter and gave you a thank you, but I'm sure it's well deserved )

[solutions]

If the object is moving at 150m/s, let's say constant speed, then your accelerometers read zero until impact.  THEN you propose to inflate the bag to protect the object.  Assume a bag with a radius of 0.5M and that it opens in 50mS. What's the acceleration of the object you are trying to "gently" slow down at impact? Two values: one at impact, the other at airbag deploy?

Think Mars lander, not dummy in a car, which I think is the context of this problem.

[Elmer]

I don't think most airbags have mach 0.5 as a design target. I would consider a rocket propelled ejection seat instead of airbag and yes, probably a distance sensor rather than an accelerometer for deployment.

[solutions]

As usual, the framer of the problem looks like he was being coy and didn't reveal his real intentions.

I spent a couple of minutes researching airbags and found this (my 10m/s guess was a wee bit on the low side) "airbags deploy at velocities of 50 to 150  m/s " www-nrd.nhtsa.dot.gov/pdf/Esv/esv16/98S9O15.PDF

sooooooooooo....object moves at 150m/s (no coincidence IMO), airbag pops at 150m/s, drops a payload object "behind it" like you were standing there.

Except, of course, this Wile E. Coyote contraption completely ignores Newton's laws if my speculation of intentions is correct, but we all know the Laws don't apply to Wile E. Coyote unless he looks down.

[Elmer]

I'm not following. Are we talking of using the airbag as a deployment ejector for a payload that is supposed to come to a halt right before impact?

EDIT: My apologies, I re-read post #1 and see 150m/s is indeed the target velocity. That number slipped off my teflon brain membrane for some reason, probably long-term exposure to solder fumes.

[solutions]

That's what it looks like to me.

Probably one of those not nice applications that kills people, which I wish people would disclose before asking for help...if that's the case.

[Wragie]

Interesting as I hadn't received any updates as to any responses since originally posting.

As per my original post it is exactly as I disclosed. The airbag soft deploys a sensor to the side of any impact disturbance. The optimal height is actually about 1 meter above the surface with slightly higher being better. These are deploying one shot surface snow sensors. The ir in the correct wave length perfectly reflects from fresh snow etc. Other types of sensors do not work for this application plain and simple. If you use the proper ir sensor it easily filters out both sunlight and man made interference. It also reflects strongly off of the high albedo of fresh snow surface. In some places were are talking about 3 meters of fresh powder that these have to be on top of not buried in at the end of deployment.

What I needed to know at the time of op is still in question. I am familiar with microchip and somewhat with Motorola mcu's. I can do this with logic but I'd rather have the flexibility from a mcu.

And no this would not kill you unless you try to catch it in your teeth, in a closed off area, with several feet of fresh snow, on a mountain, in the middle of nowhere, at 40 below, at 5am, .....  Fancy a nice safe game of lawn darts???

[CocaCola]

Based on

"It is  a one time use thing so it has to be cheap but it has to be as accurate as possible."

keep it simple and go with a mechanical detection switch or array...