message:
Porting SH1106 Oled Driver - 128 x 64 / 128 x 32 Screen is garbled but partially responsive

I'm porting the [SH1106][1] driver to netmf and have found several libraries that more or less accomplish the same thing. A few were much easier to understand and had less abstraction so I followed those.

I've tried the U8glib with my arduino and it works just fine. The ported display driver yields these results:

[![enter image description here][2]][2]
inverted:
[![enter image description here][3]][3]

What you're looking at is the screen right after the initialization and attempting to draw a filled circle. You can see the bottom of the circle at the top of the screen. Somehow the origin or page is shifted, but I don't fully understand what's going on. I can send the invert display command and that works as well and turn the display on and off. My initialization code is this:

<!-- language: c -->

    public void init()
    {
        resetPin.Write(true);
        Thread.Sleep(1); // VDD (3.3V) goes high at start,
        resetPin.Write(false); // bring reset low
        Thread.Sleep(10); // wait 10ms
        resetPin.Write(true); // bring out of reset

        dcPin.Write(DisplayCommand);

        SendCommandB(0xAE);    /*display off*/

        SendCommandB(0x02);    /*set lower column address*/
        SendCommandB(0x10);    /*set higher column address*/

        SendCommandB(0x41);//0x40);    /*set display start line*/
        SendCommandB(0xB0);    /*set page address*/
        SendCommandB(0x81);    /*contract control*/
        SendCommandB(0x80);//contrast);    /*128*/
        SendCommandB(0xA1);    /*set segment remap*/
        SendCommandB(0xA6);//invertSetting);    /*normal / reverse*/
        SendCommandB(0xA8);    /*multiplex ratio*/
        SendCommandB(0x3F);    /*duty = 1/32*/
        SendCommandB(0xAD);    /*set charge pump enable*/
        SendCommandB(0x8B);     /*external VCC   */
        SendCommandB(0x30);    // | Vpp);    /*0X30---0X33  set VPP   9V liangdu!!!!*/
        SendCommandB(0xC8);    /*Com scan direction*/
        SendCommandB(0xD3);    /*set display offset*/
        SendCommandB(0x00);   /*   0x20  */
        SendCommandB(0xD5);    /*set osc division*/
        SendCommandB(0x80);
        SendCommandB(0xD9);    /*set pre-charge period*/
        SendCommandB(0x1F);    /*0x22*/
        SendCommandB(0xDA);    /*set COM pins*/
        SendCommandB(0x12);
        SendCommandB(0xDB);    /*set vcomh*/
        SendCommandB(0x40);
        SendCommandB(0xAF);    /*display ON*/

        // Switch to 'data' mode
        dcPin.Write(Data);
        this.ClearScreen();
        this.Refresh();

    }

I have two methods to "refreshing"

<!-- language: c -->

    public virtual void Refresh()
            {
                Spi.Write(displayBuffer);
            }

        /// <summary>
        /// Send buffer to display
        /// </summary>

    public void Display()
            {
                //set column address
                dcPin.Write(DisplayCommand);
                SendCommandB(0x21);
                SendCommandB(0);
                SendCommandB((byte)(Width - 1));

                //set page address
                SendCommandB(0x22);
                SendCommandB(0);
                SendCommandB((byte)(_pages - 1));
                dcPin.Write(Data);

                //Spi.Write(displayBuffer);

                for (ushort i = 0; i < displayBuffer.Length; i = (ushort)(i + 16))
                {
                    //Spi.Write(displayBuffer);
                    SendArray(displayBuffer, i, (ushort)(i + 16));
                }
            }

At this point I'm a little lost. My hunch is something to do with paging and or display RAM. I'm looking for some insight here on how to fix this as I know there's a lot of experience here with these displays. Thanks!

  [1]: http://www.waveshare.com/w/upload/5/5e/SH1106.pdf
  [2]: https://i.stack.imgur.com/vwQEM.jpg
  [3]: https://i.stack.imgur.com/tkkMc.jpg

body:
While your initialization routine looks fine to me (comparing to the datasheet and as evidenced by the fact the display turns on), what doesn't look right is your drawing routine:

    //set column address
    dcPin.Write(DisplayCommand);
    SendCommandB(0x21);
    SendCommandB(0);
    SendCommandB((byte)(Width - 1));

    //set page address
    SendCommandB(0x22);
    SendCommandB(0);
    SendCommandB((byte)(_pages - 1));

The commands 0x21 and 0x22 don't correspond to any commands I can see in the datasheet.  They look more like commands more commonly seen with ILIxxxx or SSDxxxx screens to create an "addressable window" from 0,0 to Width-1, _pages-1.

Instead you should be using the same commands you used in the setup routine to set the current col / page coordinate in RAM to write to.

Commands `(0x00 | (col & 0x0F))` and `(0x10 | (col >> 4))` set the column position, and `(0xB0 | (page & 0x0F))` set the page number.

You then write all 128 bytes for the current page before moving on to the next page.  This means you will have to do it a page at a time, something like:

    for (ushort page = 0; page < 4; page++) {

        // Set the current RAM pointer to the start of the currently
        // selected page.
        dcPin.Write(DisplayCommand);
        sendCommandB(0x00); // Set column number 0 (low nibble)
        sendCommandB(0x10); // Set column number 0 (high nibble)
        sendCommandB(0xB0 | (page & 0x0F)); // Set page number

        // Send a single page (128 bytes) of data.
        // Without knowing the rest of your program I don't know the right
        // data sending routines to use, so I made them up. Change it to
        // do it how your program expects.  Maybe with your SendArray
        // function.

        dcPin.Write(DisplayData);
        for (ushort col = 0; col < 128; col++) {
            sendDataB(displayBuffer[page * 128 + col]);
        }
    }

Note that this method is very similar to how the KS0108 GLCD drivers work.  Each byte of the page represents 8 pixels on the screen so the screen, at 32 pixels high, is split into 4 pages, where each page is 8 pixels, or one byte, high.

The effect you are currently seeing is because you are never changing the current page number (0) so you are always writing your data to the first page.  This loops around multiple times, so you end up writing all 4 pages to the same strip of the display ending up with the last page being displayed, which is the last 8 lines of your display data.  The rest of the display is never being touched and just contains whatever random data was in the RAM at power-on.


sender: user

message:
Controlling Protoneer CNC shield without PC

