My small robot employs 4 LED's for program status reporting. I have been using the following code to hold the robot in place. The Red LED signifies the robot is ready. Pressing a switch starts robot after one second delay.
//PROGRAM #1***************************
void setup() {
// Other setup code here
RedOn(); //Red LED says robot is ready
while (digitalRead(1) == HIGH) { //Wait for start switch
}
LEDoff(); //Turn LED
delay(1000); //Wait to get hand clear of robot
}
void loop() {
// Robot starts running here
}
I want to use the LED's as a bar chart to report battery input voltage So I added this code. But the switch is no longer active. The robot just starts moving. Comparing the two program segments the if...else segments are only difference. What's wrong here?
<
//PROGRAM #2***************************
void setup() {
// Other setup code here
BatV = analogRead(7); // Read battery voltage; new battery=4.85 volts
if (BatV > 940) {RedOn(); } // Battery voltage > 4.6 volts
else if (BatV > 900) {YellowOn(); } // Battery voltage > 4.4 volts
else if (BatV > 850) {BlueOn(); } // Battery voltage > 4.2 volts
else WhiteOn(); // Battery low, replace if robot misbehaves
while (digitalRead(1) == HIGH) { //Wait for start switch
}
LEDoff(); //Turn LED
delay(1000); //Wait to get hand clear of robot
}
void loop() {
// Robot starts running here
}
From the Arduino reference for "Digital-Pins:" Arduino (Atmega) pins default to inputs, so they don't need to be explicitly declared as inputs with pinMode() when you're using them as inputs.
I've used this code for three years on numerous robots and the switch was always functional.
lastchancename: The program is for a two path line maze solving robot. It consists of over 250 lines of code--to much to post and ask you to interpret.
The code segment from //PROGRAM #1 is taken from a sketch that has worked for over three years.
The only change made to make //PROGRAM #2 is the code segment change above.
Semperidem: I do not have a pull-up resistor on the switch. It has worked without it for three years, which is consistent with the manual.
The real change is adding "if-else" statements into void setup(). These statements do work when included in void loop(). I don't want them in loop because I want the battery voltage test performed only once, at the start of the program.
The problem is without all the code we are guessing. You haven't posted enough to even compile the code so that we can try and debug.
The variable definitions are missing, and we can't see what the ledOn() routines do. For example one of them could be writing serial output that is being written to pin 1... who knows?
250 lines is not a lot... those here will quickly work out which pieces are relevant.
Here is the code for a single run. The robot runs the maze then stops. I have additional software where it eliminates dead ends and makes an optimal run. Note the code for PROGRAM #2, above is now at the end of the Goal subroutine.
I'll move the switch from D1 to D2 to test your idea, but I have low confidence it will work. here is why:
I use only the serial monitor for my testing. For example, I measured the analog value out for each sensor as I moved the black line, 50mm from robot center to each side. To do this, I would build a small loop to ReadSensors() followed by PrintS(). When this sketch runs, it first stops at line 38, waiting for the switch, D1, to be pressed. After that the serial monitor display continuously prints the values of the six sensors across the screen. So the switch at D1 does not interfere with serial data out.
Am I missing something here? Thanks for your comments.
Without a pulldown/pullup resistor you will also get random values from the digital pin, when the button is not pressed. It may work it may not... you are basically leaving it to chance.
The easiest way is just to define the pin as INPUT_PULLUP, and then look for == LOW when checking the switch.
Everybody else is going down the wrong rabbit hole....
Look at the if line again.
This is a complete statement and the else and while following it will never be executed. But I am surprised there is no compile errors from all the excess } characters.
