text:
Is there any way I can light up a candle with an Arduino?
I want to make a candle flame light up triggered by a microcontroller. Is it possible? I only want to light it up. Not turn it down. Moreover, this is for a one-time use so the candle burning down and becoming shorter is not a problem.

Do you want it to get brighter and brighter in steps?

There are some pretty good responses on this subject at https://forum.arduino.cc/index.php?topic=70373. If one of those works for you please answer your own question.

You must summon the lord of the nether world to get the most prudent solution. I will spell his name with whitespace between each letter: M a j e n k o

Have someone hold the candle and a lighter.  Then, have the Arduino light an LED.  Once they see the LED, have them light the candle.  Once the LED is out, have them blow out the candle.  Problem solved.

@Samee87 Not at all. I just want to light it up once and that is it.

A simple solution is too use nichrome wire which when a current is passes through it will heat up. You could wrap some of this wire around the wick on the candle and then power it either straight from your arduino or you could include a capacitor.
This is much safer than some of the other methods which use potentially dangerous high voltages.
I tested the nichrome wire approach and it works! See following video clip. 2 Ohm resistance and 19V for 1 second.  https://1drv.ms/v/s!AvcBubMtAczvifYZwoESAhUodOoqRA

Even when nichrome is white-hot, it is dubious that it can light a wick. Did you try? It will also not autoadjust its length as the candle becomes lower.

@user400344 i have not lit a candle with nichrome wire but im sure if i was tightly wrapped at the bottom of the wick it would light. However as you stated it will not autoadjust obviously and so this is a problem. Maybe a complicated servo system could be used.

I think this is the solution that I am looking for if the wire is capable of becoming hot enough. I will try let know what happens!!

@ANANDAPADHMANABHANS yeah make sure you buy the correct wire. Look at the sellers details.

If you have a circuit, you can switch it on and off using a microcontroller.
So what you need is a circuit which can light a candle.  Have a look at these:
DIY arc lighter
CCFL Inverter becomes an Arc Lighter?
I predict your main problem will be dealing with the fact that candles get shorter as they burn.

Actually in my case that is not a problem as this is for a strict one time turning on. I am sorry I was not clear about that in my original post. I will try these out and see what happens!!

Use two rods at either side of the candle, and engineer two motors to slide op and down these rods. Meccano kung-fu.
Use limit switches to detect the highest and lowest positions for both motors. Mount a LED on one motor, and a laser (5 mW red is plenty). From the bottom, have both motors ascend, until the LED can receive data transmitted by the laser. Yes, you can most certainly use a laser diode for Serial.print.
When at the right height, engage gasburner. You can use an LDR (shielded against light from the sides with heatshrink) to check if the candle has been lit - shortly after disengaging gasburner. You will need a reading prior to each ignition.
Let me know how that works out.

This will not be a romantic candle.

Unless you're Bender from Futurama.  But he would prefer a 6502 instead of the Arduino.

Functioning proof of concept.
Ni-chrome wire from hair dryer, approximately 2 Ohms, powered by 19 V for about 1 second. video of proof of concept. Lots to work out still, but this obviously can work.

Have you considered using a servo with a high torque, and a piezo-electric butane lighter?
The high torque would be required to push the lighter button as these tend to be rather stiff. Also, they do not always work on the first press and so a few attempts by the servo may be required. A Dynamixel AX-12A could do the job, but pricey, and could be overkill.
To save some money and time, measure the torque required to push the lighter button first and then get a servo/actuator to match.
Alternatively, use a gas oven lighter, again in conjunction with a linear actuator.


text:
Serial parsing strange data
I have a project where I use a software serial connection to read serial data from a barcode scanner.
All is good. However from time to time I have some problems with the data that I'm receiving.

You said : 123456789��?�: @���?���?���?���?���?
You said : 123456789
You said : 123456789123456
You said : 987654321789456123

My code is something similar to the one below

int count = 0;
void parseSerial() {
  char ser[20];
  while (Serial.available() > 0) {
    char c = Serial.read();
    if ( c != '\r' && count <= sizeof(ser)) {
      ser[count] = c;
      count++;
    } else {
      Serial.print("You said : ");
      Serial.println(ser);
      for(int i=0; i < sizeof(ser); i++) {
        ser[i] = '\0';
      }
      count = 0;
    }
  }
}

Any idea on how I can get rid of "��?�: @���?���?���?���?���?"?
Thanks.

The problem is that the buffer is not initialized to start with. When
you call parseSerial(), it contains garbage, which is what you see on
the serial monitor. In order to avoid printing out that garbage, you
have to properly terminate the string, i.e. add a \0 after the last
valid character.
You did that after printing the string (you filled the whole buffer
with \0, which is overkill), but that's too late. The subsequent
printouts are OK though.
The recommended way to handle incoming serial data is to look for a
terminating character (\r seems to be what you expect), and buffer
all the incoming bytes until you see it. Don't forget to save 1 byte of
buffer space for the terminating \0:
void parseSerial() {
    static char buffer[20];
    static int count = 0;

    while (Serial.available()) {
        int c = Serial.read();
        if (c == '\r') {           // received complete line
            buffer[count] = '\0';  // terminate the string
            Serial.print(F("You said: "));
            Serial.println(buffer);
            count = 0;
        }
        else if (count < sizeof buffer - 1) {
            buffer[count++] = c;
        }
    }
}

Notice that the buffer here being static, you can accumulate partial
messages through successive calls to parseSerial(). Only when the
message is complete will it print it back.

Why are you using char array when you can use String. And use Serial.readStringUntil('\r'); instead Serial.read.
Code:

void parseSerial(){
String read = " ";
int count = 0;
if(Serial.available()>0){
while(Serial.available()>0){

if(count != 20){
read = Serial.readStringUntil('\r');
count++;
}
}

}
Serial.println("You said: ");
Serial.print(read);
}

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Multiple buttons on single interrupt, how to debounce?
Buttons on separate interrupt pins work fine (triggered on FALLING), bouncing is handling by forcing a 80ms lockout period during which further presses are ignored. I like that solution for being lightweight.
My goal is to have 1 interrupt handle all events (buttons and other digital inputs). I don't want to depend on loop(), I wish to be free to use delay often rather than timer interrupts.
Most buttons execute an action when pressed, some, while pressed.
What I have now (just 2 buttons for now):

simulate this circuit – Schematic created using CircuitLab
void setup() {
  pinMode(17, INPUT_PULLUP);
  pinMode(16, INPUT_PULLUP);
  pinMode(3, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(3), wotHappnd, CHANGE);
}

boolean isDebouncing(){
  unsigned int now = millis();
  if(now - time_lastPressed > time_debounceLockout){
    time_lastPressed = now;
    return false;
  }
  return true;
}

void wotHappnd(){
  boolean interruptFalling = digitalRead(3) == LOW;
  if(interruptFalling && isDebouncing()) return;
  // digitalRead the pins; do stuff
}

Internal pullups on all used pins.
My problem is that often (~4%), on interrupt, the interrupt pin is LOW all button pins are HIGH ("not pressed" - likely bouncing just as I read it). How to fix that?
Can't use delay during an interrupt; delayMicroseconds to wait for stable readout still feels inappropriate; a cap-based delay on the interrupt pin induces a period of floating.
Prefer solutions in software or with no more than 1 extra component per input.
[edit] here's a claim that pin interrupts do some filtering already, which, if true, may make some solutions unreliable.

Can't you catch the button being pressed on the next bounce? Since the button bounces a few times, there should be one where it's LOW for long enough to catch. So in the code, you'll have to check if one of the buttons is pressed, before calling the isDebouncing function.

@Gerben It's a common debounce for all buttons. Sufficient for me. So, you're suggesting I do digitalRead in a loop until I get a LOW somewhere?

No. Do two digital reads for the two buttons in the ISR. If both are high, do nothing. Otherwise execute the code you now have in the ISR.

Oh. Still, is it certain that a bouncing button will trigger effloads of interrupts? I'm asking because I read somewhere (Electrical Engineering StackExchange?) that there is already some signal stability assurance done on interrupts in some microcontrollers, to prevent exactly that. Plus, I have no idea what impact the diodes or other connected pins may have here, if any.

I think you will find that in the end, thee best software debounced is none- a capacitor plus a resistor (or a terrible switch) will do wonders here.

Any reason you don't attachInterrupt(..., FALLING)? 2) There is no filtering done by the MCU on external interrupts.

@EdgarBonet I forgot the terms for it, so I wrote: "Most buttons execute an action when pressed, some, while pressed." For the latter, I have to know when they're released.

In the Isr, read the two pins and maintain their current status (UN debounced), and reset a counter.
In the main loop, increment that counter. If it is more than a certain number, it means that the current state of the key has been stable for a while - bounce no more.
Or Google Kuhn debounced. I wrote a blog page about that. If you want, I can post it later. The basic idea is the same.

Thanks of reminding me of Kuhn debounce. Too bad it needs polling in main loop, which I don't want to do. Polling without delay won't produce the same result... maybe polling on a timer interrupt? Hmm...

The approach I suggested is essentially the Kuhn debounced, without polling the buttons. Instead, you increment a counter as a way to detect stabilized buttons.

Sorry, I misunderstood before. Still, what puts me off is dependence on the main loop being free of long delays. Also, any idea about what's in the 4th comment under the question? Won't there be fewer CHANGE interrupts than changes on the (non-interrupt) button pin?

There is no requirement for the main loop to have any delays, long Orr short

Any solution using loop() needs loop() to NOT have long delays. Kuhn repeats 10 times per second. Arduino is a prototyping platform - perfection is reserved for later, and in the meantime I tune my signal generation using delay.

Accepting this as it seems no method as convenient as the lockout exists for my scenario, leaving loop and hardware solutions. Thank you.

As ever I am the voice of dissent: never write software to solve a hardware problem.
For a double-throw switch the classic solution is an SR latch.
Single throw is actually harder. On the face of it, debounce is a trivial matter done with a capacitor and a pull-down (or pull-up) resistor. This will certainly stop floating and false positives from induced current from spikes. However, microprocessors switch pretty fast and will recognise the edges of microsecond oscillations around the switching voltage as changes of switch state. To prevent this you need the hysteresis of a Schmitt Trigger such as an LM7414 (TTL) or LM7417 (suitable for 3V3).
Here is the debounce circuit suggested in Understanding Schmitt Triggers. Unfortunately, it doesn't behave correctly under all conditions, for reasons explained on the Ganssle page referenced later.

You can fix the problem with a diode. For TTL, R1 = 82kΩ, R2 = 18kΩ, C = 1µF

Larger values of C will absorb slower bounces. One of my projects has a relay that bounces for so long I needed 470µF.
Here's what I regard as the last word on the subject — the Ganssle page. There's even a solution for multiple buttons on a single input. This is not quite the same as multiple buttons on a single interrupt but I think the approach may be applicable.
Note that on the Ganssle page a software solution is touted as cheaper than hardware. That's irrelevant for a one-off, true for mid sized runs and potentially false for mass produced items. Debugging software has its own costs and so does product recall. Make your decision in context. Arduino projects are usually one-off.
One objection to a hardware solution is cost, in assembly time, component count and board size. For hobby work that's a personal choice, and for commercial work it's a trade-off between simplicity and reliability. Reliability of software hinges on deterministic behaviour and the management of complexity. The Atmel chip doesn't have a lot of DRAM or program space, and moving this problem out of the software will make it smaller, simpler and more predictable.
That's not to say there aren't other ways to deal with the problem.
If you really want to do it in software you need to measure the pulse width and compare it to a threshold. Since you need both falling and rising edges for this, bind to CHANGE and test for state. The primary difference between this and the Kuhn method mentioned by others is it uses the clock instead of a counter allowing you to specify millisecond duration rather than iterations.
In the excerpt below, the listen flag is a simple alternative to noInterrupt() or unbinding the handler. My loop code evaluates a state machine transition function for current state and inputs, and not all states want input.
void isr_change()
{
    if (listen)
    {
        unsigned long now = millis();
        int d2 = digitalRead(2);
        if (d2 == LOW || fall_time == 0)
        { // FALLING
            fall_time = now;
        }
        if (d2 == HIGH)
        { // RISING
            command_pending = now - fall_time > MIN_PULSE_MS;
        }
    }
}

The state machine doesn't look at digital inputs, it looks at the command_pending flag, which is reset after the transition function finishes.
This is one of those things that looks simple, isn't, but does have a stock solution. It beats me why there isn't a mass produced debouncer component the way you can get op-amps.
Thank you to kaay in comments for referring me to the MC14490 which is a DIP16 or SOIC16 with six diode protected debouncers. Kaay thinks it's expensive but consider the cost of the time to code and debug debounce of six inputs. What about the cost when the program doesn't quite fit and you have to rewrite it to shrink it? And then regression test everything. Would you pay someone $5 for an instant guaranteed result that doesn't complicate or bloat your software? The economics change with production scale of course, but in very small runs I think it's well worthwhile.
I found the MC14490 DIP16 for 5USD and the SOIC for 9AUD online. Local shops didn't carry it.

One up and one down. Pity the down-voter couldn't be bothered to say why he thinks this is a poor answer.

I am not the downvoter, but I can see that hardware is more expensive than software in terms of parts, board real state, assembly time...

@EdgarBonet I should hope you can see it, I discussed in explicitly in the penultimate paragraph.

@EdgarBonet no longer the second last para but it was when you read it. I have added some material to help people with tunnel vision.

+1 for effort. This answer gathers some nice ideas, and even if it's not a good match to the requirements in the question, it is useful. Although, gotta disagree with "(cost is) irrelevant for a one-off" - for most, slapping on a Shmitt&TheRest will cost from 20 minutes (in the unlikely case they have everything at hand) PLUS testing, to several hours. And that is ESPECIALLY hurtful if all you get is one unit. Debouncer ICs - I've had the exact same thought! As far as I'm concerned, at that price, MC14490 does not exist.

@kaay perhaps, in many ways it's a values question. I suspect most Arduino projects are labours of love, where one of the deliverables is the satisfaction of both do it yourself and design it yourself. Given the negative reactions, I may be wrong about that. The reason I think a hardware debounce may be cheaper than software for a very small run is the cost of quality control for software and the cost of pushing firmware updates.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Serial Connection
I was trying to communicate with my arduino uno over the serial connection from the USB. Connecting to it is usually not a problem, but what buggs me is the first transaction of the data... No matter with what I do it, java code or the serial monitor which comes with the IDE, I always have the problem that usually only one Byte is being transfered or received from the Arduino. What could be the problem? Is it just a bug and I have to live with it or can this somehow be fixed?
My Arduino Code:
#include "RGBdriver.h"
#define CLK 10
#define DIN 11

RGBdriver driver(CLK, DIN);
byte red = 0;
byte green = 0;
byte blue = 0;

byte newRed = 0;
byte newGreen = 0;
byte newBlue = 255;

void setup() {
  Serial.begin(9600);
}

void loop() {
  if (Serial.available() >= 3) {
    newRed = Serial.read();
    newGreen = Serial.read();
    newBlue = Serial.read();
  }

  if ((red != newRed) || (green != newGreen) || (blue != newBlue)) {
    red = newRed;
    green = newGreen;
    blue = newBlue;

    driver.begin();
    driver.SetColor(red, green, blue);
    driver.end();
  }
}

Are you waiting for the Arduino to finish the bootloader timeout after opening the serial port from the PC?

Yes, I do! The Arduino is being used for controlling the lights on my LED strip. I know it booted because they turn on and after 10-15 sec, just to be safe, I try to send the data and on the first try it turns off and on in a short time and on the second try it really changes the color.

Now I have actually looked at your code your problem is immediately obvious to me. I cover it in detail here: https://hackingmajenkoblog.wordpress.com/2016/02/01/reading-serial-on-the-arduino/

Ok what I could have changed in my code is putting Seria.available() >=3, bcs I need 3 Bytes of data for updating. But it still doesnt update the color on the first try. This also happens in the serial monitor...

I updated my code. Now it works with the serial monitor, but my java program is still not working, meaning the first attempt of sending the data doesnt work... Only after trying the data one time it will work from there on.

Are you waiting the bootloader timeout time in your java program?

Well, just to be sure I always wait for like 5-7 sec until I do anything just to be sure I am not doing something that will interupt the boot time

Even after opening the serial port in your Java program? (Open port - wait 2+ seconds - send data)

Well, I do use in the program the function setComPortTimeouts(SerialPort.TIMEOUT_READ_SEMI_BLOCKING, 0, 0). I am not actually typing data in it, I send it over right away with starting the program. I also close the port on the end, because else I won't be able to access it next time.

You do know, don't you, that the act of opening the serial port resets the Arduino?

Ok,I didn't know that ... So I will try to make a while code for input of data and see what will happen then. Also, when I open the port for the second time the Arduino doesn't reset... Everything works fine from then on.

Consider giving sufficient delay to initiate the time to receive the data. The loop would otherwise terminate since the data received is less than 3


text:
Why does "!=LOW" != "HIGH"?
I'm learning about accessing ports directly on the ATMEGA 328 using an Arduino Uno. The program sets up pin 13 as an output and pin 2 as an input. I then enable the pull up resistor on pin 2.
I read Pin 2 and set the LED high or low depending on if pin 2 is high or low.
Why is it that I cannot seem to use == HIGH in my if statement instead of != LOW?
void setup() {
  MCUCR &= ~(1 << 4); //disables pull-up disable (redundant as default is off)
  DDRB |= (1 << 5); //sets pin 13 (B5 on ATMEGA 328) as output
  DDRD &= ~(1 << 2); //sets pin 2 (D2 on ATMEGA 328) as input (redundant as default is input)
  PORTD |= (1 << 2); //since it's an input sets pull-up resistor ON
  PORTB &= ~(1 << 5); //sets pin 13 (B5 on ATMEGA 328) as LOW

}

void loop() {
  if ((PIND & (1 << 2)) != LOW) PORTB |= (1 << 5); //sets pin 13 (B5 on ATMEGA 328) as HIGH
  else PORTB &= ~(1 << 5); //sets pin 13 (B5 on ATMEGA 328) as LOW
   delay(100);

}

Because
((PIND & (1 << 2)) != LOW)

means exactly
(PIND & 4) != 0

and that is true if PIND is 4, 5, 6, 7, 12, 13, ... (any number having 4 in it binary), so it yelds
4 != 0

Which is definitively not equal
4 == 1

BTW: in C any integer != 0 is true and 0 is false, so you can as well write:
if (PIND & (1 << 2)) PORTB |= (1 << 5); //sets pin 13 (B5 on ATMEGA 328) as HIGH

if ((PIND & (1 << 2)) != LOW) PORTB |= (1 << 5); //sets pin 13 (B5 on ATMEGA 328) as HIGH
  else PORTB &= ~(1 << 5); //sets pin 13 (B5 on ATMEGA 328) as LOW

PIND & (1<<2) will return a value of either (1<<2) if PD.2 is high, or 0 if PD.2 is low.
So it basically says that if PD2 is high, set PB5; otherwise, clear PB5.enter code here

Thanks, Danny. Yeah I should have known... dork move on my part.


text:
Arduino digital output pin controling relay problem
I try my code to change the state of a relay on pushing a push button buy checking the state of a digital pin.
My code :
const int led1 = 6;
const int enable1 = 7;
boolean led1_OnOff;
long now;
int minSecsBetweenUpdates = 1; // 1 seconds
long lastSend = -minSecsBetweenUpdates * 1000l;

void setup() {
  led1_OnOff = false;
  pinMode(enable1, INPUT);
  pinMode(led1, OUTPUT);
}

void loop() {
  now = millis();
  if (now > (lastSend + minSecsBetweenUpdates * 1000l))
  {
    if(digitalRead(enable1) == HIGH)
    {
      lastSend = now;
      if(led1_OnOff == true)
      {
        led1_OnOff = false;
        //+digitalWrite(led1, LOW);
      }
      else
      {
        led1_OnOff = true;
        //digitalWrite(led1, HIGH);
      }
    }
  }

  if(led1_OnOff == true)
    digitalWrite(led1, HIGH);
  else
    digitalWrite(led1, LOW);
}

But the code keeps on looping and the relay keep changing it's state as if pin 7 is always high, I'm sure of my schematic but I don't know what's wrong with my code.
for those who want my schematic:

Did you wired pin 7? If it was floating, it will read as HIGH (mostly) and LOW sometimes. BTW your interval checking is incorrect, it doesn't work when value is expected to overflow (somewhere at 49th day). Checking the elapsed time (subtracted difference) with period value will work OK.

Perhaps you should post your wiring diagram for bigger chance to get a proper answer

Possible duplicate of Error while trying to drive relay through the state of a digital input pin in Arduino

Did the code I gave you for your practically identical question yesterday help?

no it didn't, my code was working but suddenly it has gone crazy, I even tried your code but it keeps on looping like enable1 is always high

What makes you sure your wiring is correct?

Your problem is that you are basically saying "while the pin is HIGH toggle the relay" rather than "When, and only when, the pin transitions from LOW to HIGH do I toggle the relay".
To do that you must remember what state the pin was in during the last iteration:
const uint8_t led1 = 6;
const uint8_t enable1 = 7;

void setup() {
    pinMode(enable1, INPUT);
    pinMode(led1, OUTPUT);
}

void loop() {
    static bool led1_OnOff = false;
    static bool lastValue = digitalRead(enable1);

    bool currentValue = digitalRead(enable1);

    if (currentValue != lastValue) {
        lastValue = currentValue;
        if (currentValue == HIGH) {
            led1_OnOff = !led1_OnOff;
            digitalWrite(led1, led1_OnOff);
        }
    }
}

I tried that but I have the same problem, always keeps looping like crazy and only stops looping when I hit the push button

How have you wired up the pushbutton?

It's not a small push button for arduino, it's a normal lighting AC push button, I user one side for pin 7 and the other for 5V

So no pulldown resistor? No wonder it's spazzing out - the pin is floating until you press the button and connect it to a signal of some form. Read the basic Arduino button tutorial: https://www.arduino.cc/en/Tutorial/Button

that was the problem, thanks for pointing it out...I didn't know I had to use a resistor for the AC standard push button like the arduino small push button.

A button is just a button - two metal contacts that get pressed together. Regardless of if it's for AC, DC, high voltage, low voltage, momentary, toggle, rocker, whatever. That is all they are - just two metal contacts that press together.

It now works but if I keep pushing the push button it keeps changing the relay state every one second (my pre-defined time interval), I want it to keep it's state if I keep pushing the push button and only change it if I take my hands of it and pushed it again, can you help?

Which code are you using - your original code, or my code I posted above?

my original code, I tried yours but it's not working, the delay that I add keeps it steadier but if I keep pushing the pushing button it keeps looping and changing the state of the relay every second

In what way does my code not work?

please check this link

You say your switch is between pin 7 and +5v.  Therefore you will need a pull-down resistor on pin 7.
You say that setting pin 7 to an output works.  However you are very likely to burn out the output like this.  A pull-down resistor is the way to go.

no it's connected to 5V and pin 7...I think I solved it by setting enable1 pin to OUTPUT in the setup() loop and forcing it to start at low state by calling digitalWrite(enable1, LOW);

In that case, you will need a pull DOWN resistor.

no that's only what I did, when I set enable1 to output it goes crazy but when I set it to input it's fine.

`void setup() {
led1_OnOff = false;
pinMode(enable1, OUTPUT);
digitalWrite(enable1, LOW);
pinMode(led1, OUTPUT);
}
void loop() {
now = millis();
if (now > (lastSend + 1000))
{
if(digitalRead(enable1) == HIGH)
{
lastSend = now;
if(led1_OnOff == true)
led1_OnOff = false;
else
led1_OnOff = true;
}
}
if(led1_OnOff == true)
digitalWrite(led1, HIGH);
else
digitalWrite(led1, LOW);
}`

OK, I understand what's happening now. Answer updated. You'll blow up your Arduino if you do it like that.

It now works but if I keep pushing the push button it keeps changing the relay state every one second (my pre-defined time interval), I want it to keep it's state if I keep pushing the push button and only change it if I take my hands of it and pushed it again, can you help?

Are you using either my, or @Majenko's, method for detecting when you release the button?

I used both but they both don't work so I'm using mine which is steadier if I push the push button and let go, but if I keep pushing it keeps looping.

Then I think you have another, as yet undiscovered, problem. Both methods should work.

I haven't added anything else except that I added a pull down transistor between pin 7 and ground.

My point stands.  Your solution may be sufficient for you, which is fine, but there is an undiscovered problem, otherwise it would work perfectly.  Perhaps it's interference on that cable - you could try moving the switch right next to the Arduino.

please check this link

What you have there is a cludge to avoid addressing the real problem. If you're happy with that, OK, but know that's what it is.  Also, if you want to encourage people to help you further, consider at least up-voting, or better accepting, helpful answers.

I did up-vote your answer but they said it will be considered as I don't have enough reputation to up-vote you directly...beside, what is wrong with my code?, it's the one that I tried actually and did work for me, It's not a competition here, and I didn't ask this question to have more reputation, I did ask this question to have help and you did help but your code doesn't work for me, that doesn't mean that I'm better, it just means that I found a code that is more suitable for me...thanks for your help and thanks for your understanding.


text:
Brushless motor + ESC with Arduino question
Sorry in advance as I'm still a rookie with Arduino projects. My goal is to use an Arduino Uno 3 to create an inexpensive drone/plane project.
Here are my materials and my set up:

A2212 1000kv Brushless Motor
HW30A Brushless Motor Speed Controller (ESC)
Arduino Uno R3
bunch of cables
9 V battery

Upon compiling the code I found here and connecting the 9 V battery to the ESC, all I hear is constant beep sounds from the motor (about once every 1.5 seconds). Can anyone help me figure out what's going on? Is it the 9 V battery that's not giving the motor enough juice? Or am I just too silly hoping to create something that works under $10?
#include <Servo.h>
Servo ESC1;

int pos = 0; //Sets position variable

void arm() {
  setSpeed(0); //Sets speed variable delay(1000);
}

void setSpeed(int speed){
  int angle = map(speed, 0, 100, 0, 180);
  //Sets servo positions to different speeds ESC1.write(angle);
}

void setup() {
  ESC1.attach(9); //Adds ESC to certain pin. arm();
}

void loop() {
  int speed; //Implements speed variable
  for(speed = 0; speed <= 70; speed += 5) {
    //Cycles speed up to 70% power for 1 second
    setSpeed(speed);
    //Creates variable for speed to be used in in for loop
    delay(1000);
  }
  delay(4000); //Stays on for 4 seconds
  for(speed = 70; speed > 0; speed -= 5) {
    // Cycles speed down to 0% power for 1 second
    setSpeed(speed); delay(1000);
  }
  setSpeed(0);
  //Sets speed variable to zero no matter what
  delay(1000);
  //Turns off for 1 second
}

I was able to find more instruction regarding this ESC, I'll continue to read on this while the post is up: https://www.bphobbies.com/pdf/bp/esc_2015/bp-hw30a-esc-2015.pdf

Like the previous answer stated, you should be using a 20-25c battery (can discharge up to 25A). I don't know exactly how much a 9V draws, but it definitely can't supply more than an AMP. Your motor pulls much more than 1 amp. Get yourself a nice LiPo from hobbyking.com, maybe an 8.4v or 11.1v
The ESC beeping could be telling you it can't draw enough Amps from the battery?

got it working with a better battery, thanks!

Probably a bit late but your code has some important parts commented out such as (in order):

delay(1000);
ESC1.write(angle);
arm();

Once you add those to the next lines the program should work and the esc shouldn't just beep and actually get the motor to spin

thanks anyway! we'll consider this if we use those motors again/

The beeping is actually from the ESC. I believe that this model needs to be properly configured (which you can do using the Arduino - refer to the user manual or here) before it can be used. Some kits come with it preconfigured but since you seem to have possibly purchased it individually you need to configure it yourself. Also it doesn't appear to be that your code wouldn't actually send any PWM signals to the ESC. I've only ever used Servo.write() functions in my quads, so I can't be 100% sure on that.

thank you. Correction, it's actually not a beeping sound, but a little twitch sound made by the motor (nothing from the ESC) I'll continue to read your link and learn more on this. Best regards!

That twitching is a possible error/idle warning in your ESC configuration. I know that my ESCs came programmed to start twitching like a mad dog if they were idle for 10 minutes, which kinda broke the idle warning/shutdown sequence I had designed for my camera-quad.

You need high current for working with this motor, 8.4 LiPo battery for example.


text:
Low Power Pin Change Detection (ATtiny)
I want to use an ATtiny as data logger for the opening and closing of a door/window. For that I am using a reed-switch. Since I want to run it from a 3V coin battery, long term power consumption is crucial. Therefore the ATtiny (currently 13A) is in system down mode most time and is only listening to Pin-Change-Interrupts. Depending on the state of the reed-switch the power consumption differs in an order of magnitude.

switch open:    0.1µA
switch closed: 74.5µA
my Multimeter has a tolerance of ±0.1µA

This is a difference of an order of magnitude. But it is plausible as the datasheet of the ATtiny13A states in chapter 10 that a GPIO pin can only be pulled up and is otherwise dangling. The pull-up resistor is somewhere between 20k and 50k as stated in chapter 18.2.
So in my setup the pin is pulled up and the reed-switch is grounded.
How can I reduce the power consumption in the case where the switch is closed?
Alternatively: Can I somehow revert the state of the switch, as windows and doors are closed most of the time?
The MCU is running with the 128kHz internal Clock with CKDIV8 so practically running @ 16kHz.
The minimum viable code:
/*
  3V0               SW0
   |     |     |     |
 -----------------------
 |                     |
 |                     |
 |      ATtiny13A      |
 |                     |
 |                     |
 -----------------------
   |     |     |     |
               TX   GND
 */

#include <avr/interrupt.h>
#include <avr/sleep.h>
#include <iso646.h>
#include <stdbool.h>
#include <util/delay.h>

#define BIT_SET( PORT, BIT_FIELD ) PORT |=  BIT_FIELD
#define BIT_CLR( PORT, BIT_FIELD ) PORT &= ~BIT_FIELD

#define TX_PIN          PB4
#define SW0_PIN         PB0
#define INT0_MASK       PCINT0

// MARK: - POWER

static void power_down(void) {
    BIT_SET(GIFR, _BV(PCIF));       // Clear interrupt signal
    BIT_SET(GIMSK, _BV(PCIE));      // Pin Change Interrupt Enabled
    sleep_enable();
    sleep_cpu();                    // Enter sleep mode
    sleep_disable();
    BIT_CLR(GIMSK, _BV(PCIE));      // Pin Change Interrupt Disabled
}

ISR(PCINT0_vect) {}

// MARK: - Setup

static void setup(void) {
    cli();

    // Set up output pins
    DDRB = _BV(TX_PIN);
    BIT_CLR(PORTB, _BV(TX_PIN));

    BIT_SET(PORTB, _BV(SW0_PIN));        // pull up interrupt pins
    BIT_SET(PCMSK, _BV(INT0_MASK));   // set PCINT0 to trigger interrupt
    BIT_SET(GIFR, _BV(PCIF));       // Clear interrupt signal
    BIT_SET(GIMSK, _BV(PCIE));      // Pin Change Interrupt Enabled
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);

    sei();
}

static void loop() {
    BIT_SET(PORTB, _BV(TX_PIN));
    _delay_ms(1);
    BIT_CLR(PORTB, _BV(TX_PIN));

    power_down();
}

int main(void) {
    setup();

    while (true) {
        loop();
    }
}

To be honest, your figures sound far too high. See ATtiny85: Power consumption vs clock speed You should be able to get down to 200 nA - please post your code and schematic.

Once the switch is closed, set the pin to INPUT. Once in a while, revert to INPUT_PULLUP and, if still closed, go back to INPUT to save battery. You can use the watchdog as a low-power timer for this periodic polling.

75µA at 3V means the pull-up resistor is 40k. Which is pretty much what's specified in the datasheet. You could switch to a NC reed-switch. So you pin will only be pulled LOW when the door is open, not closed. Depending on how long the door can be open, this could still be a less than ideal solution.

You could also try a higher value external pull-up resistor, optionally with a small capacitor.

@NickGammon: you are right. I had the WDT running which draws 5µA.

@EdgarBonet: I tried it and noticed that the power consumption spikes up randomly. Having a floating input does not look like a robust solution to me. But the idea to use just the WDT and not the Pin-Change-interrupt sounds more like a feasible idea. Wake up from WDT, set the input to high, look at the input, set input to low, go to bed...

I intend to use the WDT anyway to log the state every 256 * 8s (about 30 minutes)

However the WDT uses a lot more power than an external interrupt. I would only use the watchdog if I had to do something periodically, whereas logging when a window opens only has to be done when it opens.

To avoid the floating input, you can set the pin to OUTPUT LOW. But beware that you cannot switch between INPUT PULLUP and OUTPUT LOW atomically: you will have to go through either INPUT HiZ (safe) or OUTPUT HIGH (very bad).

I'm tempted to suggest two reed switches (one NO and the other NC). Then depending on the window state you change to use the switch which gives you the lowest drain (you could use a spare couple of pins to activate one or the other).
Failing that, you can just sleep when the switch is open (the low-power condition) and if it is closed use the watchdog timer to check it from time to time (in other words, drop the power to the switch while asleep). The WDT only uses around 5 µA so that isn't too bad (the coin battery probably self-discharges at about that rate anyway). That would be a lot better than a constant drain of around 70 µA.
I've got an ATtiny85 sitting in my hallway flashing an LED every couple of seconds. I can't recall when I replaced the battery, possibly once since I made it two years ago.

This is a brilliant idea. I didn't even know there are different types of reed switches. And there are also 3 pin ones wich are NC and NO at once. I'll try that out.

The additional 80uA drain is almost certainly coming from the pull-up resistor being shunted to ground though the reed switch.
https://www.wolframalpha.com/input/?i=(3+volts)+%2F(50k+ohm)+in+uA
As suggested by @Edgar Bonet, one way to greatly reduce this drain is to disable the pull-up immediately when you wake from the pin going low. At this point it is possible for the pin to stay low even if the switch is no longer grounding the pin, so you need to periodically check it using a watchdog.

Wake from pin going low pin change interrupt
Disable pull-up (stops current flowing though resistor)
Do your logging operation.
Enable a watchdog wake up
Go back to sleep.

At this point you can wake either from (1) a watchdog or (2) pin change if the pin goes high again.
If you wake from a pin change...

re-enable the pull-up
disable the watchdog
go back to sleep

If you wake from the watchdog...

re-enable the pull-up.
if the pin is high now, disable the watchdog and go back to sleep.
if the pin is low, disable the pull-up and leave the watchdog running and go back to sleep.

The watchdog timer on this part should only use single digits of uA while running, and it should only need to be running while the switch is grounding the pin. You can set the watchdog timeout to be quite long- on the order of seconds even, to reduce the frequency you  wake to check with the pull-up (and therefore the net power used, at the cost of latency for detecting pin changes). The main downside to this strategy is that you can miss activations that happen inbetween your watchdog wake-ups, so for example if the pin goes low and then you set the watchdog for 8 seconds, and then the pin changes high and then low again during the next 8 seconds, it is possible (but not assured) that you could miss the second event, so set the watchdog timeout to be short enough that you will not miss consecutive events that you care about (you might not care if the door is opened twice in the same minute anyway).
Also, as noted by the famous @nick gammon, you might be able to get lower than 5uA when sleeping without the watchdog. Check to make sure you are disabling everything in the power register and that all unused pins are in input mode (these will be disabled when sleeping as long as there is not a pin change interrupt on them).  There are lots of googleable articles on minimizing ATTINY power during sleep.
You also mentioned that your dominant case is that the switch is closed rather than opened. Since this is the higher-power case with the current switch consider using a normally open switch rather than normally closed one if possible.
Finally, if you just want simplicity and you only care about events of a minimum duration (saym then door much be open for at least 1/2 second to be noticed), then you can skip the pin change interrupt completely and only use an always-running watchdog to wake periodically and very quickly enable the pull-up and check for the desired pin state, and then disable the pull-up and go back to sleep. You should be able to do this in less than a dozen cycles so the net power usage should be almost as low as the watchdog timer drain by itself.

or connect the switch to the high side and use an external pull-down resistor how would this help? If the switch is closed most of the time, there will be a current coming from vcc, though the switch, through the pull-down to ground. It's the same as the other solution, except that you swapped the resistor and switch. Or am I missing something.

@Gerben True, true. Mixed up reasoning fixed now. Thanks!


text:
WiFi.status() hangs / resets board
Using one of the RobotDyn boards with onboard WiFi and a Generic ESP8266 module.
I can load the sketch, but when WiFi.status() is called to see if WiFi enabled, the sketch hangs, rebooting the board after ten seconds are so.

void setup() {
  Serial.begin( 115200 );
  Serial.println( "begin - wifi status: " );
  // program hangs here - - - - - - -
  int status = WiFi.status();
  Serial.println( status );
}

I think it might be a problem with the code you are using, prior to version 2.2.0 of the "ESP Core" the first block of code worked, since only the second version works.
It seems that you can get around it by rather than doing this:
 WiFi.begin(ssid, password); // connect to the network
 while (WiFi.status() != WL_CONNECTED)
 {
     delay(500);
 }

You should do this:
if (WiFi.status() != WL_CONNECTED)
{
     WiFi.begin(ssid, password); // connect to the network
     delay (500);
}

Does that look it might be a likely cause?
Sources
 1 2

No. I wish to know if WiFi available, so issues int status = WiFi.status();. The sketch hangs on this line. (Have added this to question for clarity.)

Think I found the cause!
I previously had

#include <WiFi.h>

but now using

#include <ESP2866WiFi.h>

This seems to work
I was unaware of the two library sets. Since I use both Arduino MiniPro and versions of NodeMCU, am now going through the libraries and determining what breaks.
IMHO, in regard to libraries, NodeMCU Lua libraries are far, far better than Arduino's C++ libraries.


text:
TPS/MAP calculation problem - SOLVED
In my recent project, I have to create TPS/MAP table, which is provide value of LOAD.
Here, it is my table. You can see two value of LOAD which is separate by /. (TPS LOAD / MAP LOAD)

But now here as you can see, TPS provide different value of LOAD and MAP provide different value of LOAD. So, every cell has a two value of LOAD. So, I decide just add this both LOAD and divide it by 2.
I made program for this but it access only just LAST COLUMN and LAST ROW and it provide wrong value of LOAD. I don't understand why this happen.
Here, my code.
float TPS[] = {0, 0.4, 0.8, 1.2, 1.6, 2, 2.4, 2.8, 3.2, 3.6, 4, 4.4, 4.8, 5};
float MAP[] = {0.85, 0.95, 1.05, 1.15, 1.25, 1.35, 1.45, 1.55, 1.65, 1.75, 1.85, 1.9};

float TPS_MIN = 0.00;
float TPS_MAX = 5.00;

float MAP_MIN = 0.85;
float MAP_MAX = 1.90;

float LOAD_MIN_TPS[] = {2, 3.23, 4.49, 5.73, 6.97, 8.22, 9.44, 10.63, 11.87, 13.11, 14.33, 15.00};
float LOAD_MAX_TPS[] = {10.00, 17.08, 24.11, 31.67, 38.30, 45.73, 52.63, 60.19, 67.22, 74.52, 81.68, 85.00};

float LOAD_MIN_MAP[] = {2, 2.64, 3.28, 3.92, 4.56, 5.21, 5.85, 6.47, 7.11, 7.76, 8.40, 9.05, 9.69, 10.00};
float LOAD_MAX_MAP[] = {15.00, 20.62, 26.17, 31.79, 37.35, 42.97, 48.66, 54.14, 59.76, 65.38, 70.93, 76.63, 82.18, 85.00};

float m1[12] = {};
float m2[14] = {};

float y1[14] = {};
float y2[12] = {};

float y[168] = {};

int i, j, n;

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  for(j = 0; j < 12; j++)
  {
    m1[j] = (LOAD_MAX_TPS[j] - LOAD_MIN_TPS[j]) / (TPS_MAX - TPS_MIN);

    Serial.print("m1 : ");
    Serial.println(m1[j]);

    for(i = 0; i < 14; i++)
    {
      y1[i] = m1[j] * (TPS[i] - TPS_MIN) + LOAD_MIN_TPS[j];

      Serial.print("TPS : ");
      Serial.print(TPS[i]);
      Serial.print("\t");
      Serial.print("LOAD : ");
      Serial.println(y1[i]);
   }
  }

  for(i = 0; i < 14; i++)
  {
    m2[i] = (LOAD_MAX_MAP[i] - LOAD_MIN_MAP[i]) / (MAP_MAX - MAP_MIN);

    Serial.print("m2 : ");
    Serial.println(m2[i]);

    for(j = 0; j < 12; j++)
    {
      y2[j] = m2[i] * (MAP[j] - MAP_MIN) + LOAD_MIN_MAP[i];

      Serial.print("MAP : ");
      Serial.print(MAP[j]);
      Serial.print("\t");
      Serial.print("LOAD : ");
      Serial.println(y2[j]);
    }
   }

  for(i = 0; i < 14; i++)
  {
    for(j = 0; j < 12; j++)
    {
      y[n] = (y1[i] + y2[j]) / 2;
      Serial.print("LOAD TPS : ");
      Serial.print(y1[i]);
      Serial.print("\t");
      Serial.print("LOAD MAP : ");
      Serial.print(y2[j]);
      Serial.print("\t");
      Serial.print("TPS : ");
      Serial.print(TPS[i]);
      Serial.print("\t");
      Serial.print("MAP : ");
      Serial.print(MAP[j]);
      Serial.print("\t");
      Serial.print("Final LOAD : ");
      Serial.println(y[n]);
    }
  }
  delay(1000000);
}

My serial monitor output :
LOAD TPS : 15.00    LOAD MAP : 10.00    TPS : 0.00  MAP : 0.85  Final LOAD : 12.50
LOAD TPS : 15.00    LOAD MAP : 17.14    TPS : 0.00  MAP : 0.95  Final LOAD : 16.07
LOAD TPS : 15.00    LOAD MAP : 24.29    TPS : 0.00  MAP : 1.05  Final LOAD : 19.64
LOAD TPS : 15.00    LOAD MAP : 31.43    TPS : 0.00  MAP : 1.15  Final LOAD : 23.21
LOAD TPS : 15.00    LOAD MAP : 38.57    TPS : 0.00  MAP : 1.25  Final LOAD : 26.79
LOAD TPS : 15.00    LOAD MAP : 45.71    TPS : 0.00  MAP : 1.35  Final LOAD : 30.36
LOAD TPS : 15.00    LOAD MAP : 52.86    TPS : 0.00  MAP : 1.45  Final LOAD : 33.93
LOAD TPS : 15.00    LOAD MAP : 60.00    TPS : 0.00  MAP : 1.55  Final LOAD : 37.50
LOAD TPS : 15.00    LOAD MAP : 67.14    TPS : 0.00  MAP : 1.65  Final LOAD : 41.07
LOAD TPS : 15.00    LOAD MAP : 74.29    TPS : 0.00  MAP : 1.75  Final LOAD : 44.64
LOAD TPS : 15.00    LOAD MAP : 81.43    TPS : 0.00  MAP : 1.85  Final LOAD : 48.21
LOAD TPS : 15.00    LOAD MAP : 85.00    TPS : 0.00  MAP : 1.90  Final LOAD : 50.00
LOAD TPS : 20.60    LOAD MAP : 10.00    TPS : 0.40  MAP : 0.85  Final LOAD : 15.30
LOAD TPS : 20.60    LOAD MAP : 17.14    TPS : 0.40  MAP : 0.95  Final LOAD : 18.87
LOAD TPS : 20.60    LOAD MAP : 24.29    TPS : 0.40  MAP : 1.05  Final LOAD : 22.44
LOAD TPS : 20.60    LOAD MAP : 31.43    TPS : 0.40  MAP : 1.15  Final LOAD : 26.01
LOAD TPS : 20.60    LOAD MAP : 38.57    TPS : 0.40  MAP : 1.25  Final LOAD : 29.59
LOAD TPS : 20.60    LOAD MAP : 45.71    TPS : 0.40  MAP : 1.35  Final LOAD : 33.16
LOAD TPS : 20.60    LOAD MAP : 52.86    TPS : 0.40  MAP : 1.45  Final LOAD : 36.73
LOAD TPS : 20.60    LOAD MAP : 60.00    TPS : 0.40  MAP : 1.55  Final LOAD : 40.30
LOAD TPS : 20.60    LOAD MAP : 67.14    TPS : 0.40  MAP : 1.65  Final LOAD : 43.87
LOAD TPS : 20.60    LOAD MAP : 74.29    TPS : 0.40  MAP : 1.75  Final LOAD : 47.44
LOAD TPS : 20.60    LOAD MAP : 81.43    TPS : 0.40  MAP : 1.85  Final LOAD : 51.01
LOAD TPS : 20.60    LOAD MAP : 85.00    TPS : 0.40  MAP : 1.90  Final LOAD : 52.80
LOAD TPS : 26.20    LOAD MAP : 10.00    TPS : 0.80  MAP : 0.85  Final LOAD : 18.10
LOAD TPS : 26.20    LOAD MAP : 17.14    TPS : 0.80  MAP : 0.95  Final LOAD : 21.67
LOAD TPS : 26.20    LOAD MAP : 24.29    TPS : 0.80  MAP : 1.05  Final LOAD : 25.24
LOAD TPS : 26.20    LOAD MAP : 31.43    TPS : 0.80  MAP : 1.15  Final LOAD : 28.81
LOAD TPS : 26.20    LOAD MAP : 38.57    TPS : 0.80  MAP : 1.25  Final LOAD : 32.39
LOAD TPS : 26.20    LOAD MAP : 45.71    TPS : 0.80  MAP : 1.35  Final LOAD : 35.96
LOAD TPS : 26.20    LOAD MAP : 52.86    TPS : 0.80  MAP : 1.45  Final LOAD : 39.53
LOAD TPS : 26.20    LOAD MAP : 60.00    TPS : 0.80  MAP : 1.55  Final LOAD : 43.10
LOAD TPS : 26.20    LOAD MAP : 67.14    TPS : 0.80  MAP : 1.65  Final LOAD : 46.67
LOAD TPS : 26.20    LOAD MAP : 74.29    TPS : 0.80  MAP : 1.75  Final LOAD : 50.24
LOAD TPS : 26.20    LOAD MAP : 81.43    TPS : 0.80  MAP : 1.85  Final LOAD : 53.81
LOAD TPS : 26.20    LOAD MAP : 85.00    TPS : 0.80  MAP : 1.90  Final LOAD : 55.60
LOAD TPS : 31.80    LOAD MAP : 10.00    TPS : 1.20  MAP : 0.85  Final LOAD : 20.90
LOAD TPS : 31.80    LOAD MAP : 17.14    TPS : 1.20  MAP : 0.95  Final LOAD : 24.47
LOAD TPS : 31.80    LOAD MAP : 24.29    TPS : 1.20  MAP : 1.05  Final LOAD : 28.04
LOAD TPS : 31.80    LOAD MAP : 31.43    TPS : 1.20  MAP : 1.15  Final LOAD : 31.61
LOAD TPS : 31.80    LOAD MAP : 38.57    TPS : 1.20  MAP : 1.25  Final LOAD : 35.19
LOAD TPS : 31.80    LOAD MAP : 45.71    TPS : 1.20  MAP : 1.35  Final LOAD : 38.76
LOAD TPS : 31.80    LOAD MAP : 52.86    TPS : 1.20  MAP : 1.45  Final LOAD : 42.33
LOAD TPS : 31.80    LOAD MAP : 60.00    TPS : 1.20  MAP : 1.55  Final LOAD : 45.90
LOAD TPS : 31.80    LOAD MAP : 67.14    TPS : 1.20  MAP : 1.65  Final LOAD : 49.47
LOAD TPS : 31.80    LOAD MAP : 74.29    TPS : 1.20  MAP : 1.75  Final LOAD : 53.04
LOAD TPS : 31.80    LOAD MAP : 81.43    TPS : 1.20  MAP : 1.85  Final LOAD : 56.61
LOAD TPS : 31.80    LOAD MAP : 85.00    TPS : 1.20  MAP : 1.90  Final LOAD : 58.40
LOAD TPS : 37.40    LOAD MAP : 10.00    TPS : 1.60  MAP : 0.85  Final LOAD : 23.70
LOAD TPS : 37.40    LOAD MAP : 17.14    TPS : 1.60  MAP : 0.95  Final LOAD : 27.27
LOAD TPS : 37.40    LOAD MAP : 24.29    TPS : 1.60  MAP : 1.05  Final LOAD : 30.84
LOAD TPS : 37.40    LOAD MAP : 31.43    TPS : 1.60  MAP : 1.15  Final LOAD : 34.41
LOAD TPS : 37.40    LOAD MAP : 38.57    TPS : 1.60  MAP : 1.25  Final LOAD : 37.99
LOAD TPS : 37.40    LOAD MAP : 45.71    TPS : 1.60  MAP : 1.35  Final LOAD : 41.56
LOAD TPS : 37.40    LOAD MAP : 52.86    TPS : 1.60  MAP : 1.45  Final LOAD : 45.13
LOAD TPS : 37.40    LOAD MAP : 60.00    TPS : 1.60  MAP : 1.55  Final LOAD : 48.70
LOAD TPS : 37.40    LOAD MAP : 67.14    TPS : 1.60  MAP : 1.65  Final LOAD : 52.27
LOAD TPS : 37.40    LOAD MAP : 74.29    TPS : 1.60  MAP : 1.75  Final LOAD : 55.84
LOAD TPS : 37.40    LOAD MAP : 81.43    TPS : 1.60  MAP : 1.85  Final LOAD : 59.41
LOAD TPS : 37.40    LOAD MAP : 85.00    TPS : 1.60  MAP : 1.90  Final LOAD : 61.20
LOAD TPS : 43.00    LOAD MAP : 10.00    TPS : 2.00  MAP : 0.85  Final LOAD : 26.50
LOAD TPS : 43.00    LOAD MAP : 17.14    TPS : 2.00  MAP : 0.95  Final LOAD : 30.07
LOAD TPS : 43.00    LOAD MAP : 24.29    TPS : 2.00  MAP : 1.05  Final LOAD : 33.64
LOAD TPS : 43.00    LOAD MAP : 31.43    TPS : 2.00  MAP : 1.15  Final LOAD : 37.21
LOAD TPS : 43.00    LOAD MAP : 38.57    TPS : 2.00  MAP : 1.25  Final LOAD : 40.79
LOAD TPS : 43.00    LOAD MAP : 45.71    TPS : 2.00  MAP : 1.35  Final LOAD : 44.36
LOAD TPS : 43.00    LOAD MAP : 52.86    TPS : 2.00  MAP : 1.45  Final LOAD : 47.93
LOAD TPS : 43.00    LOAD MAP : 60.00    TPS : 2.00  MAP : 1.55  Final LOAD : 51.50
LOAD TPS : 43.00    LOAD MAP : 67.14    TPS : 2.00  MAP : 1.65  Final LOAD : 55.07
LOAD TPS : 43.00    LOAD MAP : 74.29    TPS : 2.00  MAP : 1.75  Final LOAD : 58.64
LOAD TPS : 43.00    LOAD MAP : 81.43    TPS : 2.00  MAP : 1.85  Final LOAD : 62.21
LOAD TPS : 43.00    LOAD MAP : 85.00    TPS : 2.00  MAP : 1.90  Final LOAD : 64.00
LOAD TPS : 48.60    LOAD MAP : 10.00    TPS : 2.40  MAP : 0.85  Final LOAD : 29.30
LOAD TPS : 48.60    LOAD MAP : 17.14    TPS : 2.40  MAP : 0.95  Final LOAD : 32.87
LOAD TPS : 48.60    LOAD MAP : 24.29    TPS : 2.40  MAP : 1.05  Final LOAD : 36.44
LOAD TPS : 48.60    LOAD MAP : 31.43    TPS : 2.40  MAP : 1.15  Final LOAD : 40.01
LOAD TPS : 48.60    LOAD MAP : 38.57    TPS : 2.40  MAP : 1.25  Final LOAD : 43.59
LOAD TPS : 48.60    LOAD MAP : 45.71    TPS : 2.40  MAP : 1.35  Final LOAD : 47.16
LOAD TPS : 48.60    LOAD MAP : 52.86    TPS : 2.40  MAP : 1.45  Final LOAD : 50.73
LOAD TPS : 48.60    LOAD MAP : 60.00    TPS : 2.40  MAP : 1.55  Final LOAD : 54.30
LOAD TPS : 48.60    LOAD MAP : 67.14    TPS : 2.40  MAP : 1.65  Final LOAD : 57.87
LOAD TPS : 48.60    LOAD MAP : 74.29    TPS : 2.40  MAP : 1.75  Final LOAD : 61.44
LOAD TPS : 48.60    LOAD MAP : 81.43    TPS : 2.40  MAP : 1.85  Final LOAD : 65.01
LOAD TPS : 48.60    LOAD MAP : 85.00    TPS : 2.40  MAP : 1.90  Final LOAD : 66.80
LOAD TPS : 54.20    LOAD MAP : 10.00    TPS : 2.80  MAP : 0.85  Final LOAD : 32.10
LOAD TPS : 54.20    LOAD MAP : 17.14    TPS : 2.80  MAP : 0.95  Final LOAD : 35.67
LOAD TPS : 54.20    LOAD MAP : 24.29    TPS : 2.80  MAP : 1.05  Final LOAD : 39.24
LOAD TPS : 54.20    LOAD MAP : 31.43    TPS : 2.80  MAP : 1.15  Final LOAD : 42.81
LOAD TPS : 54.20    LOAD MAP : 38.57    TPS : 2.80  MAP : 1.25  Final LOAD : 46.39
LOAD TPS : 54.20    LOAD MAP : 45.71    TPS : 2.80  MAP : 1.35  Final LOAD : 49.96
LOAD TPS : 54.20    LOAD MAP : 52.86    TPS : 2.80  MAP : 1.45  Final LOAD : 53.53
LOAD TPS : 54.20    LOAD MAP : 60.00    TPS : 2.80  MAP : 1.55  Final LOAD : 57.10
LOAD TPS : 54.20    LOAD MAP : 67.14    TPS : 2.80  MAP : 1.65  Final LOAD : 60.67
LOAD TPS : 54.20    LOAD MAP : 74.29    TPS : 2.80  MAP : 1.75  Final LOAD : 64.24
LOAD TPS : 54.20    LOAD MAP : 81.43    TPS : 2.80  MAP : 1.85  Final LOAD : 67.81
LOAD TPS : 54.20    LOAD MAP : 85.00    TPS : 2.80  MAP : 1.90  Final LOAD : 69.60
LOAD TPS : 59.80    LOAD MAP : 10.00    TPS : 3.20  MAP : 0.85  Final LOAD : 34.90
LOAD TPS : 59.80    LOAD MAP : 17.14    TPS : 3.20  MAP : 0.95  Final LOAD : 38.47
LOAD TPS : 59.80    LOAD MAP : 24.29    TPS : 3.20  MAP : 1.05  Final LOAD : 42.04
LOAD TPS : 59.80    LOAD MAP : 31.43    TPS : 3.20  MAP : 1.15  Final LOAD : 45.61
LOAD TPS : 59.80    LOAD MAP : 38.57    TPS : 3.20  MAP : 1.25  Final LOAD : 49.19
LOAD TPS : 59.80    LOAD MAP : 45.71    TPS : 3.20  MAP : 1.35  Final LOAD : 52.76
LOAD TPS : 59.80    LOAD MAP : 52.86    TPS : 3.20  MAP : 1.45  Final LOAD : 56.33
LOAD TPS : 59.80    LOAD MAP : 60.00    TPS : 3.20  MAP : 1.55  Final LOAD : 59.90
LOAD TPS : 59.80    LOAD MAP : 67.14    TPS : 3.20  MAP : 1.65  Final LOAD : 63.47
LOAD TPS : 59.80    LOAD MAP : 74.29    TPS : 3.20  MAP : 1.75  Final LOAD : 67.04
LOAD TPS : 59.80    LOAD MAP : 81.43    TPS : 3.20  MAP : 1.85  Final LOAD : 70.61
LOAD TPS : 59.80    LOAD MAP : 85.00    TPS : 3.20  MAP : 1.90  Final LOAD : 72.40
LOAD TPS : 65.40    LOAD MAP : 10.00    TPS : 3.60  MAP : 0.85  Final LOAD : 37.70
LOAD TPS : 65.40    LOAD MAP : 17.14    TPS : 3.60  MAP : 0.95  Final LOAD : 41.27
LOAD TPS : 65.40    LOAD MAP : 24.29    TPS : 3.60  MAP : 1.05  Final LOAD : 44.84
LOAD TPS : 65.40    LOAD MAP : 31.43    TPS : 3.60  MAP : 1.15  Final LOAD : 48.41
LOAD TPS : 65.40    LOAD MAP : 38.57    TPS : 3.60  MAP : 1.25  Final LOAD : 51.99
LOAD TPS : 65.40    LOAD MAP : 45.71    TPS : 3.60  MAP : 1.35  Final LOAD : 55.56
LOAD TPS : 65.40    LOAD MAP : 52.86    TPS : 3.60  MAP : 1.45  Final LOAD : 59.13
LOAD TPS : 65.40    LOAD MAP : 60.00    TPS : 3.60  MAP : 1.55  Final LOAD : 62.70
LOAD TPS : 65.40    LOAD MAP : 67.14    TPS : 3.60  MAP : 1.65  Final LOAD : 66.27
LOAD TPS : 65.40    LOAD MAP : 74.29    TPS : 3.60  MAP : 1.75  Final LOAD : 69.84
LOAD TPS : 65.40    LOAD MAP : 81.43    TPS : 3.60  MAP : 1.85  Final LOAD : 73.41
LOAD TPS : 65.40    LOAD MAP : 85.00    TPS : 3.60  MAP : 1.90  Final LOAD : 75.20
LOAD TPS : 71.00    LOAD MAP : 10.00    TPS : 4.00  MAP : 0.85  Final LOAD : 40.50
LOAD TPS : 71.00    LOAD MAP : 17.14    TPS : 4.00  MAP : 0.95  Final LOAD : 44.07
LOAD TPS : 71.00    LOAD MAP : 24.29    TPS : 4.00  MAP : 1.05  Final LOAD : 47.64
LOAD TPS : 71.00    LOAD MAP : 31.43    TPS : 4.00  MAP : 1.15  Final LOAD : 51.21
LOAD TPS : 71.00    LOAD MAP : 38.57    TPS : 4.00  MAP : 1.25  Final LOAD : 54.79
LOAD TPS : 71.00    LOAD MAP : 45.71    TPS : 4.00  MAP : 1.35  Final LOAD : 58.36
LOAD TPS : 71.00    LOAD MAP : 52.86    TPS : 4.00  MAP : 1.45  Final LOAD : 61.93
LOAD TPS : 71.00    LOAD MAP : 60.00    TPS : 4.00  MAP : 1.55  Final LOAD : 65.50
LOAD TPS : 71.00    LOAD MAP : 67.14    TPS : 4.00  MAP : 1.65  Final LOAD : 69.07
LOAD TPS : 71.00    LOAD MAP : 74.29    TPS : 4.00  MAP : 1.75  Final LOAD : 72.64
LOAD TPS : 71.00    LOAD MAP : 81.43    TPS : 4.00  MAP : 1.85  Final LOAD : 76.21
LOAD TPS : 71.00    LOAD MAP : 85.00    TPS : 4.00  MAP : 1.90  Final LOAD : 78.00
LOAD TPS : 76.60    LOAD MAP : 10.00    TPS : 4.40  MAP : 0.85  Final LOAD : 43.30
LOAD TPS : 76.60    LOAD MAP : 17.14    TPS : 4.40  MAP : 0.95  Final LOAD : 46.87
LOAD TPS : 76.60    LOAD MAP : 24.29    TPS : 4.40  MAP : 1.05  Final LOAD : 50.44
LOAD TPS : 76.60    LOAD MAP : 31.43    TPS : 4.40  MAP : 1.15  Final LOAD : 54.01
LOAD TPS : 76.60    LOAD MAP : 38.57    TPS : 4.40  MAP : 1.25  Final LOAD : 57.59
LOAD TPS : 76.60    LOAD MAP : 45.71    TPS : 4.40  MAP : 1.35  Final LOAD : 61.16
LOAD TPS : 76.60    LOAD MAP : 52.86    TPS : 4.40  MAP : 1.45  Final LOAD : 64.73
LOAD TPS : 76.60    LOAD MAP : 60.00    TPS : 4.40  MAP : 1.55  Final LOAD : 68.30
LOAD TPS : 76.60    LOAD MAP : 67.14    TPS : 4.40  MAP : 1.65  Final LOAD : 71.87
LOAD TPS : 76.60    LOAD MAP : 74.29    TPS : 4.40  MAP : 1.75  Final LOAD : 75.44
LOAD TPS : 76.60    LOAD MAP : 81.43    TPS : 4.40  MAP : 1.85  Final LOAD : 79.01
LOAD TPS : 76.60    LOAD MAP : 85.00    TPS : 4.40  MAP : 1.90  Final LOAD : 80.80
LOAD TPS : 82.20    LOAD MAP : 10.00    TPS : 4.80  MAP : 0.85  Final LOAD : 46.10
LOAD TPS : 82.20    LOAD MAP : 17.14    TPS : 4.80  MAP : 0.95  Final LOAD : 49.67
LOAD TPS : 82.20    LOAD MAP : 24.29    TPS : 4.80  MAP : 1.05  Final LOAD : 53.24
LOAD TPS : 82.20    LOAD MAP : 31.43    TPS : 4.80  MAP : 1.15  Final LOAD : 56.81
LOAD TPS : 82.20    LOAD MAP : 38.57    TPS : 4.80  MAP : 1.25  Final LOAD : 60.39
LOAD TPS : 82.20    LOAD MAP : 45.71    TPS : 4.80  MAP : 1.35  Final LOAD : 63.96
LOAD TPS : 82.20    LOAD MAP : 52.86    TPS : 4.80  MAP : 1.45  Final LOAD : 67.53
LOAD TPS : 82.20    LOAD MAP : 60.00    TPS : 4.80  MAP : 1.55  Final LOAD : 71.10
LOAD TPS : 82.20    LOAD MAP : 67.14    TPS : 4.80  MAP : 1.65  Final LOAD : 74.67
LOAD TPS : 82.20    LOAD MAP : 74.29    TPS : 4.80  MAP : 1.75  Final LOAD : 78.24
LOAD TPS : 82.20    LOAD MAP : 81.43    TPS : 4.80  MAP : 1.85  Final LOAD : 81.81
LOAD TPS : 82.20    LOAD MAP : 85.00    TPS : 4.80  MAP : 1.90  Final LOAD : 83.60
LOAD TPS : 85.00    LOAD MAP : 10.00    TPS : 5.00  MAP : 0.85  Final LOAD : 47.50
LOAD TPS : 85.00    LOAD MAP : 17.14    TPS : 5.00  MAP : 0.95  Final LOAD : 51.07
LOAD TPS : 85.00    LOAD MAP : 24.29    TPS : 5.00  MAP : 1.05  Final LOAD : 54.64
LOAD TPS : 85.00    LOAD MAP : 31.43    TPS : 5.00  MAP : 1.15  Final LOAD : 58.21
LOAD TPS : 85.00    LOAD MAP : 38.57    TPS : 5.00  MAP : 1.25  Final LOAD : 61.79
LOAD TPS : 85.00    LOAD MAP : 45.71    TPS : 5.00  MAP : 1.35  Final LOAD : 65.36
LOAD TPS : 85.00    LOAD MAP : 52.86    TPS : 5.00  MAP : 1.45  Final LOAD : 68.93
LOAD TPS : 85.00    LOAD MAP : 60.00    TPS : 5.00  MAP : 1.55  Final LOAD : 72.50
LOAD TPS : 85.00    LOAD MAP : 67.14    TPS : 5.00  MAP : 1.65  Final LOAD : 76.07
LOAD TPS : 85.00    LOAD MAP : 74.29    TPS : 5.00  MAP : 1.75  Final LOAD : 79.64
LOAD TPS : 85.00    LOAD MAP : 81.43    TPS : 5.00  MAP : 1.85  Final LOAD : 83.21
LOAD TPS : 85.00    LOAD MAP : 85.00    TPS : 5.00  MAP : 1.90  Final LOAD : 85.00

NOTE : Here, I'm not providing all serial monitor output. Just needed part of OUTPUT here displayed.

Here, this is modified code which provide result which I want.
float TPS_MIN = 0.00;
float TPS_MAX = 5.00;

float MAP_MIN = 0.85;
float MAP_MAX = 1.90;

int LOAD_MIN = 2;
int LOAD_MAX = 100;

int RPM_MIN = 400;
int RPM_MAX = 6000;

float LOAD_MIN_TPS_MIN = 2.00;
float LOAD_MAX_TPS_MIN = 10.00;

float LOAD_MIN_TPS_MAX = 15.00;
float LOAD_MAX_TPS_MAX = 85.00;

float LOAD_MIN_MAP_MIN = 2.00;
float LOAD_MAX_MAP_MIN = 15.00;

float LOAD_MIN_MAP_MAX = 10.00;
float LOAD_MAX_MAP_MAX = 85.00;

float injTime_MIN_LOAD_MIN = 4.00;
float injTime_MAX_LOAD_MIN = 4.60;

float injTime_MIN_LOAD_MAX = 8.06;
float injTime_MAX_LOAD_MAX = 14.86;

float injTime_MIN_RPM_MIN = 4.00;
float injTime_MAX_RPM_MIN = 8.06;

float injTime_MIN_RPM_MAX = 4.60;
float injTime_MAX_RPM_MAX = 14.86;

float mTPSmin;
float mTPSmax;
float mMAPmin;
float mMAPmax;

float yTPSmin;
float yTPSmax;
float yMAPmin;
float yMAPmax;

float mTPS;
float mMAP;

float yTPS;
float yMAP;

float LOAD;

float TPS, MAP;

float mLOADmin;
float mLOADmax;
float mRPMmin;
float mRPMmax;

float yLOADmin;
float yLOADmax;
float yRPMmin;
float yRPMmax;

float mLOAD;
float mRPM;

float yLOAD;
float yRPM;

float yInjTime;

int RPM;

void setup()
{
  Serial.begin(9600);
}

void loop()
{
    TPS = analogRead(A0) * (5.0 / 1023.0);
    MAP = analogRead(A1) * (1.90 / 1023.0);
    RPM = analogRead(A2) * (6000 / 1023.0);

    mTPSmin = (LOAD_MAX_TPS_MIN - LOAD_MIN_TPS_MIN) / (TPS_MAX - TPS_MIN);

    Serial.print("mTPSmin : ");
    Serial.println(mTPSmin);

    yTPSmin = mTPSmin * (TPS - TPS_MIN) + LOAD_MIN_TPS_MIN;

    Serial.print("TPS : ");
    Serial.print(TPS);
    Serial.print("\t");
    Serial.print("LOAD : ");
    Serial.println(yTPSmin);

    mTPSmax = (LOAD_MAX_TPS_MAX - LOAD_MIN_TPS_MAX) / (TPS_MAX - TPS_MIN);

    Serial.print("mTPSmax : ");
    Serial.println(mTPSmax);

    yTPSmax = mTPSmax * (TPS - TPS_MIN) + LOAD_MIN_TPS_MAX;

    Serial.print("TPS : ");
    Serial.print(TPS);
    Serial.print("\t");
    Serial.print("LOAD : ");
    Serial.println(yTPSmax);

    mMAPmin = (LOAD_MAX_MAP_MIN - LOAD_MIN_MAP_MIN) / (MAP_MAX - MAP_MIN);

    Serial.print("mMAPmin : ");
    Serial.println(mMAPmin);

    yMAPmin = mMAPmin * (MAP - MAP_MIN) + LOAD_MIN_MAP_MIN;

    Serial.print("MAP : ");
    Serial.print(MAP);
    Serial.print("\t");
    Serial.print("LOAD : ");
    Serial.println(yMAPmin);

    mMAPmax = (LOAD_MAX_MAP_MAX - LOAD_MIN_MAP_MAX) / (MAP_MAX - MAP_MIN);

    Serial.print("mMAPmax : ");
    Serial.println(mMAPmax);

    yMAPmax = mMAPmax * (MAP - MAP_MIN) + LOAD_MIN_MAP_MAX;

    Serial.print("MAP : ");
    Serial.print(MAP);
    Serial.print("\t");
    Serial.print("LOAD : ");
    Serial.println(yMAPmax);

    mTPS = (yMAPmax - yMAPmin) / (TPS_MAX - TPS_MIN);

    Serial.print("mTPS : ");
    Serial.println(mTPS);

    yTPS = mTPS * (TPS - TPS_MIN) + yMAPmin;

    Serial.print("TPS : ");
    Serial.print(TPS);
    Serial.print("\t");
    Serial.print("LOAD : ");
    Serial.println(yTPS);

    mMAP = (yTPSmax - yTPSmin) / (MAP_MAX - MAP_MIN);

    Serial.print("mMAP : ");
    Serial.println(mMAP);

    yMAP = mMAP * (MAP - MAP_MIN) + yTPSmin;

    Serial.print("MAP : ");
    Serial.print(MAP);
    Serial.print("\t");
    Serial.print("LOAD : ");
    Serial.println(yMAP);

    LOAD = (yTPS + yMAP) / 2;
    Serial.print("Final LOAD : ");
    Serial.println(LOAD);

    mLOADmin = (injTime_MAX_LOAD_MIN - injTime_MIN_LOAD_MIN) / (LOAD_MAX - LOAD_MIN);

    Serial.print("mLOADmin : ");
    Serial.println(mLOADmin);

    yLOADmin = mLOADmin * (LOAD - LOAD_MIN) + injTime_MIN_LOAD_MIN;

    Serial.print("LOAD : ");
    Serial.print(LOAD);
    Serial.print("\t");
    Serial.print("injTime : ");
    Serial.println(yLOADmin);

    mLOADmax = (injTime_MAX_LOAD_MAX - injTime_MIN_LOAD_MAX) / (LOAD_MAX - LOAD_MIN);

    Serial.print("mLOADmax : ");
    Serial.println(mLOADmax);

    yLOADmax = mLOADmax * (LOAD - LOAD_MIN) + injTime_MIN_LOAD_MAX;

    Serial.print("LOAD : ");
    Serial.print(LOAD);
    Serial.print("\t");
    Serial.print("injTime : ");
    Serial.println(yLOADmax);

    mRPMmin = (injTime_MAX_RPM_MIN - injTime_MIN_RPM_MIN) / (RPM_MAX - RPM_MIN);

    Serial.print("mRPMmin : ");
    Serial.println(mRPMmin);

    yRPMmin = mRPMmin * (RPM - RPM_MIN) + injTime_MIN_RPM_MIN;

    Serial.print("RPM : ");
    Serial.print(RPM);
    Serial.print("\t");
    Serial.print("injTime : ");
    Serial.println(yRPMmin);

    mRPMmax = (injTime_MAX_RPM_MAX - injTime_MIN_RPM_MAX) / (RPM_MAX - RPM_MIN);

    Serial.print("mRPMmax : ");
    Serial.println(mRPMmax);

    yRPMmax = mRPMmax * (RPM - RPM_MIN) + injTime_MIN_RPM_MAX;

    Serial.print("RPM : ");
    Serial.print(RPM);
    Serial.print("\t");
    Serial.print("injTime : ");
    Serial.println(yRPMmax);

    mLOAD = (yRPMmax - yRPMmin) / (LOAD_MAX - LOAD_MIN);

    Serial.print("mLOAD : ");
    Serial.println(mLOAD);

    yLOAD = mLOAD * (LOAD - LOAD_MIN) + yRPMmin;

    Serial.print("LOAD : ");
    Serial.print(LOAD);
    Serial.print("\t");
    Serial.print("injTime : ");
    Serial.println(yLOAD);

    mRPM = (yLOADmax - yLOADmin) / (RPM_MAX - RPM_MIN);

    Serial.print("mRPM : ");
    Serial.println(mRPM);

    yRPM = mRPM * (RPM - RPM_MIN) + yLOADmin;

    Serial.print("RPM : ");
    Serial.print(RPM);
    Serial.print("\t");
    Serial.print("injTime : ");
    Serial.println(yRPM);

    yInjTime = (yLOAD + yRPM) / 2;
    Serial.print("Final injTime : ");
    Serial.println(yInjTime);

    delay(1000000);
}