I'm building an small CNC using `Protoneer CNC shield`, `GRBL` and `Arduino UNO`.
With this I need to connect the board to PC and send G-Code from there.
My question is, is it possible to use the arduino itself to control the CNC shield?
If yes how?
If not is there any other way to send commands other than USB (as Arduino's USB port is not a host)

Thanks

sender: assistant

body:
An Arduino can talk directly to a shield, independent of a PC.

This will, however, need a way to tell your Arduino to do it's thing. Depending on what you want it to do, this may require nothing ("send this pre-defined g-code as soon as you are turned on"), a memory card of some sort, one or more pushbuttons, or even a small screen. I have seen several 3d printers with memory cards, buttons (usually up/down/select/back), and a small screen that, once set up, can print anything you can load onto a memory card.

There are other forms of communication, too - ethernet, wifi, etc., which you can use, with appropriate shields.

In the end, of course, you still have to design your object - 3d graphics are well beyond the ability of an Arduino, so there will still be some form of computer involved.


message:
ATtiny85: Power consumption vs clock speed

Short and simple: What is the power consumption for an ATtiny85 running at 1 MHz and 8 MHz using the internal clock? Not using any sleep modes.

I have googled a lot and can't find any info on this. I ask because I want to know if it is worth using 1 MHz to increase battery life.

body:
The datasheet shows that current decreases at lower frequencies. Around **1 mA** at 1 MHz running at 5 V. More like 5 mA at 8 MHz running at 5 V.

[![Supply current vs frequency][1]][1]

You can save quite a bit by using lower voltages as well, as you can see. For really big savings use a sleep mode. Read about [Power saving techniques for microprocessors](http://www.gammon.com.au/power).

---

*(Edited to add)*

To amplify on my remarks, you should be able to get **200 nA** consumption at 3.5 V in sleep mode with no watchdog timer. That will still respond to interrupts, such as closing a switch.

[![Supply current with watchdog disabled][3]][3]

---

If you need to do things periodically you can enable the watchdog, and then get around **5 µA** consumption at 3.5 V.

[![Supply current with watchdog enabled][2]][2]

---

This is so much less current than the 1 mA mentioned above, that it is well worth exploring running in power-down mode, where possible.

  [1]: https://i.stack.imgur.com/sJkkV.png
  [2]: https://i.stack.imgur.com/ZPVOo.png
  [3]: https://i.stack.imgur.com/oagxo.png


message:
Is there any way to separate this short code into its own function? (webserver, trying to use client.print outside of main loop)

I have an arduino webserver that uses the following code:

    client.println(F("HTTP/1.1 200 OK"));
    client.println(F("Content-Type: text/html"));
    client.println();
    client.println(F(""));
    ...
    if (fan1Toggle == 0)
        client.print(F("Fan1•On
"));
    else
        client.print(F("Fan1•Off
"));

    if (fan2Toggle == 0)
        client.print(F("Fan2•On
"));
    else
        client.print(F("Fan2•Off
"));
    ...

The page is pretty long, allowing the user to toggle over a dozen different switches. Some of the code checks to see the state of a certain switch, and then displays a green or red bullet ("&#8226", like •) on the page if the switch is on or off.

Since the code for the colored bullet is repeating, I wanted to make a function for it. Then I would just call (for example) "displayBullet(fan1Toggle);", and it would determine if fan1 was on or off, and display the correct color depending on the state.

I tried to create the following function:

    void displayBullet(int toggle) {
    if (toggle == 0)     //switch is off, so display red bullet
        client.print(F("•"));
    else    //switch is on, so display green bullet
        client.print(F("•"));
    }

But then I got an error saying that "'client' is not declared in this scope".

Is there any way to work around that error, so that I can get the displayBullet() function I want? Or is this something that can't be shortened like this, because the "client" function has to be inside the main loop?

Thanks!

body:
You can pass client to the function by reference, like this:

    void displayBullet(EthernetClient & client, int toggle)
      {
      if (toggle == 0)     //switch is off, so display red bullet
        client.print(F("•"));
      else    //switch is on, so display green bullet
        client.print(F("•"));
      }

Now it knows about `client`. Make sure you pass client when you call it:

    displayBullet(client, 1);


message:
Adafruit DHT22 Library + Arduino Due not compiling?

i recently purchased a DHT22's and tried to get it to work using [Adafruit's DHT library][1] on Github.
When i compile it with a Arduino DUE, it gives me the following error:

    C:\Users\Moz\Documents\Arduino\libraries\DHT-sensor-library-master\DHT.cpp: In constructor 'DHT::DHT(uint8_t, uint8_t, uint8_t)':
    C:\Users\Moz\Documents\Arduino\libraries\DHT-sensor-library-master\DHT.cpp:14:9: error: invalid conversion from 'Pio*' to 'uint8_t {aka unsigned char}' [-fpermissive]
       _port = digitalPinToPort(pin);
             ^
    Error compiling.

It compiles on a Arduino Uno but not on the DUE.

What is the reason for this?

Edit: Below is the example code i use

    #include "DHT.h"

    #define DHTPIN 2     // what pin we're connected to

    #define DHTTYPE DHT22   // DHT 22  (AM2302)

    DHT dht(DHTPIN, DHTTYPE);

    void setup() {
      Serial.begin(9600);
      Serial.println("DHTxx test!");
      dht.begin();
    }

    void loop() {

      delay(2000);
      float h = dht.readHumidity();
      float t = dht.readTemperature();
      float f = dht.readTemperature(true);

      if (isnan(h) || isnan(t) || isnan(f)) {
        Serial.println("Failed to read from DHT sensor!");
        return;
      }

      // Compute heat index in Fahrenheit (the default)
      float hif = dht.computeHeatIndex(f, h);
      // Compute heat index in Celsius (isFahreheit = false)
      float hic = dht.computeHeatIndex(t, h, false);

      Serial.print("Humidity: ");
      Serial.print(h);
      Serial.print(" %\t");
      Serial.print("Temperature: ");
      Serial.print(t);
      Serial.print(" *C ");
      Serial.print(f);
      Serial.print(" *F\t");
      Serial.print("Heat index: ");
      Serial.print(hic);
      Serial.print(" *C ");
      Serial.print(hif);
      Serial.println(" *F");
    }

  [1]: https://github.com/adafruit/DHT-sensor-library

body:
That library uses direct pin manipulation to make things faster.  However the Due is a completely different architecture to the Uno, so direct pin manipulation is done differently.

The library would have to be written specifically to do it in the two different ways and select between them depending on which board is chosen for the compilation.  This hasn't been done, and it's unlikely it would ever be done.

This is exactly why `digitalWrite()`, `shiftIn()`, `shiftOut()` et al exists, so that you don't get these kind of problems.  By choosing not to use them Adafruit have basically decided that their library will never work on a Due.


body:
The same library works with the Due if you use the older version 1.1.13 from the same Github repo, which is the last version that officially supported the Due.

Here are the changelog entries that show the relevant changes:
> update: 0.1.13 added support for DHT33 and DHT44 - LAST DUE VERSION
>
> update: 0.1.14 replaced digitalRead with faster code (AVR ONLY!!! better support for lower Mhz devices)


body:
There are several Arduino libraries for reading DHT22 and related DHT sensors.  The Adafruit DHT library does not compile for the Due since it uses AVR specific functions not available on ARM (Due).

For the Arduino Due use Rob Tillaart's DHTstable library available from his [github page][1] where you can download a zip file.  Note that his project also has a "DHTlib" library which does not support the Due.  There exists yet more DHT libraries which Rob has listed on the [DHTLib page on arduino.cc][2].

  [1]: https://github.com/RobTillaart/Arduino
  [2]: http://playground.arduino.cc/Main/DHTLib


message:
Issues in interfacing relay with Arduino

I want to control AC bulb with Arduino, 5v-relay.
My connections are

[![enter image description here][1]][1]

My code is

<!-- language: c -->

    #define RELAY1  7

    void setup()
    {
      pinMode(RELAY1, OUTPUT);
      Serial.begin(9600);
    }

    void loop()
    {
      digitalWrite(RELAY1,LOW); // Turns ON Relays 1
      Serial.println("Light OFF");
      delay(15000); // Wait 5 seconds
      digitalWrite(RELAY1,HIGH); // Turns Relay Off
      Serial.println("Light ON");
      delay(20000);
    }

* Red LED is on according to AC bulb.
* Power LED (Green colored one) is also on as I have given 5v supply from Arduino.

The issues are

1. Bulb is not following the delay given in the code. The output for the above code is 20sec ON - 15sec OFF -20sec ON - 15sec OFF- 20sec ON -15sec OFF -  1sec ON - 20sec ON - 15sec OFF etc. means apart from 20,15 sec duration there is a duration of 1sec is coming in between as noise. What might be the reason?

2. On monitor also, only first 3 actions are getting printed after that no printing is observed.

==>The relay I am using is:

[![enter image description here][2]][2]

  [1]: https://i.stack.imgur.com/iiZRK.jpg
  [2]: https://i.stack.imgur.com/KBLdr.jpg

body:
Everything looks good, however Try a different relay, and double check your AC side and be sure the bulb voltage is correct for the AC and the bulb is OK.

You may have a power shortage from your USB or however you are powering it.  If you can monitor the 5VDC and be sure it is stable.

Good Luck


body:
what i would do is test the parts one by one.
so first look if you're signal is good by attaching a led to it.
then test you're relay with 5v.

now you should know what the problem is the arduino or the relay


message:
Interrupt variable not getting called while executing another part

volatile byte _incomingFlag = 0;

    void onIncoming () {
        _incomingFlag = 1;
        Serial.println(F("You got an interrupt"));
        mySerial.println("ATH0");
    }

    void setup () {
        /* First Start the module */
        Serial.begin(9600);
        Serial.println(F("Initializing module..."));

        powerOn();

        mySerial.begin(9600);

        sendcommand(F("AT"), F("OK"), 1000);
        sendcommand(F("AT+CLIP=1"), F("OK"), 1000);
        sendcommand(F("AT+CMGF=1"), F("OK"), 1000);

        /* We need to attach ringing Interrupt */
        attachInterrupt(M_RING_INTERRUPT, onIncoming, FALLING);

        delay(100);
    }

    void loop() {
        if (_incomingFlag == 1) {
            manageIncoming();
            Serial.print(F("_incomingFlag: "));
            Serial.println(_incomingFlag);
        } else  {
            Serial.println(_incomingFlag);
            Serial.println(F("not getting value"));
        }
        get_currentLocation();
        send_Location();
    }

I am trying to check the value of `incomingFlag` from the `loop()` . When I get a call or an SMS the interrupt function is getting executed and `incomingFlag` is set to 1 but I am not getting that value from the `loop()`. Everytime it's getting 0 if I check the value while the `send_Location` function is executing (data uploading part). How can I access the value of `incomingFlag` from the main `loop()`.

body:
    volatile byte _incomingFlag = 0;
     void onIncoming () {
                 _incomingFlag = 1;
                Serial.println(F("You got an interrupt"));
                mySerial.println("ATH0");

            }

Regardless of what your purpose is there, you **cannot successfully do serial prints inside an ISR**. All bets are off if you do that.

In fact you are doing two prints - is one SoftwareSerial?

If you must have a debugging "flag" turn on an LED. Doing serial printing requires interrupts to be on, and they are off inside an ISR.

---

**Note**: You may get the display once, and therefore you think it works. As soon as the serial buffer fills up (probably 64 bytes) then it will just block indefinitely. Your message "You got an interrupt" is already 22 bytes if you count the trailing carriage-return/linefeed.

---

### More detailed explanation

In your main loop, every time through it, you are printing either:

    _incomingFlag: 1

or

    0
    not getting value

Therefore the serial buffer will be **definitely full** (or almost full). It can't empty the buffer if you are cramming this stuff into it every time through loop.

So now you have an incoming call. You set _incomingFlag to 1, then try to do this:

        Serial.println(F("You got an interrupt"));

That blocks, because if can't fit all that into the output buffer, and the program then hangs, because the buffer is not emptied inside an ISR.


message:
How to pass a filename to a function? What type of variable is the filename?

In the example below, I have two functions that write numbers to two different files on an SD card. I'm using the [SdFat library][1].

Is there any way I can combine the two functions into one, so that I can call (for example): writeToFile(int t, FileName "filename1.txt");?

In the example below, to write a value to the "temperature.txt" file, I would like to be able to call: writeToFile(7, "temperature.txt"); In my sketch I have about a dozen functions that are writing to a dozen different files, so it would be very handy to be able to combine them into one function.

I think the main part I'm stuck on is I have no idea what the filename variable would be, or how to pass the filename to the function.

    #include <SdFat.h>
    SdFat sd;

    void setup() {
      if (!sd.begin(chipSelect, SPI_HALF_SPEED)) {
        sd.initErrorHalt();
      }

      setTemperature(7);
      setFanSpeed(4);
    }

    void setTemperature(int t) {
      SdFile rdfile("temperature.txt", O_WRITE);
      rdfile.rewind();
      rdfile.println(t);
      rdfile.close();
    }

    void setFanSpeed(int t) {
      SdFile rdfile("fanspeed.txt", O_WRITE);
      rdfile.rewind();
      rdfile.println(t);
      rdfile.close();
    }

  [1]: https://github.com/greiman/SdFat

body:
String literals are of type `const char *`. Ordinary `char *`s can be passed to it though; the `const` means that the compiler will make sure that the function doesn't attempt to change the contents.

    void setFileParameter(const char *filename, int value)
    {
       ...
    }


message:
Arduino Nano with CH340 reboots on OS X El Capitan

I installed OS X El Capitan beta on my Macbook. Now my Nano-sized Chinese Arduino operating on CH340 chip reboots the laptop when USB is unplugged. While plugged, it works fine, I can upload sketches and send/receive data via Serial.

I've tried reinstalling the CH340 driver and running the following command as per [this solution][1] and it didn't help:

    sudo nvram boot-args="kext-dev-mode=1 rootless=0"

I appreciate any ideas...

  [1]: https://www.reddit.com/r/arduino/comments/3dfr2e/ch340g_arduinos_with_osx_el_capitan/

body: The command you ran only disables driver signing verification, which means OSX stops blocking it. If it is crashing it is likely to be either a bug in OSX, or a bug in the driver. My guess is it is a bug in the driver and you'll probably have to wait until they release an updated version that is compatible with El Capitan.


body: It turns out I didn't have the latest Beta. I now updated to the latest and now my CH340-based Arduino doesn't get detected at all! Pretty much in line with everyone else complaining all over internet.


body:
Check this video https://www.youtube.com/watch?v=0zuRukW7o0A

- Reboot and press CMD+R immediately after reboot to enter in Recovery Mode
- Open Terminal from Recovery mode
- Run the command csrutil enable --without kext
- Reboot
- Install driver


body:
There is a new signed driver for OS-X El Capitan and Yosemite. This is all you want.

http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html


body:
If you have macOS High Sierra like mine 10.13.4
This is work for me
https://github.com/awangga/NFCReader


message:
Uploading Marlin Firmware To Melzi-ATmega1284p

I'm trying to flash the Marlin Firmware to my Prusa i3 3D Printer, which uses Melzi 2.0 board. Melzi is a variation of Sanguino, and Sanguino is a variation of the Arduino.

The problem is that the version I'm using of Marlin ([this one][1], development branch) only works with Arduino Mega. I saw that the file `pins_RAMPS_13.h` says the following (line 15-17):

    #if !defined(__AVR_ATmega1280__) && !defined(__AVR_ATmega2560__)
       #error Oops!  Make sure you have 'Arduino Mega' selected from the 'Tools -> Boards' menu.
    #endif

So I tried to make this part to look like this:

    #if !defined(__AVR_ATmega1280__) && !defined(__AVR_ATmega2560__) && !defined(__AVR_Melzi_ATmega1284p16mhz__)
       #error Oops!  Make sure you have 'Arduino Mega' selected from the 'Tools -> Boards' menu.
    #endif

Does anybody know if there's another repository made for the Melzi board?
Or if I should use another firmware, like Repetier (I tried, fail)?
Thanks for any help.

  [1]: https://github.com/MarlinFirmware/Marlin

body:
It looks like the Marlin firmware supports two versions of the Melzi board, although it isn't clear if it specifically includes the 2.0 version. The best thing to do is just try it. In the `Configuration.h` file find the section where it says:

    #ifndef MOTHERBOARD
      #define MOTHERBOARD BOARD_ULTIMAKER
    #endif

Now replace `BOARD_ULTIMAKER` with `BOARD_MELZI_1284` and try that. If that doesn't work you can try just `BOARD_MELZI`. If neither of those work, you are out of luck, unless you are willing to dig in and do the pin mappings yourself.


message:
Heads Up Display Helmet With arduino

I want to make a HUD Helmet similar to the one shown in Ironman movies. Please suggest me some links and parts needed for this type of project

body:
You can't.  You can't even simulate it or even begin to approach that style of display.

Try it.  Print something out then hold it in front of your face the distance the visor is away from you.  Now try and focus on it.  You can't.  The human eyes are unable to focus that closely.

You would need to focus the vision through lenses (which is what VR headsets do) or directly project through prisms and lenses into the eye (which is what Google Glass does) in order for you to be able to see the images you generate.

You could do it if you required the user to wear special glasses to focus their vision, however they then wouldn't be able to focus on anything else much and would keep walking into things and tripping over their own feet.  The rest of the world would just be a complete blur.

The whole depiction of those kind of HUD displays are impractical.  In military HUD systems the image is either fed via a single eyepiece (and it takes lots of practice and brain training to get the brain to superimpose the two images), or it's projected on to the cockpit window.  The only way it could be done as they depict it would be to directly project the images into both eyes (to create a 3D effect) superimposing it over the natural light entering the eyes.  That would then of course mean that it would be invisible to anyone except the user, so still wouldn't be quite the same.


body:
There is a fairly inexpensive solution, but it's not Arduino based.

All you need is:

 - the [Google Cardboard sdk][1]
 - a fairly modern and powerful Android phone (I have a OnePlusOne and it works well with Cardboard apps) - assuming you already own something similar, this is where the big saving happens :-)
 - a compatible head unit: there are [many][2] available on ebay (on some you might have to drill a hole where the camera of the phone is located.) price got from about $5 to $25
 - some high level programming skills to write your augmented reality application, but there's no way around it :-) - you might even find some demo on the net.

Here the basic of the solution I'm proposing is to take the video stream from the front camera on the phone, use the CardBoard API to create a view for each eye (yes, you will loose stereoscopy, since each eye will see the same image from the camera) and overlay it with whatever info you would like to show. The simpler case could be a compass, where you show N-W-S-E at the top of the field of view. Or you could even add a map, like in a FPS :-)

The part where the arduino might come useful is if you want to create some (bluetooth, for example) sensor and/or controller (using the usb port from the phone requires both a phone with HW that supports host mode and a rooted device).

  [1]: https://www.google.com/get/cardboard/
  [2]: http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR0.TRC0.H0.Xgoogle cardboard.TRS0&_nkw=google cardboard&_sacat=0


body:
You will need Electroluminescent Transparent display, something like [this display from Beneq][1]

  [1]: https://beneq.com/en/displays/products/tasel

But these displays are segmented displays...The problem with these displays  is these displays are very expensive :(
other problem is Focusing the display, You need to keep the display at your Focal distance..

Good thing is : You can use "CUSTOM ARDUINO" board to control this display, "IF" size is consideration :)

Happy Learning..


body:
Luckily the concept of an Ironman helmet has more options then one would think and can be broken down as if any form of helmet. First theres the question of dimensions and proportion - this has more options than I realized since the Ironman helmet has undergone many transformations over more than 50 years both in print and film. An image search of "Ironman mask" and "Ironman comic" shows that there are a lot of options to choose from. Additionally I haven't found a consensus to exactly how Ironman was able to see outside the helmet which leaves your options open as well.

The "Ironman Mask" has what some could argue are two covered openings for the user to look through. Call them windows, eye holes - what ever - but they are openings to allow the user a direct field of vision through the helmet. If this is the case you are asking for a system that projects an overlay of some type into the users natural line of sight. Others could argue that these "eyes" on the outside of the mask are just for looks and that the users vision is completely enclosed in the helmet and that their entire view of the outside world is somehow projected into their view within the helmet.

If we're speaking of the first case, an Arduino can be used for a simple head mounted display (there are multiple examples if you Google it - include terms "glass", "hmd", and "hud") but Uno and other atmel based Arduinos are limited to simple 8 bit animations and text, nothing truly impressive or emersive. You will also have the issue of image correction in cases where your trying to create a large overlay - the viewable image will warp and fade since not projected onto surface strait on. Lenses can be used to correct but this is costly and not realistic for most diy/makers which only leaves software based solutions which Uno cannot handle running. It is possible however with other boards like the pi zero which is comparable in size and price and has enough power for higher resolution graphics and image correction. Note this approach will still require a single lens for focusing the projected image, but these are basic and cheap lenses as opposed to prisms or multi-lens solutions.

The second case would functionally be more like a VR headset and could be a challenge with some designs of Ironman helmets due to limited space within the helmet. If willing to stretch the proportion of the helmet a generic low definition version could be created using cheap lenses and at least two unos. it will require at least one FPV camera module and two display modules as well as whatever sensors you would be using. this would be more in line with Igor Stoppa's answer.


message:
how to build rc transmitter and receiver with an old rc transmitter

I've got an Arduino Mega, an Arduino Nano, two NRF24L01 wireless modules and a old Multiplex Transmitter system.

I want to get the PWM signal and send it to the other arduino which should control the servos and the motor controller.

Is there a good instruction or know somebody how to do that easily?

I need it for a rc plane and the range should be 1km.

body:
If you are controlling an RC plane, you should probably just buy a transmitter and receiver specifically designed for that. They are cheap and reliable and will generate PWM signals on their own.

If you must use an Arduino for some reason, NRF24L01 are not going to cut it as they are not powerful enough to reach 1 km. You should probably look into something like an XBee Series 1. With about 60 mW transmit power, its range is up to 1.6 km.


message:
Arduino Software serial not showing the received data

<!-- language-all: lang-C++ -->

I get the data from a sensor which is in RS485. I am using RS485-RS232 Converter. Then its given to uart usb converter and I get the data in TTL. I am able to receive the data in uart (hyperterminal). I have connected the TX, RX, GND pins to 10, 11, GND pins of Arduino UNO.
I want to communicate it with Arduino UNO through SoftSerial and here is the code

    #include <SoftwareSerial.h>
    #define rxPin 10
    #define txPin 11

    SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);

    void setup() {
        pinMode(rxPin, INPUT);
        pinMode(txPin, OUTPUT);
        mySerial.begin(9600);
        Serial.begin(9600);
    }

    void loop()
    {
        while (mySerial.available() > 0) {
            Serial.println("Data is available");
            Serial.println(mySerial.read());
        }
    }

But I'm not able to see the data on serial monitor.

body:
I had a problem similar to yours recently.

The thing that got me was that the RS232 from the Arduino is reverse. This is because it would usually go through a RS232 IC that produces +12 and -12 signals.

A sensor or RS232 backpack on a LCD cannot deal with the reverse signals.

The SoftwareSerial library has an undocumented feature that will reverse the RS232 output for you.

When you configure your interface do the following:

    SoftwareSerial mySerial(3, 2, true);

The true option instructs the library to reverse the RS232 signals.
Hope this helps you out since this post was a long time ago.


message:
Will it work ? MPU6050 Gyro etc. etc. module

Will this code read the values properly ?
Using [MPU6050.h][1].

    #include <MPU6050.h>
    #include <Wire.h>

    void setup() {
      Serial.begin(115200);
      Wire.begin();
      MPU6050.initialize();
    }

    void loop() {
      MPU6050.getWaitForExternalSensorEnabled();
      float X = getRotationX();
      float Y = getRotationY();
      float Z = getRotationZ();
      Serial.print("X:");
      Serial.println(X);
      Serial.print("Y:");
      Serial.println(Y);
      Serial.print("Z:");
      Serial.println(Z);
    }

Please be patient. I know nothing about gyroscope's working.
I'm stupid.

  [1]: https://github.com/sparkfun/MPU-9150_Breakout/blob/master/firmware/MPU6050/MPU6050.h

body:
Code would normally look like this

    #include <MPU6050.h>
    #include <Wire.h>

    MPU6050 mpu;

    void setup() {
      Serial.begin(115200);
      Wire.begin();
      mpu.initialize();
    }

    void loop() {

      //what is this doing for you?
      mpu.getWaitForExternalSensorEnabled();

      if(mpu.getIntDataReadyStatus() == 1) {
            float X = mpu.getRotationX();
            float Y = mpu.getRotationY();
            float Z = mpu.getRotationZ();
            Serial.print("X:");
            Serial.println(X);
            Serial.print("Y:");
            Serial.println(Y);
            Serial.print("Z:");
            Serial.println(Z);
      } else
      {
            Serial.println("MPU not ready");
      }

    }


message:
Unable to upload code to the Arduino Nano

I tried to to upload a hex file I generated for the Arduino Nano using avrdude but I keep getting the error:

    avrdude: stk500_2_ReceiveMessage(): timeout

First the arduino board stops doing whatever it is programmed to do, in this case powering a vibration motor .
Then this error keeps showing up in delays of around 10 seconds.
That error is then followed by

    avrdude: ser_recv(): read error: The I/O operation has been aborted because of either a thread exit or an application re
    quest.

which appears to be caused by me pulling out the USB cable after waiting a while.

Thanks

body: I suggest you disconnect the motor while you are uploading. The power it is using, or the electrical noise it is generating, may intefere with the uploading process.


message:
Arduino not detected On El Capitan Public Beta 6

Since I updated to El Capitan Public Beta, my Arduino Uno doesn't show up in the serial devices list.

The System Information utility shows an Arduino connected on the USB port (as 'Communication Device'), but a serial port does not get created at `/dev`.

The board works on Windows and the previous versions of El Capitan.

The problem persists on beta 6.

body:
As noted [elsewhere][1], there have been plenty of problems with the CH340 driver and the OSX El Capitan betas, culminating into the driver flat out not working in the latest beta. This is either a bug with OSX or a bug in the driver. I would lean towards this being a bug in the driver, which hasn't been updated since late 2013.

There are other 3rd party drivers that might work on El Capitan. [mac-usb-serial.com][2] is the most reliable looking one that I could find, and it does appear to be [actively developed][3]. It does cost money, but it is signed (which the mfg. driver isn't) and it has a test utility you can use before purchasing.

The only other options after that are:

 - Hope that WCH update their driver (don't hold your breath).
 - Program using an external programmer
 - Buy an Arduino not using the CH340

  [1]: https://arduino.stackexchange.com/questions/13998/arduino-nano-with-ch340-reboots-on-os-x-el-capitan/14005#14005
  [2]: https://www.mac-usb-serial.com/
  [3]: https://twitter.com/osxpl2303


body:
I have the OS X 10.11 installed and was unable to upload to my Arduino board. I always got stuck with the error code

    avrdude stk500_getsync() not in sync resp=0x00

After installing the [FTDI driver][1] it didnt't work either. So I figured out Apple provides it's own FTDI driver kernel extension since OS X 10.9, named *AppleUSBFTDI.kext*. So the AppleUSBFTDI kernel extension interferes with the FTDI driver. An USB port shows up in the Arduino Application, but no communication involving avrdude is possible.

Solution (without modifying or disabling any system security options introduced in 10.11):

 1. Open a terminal
 2. Execute: *sudo kextunload /System/Library/Extensions/AppleUSBFTDI.kext/* -> this will unload the Apple FTDI Kernel extension.
 3. Reinstall the [FTDI driver][1]
 4. Start the Arduino IDE, select a Com Port, the correct Arduino board
 5. Compile and upload your sketch to the board.

Please note that *kextunload* will only temporarily unload the module. When your system gets rebooted, you have to do this step again. It's possible to remove the kernel extension, but out of security reasons I don't describe how to do it in this post. If you're familiar with the console, you know how to do this :)

  [1]: http://www.ftdichip.com/Drivers/VCP.htm


body:
Check this [https://www.youtube.com/watch?v=0zuRukW7o0A][1]

 - Reboot and press CMD+R immediately after reboot to enter in Recovery
   Mode
 - Open Terminal from Recovery mode
 - Run the command csrutil enable --without kext
 - Reboot
 - Install driver

  [1]: https://www.youtube.com/watch?v=0zuRukW7o0A


body:
My version of OS X 10.11 did not have the driver installed for the FTDI cable that I had.  I downloaded the drivers here (for free): [PL2303 Mac OS X Driver Download][1]

  [1]: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41


message:
How to empty the buffer for Serial port?

<!-- language-all: lang-C++ -->

I have a Yun that accepts commands via the bridge (note the below code is part of a very simple virtual keyboard that accepts commands then runs `Keyboard.println` on them:

    #include <stdlib.h>
    #include <string.h>
    HardwareSerial *port;

    void setup() {
      port = &Serial1;
      port->begin(9600);
    }

    void loop() {
      if (port->available()) {
        String cmd = port->readString();

        if(cmd.length() > 1){
          String instruction = cmd;
          int arg_comma_index = 0;
          arg_comma_index = instruction.indexOf(",");
          String func = instruction.substring(0, arg_comma_index);
          String args = instruction.substring(arg_comma_index + 1, instruction.length() + 1 );

          Keyboard.begin();
          Keyboard.println(args);
          Keyboard.end();
        }
        port->read(); // Try to throw away whatever's left to prevent looping (which is still happening).
      }
    }

If I send it a short string:

* The first time, immediately after starting the sketch, it works.
* The second time, it works but loops anywhere from 1-5 times.
* The third time, it loops more times still.
* If I leave the device running (even if not operating it), the number of times it loops goes up _when_ I finally do send it an instruction. I'm seeing 20-75 loops after less than 15 minutes of uptime.

Clearly the loops where no instruction is being received are still building up something here. I've tried:

* Restarting the port each `void loop()`.
* Flushing the port at the top and/or bottom of each `void loop()`.
* Setting `cmd = ""` at the end of each `void loop()`.
* Checking `peek()`, `available()`, and `readString()` - after I send it one instruction, they return the same values every single time they loop.

body:
It's quite simple to empty the serial buffer - you just read all the data that is in the buffer and throw it away:

    while (port->available()) {
        port->read();
    }


body:
<!-- language-all: lang-C++ -->

How do you send your commands, char by char or one shot ?

If there is nothing to read, `port->available()` may return -1 error code after 1 sec, but you already checked, isn't it ? Anyway, you should check if it returns something `> 0` instead of something `!= 0`.

Note that `readString()` doesn't take any parameter (https://www.arduino.cc/en/Reference/StreamReadString). I suspect this function not acting as `read()` to decrease the number returned by `available();`
If you want to catch \n, use `readStringUntil('\n')` instead (https://www.arduino.cc/en/Serial/ReadStringUntil).

Try to put the full code (**with the loop**) given by Majenko at the end of your loop() function.

    #include <stdlib.h>
    #include <string.h>
    HardwareSerial *port;

    void setup() {
      port = &Serial1;
      port->begin(9600);
    }

    void loop() {
      if (port->available() > 0) {
        String cmd = port->readString();

        if (cmd.length() > 1) { // Why not 0 ?
          String instruction = cmd;
          int arg_comma_index = 0;
          arg_comma_index = instruction.indexOf(",");
          String func = instruction.substring(0, arg_comma_index);
          String args = instruction.substring(arg_comma_index + 1, instruction.length() + 1 );

          Keyboard.begin();
          Keyboard.println(args);
          Keyboard.end();
        }
        while (port->available() > 0) {
            port->read();
        }
      }
    }


body:
<!-- language-all: lang-C++ -->

I wouldn't be using readString myself. In fact I wouldn't be using the String class at all. `readString` keeps reading until it times out (by default after one second), so it may read more - or less even - than you want. It will also introduce a one-second delay while it sits around waiting for that second to elapse.

You are much better off doing a non-blocking loop, and then processing data when you get a known delimiter, like a newline or comma, or whatever you designate as "ending the stream". Example code that uses a newline delimiter:

    // how much serial data we expect before a newline
    const unsigned int MAX_INPUT = 50;

    void setup ()
      {
      Serial.begin (115200);
      } // end of setup

    // here to process incoming serial data after a terminator received
    void process_data (const char * data)
      {
      // for now just display it
      // (but you could compare it to some value, convert to an integer, etc.)
      Serial.println (data);
      }  // end of process_data

    void processIncomingByte (const byte inByte)
      {
      static char input_line [MAX_INPUT];
      static unsigned int input_pos = 0;

      switch (inByte)
        {

        case '\n':   // end of text
          input_line [input_pos] = 0;  // terminating null byte

          // terminator reached! process input_line here ...
          process_data (input_line);

          // reset buffer for next time
          input_pos = 0;
          break;

        case '\r':   // discard carriage return
          break;

        default:
          // keep adding if not full ... allow for terminating null byte
          if (input_pos < (MAX_INPUT - 1))
            input_line [input_pos++] = inByte;
          break;

        }  // end of switch

      } // end of processIncomingByte

    void loop()
      {
      // if serial data available, process it
      while (Serial.available () > 0)
        processIncomingByte (Serial.read ());

      // do other stuff here like testing digital input (button presses) ...

      }  // end of loop

In my example code you would do whatever-it-is you want in `process_data` which is called once an entire line arrives. Then you don't need to discard incoming data (empty the serial buffer), which seems to me to be a bad idea anyway.


message:
unresolved overloaded function type for Wire.onReceive

<!-- language-all: lang-C++ -->

I am attempting to make an I2C slave out of my Arduino and I can't get past the Wire.onReceive function. Here is my code. The documentation says to just add a function that has the style of void myHandler(int bytes) but I can't figure out why my readPI function does not meet these requirements.

        #include "piCom.h"
        #include "WireAddresses.h"
        #include <Wire.h>

        pi::pi(){
           Wire.begin(NB_INFO); // is 0x04
           Wire.onReceive( readPI );
           //Wire.onRequest(sendPI);
        }

        void pi::readPI(int byteCount){
           while( Wire.available() ){

                 ref_IMU = Wire.read();

           }//end while

        }//end readPI

        void pi::sendPI(){

           Wire.write(1);
           //use to send pressure info to pi

        }//end sendPI

        //double pi::getref_IMU(){return ref_IMU;}

then here is the error

    piCom.cpp: In constructor 'pi::pi()':
    piCom.cpp:7: error: no matching function for call to'TwoWire::onReceive(<unresolved overloaded function type>)'
     Wire.onReceive( readPI );
                            ^

    no matching function for call to 'TwoWire::onReceive(<unresolved overloaded function type>)'

Any help is greatly appreciated.

body:
        void pi::sendPI(){

That is a class function (method) which has an implicit **this** pointer. You can't use it as a static ISR.

In general, classes cannot implement ISRs for this reason. There are a few workarounds, one being to make it a **static** class function. However then it will affect the entire class, not just one instance.


message:
Receiving partial messages when using VirtualWire and ServoTimer2

I'm writing a project where an Arduino board that is connected to a servo engine receives commands from another Arduino. The possible commands are:

 1. Move 10 degrees
 2. Reset position
 3. Sweep until you're told to stop

My problem is with the sweep-mode, when I get the sweep command, I get into a while loop, that first checks for a sweep-terminator and then sweeps.

    } else if (message == sweep) {
      Serial.println("sweep");
      while (msg1 != sweep_term) {
        // set the direction for the servo to move
        if (val == 750){
          val = 2250;
        } else {
          val = 750;
        }

        // move the servo
        myservo.write(val);
        // wait for the servo to move
        delay(15);

        // wait for a message
        if (vw_get_message(buf1, &buflen1)) {
          buf1[buflen1] = '\0';
          msg1 = (char*)buf1;
          memset(buf1,'0',VW_MAX_MESSAGE_LEN);
          Serial.print(buflen1);
          Serial.print(" [sweep] Got: ");
          Serial.println(msg1);
        }
      }
    }

For some reason, when I'm in this loop I don't get the sweep terminator message, or I get a part of it. I suspect that the servo is responsible for this, since when I run the same program without `myservo.write()`s I *do* receive those terminators.

body:
If `msg1` is of type `char*` (as is implied by the cast in `msg1 = (char*)buf1;`), then it seems to me that that statement will copy the address of `buf1` to `msg1`.  Then, when you fill `buf1` with ascii zeroes (ie, characters `'0'`) `msg1` ends up being a string of ascii zeroes.

On the other hand, if `msg1` is of type `String` (to go along with your comment about `buf1` being of type `String`) the cast should be unnecessary.

Note, if you don't give the source for the `vw_get_message()` routine and the declarations for all of the constants and variables used in the code extract, it's unlikely anyone can definitively answer your question.

Note, the `while` test, `msg1 != sweep_term`, may not be well-defined on entry to the while loop.  Or, if `msg1` is left over from a previous use, you won't enter the loop at all.  Consider writing the loop in the form `do { ... } while (msg1 != sweep_term);` instead.

Note, if (as said in a comment) `buf1` is of type `String`, then the statement `memset(buf1,'0',VW_MAX_MESSAGE_LEN);` is a line of code I'd recommend against, because it treats `buf1` as a simple array rather than as an object.  (In this case it *should* make no difference, but it requires some research to be sure of that. [[1](https://stackoverflow.com/questions/422830/structure-of-a-c-object-in-memory-vs-a-struct),[2](https://stackoverflow.com/questions/1632600/memory-layout-c-objects),[3](http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus),[4](http://databasefaq.com/index.php/answer/111791/c-c-11-move-which-rules-determine-whether-an-object-is-trivially-copyable),[5](https://stackoverflow.com/questions/29034121/what-will-happen-on-memcpy-of-structures-with-c-string)])


body: I simply connected the servo to an external power 5V power source, and everything works perfectly fine. It seems like the servo's resistance was too much for the RF receiver to be able to work as well.


message:
MPU9150 (JEFF LIB) + FIFO_OVERFLOW INTERRUPT + SERIAL PRINT

Overflow enthusiasts!

I am trying to log accelerometer and gyro data using Serial.print. I have enabled the FIFO_Overflow interrupt. Whenever I log data, the serial port freezes. I am suspecting an interrupt issue while I am using Serial.print. Is there any way to get continuous data for debugging purposes? I know that the Serial library can affect interrupts and wonder whether you guys could help me a little bit ?

<!-- language: c -->

    #include "Wire.h"
    #include "I2Cdev.h"
    #include "MPU9150.h"
    #include "helper_3dmath.h"

    // class default I2C address is 0x68
    // specific I2C addresses may be passed as a parameter here
    // AD0 low = 0x68 (default for InvenSense evaluation board)
    // AD0 high = 0x69
    MPU9150 accelGyroMag;
    #define LED_PIN 13
    volatile boolean state_fifo_int = false;
    uint16_t fifo_count;
    uint8_t fifo_buffer[8];
    int16_t acc_temp[3];
    int16_t gyro_x;

    void setup(){
        // join I2C bus (I2Cdev library doesn't do this automatically)
        Wire.begin();
        // initialize serial communication
        // (38400 chosen because it works as well at 8MHz as it does at 16MHz, but
        // it's really up to you depending on your project)
        Serial.begin(115200);
        // initialize device
        Serial.println("Initializing I2C devices...");
        accelGyroMag.initialize();
        // verify connection
        Serial.println("Testing device connections...");
        Serial.println(accelGyroMag.testConnection() ? "MPU9150 connection successful" : "MPU9150 connection failed");
        // configure Arduino LED for
        pinMode(LED_PIN, OUTPUT);
        attachInterrupt(0,fifo_int,CHANGE);
    }

    void fifo_int() {
      state_fifo_int = true;
    }

    void loop(){
      while(!state_fifo_int) {
        accelGyroMag.setIntFIFOBufferOverflowEnabled(true);
        // enable fifo_interrupt
        accelGyroMag.setFIFOEnabled(true);
        accelGyroMag.setAccelFIFOEnabled(true);
        accelGyroMag.getXGyroFIFOEnabled();
        accelGyroMag.getAccelFIFOEnabled();
        fifo_count = accelGyroMag.getFIFOCount();
        accelGyroMag.getFIFOBytes(fifo_buffer,8); // fill in fifo bytes
        acc_temp[0] = (((int16_t)fifo_buffer[0]) << 8) | fifo_buffer[1];
        acc_temp[1] = (((int16_t)fifo_buffer[2]) << 8) | fifo_buffer[3];
        acc_temp[2] = (((int16_t)fifo_buffer[4]) << 8) | fifo_buffer[5];
        gyro_x = (((int16_t)fifo_buffer[6]) << 8) | fifo_buffer[7];
        Serial.print((float)acc_temp[0]/16384);
        Serial.print("  ");
        Serial.print((float)acc_temp[1]/16384);
        Serial.print(" ");
        Serial.print((float)acc_temp[2]/16384);
        Serial.print(" ");
        Serial.println(gyro_x);
       }
       accelGyroMag.setIntFIFOBufferOverflowEnabled(false);
       // disable fifo_interrupt
       accelGyroMag.resetFIFO();
       state_fifo_int = false;
    }

The library for the MPU9150 is by Jeff Rowberg.

body:
When I've gotten into a bind with data being generated faster than I can dump it, or the process cannot tolerate the printing delays, I've made a memory buffer to store as much raw data as I can and print it after the test-run. If you're not using a debugger (which can print memory contents), you'll still need to have serial print code in your sketch but it can execute after the you run the code under test. Store the minimum size raw data (to maximize the amount you can store) and do the formatting on your PC.

If you need to be able see what happened prior to an unusual event your code can detect, use a ring buffer (FIFO) in memory and let it wrap around (don't even bother to detect wrap-around). As soon as your code detects the event, print the ring-buffer contents.

It's not continuous capture but often, it's enough.


body:
After reading the datasheet on the PS manual, I found out that the INT1 pulse had a width of 50uS.

So what I simply did was to declare a global integer and check it at the end of the loop.

Whenever I checked the incremented variable at the end, it was 48!.I personally suspected that my loop speed was to slow. Additionally the timeout value 14 ms per loop arbitrary. Clearly a disparity exists in the interrupt routine for the sensor and the microcontroller.

So what I simply did was to reconfigure the sensor output to a latched signal which clearly solved the problem. I am now getting synchronized interrupt with convincing results.

Here is the code:

    #include "Wire.h"
    #include "I2Cdev.h"
    #include "MPU9150.h"
    #include "helper_3dmath.h"

    #define LED_BUILTIN 13

    MPU9150 accelGyroMag;

    volatile boolean state_fifo_int = false;
    int x = 0;

    void blink(uint16_t offTime, uint16_t onTime){
    digitalWrite(LED_BUILTIN,HIGH);
    if(onTime) delay(onTime);
    digitalWrite(LED_BUILTIN,LOW);
    if(offTime) delay(offTime);
    }

    void resetSensor(){
      accelGyroMag.reset();
      delay(50);
      accelGyroMag.initialize();
      //Serial.println("Initialize if connection test failed");

      if(accelGyroMag.testConnection()){ //disable interrupts
         accelGyroMag.setIntFIFOBufferOverflowEnabled(false);
         // disable fifo_interrupt
         accelGyroMag.resetFIFO();
            // verify connection

         //Serial.println("Connection tested successfully, Disabling interrupts");
         }
    if(!accelGyroMag.testConnection()){ // try to recover sensor
      accelGyroMag.initialize();
        //Serial.println("Initialize if connection test failed");
      }
    if(accelGyroMag.testConnection()){  // reconfigure sensor for Fifo and interrupts

       accelGyroMag.setFIFOEnabled(true);
       accelGyroMag.setXGyroFIFOEnabled(true);
       accelGyroMag.setAccelFIFOEnabled(true);
       accelGyroMag.setInterruptMode(false);// Set interrupt logic level mode 0 = active-high
       accelGyroMag.setInterruptLatch(true); //set interrupt 1=latch-until-int-cleared ( latch after INT_STATUS READ)
       accelGyroMag.setIntFIFOBufferOverflowEnabled(true);

       }
    else {
     // Serial.println("MPU9150 connection failed");
      //Serial.println("locking UP");
      while(true){
         for(uint8_t i=0;i<3;i++){blink(50,100);} // S
         delay(250);
         for(uint8_t i=0;i<3;i++){blink(50,300);} // O
         delay(250);
         for(uint8_t i=0;i<3;i++){blink(50,100);} // S
         delay(500);
        }
      }
    }

    void setup(){
      Wire.begin();
      Serial.begin(115200);
      pinMode(LED_BUILTIN, OUTPUT);
    // other stuff
      attachInterrupt(0,fifo_int,RISING);
      resetSensor();
    }

    void fifo_int() {
      x++;
      state_fifo_int = true;

    }

    static unsigned long timeout = 0; // used to detect dead sensor/connection
    uint16_t fifo_count;
    uint8_t fifo_buffer[8];
    int16_t acc_temp[3];
    int16_t gyro_x;

    void loop(){

      if(state_fifo_int){ // interrupt has triggered
        blink(0,1);  // really quick blink // really quick blink
        //Serial.println(x);
        state_fifo_int = false;
        accelGyroMag.resetFIFO();
        accelGyroMag.getFIFOBytes(fifo_buffer,8); // fill in fifo bytes
        accelGyroMag.getIntFIFOBufferOverflowStatus(); // read the INT_STATUS reg in order to clear the Latch.
        acc_temp[0] = (((int16_t)fifo_buffer[0]) << 8) | fifo_buffer[1];
        acc_temp[1] = (((int16_t)fifo_buffer[2]) << 8) | fifo_buffer[3];
        acc_temp[2] = (((int16_t)fifo_buffer[4]) << 8) | fifo_buffer[5];
        gyro_x = (((int16_t)fifo_buffer[7]) << 8) | fifo_buffer[8];

        timeout = millis();

      }

     if((millis()-timeout)>1000){ //last interrupt was over 1 second ago! better reset Sensor!
       blink(100,500);
       blink(100,500);

       resetSensor();
      }
    }


message:
Analog input weirdness (barrel connector vs USB power)

I noticed that my Arduino Mega performs differently in how it presents values from say analog input A0, depending on whether it is being powered by USB or by a fresh 9V battery wired and connected through the barrel connector.

There must be some sort of difference to what happens when both USB and the barrel connector are employed vs. just USB being used for power.

To be specific, when running just on USB power, the analog inputs seem to flicker more allowing for oversampling and measurements beyond the 10 bit accuracy of the DAC. In fact with analogReference(DEFAULT) it is possible with 64x oversampling to see 100uV level changes when only USB power is employed. Note that these changes are not just noise, they actually correspond to 100uV level changes in the input connected to A0 with high correlation.

As soon as I connect the barrel connector, the picture changes significantly. Values coming out of the ADC seem to pretty much snap and there is far less flicker. The ADC becomes, well, discrete and you get your 1,024 levels and that's about it. There may be a tiny bit of flicker as you increase or decrease voltage and approach the next increment, but this is not significant enough to actually increase the ADC resolution reliably.

Even going so far as setting the analogReference to EXTERNAL while the barrel connector is employed and connecting the AREF pin to the 5v connector directly, which by the way reads at 5.004 V  (unlike the 4.992 V it reads when USB is powering the device) still reproduces the problem.

Summary: Effectively, when running on USB power only I can oversample the analog inputs and get significantly more than 10-bit resolution. While when running using the barrel connector, with the USB still attached, I can only get the 10-bit resolution natively provided by the ADC.

If anyone has any ideas on what is causing this difference in behavior, I am all ears. If I failed to explain anything or perhaps created some confusion, I would be more than happy to clarify.

Note: This is an authentic Arduino Mega board.

body:
Looking at the [schematic][1] the barrel plug has a couple of linear voltage regulators (top left of schematic), while the USB input just has a couple of MOSFETs (bottom right of schematic) which are basically just there to switch off the USB power if there is something plugged into the barrel jack (and also maybe provide a little input protection). So the Arduino is relying on the USB power to be pre-regulated. For the most part this is correct, but USB voltage can vary widely depending on the cable length (voltage drop), the power source it is connected to (no two computers or wall warts are the same), and how many devices are the same hub (if connected to a computer or hub). I would not rely on the two power sources being matched at all.

The flicker you are talking about sounds like the power coming from USB could have significant ripple. I doubt that the USB power is allowing you to "oversample". The way ADCs in AVRs work is they have a reference voltage and when sampling, will give you a reading of where the voltage is between 0 and the voltage reference. With a 10-bit ADC there are ~1000 steps, so to measure 100uV changes, you would have to have a 100 mV reference voltage, which according to the [datasheet][2] (p.379), the minimum is 1.0 V. Basically, it is physically impossible for the Arduino Mega to measure those kinds of changes.

What is more likely to be happening is that you are probably getting some weird aliasing between the ripple frequency of your USB voltage and the sampling frequency of your code. The best way to debug this kind of thing would be to pull out an oscilloscope and check if and how much ripple is coming off the USB power.

If accuracy is important to your project, and being able to accept both power inputs is a requirement, you might look into maybe getting your own external voltage reference and piping it into VREF. Otherwise, I would stick to only using the barrel plug as it is regulated and will be consistent.

  [1]: https://www.arduino.cc/en/uploads/Main/arduino-mega-schematic.pdf
  [2]: https://www.sparkfun.com/datasheets/Components/ATMega1280.pdf


message:
Arduino User Input

Is it possible to accept input from an end user via terminal, or some other application?

I want to create a prototype for a friend, but he'd need to enter his wireless network and password to complete the setup of the project.

Any advice?

Thanks!

body:
Since you have mentioned that all that you want your friend to do is enter the WiFi SSID and password, I am gonna assume that its where his interaction with the device ends.

In this case, I would recommend using the arduino YUN, it cant get simpler than that.

The YUN is capable of creating an AP network, your friend can connect to it and then go to the arduino home page and then connect to his WiFi.

**EDIT:**

Another option would be to use a matrix keypad and LCD screen and have your friend manually enter the details


message:
Reading a part of bitmap image on Arduino

I'm pretty much a beginner when it comes to programming and have only recently started learning C++. Right now I'm stuck trying to covert a bitmap into a binary array. This is for a Robotics competition I've entered. The bitmap is a 54*96 pixel monochromatic 1 bpp image. I'm confused with the offset positions while trying to read the header. This is the code I've written so far and would greatly appreciate any help. I think the error lies in increment of the `lineNo` variable which needs to be in hex, but how to increment such values?

What I want to ultimately achieve is to read only some parts of the bitmap particularly the boxes with cross on them (see image below). How do I find out the pixel locations?

<!-- language: lang-cpp -->

    #include <SD.h>
    #include <SPI.h>
    File bMap;
    File Text;
    void setup()
    {
      Serial.begin(9600);
      while (!Serial) {
        ;
      }
      Serial.print("Initializing SD card...");
      pinMode(10, OUTPUT);
      if (!SD.begin(4)) {
        Serial.println("initialization failed!");
        return;
      }
      Serial.println("initialization done.");
      int height = 0;
      int width = 0;
      int  bitmapOffset = 0xa;
      bMap = SD.open("map.bmp", FILE_READ);
      Text = SD.open("test.txt", FILE_WRITE);
      \\bMap.seek(0xa);
      \\bitmapOffset = bMap.read();
      \\Serial.println(bitmapOffset, BIN);
      \\Serial.println(bMap, HEX);
      bMap.seek(0x16);
      for (int i = 0; i < 4; i++) {
        height += (bMap.read() << (8 * i));
        Serial.println(height);
        int lineNo;
        int fileposition = 0;
        for (lineNo = 0; lineNo < height; lineNo++)
          fileposition = bitmapOffset + (lineNo);
        bMap.seek(fileposition);
        //Serial.print(lineNo);
        Serial.print(fileposition);
        //Serial.print(bitmapOffset);

      }

      bMap.seek(0x12);
      for (int i = 0; i < 4; i++) {
        width += (bMap.read() << (8 * i));
        Serial.println(width);
        if (Text) {
          Text.println(height, width);
          Text.close();
        }
      }
    }

    void loop() {}

[![Maze][2]][2]

  [2]: https://i.stack.imgur.com/hSEHx.png

body:
Any coordinate in a bitmap (note: the term bitmap here [all lower case] refers to the concept of a grid of pixels, not the Windows BMP file format which I will always refer to as BMP all in capitals) can easily be calculated as long as you know the width.  The height is only needed to stop you going too far.

Any pixel offset in a buffer of pixels is calculated as `y * width + x` assuming a *left-right / top-down* pixel arrangement in the buffer.

The information you are really interested in with your bitmap is actually considerably less than is in the BMP that you show.  Your BMP is 56x96 pixels, but the information you actually care about is actually only in a resolution of 7x12 blocks.

It would be far simpler if you could pre-process the provided BMP on a PC to create an array of 84 entries each with a different tag or value to represent what it is.  Your image there could then be represented as the array:

    { 3, 3, 3, 3, 3, 3, 3,
      3, 1, 0, 0, 0, 1, 3,
      3, 0, 0, 0, 0, 1, 3,
      0, 0, 1, 1, 0, 0, 3,
      3, 2, 1, 0, 0, 0, 3,
      3, 1, 0, 0, 1, 0, 3,
      3, 0, 1, 0, 0, 0, 3,
      3, 0, 0, 0, 2, 0, 3,
      3, 0, 0, 1, 0, 0, 3,
      3, 1, 1, 0, 1, 0, 3,
      3, 0, 0, 0, 0, 0, 3,
      3, 3, 3, 0, 3, 3, 3 };

Where 0 is an open white space, 1 is a closed black space, 2 is a black space with a cross and 3 is a border space.

The two crosses would then be calculated as `(1,4) = 4 * 7 + 1 = 29` and `(4,7) = 7 * 7 + 4 = 53`.

Working with BMP files is somewhat more tricky.  They come in multiple depths and multiple bit arrangements, as well as different versions with different header sizes.  They also have different padding requirements for different line lengths and bit depths, and are generally a rather nasty file format all round.

And on top of that they are upside down.  BMP is the only file format I know of where 0,0 is at the bottom left instead of the top left.  Consequently you have to invert all your Y coordinates to make sense of it, and parsing a BMP file from the top down is really slow because you have to keep jumping backwards in the file.

So it would be much better if you could write a program on a PC using software which already understands the BMP format and can render it into a buffer for your program to then parse each block to work out what it is and build up a small 84 byte file of the actual information you need for your robot.

If you must read the BMP file directly on the Arduino then I have code you use to help you.  It's not designed for the Arduino but for the chipKIT boards (though it's very similar) and is designed as part of my DisplayCore framework for chipKIT (and other more powerful) boards, but you are welcome to take whatever bits you like, or just use bits to give you more insight into how BMP files work.  You can get the code from Github here: https://github.com/MajenkoLibraries/DisplayCore/tree/master/ImageReaders/BMPFile

To parse your bitmap into an array you would have to take each 8x8 block of pixels and work out what shape is in it - whether it's all black, all white, a cross, or a border piece.


message:
Reading states of multiple toggle switches

I'm working on modifying this [example][1] from the Arduino website to read the state of 3 toggle (SPDT) switches. If I have one toggle switch hooked up, my sketch works as expected...the sketch will log the state of the switch in the serial debugger every-time the state changes, and only when the state changes.

However, if I add in two more switches, the serial debugger will continuously output my log messages, without detecting if the state has changed.

Here's the code from my sketch:

    const int  switchOnePin = 2;    // digital in 2 (pin the switch one is attached to)
    const int  switchTwoPin = 3;    // digital in 3 (pin the switch two is attached to)
    const int  switchThreePin = 4;  // digital in 4 (pin the switch three is attached to)

    int switchOneState = 0;         // current state of the switch
    int lastSwitchOneState = 0;     // previous state of the switch

    int switchTwoState = 0;
    int lastSwitchTwoState = 0;

    int switchThreeState = 0;
    int lastSwitchThreeState = 0;

    void setup() {
      // initialize serial communication at 9600 bits per second:
      Serial.begin(9600);

      int switchOneState = 0;         // current state of the switch
      int lastSwitchOneState = 0;     // previous state of the switch switch pins as an input
      pinMode(switchOnePin, INPUT);
      pinMode(switchTwoPin, INPUT);
      pinMode(switchThreePin, INPUT);
    }

    void loop() {

      // read the switch input pins:
      switchOneState   = digitalRead(switchOnePin);
      delay(50);
      switchTwoState   = digitalRead(switchTwoPin);
      delay(50);
      switchThreeState = digitalRead(switchThreePin);

      // compare the switchState to its previous state
      if (switchOneState != lastSwitchOneState) {
      // if the state has changed, increment the counter
        if (switchOneState == HIGH) {
        // if the current state is HIGH then the button
        // went from off to on:
        Serial.println("Switch one is on");
      }
      else {
        // if the current state is LOW then the button
        // went from on to off:
        Serial.println("Switch one is off");
      }

      if (switchTwoState != lastSwitchTwoState) {
        if (switchTwoState == HIGH) {
        Serial.println("Switch two is on");
      }
      else {
        Serial.println("Switch two is off");
      }

      if (switchThreeState != lastSwitchThreeState) {
        if (switchThreeState == HIGH) {
        Serial.println("Switch three is on");
      }
      else {
        Serial.println("Switch thre is off");
      }
     }
    }
      // Delay a little bit to avoid bouncing
      delay(50);
    }
    // save the current state as the last state,
    //for next time through the loop
    lastSwitchOneState   = switchOnePin;
    lastSwitchTwoState   = switchTwoPin;
    lastSwitchThreeState = switchThreePin;
    }

And here's what my circuit looks like:

[![enter image description here][2]][2]
Does anyone have any insight into what I may be doing wrong? I'm not quite sure if it's a circuit or a sketch issue (or both).

**EDIT** I tried adding a delay of 50ms between each digital input read, but that still did not seem to help the problem.

  [1]: https://www.arduino.cc/en/Tutorial/Switch
  [2]: https://i.stack.imgur.com/ZLAB6.png

body:
    lastSwitchOneState   = switchOnePin;
    lastSwitchTwoState   = switchTwoPin;
    lastSwitchThreeState = switchThreePin;

should be

    lastSwitchOneState   = switchOneState;
    lastSwitchTwoState   = switchTwoState;
    lastSwitchThreeState = switchThreeState;


body:
The problem was two pronged---both the copy/paste error that @Gerben pointed out, as well as the incorrect if-else statements that @BrettAM pointed out. Below is the working code:

    const int  switchOnePin = 2;    // digital in 2 (pin the switch one is attached to)
    const int  switchTwoPin = 3;    // digital in 3 (pin the switch two is attached to)
    const int  switchThreePin = 4;  // digital in 4 (pin the switch three is attached to)

    int switchOneState = 0;         // current state of the switch
    int lastSwitchOneState = 0;     // previous state of the switch

    int switchTwoState = 0;
    int lastSwitchTwoState = 0;

    int switchThreeState = 0;
    int lastSwitchThreeState = 0;

    void setup() {
        //initialize serial communication at 9600 bits per second:
        Serial.begin(9600);

        int switchOneState = 0;         // current state of the switch
        int lastSwitchOneState = 0;     // previous state of the switch switch pins as an input
        pinMode(switchOnePin, INPUT);
        pinMode(switchTwoPin, INPUT);
        pinMode(switchThreePin, INPUT);
    }

    void loop() {
        // read the switch input pins:
        switchOneState   = digitalRead(switchOnePin);
        switchTwoState   = digitalRead(switchTwoPin);
        switchThreeState = digitalRead(switchThreePin);

        // compare the switchState to its previous state
        if (switchOneState != lastSwitchOneState) {
            // if the state has changed, increment the counter
            if (switchOneState == HIGH) {
            // if the current state is HIGH then the button
            // went from off to on:
                Serial.println("Switch one is on");
            } else {
                // if the current state is LOW then the button
                // went from on to off:
                Serial.println("Switch one is off");
            }
        }

        if (switchTwoState != lastSwitchTwoState) {
            if (switchTwoState == HIGH) {
                Serial.println("Switch two is on");
            } else {
                Serial.println("Switch two is off");
            }
        }

        if (switchThreeState != lastSwitchThreeState) {
            if (switchThreeState == HIGH) {
                Serial.println("Switch three is on");
            } else {
                Serial.println("Switch thre is off");
            }
        }

        // Delay a little bit to avoid bouncing
        delay(50);

        // save the current state as the last state,
        //for next time through the loop
        lastSwitchOneState   = switchOneState;
        lastSwitchTwoState   = switchTwoState;
        lastSwitchThreeState = switchThreeState;
    }


message:
Using STL vector to create an array causes an error

I have installed the STL for arduino, and it has been working fine. Then I tried to create a vector using a custom class, and it gave me a massive error message. When using it on primitive data types (ex. int) it works fine, but in any one of my own classes (including classes from sample code) it gives this error:

    Arduino: 1.6.3 (Windows 8.1), Board: "Arduino Uno"

    Build options changed, rebuilding all

    C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -w - fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD   -std=gnu++11 -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10603 -  DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -IC:\Program Files   (x86)\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files   (x86)\Arduino\hardware\arduino\avr\variants\standard   C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp -o    C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp.o

    In file included from c:\program files     (x86)\arduino\hardware\tools\avr\avr\include\vector:33:0,

                     from Navigation.ino:2:

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h: In instantiation   of 'void std::__destroy_aux(_ForwardIterator, _ForwardIterator, __false_type)   [with _ForwardIterator = Obstacle*]':

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:78:55:   required  from 'void std::__destroy(_ForwardIterator, _ForwardIterator, _Tp*) [with  _ForwardIterator = Obstacle*; _Tp = Obstacle]'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:83:51:   required from 'void std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = Obstacle*]'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:115:27:   required  from 'void std::destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = Obstacle*]'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:284:42:   required from 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = Obstacle; _Alloc = std::allocator<Obstacle>]'

    Navigation.ino:36:23:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:66:22: error: 'destroy' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

         destroy(&*__first);

                      ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:114:13: note: 'template<class _ForwardIterator> void std::destroy(_ForwardIterator, _ForwardIterator)' declared here, later in the translation unit

     inline void destroy(_ForwardIterator __first, _ForwardIterator __last) {

                 ^

    Error compiling.

**EDIT:**
Here is the code:

    #include <iterator>
    #include <vector>
    #include <pnew.cpp>

    class Test {
    public:
        int i;
    };
    std::vector<Test> test;

Change the last line to

    std::vector<Test&> test

and:

            Arduino: 1.6.3 (Windows 8.1), Board: "Arduino Uno"

    C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -std=gnu++11 -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10603 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp -o C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp.o

    In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\vector:35:0,

                     from Navigation.ino:2:

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'class std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>':

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:101:8:   required from 'struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:155:7:   required from 'class std::vector<Obstacle&>'

    Navigation.ino:36:24:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:89:8: error: forming pointer to reference type 'Obstacle&'

       _Tp* _M_start;

            ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:90:8: error: forming pointer to reference type 'Obstacle&'

       _Tp* _M_finish;

            ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:91:8: error: forming pointer to reference type 'Obstacle&'

       _Tp* _M_end_of_storage;

            ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:94:8: error: forming pointer to reference type 'Obstacle&'

       _Tp* _M_allocate(size_t __n)

            ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:96:8: error: forming pointer to reference type 'Obstacle&'

       void _M_deallocate(_Tp* __p, size_t __n)

            ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'class std::vector<Obstacle&>':

    Navigation.ino:36:24:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:165:23: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

       typedef value_type* pointer;

                           ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:166:29: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

       typedef const value_type* const_pointer;

                                 ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:167:23: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

       typedef value_type* iterator;

                           ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:168:29: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

       typedef const value_type* const_iterator;

                                 ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:178:49: error: forming pointer to reference type 'Obstacle&'

       typedef std::reverse_iterator<const_iterator> const_reverse_iterator;

                                                     ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:179:43: error: forming pointer to reference type 'Obstacle&'

       typedef std::reverse_iterator<iterator> reverse_iterator;

                                               ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:189:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_allocate' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

       using _Base::_M_allocate;

                    ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:190:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_deallocate' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

       using _Base::_M_deallocate;

                    ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:191:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_start' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

       using _Base::_M_start;

                    ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:192:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_finish' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

       using _Base::_M_finish;

                    ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:193:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_end_of_storage' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

       using _Base::_M_end_of_storage;

                    ^

    In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\iosfwd:22:0,

                     from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\iterator:35,

                     from Navigation.ino:1:

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h: In instantiation of 'class std::allocator<Obstacle&>':

    Navigation.ino:36:24:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h:638:22: error: forming pointer to reference type 'Obstacle&'

       typedef _Tp*       pointer;

                          ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h:639:22: error: forming pointer to reference type 'Obstacle&'

       typedef const _Tp* const_pointer;

                          ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h:658:8: error: forming pointer to reference type 'Obstacle&'

       _Tp* allocate(size_type __n, const void* = 0) {

            ^

    Navigation.ino: In constructor 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]':

    Navigation.ino:36:24: note:   when instantiating default argument for call to std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]

    In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\vector:35:0,

                     from Navigation.ino:2:

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>]':

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:240:16:   required from 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]'

    Navigation.ino:36:24:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:21: error: 'struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >' has no member named '_M_deallocate'

       ~_Vector_base() { this->_M_deallocate(_Base::_M_start, _Base::_M_end_of_storage - _Base::_M_start); }

                         ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:21: error: '_M_start' is not a member of 'std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >::_Base {aka std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>}'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:83: error: '_M_start' is not a member of 'std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >::_Base {aka std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>}'

       ~_Vector_base() { this->_M_deallocate(_Base::_M_start, _Base::_M_end_of_storage - _Base::_M_start); }

                                                                                ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:83: error: '_M_end_of_storage' is not a member of 'std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >::_Base {aka std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>}'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_Vector_alloc_base(const allocator_type&) [with _Tp = Obstacle&; _Allocator = std::allocator<Obstacle&>; std::_Vector_alloc_base<_Tp, _Allocator, true>::allocator_type = std::allocator<Obstacle&>]':

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:110:54:   required from 'std::_Vector_base<_Tp, _Alloc>::_Vector_base(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::_Vector_base<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:240:16:   required from 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]'

    Navigation.ino:36:24:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:85:53: error: using invalid field 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_start'

         : _M_start(0), _M_finish(0), _M_end_of_storage(0)

                                                         ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:85:53: error: using invalid field 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_finish'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:85:53: error: using invalid field 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_end_of_storage'

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>]':

    Navigation.ino:36:24:   required from here

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:284:42: error: '_M_start' was not declared in this scope

       ~vector() { destroy(_M_start, _M_finish); }

                                              ^

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:284:42: error: '_M_finish' was not declared in this scope

    Error compiling.

body:
    std::vector<Test&> test

Yes, well I doubt you can make a vector of references. A vector of **pointers** I could believe.

See, for example: <https://stackoverflow.com/questions/922360/why-cant-i-make-a-vector-of-references>