Pages: [1]   Go Down
Author Topic: aa  (Read 1928 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 2
View Profile
aa
 Bigger Bigger  Smaller Smaller  Reset Reset

tres
« Last Edit: August 06, 2014, 07:41:30 am by palavro » Logged

Global Moderator
Netherlands
Online Online
Shannon Member
*****
Karma: 227
Posts: 14051
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Most cars tend to reflect a lot of light because they often got a lot of glass, chrome, and other reflecting parts on them.
Is that going to be a problem for the sensor? If so, is there a way to cope with it?
No, I expect not.

Quote
And a more general concern: How well do IR sensors work in bright daylight situations? (The sensor will obviously be mounted horizontally)
As long as you do not get direct sunlight in the sensor I expect they work well.

Quote
The distance will be in the range between 10 and 150cm.
HOw fast will the cars pass?
How many samples do you want to take of the passage?
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The Arduino is very fast. It could probably sample 100 times a second without breaking a sweat.

I'm not sure how IR can be used to determine distance though? I guess you could strobe an IR emitter and measure the strength of the reflected IR, but that would only work for surfaces that uniformly reflect IR, which cars definitely aren't. IR is well suited to detecting if something is/isn't there, rather than how far away it is. It seems like an ultrasonic ping sensor would work better for measuring distance?

For logging, you could log to the built-in internal EEPROM but you only have room to store 1024 samples. If you store only one sample per car, only 1,024 cars could pass you before you run out of room. Plus you have to take your device off the bike and bring it to a PC (or bring a laptop out to the bike) to download the results. I suggest an SD card instead -- more room, easier to download.
Logged

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The sensor I had in mind is the Sharp GP 2 Y0A 02 YK. Actually I'm not sure if it is IR, it only says "optical". This will not work on the surface of a car?
Ah, the datasheet says it works based on triangulation. So, it would not work on a mirror placed at an angle to the sensor, because the light would be sent off some other direction. But for shooting a car with the sensor aimed perpendicular to it, I would think it would work (though some error may be introduced by curved body panels).

Neat sensor!
Logged

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I see. Well, even if there's no formula to describe the curve, you can always do what the automotive engineers do -- make a map. You can test the unit under static conditions at, say, 1cm intervals between 0 and 150cm, and record each analog voltage at each distance (divide by 4 to convert the 10-bit number into a more easily manageble 8-bit byte).

Now out in the field, you can use the map to decide what distance a sampled voltage equates to.

Code:
const byte distanceMap[150] = { 12, 16, 18, 25, 39, 54, 67 } //etc
loop()
{
byte sample = analogRead() / 4;
byte i;
for(i = 0; sample < distanceMap[i]; i++); // semicolon ; here deliberately -- empty loop
byte distance = i;
}

An array of bytes, 150 bytes long, will easily fit on an Arduino.
« Last Edit: August 24, 2013, 10:00:34 pm by tylernt » Logged

Global Moderator
Netherlands
Online Online
Shannon Member
*****
Karma: 227
Posts: 14051
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

+1 for the map solution
if you want to use less bytes for the array you can use MultiMap - http://playground.arduino.cc/Main/MultiMap -

Note 1: the linear search misses a stop criteria for end of the array.
Code:
for(i = 0; i<150 && sample < distanceMap[i]; i++); // semicolon ; here deliberately -- empty loop
Note 2: with 150 elements a linear search takes on average 75 compares, a binary search would need 9 compares (in theory, in practice about 25).
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for the code, it already scares me.
The Arduino programming IDE makes things easier, but, you'll still need some programming skills. We (probably) won't write your program for you, but we can sure help. smiley

Quote
RTC (i2c, says ds1307 based)
If your budget can support it, consider the DS3231 as it uses the same software library but is more accurate.

Quote
is there any drawback picking a Nano/Mini/Micro over a bigger board?
Well the Nano has USB on board, so it's plug'n'play for programming it. The Mini/Micro, on the other hand, requires a USB-serial adapter to program it. Since you're probably not going to need to program it after you finish debugging, this is probably not a big issue. But selecting a 3.3V board (i.e., not the Nano) is ideal as it makes talking to the SD card easier.

Quote
If my choice of hardware is complicating the coding than I'd rather swallow the bitter pill of getting an Uno or the like in a case outside teh bike.
No problem, using a Mini or Micro will not change your code BUT the SD card library is rather big (13KB!) so you will want to make sure you get a 32KB (Atmega328P) Mini/Micro and not the 16KB version.
Logged

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Note 1: the linear search misses a stop criteria for end of the array.
Code:
for(i = 0; i<150 && sample < distanceMap[i]; i++); // semicolon ; here deliberately -- empty loop
Thanks for catching my bug.

Quote
Note 2: with 150 elements a linear search takes on average 75 compares, a binary search would need 9 compares
I don't think speed is an issue here, as the Arduino will spend most of it's time waiting for that 39ms sensor readout and even 150 compares is going to take way less than 1ms.
Logged

Global Moderator
Netherlands
Online Online
Shannon Member
*****
Karma: 227
Posts: 14051
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I don't think speed is an issue here, as the Arduino will spend most of it's time waiting for that 39ms sensor readout and even 150 compares is going to take way less than 1ms.
Think you are right smiley-wink   In practice binary search is complexer than linear search. It has (in practice) about 2x the number of compares.

Furthermore there are other tactics than binary search, that might even be better.
- most of the time the distance is large so starting at the end of the array might give almost instantaneous hit, reducing the average quite a lot.
  however when the car passes it will take additional time.
- check the middle element(75) first and then working down to 0 or up to 150 ==> would half the average.
- start with the previous found index first and go up/down from there.
- extrapolate the last 2(n) found values to estimate a starting point. (quite math expensive)
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
But selecting a 3.3V board (i.e., not the Nano) is ideal as it makes talking to the SD card easier.

The Sharp sensor requires 5V, I assume I can use the USB power supply that powers the arduino for it?
Oh dear, that does make things more complicated. I recommend you stick with the 3.3V Arduino as you'll be both sending and receiving to/from the 3.3V SD card. For the Sharp sensor, you can read the higher voltage with a simple voltage divider (two small resistors).

So, timing -- your Arduino clock will drift relative to the sensor and you may eventually end up sampling the voltage right in the middle of the sensor's transition from one voltage to another. If you don't want the occasional erroneous reading, you'll want to power off the sensor and power it back on to make sure you stay synchronized -- this will require two more small inexpensive parts, a current-limiting resistor and a transistor. Or just live with a few inaccurate readings.

Let's talk about power supply -- USB is fine for testing at home, but will you use something like four AAA NiMH batteries on the bike? Because they could power the sensor directly, and the Micro/Mini has an onboard voltage regulator you can tap in to for the SD card. (Alkaline batteries would be a little on the high side for voltage.)

The only downside to powering the sensor directly from battery, is battery voltage varies with battery charge. You can compensate by using the AREF pin on the Arduino to reference battery voltage though (through another voltage divider).

Quote
The best I could find is this Pro Mini 3.3V / 8Mhz Clone plus an FTDI Breakout.
Please note that the FTDI boards (USB-Serial) come in 5V and 3.3V flavors as well -- make sure to select 3.3v!
« Last Edit: August 25, 2013, 08:04:44 pm by tylernt » Logged

Idaho, US
Offline Offline
Edison Member
*
Karma: 22
Posts: 1074
Special User
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well since the output is less than 3.3v, you can ignore all the stuff about AREF then. Have you seen the discussion on

https://www.sparkfun.com/products/8958

They mention a lot of the things we've already talked about, maps, taking/averaged repeated samples, etc.
Logged

Pages: [1]   Go Up
Jump to: