I got assistance and constructive feedback elsewhere.

If you are going to discard the return value, why bother calling the function?

I don’t recall discarding the information.
As i understand it, by placing this in the setup part of the sketch, it applies the restriction to the entire Code. I have put it in here, to prevent my servos from clashing on physical objects and trashing themselves due to a balls up in the loop section. If it doesnt work like this then i have made a mistake. I refer to you the "Newbie" part of my stats.

If you aren't going to do anything, does the conditional matter? If you aren't sure yet what to do, put a comment to that effect in the body.

I don't know, you tell me. It makes the sketch works in a different way to how it works without it, a way that is closer to what I want/expect it to do. So it seems to be a good idea. I specifically want it to do nothing here. Again, I refer to you the "Newbie" part of my stats.

If vertical spacing is good, why isn't horizontal spacing?

maybe because I have been working on this simple silly little code (which appears to be below you) for some time, and things have been chopped and changed more times than I care to count.
maybe just because it annoys you. Evidently

I think this is properly indented now.

I realised already that i needed to move the calcs into the "for" sections. Although whether or not "for" is the best instruction to use in this scenario, i don’t know.
I have got so far, I want it to update once per sweep. I have added a count function, and have put a "print" request within this, so that it should only print once per sweep too.

I am currently getting the prints at the end of each sweep, and it is printing the value of the extremes only. (40, 130, 40, 130 etc..)

(once i have got a simple sweep back and forth going, i will be able to include the vertical axis, and identify a position, before making a movement decision based on the information.)

I think it is the voidloop where i have fallen down, but here is everything:

Code:

#include <AFMotor.h>
#include <VarSpeedServo.h>

AF_DCMotor motorL(3, MOTOR12_1KHZ); 
AF_DCMotor motorR(2, MOTOR12_1KHZ);
VarSpeedServo Hori;
VarSpeedServo Vert;

const int PR = A1; // connect PR to A1
const int RLED = 13; // indicator LED: 13 and 2 are the only properly pins on the motorshield.
const int LLED = 2; // indicator LED

int HoriPos = 90;      // straight forward,
int VertPos = 90;      // 30 degrees up from horizontal

int LightLevel;
int PrevLightLevel;
int Direction;
byte count =1;

void setup() {

  Serial.begin(9600);  // Serial at 9600 bps

  Hori.attach(9);  // Hori Servo on Pin 9 (Servo2 on the Motorshield)
  Vert.attach(10); // Vert Servo on Pin 10 (Ser1 on the Motorshield)

  constrain(HoriPos, 40, 130); // 90 is center, straightforward, 40 is Left, 130 is full right. Doesnt foul when vert is = 120, would foul if vert is < 120
  constrain(VertPos, 1, 170); // 0 is tilted back approx 30,  170 is max down without fouling on body. 30 is vertical, 120 is horizontal

  motorL.setSpeed(150);      // set the speed of motors: 0 is stop, 255 is full speed:
  motorR.setSpeed(150);

  pinMode (RLED,OUTPUT);
  pinMode (LLED,OUTPUT);

}

void loop() {


   
  for(HoriPos = 40; HoriPos <= 130; HoriPos += 1)
  {   

    Hori.write(HoriPos);
    PrevLightLevel = LightLevel;
    LightLevel = analogRead(PR);   

    if (LightLevel > PrevLightLevel && count == 1) {
      Direction = HoriPos;
      Serial.println(Direction);
      count = 0;
    }

    if (LightLevel > PrevLightLevel && count == 0) {
    }

    if (LightLevel < PrevLightLevel) {
    }
   
    if (HoriPos == 130){
      count = 1;
    }
    delay(50);                         


  }


  for(HoriPos = 130; HoriPos >= 40; HoriPos-=1)   
  {

    Hori.write(HoriPos);

    LightLevel = analogRead(PR);   
    PrevLightLevel = LightLevel;
    if (LightLevel > PrevLightLevel && count == 1) {
      Direction = HoriPos;
      Serial.println(Direction);
      count = 0;
    }

    if (LightLevel > PrevLightLevel && count == 0) {
    }

    if (LightLevel < PrevLightLevel) {
    }

    if (HoriPos == 40){ 
      count = 1;
    }
    delay(50);                         


  }
}



   

Thanks for looking.

Hi there I am fiddling with my second light follower robot on my 2WD chassis
the first one was the classic "3 photo resistors" model.
Now iI have fitted a servo onto the chassis, and have mounted a single photo resistor onto the servo.



https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-ash3/178416_637341408647_239375050_o.jpg

