Help with proximity sensor-based LED project


#1

Hi all! So I only recently got started in using the Arduino and I want to continue exploring it. I want to work with sensors, specifically a proximity sensor. I figure I should stick to the basics and use the sensor with LEDs. So my question is, is there a way that I can use a proximity sensor to control the brightness of an LED using an Arduino? As in, the closer a person gets the brighter it becomes, and the farther away the dimmer? What kind of code would I need? Would I be able to do this with multiple LEDs? How portable can I make it (I was told I could just upload the program and replace my laptop with a battery of some sort as the power source, is that correct)? And are all of these materials available at SAIC?

Thanks a bunch!


#2

Hi @tespin,

Here are some links helpful tutorials for getting started on your project:

It’s hard to give you any specific instructions until you have some code in the works. I recommend you complete those tutorials first (they should go quick) and then try hacking and mashing them up to get what you want.

I can provide you with the parts you need for the tutorials (I’m around 9-4 all week. Maclean, 410) As for the proximity sensor, maybe look here:

Or here:

Good luck!


#3

@dander4,

Thanks for the resources! I’ll look over them tonight. Would it be possible for me to stop by tomorrow or during the weekend and get some help then?


#4

Sorry for the delay, the reply feature wasn’t working for me last night. I’m available today after 2:30. Does that work for you?


#5

That’s alright. And yes, that is great, because I’ll be going to that workshop in the Digitarium today. I will see you then.


#6

@dander4,

Hello! I just wanted to let you know that I had gone to visit you at around 2:40 and you weren’t there, but I had waited around the Maclean building and knocked periodically until about 3:30 before I had to leave. I didn’t want you to think I didn’t try to come, so yeah. Will you be available any time before Wednesday (the earlier the better)?


#7

Oh sorry I missed you today. I was in the io Lab (425). Lets coordinate another time off the forum. My email: dander4@SAIC.edu


#8

I have made a couple projects with proximeters and worked with students on proximeter projects. My major input is that noise (incorrect readings) ruins what should be a smooth transition. For example, if your proximeter reads 6 meters, 5.5 meters, 5 meters, 4.5 meters, then suddently 8 meters, the LED dims slowly then suddenly flashes brightly. Perhaps great if you want a stroboscopic effect but not so great if you want that smooth transition.

I’m no expert in this but I’ve found that the cheaper the proximeter, the more noisy it is. Averaging the data helps, adding all of the values together for a certain time period, depending on how responsive your system needs to be, and dividing that number by the number of values. Rough idea here.

Edit, oh also, this function always seems to take students a while to get the hang of but you will definitely need it for your project. map(). The same function is in Processing, if you want to start working with it with mouse movements and shape size or something simple and easier to understand.


#9

My favorite equation for smoothing smoothing distance sensor data looks something like this:


float smoothedSensorValue = 0;

float smoothingFactor = 0.99; // 1 = no change, 0 = no smoothing, 0.5 = some smoothing

void setup()
{
/// ...
}


void loop()
{
  float rawSensorValue = analogRead(0); // get the raw value

   smoothedSensorValue = smoothedSensorValue * (1 - smoothingFactor) + smoothingFactor * rawSensorValue;

  
}

Basically, in this equation you are doing a simple mixing of the old, smoothed value, and the new jumpy value.

When smoothingFactor = 0.99, then the new smoothed value is made equal to 99% of the last smoothed value + 1% of the new raw (jumpy) value, resulting in very SMOOTH data. If smoothingFactor = 0.4 then the new smoothed value is equal to 40% of the last smoothed value 60% of the jumpy fresh data.

The downside to smoooooooth data is that it is not very responsive – that is – it takes a long time for your smooth data to catch up to big changes in the jumpy sensor data. The upside is that it is … smooooooooth.


#10

By the way, I just uploaded a bunch of normalization, smoothing, etc examples to the olabs example repo: