Hi! I'm a bit new to programming in Arduino, and i'm asking if my code would work and if it is coded correctly.
Please hear me out, my project is creating a simple traffic light with the feature to catch or detect people who "beat the red light" or keep going past the red light.
So my goal is to program a traffic light that uses a photo resistor with a light source and a buzzer to signal if someone beats the red light. the set up for the 'sensor' is this: a light source is directed to the ldr and when a car passes through, the light would be blocked, causing the buzzer to ring
i attached the code file below to see if it works, i've already compiled it and ask if it works.
I've tried to use while commands but failed to understand them well so i just kept using if commands
int RED = 11;
int YELLOW = 12;
int GREEN = 13;
int buzPin = 9;
int ldrPin = A0;
void setup() {
pinMode(RED, OUTPUT); // red
pinMode(YELLOW, OUTPUT); // yellow
pinMode(GREEN, OUTPUT); // green
pinMode(buzPin, OUTPUT); // buzzer
pinMode(ldrPin, INPUT); //ldr
}
void loop() {
digitalWrite(GREEN, HIGH);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW); // GREEN IS A GO
delay ( 10000 );
digitalWrite(GREEN, LOW);
digitalWrite(YELLOW, HIGH);
digitalWrite(RED, LOW); // YELLOW IS A GO
delay ( 2500 );
digitalWrite(GREEN, HIGH);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW); // RED IS A GO
delay ( 10000 );
int ldrStatus = analogRead(ldrPin);
if ( (ldrStatus <300) && ( digitalRead(RED) == HIGH ) ){ // if ldr receives NO LIGHT and RED is HIGH
digitalWrite(buzPin,HIGH); // then buzzer is HIGH
Serial.println("ALERT! ALERT!"); // and print "ALERT! ALERT!"
} else { // if not
digitalWrite(buzPin,LOW); // then buzzer is LOW
Serial.println("SAFE"); // and print "SAFE"
}
}
I don't think it will do what you want, partly (see my next posts for more reasons) because you never (as far as I can see) make the red led high. So even if there was any point in reading an output to see if it's high when you would know that since you are the one who would make it so, it isn't ever set as high so it won't be.
(Or did you mean that last block of writes to make the red high?... copy / paste failure?)
digitalWrite(GREEN, HIGH);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW); // GREEN IS A GO
delay ( 10000 );
digitalWrite(GREEN, LOW);
digitalWrite(YELLOW, HIGH);
digitalWrite(RED, LOW); // YELLOW IS A GO
delay ( 2500 );
digitalWrite(GREEN, HIGH);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW); // RED IS A GO XXXXX should this be HIGH?
delay ( 10000 );
I don't think it will do what you want, partly (see my next posts for more reasons) because you never (as far as I can see) make the red led high. So even if there was any point in reading an output to see if it's high when you would know that since you are the one who would make it so, it isn't ever set as high so it won't be.
(Or did you mean that last block of writes to make the red high?... copy / paste failure?)
digitalWrite(GREEN, HIGH);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW); // GREEN IS A GO
delay ( 10000 );
digitalWrite(GREEN, LOW);
digitalWrite(YELLOW, HIGH);
digitalWrite(RED, LOW); // YELLOW IS A GO
delay ( 2500 );
digitalWrite(GREEN, HIGH);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW); // RED IS A GO XXXXX should this be HIGH?
delay ( 10000 );
When you try your code I expect you will discover the problem with delay(); Your next step is to try the blink without delay example and use what you learn from that in this.
I'm puzzled as to why you are asking. Upload you code and try it.
Yeah about testing, i can't test it now exactly. I don't have an arduino board. This is our school project and our teacher provides a arduino kit with all necessary parts. And so we only get to test it during class.
This is our school project and our teacher provides a arduino kit with all necessary parts. And so we only get to test it during class.
Sorry, I had not realised that. That's a real shame because the joy of experimenting (for me anyway) is writing some code, uploading it, finding it doesn't do what I expected and trying again. To do that means having some hardware to hand to play with.
Any chance you could buy one, or get your parents to buy one for you?
Another reason is a sort of "semi legal" one, which may or may not be of interest or concern to you, and it concerns your thinking rather than your coding...
Where I live, there has to be proof that you entered the intersection after the light went red. So eg our cameras take two pics, one just after the light goes red and one a tiny bit after that. You're only in breach if the first pic shows you haven't crossed the line and the second shows you have. I was ticketed and convicted many years ago by a Speed Cop who did that visually. He kept his eye on the light, not the road. Then he only looked at the road when the light had turned red. He saw me cross the line, but knew the light was red already. The Beak agreed...
As your logic stands (other considerations aside) you are looking for the car to be in the intersection when the light is red. That's not illegal in itself. You need to look for the car to have entered the intersection while the light is red. (Note the distinction: "be in" as opposed to "have entered".)
So what I think you need to do is, look for a change in the ldr from "car absent" to "car present" only after the light is red. That will prove the vehicle entered the intersection illegally.
It's okay. Although i do love doing electronics and programming, i'm more inclined in graphic design and this is just a one time project , so i guess i won't be investing in one (although i really want one haha)
PerryBebbington:
When you try your code I expect you will discover the problem with delay(); Your next step is to try the blink without delay example and use what you learn from that in this.
If we ever do encounter this problem, can you elaborate on it a bit? i'm having a bit of trouble since i'm not much of an expert.
elvon_blunden:
Another reason is a sort of "semi legal" one, which may or may not be of interest or concern to you, and it concerns your thinking rather than your coding...
Where I live, there has to be proof that you entered the intersection after the light went red. So eg our cameras take two pics, one just before the light goes red and one after. You're only in breach if the first pic shows you haven't crossed the line and the second shows you have. I was ticketed and convicted many years ago by a Speed Cop who did that visually. He kept his eye on the light, not the road. Then he only looked at the road when the light had turned red. He saw me cross the line, but knew the light was red already. The Beak agreed...
As your logic stands (other considerations aside) you are looking for the car to be in the intersection when the light is red. That's not illegal in itself. You need to look for the car to have entered the intersection while the light is red. (Note the distinction: "be in" as opposed to "have entered".)
So what I think you need to do is, look for a change in the ldr from "car absent" to "car present" only after the light is red. That will prove the vehicle entered the intersection illegally.
Thanks! well instead of altering the code, my instinct would probably move the ldr and the light source farther, maybe an average car length after the line so that when it does reach that area during red light, it would be considered as "beating the red light"
If we ever do encounter this problem, can you elaborate on it a bit?
I'm deliberately avoiding telling you the answers because I want you to find out for yourself and find out how to fix it for yourself. I think you have enough information to get there, you just need to experiment.
KuyaNate17:
well instead of altering the code, my instinct would probably move the ldr and the light source farther, maybe an average car length after the line so that when it does reach that area during red light, it would be considered as "beating the red light"
That's a very good idea, and will probably do the trick for your purposes. It also gives you scope to put something in your "further work required" chapter, and every report needs to have one of those
I'm with PerryB though (and although he didn't elaborate, AWOL was alluding to the same thing) in that you may well need to look into BlinkWithOutDealy, but as you say that's tomorrow's discussion.