The servo scans from 40 degrees, to 130 degrees (90 is the centre, both of these values are the extents possible without fouling the photo resistor on the bodywork)

I want the photo resistor to take a reading for each increment of servo movement, compare it to the previous reading, and once the light level starts to drop down again (as in once the photo resistor has scanned past the light, and starts to scan away from the light source), it notes the position of the servo, and logs it as a "direction" to the light source.

currently 130 is left, 90 is straight forward, and 40 is right. I would build "windows" into the factors, as in "if the light is between 80 and 100, straight forward, else steer, depending on value)

here is my voidloop. I think im along the right lines, I know it is incomplete to do what i want, but im not sure what to focus on to do what i need to do. any advice would be top

Code:

 
//Sense Light direction
  int LightLevel = analogRead(PR);   

      if (LightLevel < PrevLightLevel) {
        PrevLightLevel = LightLevel;
      } 
  else if (LightLevel > PrevLightLevel) {
        Direction = HoriPos;
      } 
     
  Serial.print(Direction);
  Serial.print(", ");
  Serial.println(LightLevel);   

 
  {
  for(HoriPos = 40; HoriPos < 130; HoriPos += 1)
  {   
    Hori.write(HoriPos);             
    delay(15);                     
  }
  for(HoriPos = 130; HoriPos>=40; HoriPos-=1)   
  {
    Hori.write(HoriPos);             
    delay(15);                     




  }
}

Woah. Thats the Badger. Sorry i didnt put the code up earlier. 

Im a bit of a noob, so tend to take "example" codes, and then mash them together. I think i see what i did wrong there. I also think i see why on the sample code I was referencing it wasnt causing any problems.

Though there are anomalies which still confuse me.

prime example, some codes specify that pins are either input or outputs.
others, they dont bother.
does it matter which way around you do these things?

every day is a school day, still learning. I will try and regraph this data now...

Thank you kindly.

Code is below. Sorry, i could have done something daft in there.

whats an "SW artefact"??
it did occour to me that it could be a short, but i started off with the circuit on a breadboard, and have subsequently put it onto a veroboard. both builds have the same issues.
Also, the spikes back on the colours graph nr the top, all line up, which suggests to me it could be an arduino issue, rather than the hardware.
i dont suppose i can clean up the power supply recieved from the usb, but obviously i need it to read the serial port.

I am trying to sort the PR values, with no colours involved. on the lastest tests, the LED has been off (write 255 to all pins as it is common anode, rather than cathode)

Code:

const int LEDR = 6;
const int LEDG = 5;
const int LEDB = 3;
int PR1 = A2;

const int button = 4;
//int Scale = 0;


void setup(){

  Serial.begin(9600);

  pinMode (LEDR, OUTPUT);
  pinMode (LEDG, OUTPUT);
  pinMode (LEDB, OUTPUT);
  pinMode (PR1, INPUT);

  pinMode (button, INPUT);

  analogWrite(LEDR, 255);
  analogWrite(LEDG, 255);
  analogWrite(LEDB, 0); // Program Starts Blue
 

}

void loop()  {

  analogWrite(LEDR, 255);
  analogWrite(LEDG, 255);
  analogWrite(LEDB, 0); // Program Starts Blue

  while (digitalRead (button) == HIGH){
    // stops script. Its waiting for a button press (LOW on "button")
  }

Serial.println("************************Break*********************");  
  //Scale = 0;

  //Green Up
  for(int fadeValue = 255 ; fadeValue >= 0; fadeValue -=5) {
    analogWrite(LEDG, fadeValue);
    delay(20);  
    PR1 = analogRead(PR1);
    Serial.println(PR1);
  
                          
  }

  //Blue Down
  for(int fadeValue = 0 ; fadeValue <= 255; fadeValue +=5) {
    analogWrite(LEDB, fadeValue);  
  delay(20);      
    PR1 = analogRead(PR1);
    Serial.println(PR1);
                      
  }

  //Red Up
  for(int fadeValue = 255 ; fadeValue >= 0; fadeValue -=5) {
    analogWrite(LEDR, fadeValue);  
    delay(20);    
    PR1 = analogRead(PR1);
    Serial.println(PR1);
                        
  }

  //Green Down
  for(int fadeValue = 0 ; fadeValue <= 255; fadeValue +=5) {
    analogWrite(LEDG, fadeValue);      
   delay(20);    
    PR1 = analogRead(PR1);
    Serial.println(PR1);
                            
  }



}

more graphs.

