text:
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, 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.

You can't add arbitrary devices to a conditional check and expect the code to work. The code needs to be ported to the device.

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.


text:
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

Someone mentioned below and I think you should think about your goal (a helmet display) vs. your approach (an Ironman-styled helmet display). It is quite easy to do a helmet mounted display - VR being one. it is another story to an Ironman styled helmet display. If the latter is important to you, you may need to wait sometime.

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

the Google Cardboard sdk
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 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).

You will need Electroluminescent Transparent display, something like this display from Beneq
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..

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.

See my answer. Nowadays even VR and AR are getting quite cheap :-)

@IgorStoppa Do you know what the Iron man HUD is like? It's not a vr headset. There is no headset. It's nothing like Google cardboard or occulus rift or anything like that. A vr headset is not what the op is asking for.

Did you read my answer before writing the comment above? I described an augmented reality contraption, not a VR headset. Which is precisely what can be done, as I described, with Cardboard, since there is a camera on the other side of the phone. The fact that in the movie the HUD is allegedly done with a projector is irrelevant, for the purpose of creating an augmented reality experience. At least I have proposed a plausible solution.

What you are describing is a VR headset that happens to have a camera. That's not AR, for that you need something like Glass . It's a completely different concept. If the OP wanted a VR headset, with or withoutvavcanera, he wouldn't be asking for an iron man hud.

Nope, you are just yet another victim of marketing campaigns. See the definition: https://en.wikipedia.org/wiki/Augmented_reality. It's exactly what I described. The key point is that you show to the user a live stream of a camera with a feed from (roughly) the same perspective as the real eyes. And then overlay it with additional info. So a VR device is perfectly ok, as long as it shows as base image a live feed from the user's perspective, rather than a fully synthesized world.

It still, whatever your chosen definition, isn't even close to the Iron man HUD the OP is asking about.

Matter of opinion. Btw, any sane design of a weaponized AR a-la-IronMan would do just this: use a slab of metal with a camera on the outer side and a display/projector on the inner side, rather than ALON for see-through, like HoloLens. The ALON can be used to protect the camera. So I think this is really close to what the OP was asking. But I'll let him decide.

You can't. that's a little presumptive.

@dannyf Science Fiction is called that for a reason. With current technology it's impossible to project onto glass an inch away from an eyeball and be able to focus on it. So you can't is not presumptive, it's correct.

@Majenko This answer is categorically wrong. I'm sorry to sound harsh, but your last comment was in Jul of '17 at which point many examples where available to prove the concept is possible if you were to search for it. You should remove this or change it

@JSON I'd love to see one. I still say what the op asks for is impossible.

@Majenko - https://hackaday.com/2018/03/25/iron-man-mask-with-a-hud/ . Not the best, but at least proves it's possible

A poor man's Google glass. Have you seen the iron man HUD? It's nothing like that. Completely different. And impossible. Still, not a bad attempt at making something light up within the field of vision.

@Majenko I think your taking the OP's question too literally although a true reproduction would definitely be out of the question to an amateur. Since people who develop flying weapons systems aren't likely to frequent this Q/A I'm assuming the OP and others with interest are likely looking for something simpler than what your imagining ;)

You would be amazed at the preposterous things people that come here think they can do with an Arduino. Very often you just have to tell them no, and to get realistic.

From the film i think is pretty clear all of those effect is what Stark perceive, so a AR or a VR is exactly what he experience (AR advantage is that you have 0 latency on the outside image and your eyes has better contrast than any camera). He probably have VR and those effect are painted in the 3d space (the first time he put the mask, you can see the system does a full 3d scan of the room), so you can get basic result with a VR + camera + deep sensor (some smartphone). DJI has a game like this for its drone! (they use stereo camera for deep)

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.

source: Stack Exchange

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/

sort: votes


text:
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.

1km is pretty much impossible with the NRF24L01

Do you know another wireless modules??

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.

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


text:
Arduino Software serial not showing the received data

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.

After converting it to RS232, its given to uart converter where i get data in TTL - please edit your post to show your wiring.

Also please show what these mysterious converters are that you have used. Model numbers, connector types, etc.

The phrase "given to uart usb converter" immediately rings alarm bells to me - is this something that you plug into a USB port, and you are now trying to connect it to a TTL UART input?

Did you reverse tx and rx pins?

Majenko...Its an nT RS422 to RS232 converter.After that its connected to UART USB   converter which has max3233. I'm getting data properly at hyper terminal. Then  i have connected RX TX pins of it  to TX RX of microcontroller. But not able get the output.

Yes i have reversed the RX TX pins @Visual Micro

Confirm each step. Do you have data when going directly from 485 to 232 into Hyperterminal?  Do you have communication between Arduino and Hyperterminal without the extra software serial stuff? If you do then it's probably something to do with how its pulling data from your software serial and sending it to the Serial.println(). Try using mySerial.readline() or change the Serial.println(mySerial.read()) to Serial.print(mySerial.read()).

Remove setting the pinMode(). Note required for SoftwareSerial

