unisev Posted June 8, 2013 Report Share Posted June 8, 2013 Hello and thank to Jeff Rowberg for your great work and those usefull examples. I'm trying to make those example codes working fine :The “MPU6050_raw” is ok.But the “MPU6050_DMP6” is not : 1) INTERRUPTION PIN : My interruption pin is not connected between MPU6050 & Atmega. (I’m using a all-in-one Drotek flight controller).Is it possible to change the wiring of the INT to another Arduino PIN (I mean, not the digital PIN2) ? If yes, where can I change this "parameter" in the code ?For the moment, and just to make it work, I simply supress the while loop... 2) PROCESSING RENDER : Here is my screen : As you can see, processing is receiving DATA, but this green thing does not look like a teapot. Thanks for reading this. Quote Link to comment Share on other sites More sharing options...
unisev Posted June 12, 2013 Author Report Share Posted June 12, 2013 Hello, after taking a look to this video : http://www.google.fr/url?sa=t&source=web&cd=2&ved=0CDAQtwIwAQ&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DShdGoUaXMnc&ei=S5m3UZCVIYKxhAf6nYDQDA&usg=AFQjCNFDnE0eLVZEfWnN2C7f2c4VYmP2Iw&sig2=VOD23UV7V3FXoDaem7ZNjA I now understand there is no teapot... my only problem is the immobility of this "arrow plane" So let me give you more about my hardware : I'm using a "Drotek Flight Controller" originaly designed to be used with the MultiWii code : http://www.drotek.fr/shop/fr/home/72-multiwii-mpu6050-hmc5883-ms5611.html This little PCB contain : AtMega328P (& FTDI) MPU6050 gyro & accelerometer HMC5883 magnetometer MS5611 altimeter And currently don't know how those device are arranged, but it seems that the 328P is not connected to the INT pin of the MPU6050. Anyway, this "flight controller" is working well with the MPU6050_raw example. So let me give you more about my code : I did not modify the Processing code, except to use the right COM port, so let's talk about the Arduino Code : Since I have no interrupt PIN connected between the 328P and the MPU6050, I must modify the Arduino code at least here : // 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 // . // . // . } Firstly I just removed all this "while loop", now the 328P is sending data to Processeing, but the "Arrow Plane" is still not moving.Does somebody can help ? PS : A also change in the MPU6050.h file this line from LOW to HIGH : #define MPU6050_DEFAULT_ADDRESS MPU6050_ADDRESS_AD0_LOW Quote Link to comment Share on other sites More sharing options...
janeppo Posted June 17, 2013 Report Share Posted June 17, 2013 Just trying to help ... I had similar problems with my Drotek MPU9150 breakout connected to an Arduino Uno rev3, but got it working after a while. I also changed the default address to MPU6050_ADDRESS_AD0_HIGH. That's fine, but a cleaner way to do this is to leave MPU6050.h alone and change the sketch: // 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 (for Drotek breakout) MPU6050 mpu(0x69); the teapot demo expects binary input from the serial line. The sketch provides this for the raw sensor data (but not for the DMP output) // uncomment "OUTPUT_TEAPOT" if you want output that matches the // format used for the InvenSense teapot demo #define OUTPUT_TEAPOT if I do not connect the interrupt pin, the teapot demo will nevertheless show a 'moving' plane model, but sometimes it stops unexpectedly if I do connect the interrupt pin, the demo will not stop unexpectedly sometimes the teapot demo starts with a 'stuck' plane model. It will start moving after I press the Arduino reset button one or more times you can check the serial communication with the serial monitor and compare the MPU6050_DMP6 and MPU6050_raw sketches Your serial DATA from the MPU6050_DMP6 sketch look familiar to me. There is a regular increase in the last position, that more or less corresponds to an initial settling to a stable orientation. If the teapot demo works (i.e. the plane model moves) for the MPU6050_raw sketch it is hard to understand why it doesn't work with these serial DATA from the MPU6050_DMP6 sketch, unless this is ALL serial DATA and the output from the sketch stopped unexpectedly. Quote Link to comment Share on other sites More sharing options...
unisev Posted June 17, 2013 Author Report Share Posted June 17, 2013 Thank you janeppo, I finally found the problem, this was about the 14 byte packet synchronisation.Finally, the last trick to fix it was just to add ONE character in the information text send by the Arduino : This is not a real FIX but it works : The best way should be to re-think the Processing synchronising part. Quote Link to comment Share on other sites More sharing options...
nixt Posted July 18, 2013 Report Share Posted July 18, 2013 I am facing the same problem. Data is coming into processing but nothing moves. The model did move three times but that was only out of chance. It seems the synchronising part never really synchronizes and keeps going in a loop. I tried to your fix unisev but it didn't work for me... any ideas? Quote Link to comment Share on other sites More sharing options...
nixt Posted July 20, 2013 Report Share Posted July 20, 2013 I fixed it by completely removing this part of the code : if (aligned < 4) { // make sure we are properly aligned on a 14-byte packet if (serialCount == 0) { if (ch == '$') aligned++; else aligned = 0; } else if (serialCount == 1) { if (ch == 2) aligned++; else aligned = 0; } else if (serialCount == 12) { if (ch == '\r') aligned++; else aligned = 0; } else if (serialCount == 13) { if (ch == '\n') aligned++; else aligned = 0; } //println(ch + " " + aligned + " " + serialCount); serialCount++; if (serialCount == 14) serialCount = 0; } else It does not try to align to the 14-byte packet anymore but it seems to work. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.