I was able to get a lot of help from this topic string.
But I am still getting some FIFO overflows and weird row titles. What is wrong with my code? Did I miss a step or did I leave something out. I have attached a screen shot of the results, code, and a picture of the current circuit that got the results.
Modified_MPU6050_DMP6.ino (14.8 KB)
The FIFO overflow could be a serious problem, but I don't know what is causing it.
Perhaps you can select less output, so the Arduino has to do less calculations.
The weird characters seems to be the teapot demo data.
Serial.write(teapotPacket, 14);
Could you keep the "OUTPUT_READABLE_QUATERNION" and comment out the others. So the output will only be the quaternion data. Perhaps that is working.
If it is working, it should work without a single problem, for hours, for days, for years.
The breadboard is known to be the cause of many problems, because sometimes the contacts are not very good. The other most common problem is the supply voltage, but since the sensor is running at 3.3V, it should not be a problem.
This is taking way too long, and it feels like I am going in circles. What I am going to ask you now is this. Since I am able to now get readings from the sensor, and I have a template to filter what the sensor reads. What I need is a simplified solution that would format the information, similar to the GY's playground website, so that when I send it to a phone I can record it. I am on a tight deadline and I need to have a baseline for my project.
I'm a little confused.
I answered your questions about filtering and about FIFO overflow.
Can you use the #defines in the dmp example sketch to output only the quaternion ?
If that is working without FIFO overflow, you are one step further.
I don't know what GY's playground is. Do you want to send it to a phone ? with Bluetooth ? on Android ? I don't know about using the data on a phone. You could start a new topic for that.
Sorry for confusing you earlier. I was getting a little frustrated, but now I am doing much better since I started modified the code to fit my needs.
In the next post is the new code that I modified from Jeff's original which is able to display two values that I need for my project. Problem no is that the accelerometer will not display constant values through the buffer and causes a FIFO overflow. I originally used the WORLDACCEL routine, but I was worse than the REALACCEL. What can you suggest to improve this issue?
Also, I understand that on line 196 I could put in code to perform another function, but I wanted to ask where I should code that would be able to transfer the results from the GY to another component? I have code that would transfer information from the Arduino to a Bluetooth transmitter (RN42), but I can't figure out where I exactly I should place it.
// I2C device class (I2Cdev) demonstration Arduino sketch for MPU6050 class using DMP (MotionApps v2.0)
// 6/21/2012 by Jeff Rowberg <jeff@rowberg.net>
// Updates should (hopefully) always be available at https://github.com/jrowberg/i2cdevlib
//
// Changelog:
// 2012-06-21 - added note about Arduino 1.0.1 + Leonardo compatibility error
// 2012-06-20 - improved FIFO overflow handling and simplified read process
// 2012-06-19 - completely rearranged DMP initialization code and simplification
// 2012-06-13 - pull gyro and accel data from FIFO packet instead of reading directly
// 2012-06-09 - fix broken FIFO read sequence and change interrupt detection to RISING
// 2012-06-05 - add gravity-compensated initial reference frame acceleration output
// - add 3D math helper file to DMP6 example sketch
// - add Euler output and Yaw/Pitch/Roll output formats
// 2012-06-04 - remove accel offset clearing for better results (thanks Sungon Lee)
// 2012-06-01 - fixed gyro sensitivity to be 2000 deg/sec instead of 250
// 2012-05-30 - basic DMP initialization working
// 2013-03-14 - Modified to better suit Nano 3.0
// Arduino Wire library is required if I2Cdev I2CDEV_ARDUINO_WIRE implementation
// is used in I2Cdev.h
#include "Wire.h"
// I2Cdev and MPU6050 must be installed as libraries, or else the .cpp/.h files
// for both classes must be in the include path of your project
#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"
//#include "MPU6050.h" // not necessary if using MotionApps include file
// class default I2C address is 0x68
// specific I2C addresses may be passed as a parameter here
// AD0 low = 0x68 (default for SparkFun breakout and InvenSense evaluation board)
// AD0 high = 0x69
MPU6050 mpu;
// uncomment "OUTPUT_READABLE_QUATERNION" if you want to see the actual
// quaternion components in a [w, x, y, z] format (not best for parsing
// on a remote host such as Processing or something though)
#define OUTPUT_READABLE_QUATERNION
// uncomment "OUTPUT_READABLE_REALACCEL" if you want to see acceleration
// components with gravity removed. This acceleration reference frame is
// not compensated for orientation, so +X is always +X according to the
// sensor, just without the effects of gravity. If you want acceleration
// compensated for orientation, us OUTPUT_READABLE_WORLDACCEL instead.
#define OUTPUT_READABLE_REALACCEL
#define LED_PIN 13 // (Arduino is 13, Teensy is 11, Teensy++ is 6)
bool blinkState = false;
// MPU control/status vars
bool dmpReady = false; // set true if DMP init was successful
uint8_t mpuIntStatus; // holds actual interrupt status byte from MPU
uint8_t devStatus; // return status after each device operation (0 = success, !0 = error)
uint16_t packetSize; // expected DMP packet size (default is 42 bytes)
uint16_t fifoCount; // count of all bytes currently in FIFO
uint8_t fifoBuffer[64]; // FIFO storage buffer
// orientation/motion vars
Quaternion q; // [w, x, y, z] quaternion container
VectorInt16 aa; // [x, y, z] accel sensor measurements
VectorInt16 aaReal; // [x, y, z] gravity-free accel sensor measurements
VectorInt16 aaWorld; // [x, y, z] world-frame accel sensor measurements
VectorFloat gravity; // [x, y, z] gravity vector
float euler[3]; // [psi, theta, phi] Euler angle container
float ypr[3]; // [yaw, pitch, roll] yaw/pitch/roll container and gravity vector
// packet structure for InvenSense teapot demo
uint8_t teapotPacket[14] = { '
, 0x02, 0,0, 0,0, 0,0, 0,0, 0x00, 0x00, '\r', '\n' };
// === INTERRUPT DETECTION ROUTINE ===
volatile bool mpuInterrupt = false; // indicates whether MPU interrupt pin has gone high
void dmpDataReady() {
mpuInterrupt = true;
}
// === INITIAL SETUP ===
void setup() {
// join I2C bus (I2Cdev library doesn't do this automatically)
Wire.begin();
// initialize serial communication
Serial.begin(9600);
// NOTE: 8MHz or slower host processors, like the Teensy @ 3.3v or Ardunio
// Pro Mini running at 3.3v, cannot handle this baud rate reliably due to
// the baud timing being too misaligned with processor ticks. You must use
// 38400 or slower in these cases, or use some kind of external separate
// crystal solution for the UART timer.
// initialize device
Serial.println(F("Initializing I2C devices..."));
mpu.initialize();
// verify connection
Serial.println(F("Testing device connections..."));
Serial.println(mpu.testConnection() ? F("MPU6050 connection successful") : F("MPU6050 connection failed"));
// load and configure the DMP
Serial.println(F("Initializing DMP..."));
devStatus = mpu.dmpInitialize();
// make sure it worked (returns 0 if so)
if (devStatus == 0) {
// turn on the DMP, now that it's ready
Serial.println(F("Enabling DMP..."));
mpu.setDMPEnabled(true);
// enable Arduino interrupt detection
Serial.println(F("Enabling interrupt detection (Arduino external interrupt 0)..."));
attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();
// set our DMP Ready flag so the main loop() function knows it's okay to use it
Serial.println(F("DMP ready! Waiting for first interrupt..."));
dmpReady = true;
// get expected DMP packet size for later comparison
packetSize = mpu.dmpGetFIFOPacketSize();
} else {
// ERROR!
// 1 = initial memory load failed
// 2 = DMP configuration updates failed
// (if it's going to break, usually the code will be 1)
Serial.print(F("DMP Initialization failed (code "));
Serial.print(devStatus);
Serial.println(F(")"));
}
// configure LED for output
pinMode(LED_PIN, OUTPUT);
}
// === MAIN PROGRAM LOOP ===
void loop() {
// if programming failed, don't try to do anything
if (!dmpReady) return;
// wait for MPU interrupt or extra packet(s) available
while (!mpuInterrupt && fifoCount < packetSize) {
// other program behavior stuff here
// .
// .
// .
// if you are really paranoid you can frequently test in between other
// stuff to see if mpuInterrupt is true, and if so, "break;" from the
// while() loop to immediately process the MPU data
// .
// .
// .
}
// reset interrupt flag and get INT_STATUS byte
mpuInterrupt = false;
mpuIntStatus = mpu.getIntStatus();
// get current FIFO count
fifoCount = mpu.getFIFOCount();
// check for overflow (this should never happen unless our code is too inefficient)
if ((mpuIntStatus & 0x10) || fifoCount == 1024) {
// reset so we can continue cleanly
mpu.resetFIFO();
Serial.println(F("FIFO overflow!"));
// otherwise, check for DMP data ready interrupt (this should happen frequently)
} else if (mpuIntStatus & 0x02) {
// wait for correct available data length, should be a VERY short wait
while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();
// read a packet from FIFO
mpu.getFIFOBytes(fifoBuffer, packetSize);
// track FIFO count here in case there is > 1 packet available
// (this lets us immediately read more without waiting for an interrupt)
fifoCount -= packetSize;
#ifdef OUTPUT_READABLE_QUATERNION
// display quaternion values in easy matrix form: w x y z
mpu.dmpGetQuaternion(&q, fifoBuffer);
Serial.print("quat\t");
Serial.print(q.w);
Serial.print("\t");
Serial.print(q.x);
Serial.print("\t");
Serial.print(q.y);
Serial.print("\t");
Serial.println(q.z);
#endif
#ifdef OUTPUT_READABLE_REALACCEL
// display real acceleration, adjusted to remove gravity
mpu.dmpGetQuaternion(&q, fifoBuffer);
mpu.dmpGetAccel(&aa, fifoBuffer);
mpu.dmpGetGravity(&gravity, &q);
mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);
Serial.print("areal\t");
Serial.print(aaReal.x);
Serial.print("\t");
Serial.print(aaReal.y);
Serial.print("\t");
Serial.println(aaReal.z);
#endif
delay(500);
// blink LED to indicate activity
blinkState = !blinkState;
digitalWrite(LED_PIN, blinkState);
}
}
The "delay(500)" would be the place to insert new code, before the delay.
The samples have been read, and the delay is only to wait for a new request.
I don't understand why you still have FIFO overflow, sorry.
Which coordinates are better, I don't know. It depends on what you want.
I guess you use the UART_RX and UART_TX of the RN42.
I have never used Bluetooth with the Arduino, so I don't know how data is best transferred.
What I need from the GY521 is the orientation and movement readings so that I can see a person's activity within a specific amount of time.
I have the RN42 communication taken care of, but I just needed advise of where to place the RN42 subroutine in the code to transmit the GY's readings.
Have any suggestions of how I can get the accelerator readings to be stable? The gyroscope is working, but the REALACCEL is random.
Swoop132:
Have any suggestions of how I can get the accelerator readings to be stable? The gyroscope is working, but the REALACCEL is random.
I would mention two things. First, the second mpu.dmpGetQuaternion(&q, fifoBuffer); line is unnecessary since you have already run it once and populated the "q" quaternion object with data from the FIFO buffer. Running it twice shouldn't hurt anything, but it will take extra time, which is never a good thing.
Second, the delay(500) line is going to kill your performance. The DMP6 example sketch is only partially interrupt-driven; the "data available" interrupt flag (in the mpuInterrupt variable) will be set immediately by the interrupt handler code, but the data won't actually be read just until the loop() function restarts and you get to that part of the code again. In the default configuration, the DMP is spitting out 42 bytes of data at 100 Hz, and if you use delay(500) (which is a blocking call), then you will let 50 packets buffer in the FIFO. The FIFO is only 1024 bytes, and 50 x 42 = 2100 bytes, which means you will get an overflow basically every time with huge gaps in between each new position/movement output.
The delay should go away entirely, or be implemented somehow in a non-blocking way. Also, you can change the output rate of the DMP to something slower than 100Hz (sometimes hard to process on an Arduino especially at 8MHz) by modifying the last byte on line 261 of MPU6050_6Axis_MotionApps20.h. The default value is 0x01, but setting it to 0x07 will give you a 25Hz rate.
Thank you for explaining some things and providing me with some great advice, but I have some questions about the next issue that I am running into. As Erdin and I discussed, there was an unclear location of where I could place additional code to transmit the GY's recordings. I tried placing the transmission commands in the location that was commented, but also where Erdin suggested. No matter what I tried there was either an error stating that the commands needed to be character strings or the phone app that I am developing did not recognize what was being transmitted. I know that the phone app and the Bluetooth transmitter work because I have tested it with a test program.
With the suggestion of slowing down the DMP frequency to 25Hz, would this allow the data to be transmittable to the phone? If not, what would you suggest that would allow me to transmit the information?