Yes i have data from 485 to 232 to Hyperterminal and o checked in hyperterminal also. Communication between Arduino and Hyperterminal is not happening. Only if i press RESET button once, i am able to get one data. If i press RESET many times then data is displayed on serial monitor. And data is displayed properly on Serial Monitor if i remove the microcontroller (ATMEGA328). So i thought of using Software Serial. @ChefFlambe

Okay @VisualMicro

Still not getting output. Don't know what is wrong

Is your end goal to have the Arduino act only as a bridge to a PC for sensor data?

No it not like that. I want to manipulate the data coming from sensor using Arduino and then store it onto SD Card. Its kind of a datalogger  @Chef Flambe

Voting to close as this question was abandoned in unanswerable form over a year ago.

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.

While occasionally useful, this overlooks the dangerous issue that even apart from the inversion, the Arduino cannot safely handle RS232 levels.  Pretty much every level shifter intended for RS232 is an inverting level shifter - so this issue basically only comes up with homegrown minimalist implementations, and would not be expected to occur with the MAX3233 the poster says they are using.


text:
Will it work ? MPU6050 Gyro etc. etc. module
Will this code read the values properly ?
Using MPU6050.h.
#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.

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");
  }

}


text:
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

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.

thanks for your help, I was just able to upload the hex using Xloader software.


text:
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.

Which chip does your Arduino use for the USB interface? Is it the CH340 or the PL2303, or some other variant?  Did any of the answers help resolve your issue? If so, could you accept the answer the answer that helped you?

@Greenonline Unfortunately none of the answers worked for me. I program my Arduino using an Ubuntu machine, though I'd still try any new answers that might come up. Downloading the PL2303 driver did not work for me. And I cannot figure out what chip my Arduino uses.

As noted elsewhere, 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 is the most reliable looking one that I could find, and it does appear to be actively developed. 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

mac-usb-serial.com worked for me in getting a CH34x driver working in 10.11 El Capitan.  It was worth the $8 to put an end to fighting with it.

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 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):

Open a terminal
Execute: sudo kextunload /System/Library/Extensions/AppleUSBFTDI.kext/ -> this will unload the Apple FTDI Kernel extension.
Reinstall the FTDI driver
Start the Arduino IDE, select a Com Port, the correct Arduino board
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 :)

I tried the answer that semm0 mentioned, but the terminal said that I did not have the proper permissions to access that.

Check this 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

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


text:
How to empty the buffer for Serial port?

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.

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();
}

Thank you! Unfortunately, this isn't fixing my looping problem. I put port->read(); at the end of my loop but it is still running a variable number of times.

Maybe if you posted your real code instead of some mashup of c and basic we might be able to help you better.

I've posted the code.

That is quite some code. I can't fathom quite what you're attempting to do there.  I think your main problem is that you are using readString() which doesn't do what you think it does.  I think you want readString('\n') to read up to a newline (or whatever terminator you choose) character. Also, what is all the rest meant to be doing? Whatever it is you seem to have made it overly complex and bizarre.  Please expand your question with what you intend it to do.

The code I posted above is a much-shortened snippet of the original code, but it displays the same issue (I shortened it for easier reading and debugging). The device is a simple virtual keyboard, accepting some commands over the bridge and outputting them with Keyboard.println.

To your point about readString(), I do want to read the entire buffer into cmd. I assume using readString('\n') instead would have the same effect if \n were at the end of the line?

readString() will read until it fails to read for 1 second. readString('\n') will read until it fails to read for 1 second or receives a newline. Oh and do yourself a favour and lose the crutch of the String class.

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.

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();
    }
  }
}

I suspect this function not acting as read() to decrease the number returned by available(); - readString will indeed read (and decrease the number in the buffer) however it just reads until it times out, so it could read more, or less even, than is required.


text:
unresolved overloaded function type for Wire.onReceive

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.

    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.

I ended up just putting the functions inside the .ino file. it's not as neat as I'd like but it works. Thanks for teaching me something new.

You can make a static class function (one that does not belong to a particular instance) and keep the function inside your class then.


text:
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:

Move 10 degrees
Reset position
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.

What do you imagine that memset(buf1,'0',VW_MAX_MESSAGE_LEN); does?

@jwpat7, fills buf1 with zeros? It wasn't intended to be null-terminator or anything else. msg1 is a of type String, not char *

@Quaker You're filling the string with VW_MAX_MESSAGE_LEN zero characters - it's ending up as "000000000....000".  '0' is the character 0 as if you had typed it on your keyboard, not ASCII character code 0 or the NULL character.

Please post the data types for msg1 and buf1.

I suspect that the servo is responsible for this - can you run the code, with the myservo.write() but without the servo physically connected. This will eliminate a possible electrical problem.

@NickGammon, I will try that. msg1 is a String while buf1 is a uint8_t.

@Majenko, I didn't understand your comment. AFAIK there are only two options, 0 as a number and 0 as an ASCII character, what is the 3rd option you suggested?

@Quaker NULL is 0 as a number - used to denote the end of a string.  It's known as the "NULL Terminating Character".  You are using "0 as an ASCII character" when you should be using "0 as a number to denote the NULL terminating character".

