Hello, this code is working (sorry it's written in french).
It is supposed to simulate two opposing traffic lights in an intersection. The button is a master button used to bypass the automatic light switching and make the current green light go to orange.
I noticed that when I press the button too long it messes with the lights so how can I ignore the longpress ?
I'd like some overall advice on the code (if I can make it more efficient).
int trafficLight1[] = {13,12,11}; // Red , Orange , Green,
int trafficLight2[] = {10,9,8}; // Red , Orange , Green,
int button = 7;
int configurations = 4;
int durations[] = {8000,1500,8000,1500}; // time interval of each configuration
long previousMillis = 0;
int ledState;
int buttonState = 0;
int i = 0;
void setup()
{
for(int i = 0; i < 4; i++) {
pinMode(trafficLight1[i], OUTPUT);
pinMode(trafficLight2[i], OUTPUT);
}
Serial.begin(9600);
}
void loop()
{
unsigned long currentMillis = millis();
int buttonState = digitalRead(button);
delay(30);
if (buttonState == 1){
if (isOn(trafficLight1[2])) i = 3; // If button pressed while Traffic Light 2 is Green, switch i to 3 (config 3)
else if (isOn(trafficLight2[2])) i = 1; // If button pressed while Traffic Light 1 is Green, switch i to 1 (config 1)
}
if((currentMillis - previousMillis < durations[i])) {
chooseConfig(i);
} else {
previousMillis = currentMillis;
if(i >= configurations) i = 0; // If configurations counter is full, reset to 0
else i++;
}
}
void ActivateTrafficLight1(String conf)
{
for(int x = 0; x < 3; x++)
{
if(conf[x] == '0') ledState = LOW;
if(conf[x] == '1') ledState = HIGH;
digitalWrite(trafficLight1[x], ledState);
}
}
void ActivateTrafficLight2(String conf)
{
for(int x = 0; x < 3; x++)
{
if(conf[x] == '0') ledState = LOW;
if(conf[x] == '1') ledState = HIGH;
digitalWrite(trafficLight2[x], ledState);
}
}
void chooseConfig(int i)
{
switch(i){
case 0: // Config 0 => Traffic Light 1 is Red, Traffic Light 2 is Green
ActivateTrafficLight1("100"); //String "001" corresponds to : Red OFF / Orange OFF / Green ON
ActivateTrafficLight2("001");
break;
case 1: // Config 1 => Traffic Light 1 is Red, Traffic Light 2 is Orange
ActivateTrafficLight1("100");
ActivateTrafficLight2("010");
break;
case 2: // Config 2 => Traffic Light 1 is Green, Traffic Light 2 is Red
ActivateTrafficLight1("001");
ActivateTrafficLight2("100");
break;
case 3: // Config 3 => Traffic Light 1 is Orange, Traffic Light 2 is Red
ActivateTrafficLight1("010");
ActivateTrafficLight2("100");
break;
}
}
boolean isOn(int a)
{
return(digitalRead(a));
}
Do you have a problem with the program ?
UKHeliBob:
Do you have a problem with the program ?
Sorry i had trouble with my post. You can read it now.
how can I ignore the longpress ?
Perhaps act when the button becomes pressed rather than when it is pressed. Look at the StateChangeDetection example in the IDE
The delay(30) as a debounce is just covering up the problem. Normally for debouncing, you check that the button is pressed continually for a period, and don't just throw in a delay to slow down the whole program.
You need to change your logic from checking that the button is currently pressed to finding when it becomes pressed. Look for the transition, when it wasn't pressed before but now it is.
Slightly OT...
I've often wondered how much market opportunity, and what price point there would be for a seriously 'real' scale model traffic light controller.
Supporting more than two directions at a single junction...
IR in-road sensors to detect (e.g. MINIC), or hand-pushed vehicles...
Left and/ or right turn arrows...
Flashing walk/don't walk pedestrian crossings,
- and the ability to tie multiple junctions together for traffic flow across the whole layout...
Control inputs and outputs to interlink with train signalling / boom gates etc...
Each controller (at this stage) will support up to 64 single colour LED 'bulbs', it could easily be more for larger layouts, but also depends on the number of aux inputs and outputs needed.
The controller setup is pretty complex, but is performed via web page, and saved in EEPROM between play sessions.
I haven't thought too hard about the 'wake up' state, as the state of the layout may have changed while the controller was off... so it may have go through some simple learning process - to begin at a default for each junction and light stand.
Actually, I wish they would smarten up the controllers here in the US - they tend to use a buried coil of wire in each lane as a "metal detector" to detect vehicles so that they can only enable the lights if there is a vehicle waiting to go. Unfortunately, they use a "detect" rather than "detect and see if still there in 5 seconds", so what happens is that the sensor in the left turn lane senses a car that goes over it - when a car coming from the side turns and crosses over the sensor in the left turn lane from the side instead of staying in the lane they are supposed to, it trips the controller and then we get a cycle where it turns the lights for the imaginary car waiting to make the left turn. It needs to see if it is still there in 5 seconds so it is a real one instead of one that just turned over the sensor. (of course, then there are those that don't have a clue how the sensors work and pull past them or stop short so it doesn't sense them too).
I'm sure there's a dozen different models with different capabilities. The ones I've seen in the US with a detector in the right lane do work like you propose because of the right-turn-on-red rule can mean a car can be detected and then move off.
MorganS:
I'm sure there's a dozen different models with different capabilities. The ones I've seen in the US with a detector in the right lane do work like you propose because of the right-turn-on-red rule can mean a car can be detected and then move off.
That's a good point.. turn permitted on red is 'interesting' to implement, but doable.
I developed a full simulation 25 years ago - that turned the whole control model in its head by sensing vehicles as they departed the junction (rather than on approach) - and applied a bias to the 'forward' routes and junctions to load up the timing... and it worked very well! My project name was 'CARS - computerised adaptive routing system'.
It had some neat capabilities, like self healing around blockages and jams - as well as optimised use of turn lanes 'as needed, and continuously variable timing of phases to suit realtime flow metrics.
It handled emergency traffic and surge events flawlessly.
oh well.