The Blue line is with "//" before the "write to LED" line. The duino still carries out the calcs.
the red line is with a "//" before EVERYTHING other than "write PR value to serial port"
less spikeyness, but the spikeyness is still there.
the LED isnt doing anything either, its off, so it cant be PWM sensitivity?

suggestion as to resistor change perhaps?
i wouldnt know where to start there 

Hi dc42. That was my thoughts, the opaque SHOULD be super predictable and stable, so thats the one to concentrate on.
so your suggestions in order:

• The filter is very opaque. held directly over a Halogen Desk lamp, you can JUST see a glow through it, but it gets very hot very quickly. The LED has nothing on the power of this lamp.
• I am pretty certain no exterior light is getting in. the setup has a slot barely big enough to fit the filter into, and is encased on all sides by ply or natural timber (modified further than the picture above). Running the test in the dark makes no difference. I have also blacked out the onboard LEDs on the duino on the off chance they were shining through the shield
• the pull up resistor is 10k ohm.
• i moved the USB to a front mounted port on the PC, rather than in the back. I dont THINK it made any difference. It is still very spiky.
• i have run the program without the "write to LED" line in it, so it still carries out all the calculation. It still creates the spikes just the same

Maybe a change of resistor would help, the spikes are effectively the voltage returning to LOW?, but what would you suggest on that front?
I will have a fiddle with the PWM,if i can work it out...

Thank you kindly.

The sketch outputs the reading taken from the PR, once per "fade unit" on the LED.

this results in a column of data pasted into excel
The sketch is re run for each coloured filter, and the column pasted into the file

the x Axis, represents the cycling from Blue (Left most) through to Red (Right most). The units are currently only "line numbers"

The Y axis represents the reading from the PR. as the colour changes on the LED, the filter allows only a certain percentage of light through to teh PR.

for each colour, there is a separate column in the data set, and therefore a separate line on the graph.
The Dark grey represents an opaque filter, and in theory should sit at or close to 1023 and be stable...
the Light grey represents no filter, and is expected to be "high" on the graph (low resistance) but how high is not known, as it this will depend on the sensitivity of the PR and the quality of light out put by the LED.

ideally the coloured graphs will be adjusted so that the 100% light transmission is defined by the light grey coloured line, as 100% on the Y axis, and 0% is defined by the Dark Grey line.

Also, i have no idea what the flat table in the middle of the green line is, but i ran the sketch twice, and got the same flat table...

[Can some one please provide a suggestion as to where the spikes on the OP line are coming from please ?]

I have a project. The project comprises an RGB LED, a light tight tube, and a photo resistor at the other end. There is a slot in the tube, into which I can put Photographers filters

Here is the filter book

each filter comes with a graph, showing the transmission of light (100% to 0%) over a range of wavelengths, (300 to 800 nm, which can be considered blue through to red to all intense purposes)




here is the setup (there is a hole vertically though the wooden block)

Upon button press, the LED scrolls through its colour range. I did this by starting fully blue, fade green up, then once green is 100%, fade blue down, and once blue is at 0%, fade red up, followed lastly by fading green back down again.

the sketch fades "5" of the "255" per cycle of the processor.
on each cycle it prints the PR resistance to the serial port.
there is a 20ms delay on each cycle to let the LED and PR settle (and so one can observe the colour change)



Now on this here graph, (Y axis Analog read from the PR, X axis is sketch cycle).
No filter, is self explanatory, no filter. I kind of expected it to be a bit rough, as the PR has limitations in detection, and the LED certainly wont output pure light

OP (Opaque) is the dark line at the bottom, and involved placing black card in slot, effectively darkening the PR completely.

Now the colour graphs are "OK" upon comparison to the provided filter graphs, but in the loosest sense. The basic form is there, but little more.

Can some one please provide a suggestion as to where the spikes on the OP line are coming from please ?

I think if i can eliminate this "noise" i will get much better results.

FYI, The PR is set up  with one side wired to the A2, and Ground, and the other to +5V via a 10k ohm resistor

Maybe i can eliminate the spikes with some mods to the sketch, or is it more likely to be a physical thing?

Please accept my humble apologies. I had wired it wrong, like a twit.
DOH!

Think i will check my wiring and run a simple test sketch on the PRs on their own. That data looks like it might be static from a miss wire. Thanks for the input guys. Tis helpful

so if it is being bathed in a half power glow of an LED powered by arduino PWM, it should pick up the overall light level surely?

http://www.arduino.cc/en/Tutorial/Smoothing

It is not going to be easy to build this into my sketch