@Majenko, no I don't. That wasn't my intention and I clearly stated in the second comment that It wasn't intended to be null-terminator. When I wanted to terminate the string I did it as in buf1[buflen1] = '\0';, while when I used memset() I only wanted to overwrite the whole buffer with a constant character, it could have been 'Z' or anything else.

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.

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,2,3,4,5])

It seems likely buf1 is uint8_t judging by this prototype:  uint8_t  vw_get_message (uint8_t *buf, uint8_t *len)

buf1 is indeed a uint8_t and msg1 is a String. I thought that assigning a char * string to a String copies it (as in C#) and not just copying the pointer.

Could it be that the movement of the engine is blocking the RF receiver from receiving the message that is being sent while it's working?

I'm reading online that there are a lot of problems with receiving RF signals while servo is running. When the signal wire of servo is disconnected my code works fluently, but when it is connected and the engine is running - the troubles starts. Any suggestion?

For problem diagnosis, you could try powering different systems (such as Arduino, radio, and servos) with isolated and well-bypassed power supplies, and make all connections with short, soldered-in-place wires.  (See eg seattlerobotics re bypassing.)  Have a 10 or 20 uF cap connected where power goes onto each board, and 0.001 or 0.01 uF caps from each power line to ground, to prevent electrical noise from spreading via power supply connections.  You may need to enclose the radio (except its antenna) in a metal case.

If you can temporarily substitute a wired connection in place of the radio connection, that would allow you to check out your code and perhaps decide if problems are mostly hardware or mostly software.


text:
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 ?
#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.

Do you guys think it will work without the Serial.print library ? I cant approve if i get the right values. Dont want my project to crash.

Whenever I log data, the serial port freezes - after how much data? A line? 100 lines?

Arbitrary 50-70 lines

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();
  }
}

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.


text:
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.

Looking at the schematic 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 (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.

Or use one of the internal voltage references (1.1V or 2.56V) in the ATmega1280.

@Gerben Yeah I thought of that, the asker didn't make it clear what types of sensors he was using and what village ranges he was looking at, but vaguely implied it was 5 volts.

@Jake, Analog Sensor A0, voltage range required = 0 - 5 V. analog reference DEFAULT(or EXTERNAL tied to 5V), same result.


text:
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!

Use Serial. It can be used to send text to the console, and receive text-input from the user.

Is there a way to use the c prompt? I hate to have him download something and hung up on the install. I realize it's simple but he's not computer savvy. Thanks for the info!

No, you can't do it from the "c prompt". You need some kind of serial terminal. Many versions of Windows come with Hyper Terminal which will do the job.  Downloading a terminal program isn't a onerous task or particularly difficult. There are many to choose from and they are easy to install.  I have never known one to get "hung up on the install".

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

Ya, I see that recommendation, thought of it, but don't think 80 bucks is worth the project to buy the yun.

you could always use a matrix keypad and a LCD display for entering the details.
Via the computer will involve installing drivers and will require you to create a simple app to send data via the serial port

Yes, I think that's going to be the best answer. Thanks :)


text:
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?
#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() {}

Is it an actual Windows BMP image file format?  That's not a trivial format and you need to understand it intimately.

Yes, it is. I have been reading about them and this helped greatly https://upload.wikimedia.org/wikipedia/commons/c/c4/BMPfileFormat.png but still confused as of how certain values correspond to certain positions. I haven't been able find a comprehensive guide on it yet.

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.

Wow, Thanks just the explanation I was looking for.


text:
Reading states of multiple toggle switches
I'm working on modifying this example 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:

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.

Not sure this is the entirety of the problem, or if it's just a "transcription" error when you made your circuit diagram, but you've got both sides of your switches connected to +5V. One side should be connected to ground, and the other to +5V.

@AndrewMadsen, yes, that is just a transcription error...thank you for catching that!

A bit off topic: why aren't you using the internal pullup resistors? You could simply connect the input to GND (for logical zero) or leave them open (for logical one, courtesy of the pullup resistor).

@IgorStoppa, I just wasn't aware they could work that way to be honest (still a beginner with Arduino)

I think your {} bracketing got a bit messed up, do you intend to only check the state of switch two if switch one changed?

Sort out the formatting of your program and you should immediately see your error.  This is a good example where proper indenting is vitally important.  Don't get lazy right from the beginning and force yourself to lay your programs out properly. It'll become a good habit to get into.

@BrettAM, that seems like it could be right...I had wanted to check the states of all the switches while the sketch is running.

@BrettAM That said, I'm not quite seeing where my bracketing has broken down.

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;
}

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

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

That's definitely part of the problem; so I did mark it up. Thank you! Still only able to read the result of switch one though.


text:
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.

Does the error occur on a POD class? say, a class with just one public integer member and the default constructor/deconstructor? Also, if it works for primatives, it should work with pointers to your class.

Please post the code, not just the error message. Make up a Minimal, Complete, and Verifiable example.

Yes, it occurs on a POD class, and it returns an even larger error message upon trying to use a pointer

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

I'm too used to java