text:
Measure the duration a pin is in a HIGH state
I'm struggling with getting the button configuration. Simply, I have a LED controlling setup for a button to increase its brightness when pressed. However, I would like to have it setup like this:

When button is pressed.
change the value by 1,
wait for 500ms,
Then go fast (with the usual void loop time).

Is it something to do with interrupts? If I just write it like below, it actually (obviously) goes by +1 by itself, even when button is not pressed.
void loop() {
  if(digitalRead(button_pressed) == HIGH) {
    current_state = current_state+1;
    delay(500);
    current_state = current_state+1;
  }
}

It is not clear to me what you want and what you got.

Simply, as you would imagine volume control for instance. You don't want to have it to randomly detect button presses, I mean - sometimes when you want to press the button just once it would detect it as '3' or more. So generally - when button is pressed and hold - to add "1" by the counter, but if it's pressed >1sec, go with the arduino clock in the void loop, changing the volume fast.

Fairly simple. If thee button IS pressed, increment a button counter, otherwise, reset it. Test the button counter to see if it is bigger than a preset number (that determines how long a long press needs to be). If so, increment volume fast. If not, increment volume slowly.

Non-blocking version.
bool old_button_state = LOW;
void loop()
{
    if(digitalRead(button_pressed) == HIGH)
    {
        current_state = current_state+1

        if( old_button_state==LOW )
            delay(500); // long delay
        else
            delay(100); // short delay

        old_button_state = HIGH;
    }
    else
    {
        old_button_state = LOW;
    }
}

Simplistic version.
void loop()
{
    if(digitalRead(button_pressed) == HIGH)
    {
        current_state = current_state+1
        delay(500);// long delay

        // repeat while the button is being pressed
        while(digitalRead(button_pressed) == HIGH)
        {
            current_state = current_state+1
            delay(100); //short delay
        }
    }
}

Ideally you wouldn't just wait for 500ms, but 'break out' of this delay as soon as the button is released.

Thanks for that, but seems like it's not doing it's job.. not sure why, but it shows blank at first (I've got LCD to show this value), and when trying to go down with the "down" button, it shows the max. value I have set it up to.

That's what you get when you don't post the entire code :-) . The code above will do nothing will the button is being pressed. So while the button is pressed, the LCD will not be updated.

I added a non-blocking version to my answer.

Still something feels not right :) I mean, I would think of something like "check for the HIGH status being ON for 1 sec, add one step, after 1sec, go with the usual clock rate". That's the hard thing here

I don't quit understand. Doesnt the code work? Or do you want something that doesn't use the delay function?

Yes, it seems like it only 'sees' the 1sec delay, and it goes by one up each 1 sec, instead of going by plus one in 1sec and then fast.

1 second?  The delay is 500ms! Seems like your other code is adding an additional delay of 500ms.

Sorry, I have changed to 1sec, but still :)
Simply, as you would imagine volume control for instance. You don't want to have it to randomly detect button presses, I mean - sometimes when you want to press the button just once it would detect it as '3' or more. So generally - when button is pressed and hold - to add "1" by the counter, but if it's pressed >1sec, go with the arduino clock in the void loop, changing the volume fast.

long timenow, timelong=500;
int current_state = 0;
void increase_state()
{
    current_state++;
    Serial.println(current_state);
}

void loop()
 {
    if(digitalRead(button_pressed)) //button is pressed
    {
        timenow=millis();   //get current time
        increase_state(); // increase by 1
        while (digitalRead(button_pressed)) //check if the button is still pressed
            {
                //rapidly increase "current_state" by 1 if button is pressed more than 500ms with interval of 50ms.
                if ((millis()-timenow)>timelong)
                {
                increase_state();
                delay(50);
                }
            }
    }
    delay(500)
 }

The increment of current_state is always by 1. If button is pressed, it will always increase by 1, but if it's not a long press, you have to wait another 500ms to increase it values again.

Could you add a line with Serial monitor to print out the value? As I cannot quite adapt this to my code... let's say that starting value is 0, and then you would add values to it.

answer edited :)

Fairly simple.

I thought I would lay out my code here so it is more clear.
if (BTN_PRESSED()) {            //button is pressed now
    btn_cnt += 1;               //increment button counter
    if (btn_cnt >= BTN_LONGPRESS) {
        volume += VOLINC_FAST;  //btn has been pressed for a long time, so increment volume fast
    } else {
        volume += VOLINC_SLOW;                              //otherwise increment the button slowly
    }
} else btn_cnt = 0;             //button is not pressed so reset the counter

It basically follows what I laid out earlier and is self explanatory, I hope.
Formatting needs more work, obviously.
edit: reformatted the code a little bit to make it more readable.
here is an example of this code at work:

here, the code is used to detect a button press (active low) on RA0. Once the button counter (btn_cnt) has been pressed sufficiently long (set by BTN_LONGPRESS), it increments volume by VOLINC_FAST (=4); otherwise, it increments volume by VOLINC_SLOW (=1).
the simulation shows just that. the value of volume is output on PB0..7, to a dac to show more graphically what happens to volume's value.
1) when the button is high (=not pressed), volume is not changed and you see a flat line on the DAC output;
2) when the button is just pressed (but not sufficient to trigger BTN_LONGPRESS), volume is incremented slowly and you see the DAC's output goes up slowly (1 at a time);
3) when the button is pressed long enough, volulme is incremented fast and you see the DAC's output goes up much steeper.
Obviously, you can modulize the code so it can process multiple buttons and return multiple states - not pressed, pressed, long pressed, double pressed. or if you wish, allow it to process bounces.
all sorts of possibilities but the basic idea is the same.

I see, but thing with arduino is that you have it all in this "big" void loop, so even if you say it to "add 1", it could detect one button press as "5", and in fact add 1 five times.


text:
Arduino Mega read data from USB
I´m completely new to the arduino and not used to work with it. Due to an project I need to know the best way to transfer Data to my Arduino Mega. The transferred file will be an sliced 3D object. Is it possible to use the built in USB port to read from a stick? Or do I have to use a PC to transfer my data?
Please help me to answer this question since I have no clue how to manage to get the sliced file to my Arduino.

How big is your sliced 3D object? Are you sure, that it will fit on an Arduino Mega?

Accessing a USB stick is not directly possible and not cost effective to add to this platform (vs changing it for a cheaper one that can do so natively), but you can access an SD card, which you could of course have initialized on a PC via a USB adapter.

It would be easier to use a Raspberry Pi.  They support USB natively, so can read a memory stick or directly from a serial port.

The Arduino Mega doesn't support USB-host, so you can't connect a USB stick directly.
The easiest way is to connect it to a computer, and send the data over the serial connection.

And probably only a little bit of it at a time... for example Arduino-based 3d printers "drip feed" the data only a bit in advance of when it is being used, as a many-megabytes part file would not fit in the ATmega at once.  Of course this approach only works for tasks where the can be accessed with a fairly local view - anything that requires looking at separated parts of the data at once (like the conversion of a 3d model to toolpaths) has to be done beforehand on a computer with enough memory.

Thank you both for your ideas on the problem. @ChrisStratton the goal will be to create the toolpath on a machine with enough memory and to send the result to the Arduino. The Arduino then will be used just to control 3 motors to follow the created path and to control the printhead. Is it possible to send the toolpath via the USB port or do I have to establish some kind of other connection?

Since you're basically re-inventing the equivalent of a 3d printer firmware, you should probably start by thoroughly familiarizing yourself with how the open source ones work.   There are likely other gcode interpreters you can find as well.  To put it in historical terms, you'll be tunneling a serial channel through a USB port and more or less using it to emulate a punched tape...

So you just need to check that arduino serial is good enough-fastest it budges data from pc is 250000 baud -which is just over 30kb a second. To put the terminology in historical terms baud refers to the number of different symbols and was used with telegrams in the 19 century.Bit rate concerns two symbols.Thats why its 30kb.


text:
Arduino rc plane logger
Well, I want to make an rc plane with an arduino that logs to an sd card
A) Video
B) Accelerometer data
C) Tempature
D) Humitity
E) Atmospheric pressure
F) Gyroscope Data
What arduino/parts should I use? I have a maximum of 170 grams or 6 OZ.
The arduino will not control the plane, just log data. I'm thinking an arduino 101... but I would like to know if there is a lighter/better way.  THANKS! :)

I'm voting to close this question as off-topic because this is a "shopping" question.

OH, sorry. I didn't know.

It is not an Arduino answer but a Raspberry Pi with a Sense hat will record most of what you need with little coding.  Add a Pi camera and you have all this for about $100.  The Sense Hat temperature sensor doesn't work because it is too close to the CPU but you could get a digital thermometer for a few bucks.

This is VERY false. You don't need to learn Python. You can easily make a Pi and Pi Cam work with C++, a much more powerful language. WiringPi also has many functions such as pinMode() and digitalWrite()... Sounds familiar.

Thanks for the corretion @Dat Ha.  I have edited my post.

I've completed a similar project.

For the Arduino, I used a Pro Mini for its small size and weight.
For the accel/gyro, I used an MPU-6050. 2 bird, 1 stone!
For the Temp/Baro, I used an MPL3115A2. Again, 2 bird, 1 stone!
For the camera feed, use one of these pre-built things.


text:
Pulldown resistors and multiple switches
Maybe this is a question for Electronics SE but I’m not a member there yet so hopefully someone will have an answer here.
I did an experiment with having some push-to-make buttons connected to my Uno. I copied the circuit from the aduino.cc website and all worked exactly as expected. Here is my schematic of the circuit as I have it now:

The pins are both held LOW by the Pulldown resistor until the switch is closed, when they go HIGH.
All well and good. But I’ve just been looking at the circuit and something puzzles me. I can see a direct connection from Switch 1 to Pin 2 VIA the resistors and the Ground connection – and vice versa, S2 to P1. See my pathway in Red here:

Now, to be clear, this is NOT happening – but I just want to understand why not. Is it just that the 2 resistors in combination provide enough resistance to stop the opposite pin from going HIGH? In which case, this Pulldown resistor is actually serving 2 completely different functions in the circuit…?

An input pin is in what is known as high impedance mode. That is, to all intents and purposes, to the external circuit it looks like a massive resistor to ground.
This resistance can be in the millions of ohms.
So let's redraw your circuit with those input pins as big resistors:

simulate this circuit – Schematic created using CircuitLab
Now you can see how the schematic really looks (see how it's set up so +5V is at the top and GND is at the bottom - the [conventional] current flows then from top to bottom).
So with SW2 pushed (as shown) the current wants to flow from 5V (top) to GND (bottom). That goes through SW2, through R2, and down to ground. Some tiny amount also flows through R4, which represents the input pin.  Since by then the current is already at ground and has reached its destination there is no reason at all for it to then flow back up through R1, and back down to ground again through R3. For current to flow through R1 the voltage at IN1 would have to be negative since current will only flow from a higher to a lower voltage. And since it isn't negative, no current can flow.

This explains it the best way for me. I've marked it as the answer, thank you. So if we were to have NO R1 on this diagram, IN1 would still not go High because that would mean the current would have to flow back through R3 to get to the place where it's already managed to get...?

Call the resistors R1 and R2, the negative terminal Ground, and the positive terminal V+.  The junction of R1 and R2 is connected to Ground.  This holds the resistor ends at the junction to zero volts relative to ground.  Ignoring P2 for the moment, the other end of R2 is open circuit to V+ when S2 is open.  Applying Ohm's law, we have a finite resistance in series with an infinite resistance, so zero volts across R2 when S2 is open.  Thus one sees that voltage across R2 is not affected by voltage changes across R1.
P2 as an input is not completely an open circuit; typically its effect is similar to a multi-gigaohms resistor to some voltage between Ground and V+.
Edit:
More directly, observe that the voltage at the Ground ends of R1 and R2 is zero and remains at zero no matter what S1 and S2 do.  Thus, operation of S1 does not affect voltage at P2, and operation of S2 does not affect voltage at P1.

Sorry, I'm failing to understand this, why would there be zero volts across R2? I assume you mean with S1 closed...? Also, if we imagine replacing the resistors with just conductors, they would presumably have a "finite" resistance as well - but then that just looks like a direct circuit connecting S1 to P2.

@Lefty, see edit

jwpat7 +1 but I'm obviously deficient  in my understanding here so I will need to re-read your answer a few dozen more times before it starts to make sense to me. Fundamentally, I feel that, just because the ground ends of R1 and R2 are connected to ground, that doesn't mean that there is no circuit from  S1 to P2. If you replace the resistors in the circuit with straight conductors, you will see that there is nothing "special" about having a connection to ground - the value of the resistors therefore MUST be important (withing reason)...?

Well yes, there is a circuit from S1 to P2, but the resistors' junction is always at ground, thus any charge anywhere else in that circuit can flow only to that junction and ground. P2 - as an input - has "no" ability (read: very little) ability to source or sink current so with negligible current in R2 then by ohm's law, P2 must also be at ground.

It helped me to draw an equivalent schematic to yours when S1 is closed and S2 is open. P2 is neither high nor low by itself; it is a high-impedance (which is why you need a pulldown or pullup resistor). It is pulled to ground by R2 and the fact that the junction of the two resistors is grounded. If you disconnected that junction from ground, P2 would see a 20K pullup, but as it is, the (left) end of R2 stays at ground, regardless of what you apply to the P1-R1 junction.

simulate this circuit – Schematic created using CircuitLab

A simple rule of thumb is that electricity always follows the path of least resistance. The energy going over the switch has a lower resistance path to ground through the Arduino than it does through the pull-down resistor, so it will prefer to go that way than through one - or both resistors when it is available.

True - but (correct me if I'm wrong) the need for the Pulldown resistor shows that even an open circuit actually needs to be grounded to stop the pin from fluctuating - hence the need for the resistor. It seems to me that I would expect more current to flow through 2 resistors than to to flow through an open circuit..?


text:
How do I configure the Arduino IDE to look for source code in a subdirectory within the directory that holds my sketch?
I'm writing an Arduino program that contains various .h and .cpp files. Due to organizational needs, I have configured the directory that contains my Arduino sketch (.ino) to possess a subdirectory. This subdirectory contains related source code.
An example layout of my project directory is located below:
mysketch
    mysketch.ino
    mycode.h
    mycode.cpp
    mylibs
        mylib1.h
        mylib1.cpp
        mylib2.h
        mylib2.cpp
        mylib3.h
        mylib3.cpp

With this, I'm able to successfully #include the header files. However, the compiler then complains that mylib1.cpp, mylib2.cpp, and mylib3.cpp are not defined (however they are). I'm guessing that the Arduino only looks for source files within the same directory that the sketch lives in. Thus subdirectories contains source code are ignored.
I can then modify my directory layout such that all of the 'mylib.h/.cpp's' are in the same directory and the project compiles fine.
So my question: how do I configure the Arduino IDE to reference source code within a subdirectory? Also, I would prefer that the mylibs exist within the same directory, and not within the Arduino 'library' directory. This will allow me to then easily distribute the code as a single zipped folder.

In the Arduino IDE the answer is simple: you can't.
The Arduino IDE doesn't compile within the directory your sketch is in. Instead it writes out a fresh copy of all the files directly from the tabs in the IDE into a temporary build folder (munging them as it goes if they are .INO or .PDE) and then compiles them there. Anything else within your sketch folder is completely ignored.
If you want that kind of functionality you will have to use a different IDE.
For example, UECIDE lets you have a structure like:
MySketch/
    MySketch.ino
    libraries/
        MyLib1/
            MyLib1.h
            MyLib1.cpp
        MyLib2/
            MyLib2.h
            MyLib2.cpp

The behavior of the Arduino IDE with this sort of thing has changed over time so it depends on which version of the Arduino IDE you're using. With recent versions you can put the files in a src subfolder of your sketch folder and then do:
#include "src/mylib1.h"

or:
#include "src/mylib1/mylib1.h"

depending on how you want to organize the folder structure.
When doing this you may find that Arduino libraries often use incorrect include syntax in their source code. For example in mylib1.cpp:

#include <mylib1.h>

although wrong, would still work if the library was located in one of the Arduino libraries folders but with the library located in the sketch folder this no longer works and you need to change it to:
#include "mylib1.h"


text:
DS18b20 Order of sensors on a cable
I have a string of 10x DS18b20 sensors on a single two wire line (parasitic power). Below is a table of the sensors, Where they are located on the wire, and in what order where they discovered.
Serial              Order on wire*   Order discovered
286305560100002c    1                7
28a158610100006a    2                3
28ad48610100006b    3                6
2851ae60010000ad    4                4
289b426101000089    5                8
28cd1161010000ce    6                5
2864026101000030    7                1
280c766101000026    8                2

I read this document on how the OneWire discovers sensors on the bus. https://www.maximintegrated.com/en/app-notes/index.mvp/id/187
My question: Is there a way to detect the order of the sensors on a wire?

I don't think so. There is nothing different between the different sensor, other than a minute difference in resistance in the wire, due to a longer length.

The discovery order is according to the search algorithm (which depends on the ROM/ID number). You can either put the sensors in order when you have their ID or use a mapping table in your sketch. The search algorithm does not determine the physical order of the sensors.

There is no way to detect position on the bus because all devices are connected in parallel. This is why a serial or "chain" wire, added to the newer devices, is required.
(To complicate matters, what is the "order of devices" - or even the meaning of "order" in a center-fed bus, or a circular, star, or other branched network? Order is just something we perceive when looking at an end-fed linear network. Electrons don't care. Think of a capacitor (unfortunately, the bus behaves like one but that's another story) with two plates, several centimeters square, and a dozen 1-wire devices connected from plate to plate. Now what is their order? Ow, my brain hurts! Let's go back to linear buses.)
The discovery order is a function of the set of binary device IDs on the bus. There are two ways I know of to come to know the physical ordering, both empirical (i.e., by observation):

Connect the set of devices one at a time, to a temporary bus such as a breadboard. With an Arduino, read the their IDs and tag them (human readable). With knowledge of the discovery alogrithm, or by running actual discovery on an Arduino with all devices connected, write down the IDs in the order they are discovered which is invariant for a given set of device IDs. Assemble your wired bus with the devices in this order.
(The reverse of 1 and quicker to build, and is what you've already shown in your question: Wire the bus. With a simple Arduino program, repeatedly sample all devices on the bus and report print their indices and temperatures (the indices will be in discovery order). One at a time, warm each device with your hand and notice which device index is affected. Write down the physical position (first, second, ...) and the index. This is the mapping table between position and index. Include it in your control algorithm.

So I would say that the DS1820 for professional use is useless!
There is no simple way to add or replace a sensor on existing temperature measuring appliance and to be sure about what are you measuring. Am I right?

@Satman Sometimes the sensors don't respond anyway, so what you might think as sensor 3 would become sensor 2 if sensor 2 didn't respond. I wouldn't say they are useless, but you would need to know the sensor ID (something you might find out on the bench) before deploying it into the field. Using the ID would be much more accurate anyway, because then you are certain that you got a certain sensor, and not just because it happens to be 5th in a chain.

what you can apparently do is use the User Data space set aside for the alarm and add an ID in there. I have not done this yet but am looking at this option as my sensor array has over 40 sensors in a line and ideally I would like the top one to be 0 and the last one in the chain to be 40.

I found this application note.
APPLICATION NOTE 4037
Regain Location Information by Leveraging the 1-Wire® Chain Function—A Simple Signaling and Protocol Method Determines Device Physical Location
https://www.maximintegrated.com/en/app-notes/index.mvp/id/4037

Note that 1) this technique is not applicable to DS18b20 and similar 1-wire devices; and the new devices - when using this capability - are not 1-wire any more, the chained signal requiring another conductor.


text:
Error message - help needed
As many of you know (if you read my bio or simply read my previous questions), I'm trying to build a rocket. The code was going well, but once I split my objects into 2 files, a .h and .cpp file, this error message appeared.
The full code is on GitHub because it is simply too long!
Here is the error message :
Arduino: 1.8.1 (Windows 7), Board: "Arduino Pro or Pro Mini, ATmega328 (5V, 16 MHz)"

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpInitialize()'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpPacketAvailable()'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetAccel(long*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetAccel(int*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetAccel(VectorInt16*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetQuaternion(long*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetQuaternion(int*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetQuaternion(Quaternion*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetGyro(long*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetGyro(int*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetGyro(VectorInt16*, unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetLinearAccel(VectorInt16*, VectorInt16*, VectorFloat*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetLinearAccelInWorld(VectorInt16*, VectorInt16*, Quaternion*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetGravity(VectorFloat*, Quaternion*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetEuler(float*, Quaternion*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetYawPitchRoll(float*, Quaternion*, VectorFloat*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpProcessFIFOPacket(unsigned char const*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpReadAndProcessFIFOPacket(unsigned char, unsigned char*)'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

sketch\vehicle.ino.cpp.o (symbol from plugin): In function `Fins':

(.text+0x0): multiple definition of `MPU6050::dmpGetFIFOPacketSize()'

sketch\Gyroscope.cpp.o (symbol from plugin):(.text+0x0): first defined here

exit status 1
Error compiling for board Arduino Pro or Pro Mini.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Perhaps edit your question and say whether IDE starts the compile and link, or if not, show the commands used to compile and link the code.  Also, while code may be lengthy, in the question you could show a summary of the #include statements used in each unit of code.

The problem is the way the author of the MPU6050 library wrote MPU6050_6Axis_MotionApps20.h is not compatible with the way you're using the library. Multiple proposals for fixing the issue have been submitted but they are all outdated to some extent:
https://github.com/jrowberg/i2cdevlib/pull/174
download at https://github.com/martinjos/i2cdevlib/archive/master.zip
https://github.com/jrowberg/i2cdevlib/pull/162
download at https://github.com/cgel/i2cdevlib/archive/master.zip
https://github.com/jrowberg/i2cdevlib/pull/268
download at https://github.com/onliner10/i2cdevlib/archive/master.zip

This is 3 years way too late, but here's what I did

In my own mpu_sensor.h file, I only included

#ifndef MPU_SENSOR_H
#define MPU_SENSOR_H

#include "MPU6050.h"
#include "helper_3dmath.h"
....
#endif

Note that I don't include MPU6050_6Axis_MotionApps20, since most datatypes are declared in MPU6050 and helper_3dmath

In my mpu_sensor.cpp file, here's my includes:

#include "MPU6050_6Axis_MotionApps20.h"
#include "mpu_sensor.h"

Please note that MPU6050_6Axis_MotionApps20.h must be before the line that includes mpu_sensor.h.
It works now.
I agree that the library itself should be updated, but it seems like the author is not updating for the past few years.