The Yaw function seems to work. It's really hard to tell though because the slightest movement of the sensor makes the output swing wildly. I don't have much experience with this type of sensor, so any progress I make will be like a turtle, and it's not really my highest priority. I suspect that porting the existing well-known functional code would provide a better result than me hacking on the simple program.
Thanks Steve. That's what I had. I'm now seeing more drift... in all axes.
Kaeru,
I wonder if this code isn't correct now! Without further corrections, I would expect some drift... after all, you are integrating errors. That's why the DMP exists.
If you are comparing your results with the DMP6 results ...
I have had a chance to play with the DMP_6 functionality with the Arduino... I can see why everyone is excited, and I can see
that there is a huge deterrent: the overall lack of information. The results look very impressive... but the absolute values are wrong.
And I think that the results only look impressive, because the unit always comes back to a negligible error once motion stops... but it does so over
time. Clearly, what is being done (among other things) is that in the absence motion, variables are being recalculated... with the knowledge that no rotation has occurred and the assumption of known acceleration.
If I look at the DMP values right after motion stops... then it isn't as impressive. These kinds of correction techniques are useful... and I am not criticizing them, I am just saying the dis-advantages of using the DMP might sometimes outweigh the advantages ... it seems to be how well the solution meets a particular context.
So, your effort is well worth your time.
When you say that you tested the code on the Arduino and there was no drift... were you referring to the DMP6 example?
One thing that is odd ... when I looked at the DMP6 output, the total rotation on an axis was always less than 180...so for example, on the roll axis... it went from +77 to -80 something... . don't remember the exact numbers. And my look at your results, errors pushed the roll axis 0 to -154... and then reversed direction.
Unfortunately, your code makes the cube rotate in every 3 axis.
But minor amendment makes it stable, except Yaw response.
static unsigned long _time = 0; seems to make the cube rotation in every 3 axis, and MPU6050 = i2c_newbus(0, 1, 0); seems to make high sensitivity of the cube response. (Slight rotation of GY-521 makes the cube flipping.)
I connected GY-521 module to Propeller QuickStart as follws;
VCC 3.3V
GND GND
SCL P28
SDA P29
Here is my amended one.
But I wander why your code works well on your board and not on my board.
Rich,
I will make new thread about MPU6050 DMP, and lets discuss MPU6050 DMP matter there.
My attempt is porting MPU6050 quaternion Arduino code in Varesano.net (NOT DMP one) to Propeller C code.
It is almost done, great thanks to Jazzed, except Yaw response.
With original Arduino code, the cube in Processing screen responds to all Yaw, Pitch and Roll rotation of GY-521 module.
But with ported Propeller C code, the cube only responds to Pitch and Roll rotation and does not respond to Yaw rotation.
I guess no response of Yaw might be caused by different initialization of MPU6050.
Sorry, didn't mean to deflect the conversation. And I should also correct myself. When I was referring to the results looking as expected, I hadn't moved the unit ...
A minor oversite:)
After movement I am seeing chaotic motion as before... on all axes.
Hard as it is to believe, I am wondering if there isn't a hidden serial problem. The program seems very sensitive to serial related issues. Occasionally, the order that I do things...
seems to affect the starting conditions that I see on the screen.
It wouldn't take more than an occasional dropped byte to create this kind of chaos.
To figure this out, you could take data that you know is valid and which produces known dynamic results and reports to the screen... feed that data to the program you have ported, rather than reading it from the MPU...the timing doesn't have to be perfect. If it is a serial problem, it should produce a pattern that you don't expect.
Before doing all that work, try lowering the Baud rate.
I get the same basic results whether I use 5V or 3.3V... the only exception is that on the Project Board you don't get the 5V you need from Vin when powered by usb.
Also, I am using Processing on a Mac... so my results could be a little different than what you see.
I should add that I looked at the serial stream using the screen utility. There was an occasional hiccup, at the very start, which I think is a normal buffer issue on the Mac. So long as I started the serial terminal before the Prop sent data, everything appeared to be ok coming out of the Prop. I didn't examine the actual data, just the format and data size, which looked fine. And I am not entirely certain that my Mac is 100% healthy in the USB terminals. I was getting system problems before a sick board of mine finally died. I know it was USB at that time, because if I simply turned the board off, the system recovered. If I didn't the system crashed.
I can't believe that I have a hardware problem, because the DMP_6 program worked just fine. So it looks entirely possible that there is a slight difference between how the Prop is generating serial and how Processing is interpreting serial. And since my serial utility doesn't have a problem with the Prop signals, I'm guessing there is a problem on the Processing side... probably Java... probably nothing they can do about it.
I'm not sure if you all are unsure if the problems you are seeing are from the sensor itself or from the code reading the sensor. While I was impressed by these sensors when used with an Arduino, what really blew me away was it's use in a camera stabilizer.
I recently purchased a 3-axis camera stabilizer to use with my 'copters. The BaseCam board uses a MPU6050 as its sensor and displays the orientation with a GUI. The yaw (and other axes) are rock solid with the GUI.
I think it's pretty clear these sensors can provide really good position information. I'd sure like to figure out how to get similar results with a Propeller.
1) Where did the file we have been testing originate?
2) If it is a port of another file, please show the original.
3) Is it known to work as is without modification anywhere?
1) Where did the file we have been testing originate?
2) If it is a port of another file, please show the original.
3) Is it known to work as is without modification anywhere?
Not sure if this is helpful but the Processing code came from the FreeIMU project. I found the full FreeIMU Arduino & Processing project on GITHub. As far as I can tell this is the Fabio Varesano Association's project, maintained in Fabio's passing, by a group of interested developers.
From what I can gather, the Arduino code that works with the Processing "FreeIMU_cube" project is the Arduino example project "FreeIMU_serial" within the "libraries" portion of the project.
FreeIMU_cube path from the project archive:
FreeIMU_serial path from the project archive:
I've had success in using the FreeIMU_cube code with Jazzed's propeller code, but yes getting "quite jumpy results."
I've not had success with the FreeIMU_serial Arduino code on an Arduino Leonardo. Code compiles, I can see that Processing is sending its "v" char from it'd Setup function. The R/X LED on the Leonardo lights up about every second. But Processing does not get a response from the Leonardo. And, yes, I've updated the port to the Arduino's port ID.
Perhaps the FreeIMU_serial Arduino code could be translated to a SimpleIDE project? I'm out of time for the day, but will look into that later.
1) Where did the file we have been testing originate? 2) If it is a port of another file, please show the original. 3) Is it known to work as is without modification anywhere?
Belows are not ported from Fabio Varesano Association, but from MPU6050_DMP6.
The I2C routines seem ok on P0/1 (my P28/29 pins are not easily accessible), but I've moved on to the simplei2c library because I understand it better. Reading/writing one byte at a time is what the I2Cdev.cpp code does. I've been able to get the initialization started, but I've hit other problems.
Now, that I've been able to run the "proper initialization" the old program I attached is horribly unstable. LOL. Maybe more tomorrow ....
Comments
This is what I did:
void getQ(float * q){ unsigned long lastUpdate, now; float val[6]; getValues(val); //now = micros(); now = CNT / (CLKFREQ / 1000000.0); //print("now = %d \n", now); //print("lastUpdate = %d \n", lastUpdate); sampleFreq = 1.0 / ((now - lastUpdate) / 1000000.0); lastUpdate = now; //print("sampleFreq = %f \n", sampleFreq);void getQ(float * q){ unsigned long lastUpdate, now; float val[6]; getValues(val); //now = micros(); // now = CNT / (CLKFREQ / 1000000.0); static unsigned long _time = 0; unsigned long rc = (CNT - _time); _time = CNT; now = rc/(CLKFREQ/1000000); //print("now = %d \n", now); //print("lastUpdate = %d \n", lastUpdate); sampleFreq = 1.0 / ((now - lastUpdate) / 1000000.0); lastUpdate = now; //print("sampleFreq = %f \n", sampleFreq);Kaeru,
I wonder if this code isn't correct now! Without further corrections, I would expect some drift... after all, you are integrating errors. That's why the DMP exists.
If you are comparing your results with the DMP6 results ...
I have had a chance to play with the DMP_6 functionality with the Arduino... I can see why everyone is excited, and I can see
that there is a huge deterrent: the overall lack of information. The results look very impressive... but the absolute values are wrong.
And I think that the results only look impressive, because the unit always comes back to a negligible error once motion stops... but it does so over
time. Clearly, what is being done (among other things) is that in the absence motion, variables are being recalculated... with the knowledge that no rotation has occurred and the assumption of known acceleration.
If I look at the DMP values right after motion stops... then it isn't as impressive. These kinds of correction techniques are useful... and I am not criticizing them, I am just saying the dis-advantages of using the DMP might sometimes outweigh the advantages ... it seems to be how well the solution meets a particular context.
So, your effort is well worth your time.
When you say that you tested the code on the Arduino and there was no drift... were you referring to the DMP6 example?
I don't know what it means.
Thank you for your code.
Unfortunately, your code makes the cube rotate in every 3 axis.
But minor amendment makes it stable, except Yaw response.
static unsigned long _time = 0; seems to make the cube rotation in every 3 axis, and MPU6050 = i2c_newbus(0, 1, 0); seems to make high sensitivity of the cube response. (Slight rotation of GY-521 makes the cube flipping.)
I connected GY-521 module to Propeller QuickStart as follws;
VCC 3.3V
GND GND
SCL P28
SDA P29
Here is my amended one.
But I wander why your code works well on your board and not on my board.
Rich,
I will make new thread about MPU6050 DMP, and lets discuss MPU6050 DMP matter there.
I want to finalize my attempt.
It is almost done, great thanks to Jazzed, except Yaw response.
With original Arduino code, the cube in Processing screen responds to all Yaw, Pitch and Roll rotation of GY-521 module.
But with ported Propeller C code, the cube only responds to Pitch and Roll rotation and does not respond to Yaw rotation.
I guess no response of Yaw might be caused by different initialization of MPU6050.
Initialization in Arduino code:
setClockSource(MPU60X0_CLOCK_PLL_XGYRO);
setFullScaleGyroRange(MPU60X0_GYRO_FS_250);
setFullScaleAccelRange(MPU60X0_ACCEL_FS_2);
setSleepEnabled(false);
setI2CMasterModeEnabled(0);
setI2CBypassEnabled(1);
setFullScaleGyroRange(MPU60X0_GYRO_FS_2000);
Initialization in Propeller C code:
n = i2c_out(MPU6050, devAddr, PWR_MGMT_1, 1, &PowerMgmt, 1);
n += i2c_out(MPU6050, devAddr, SMPLRT_DIV, 1, &SampleRate, 1);
n += i2c_out(MPU6050, devAddr, CONFIG, 1, &DLP, 1);
n += i2c_out(MPU6050, devAddr, GYRO_CONFIG, 1, &GyroFS, 1);
n += i2c_out(MPU6050, devAddr, ACCEL_CONFIG, 1, &AccelFS, 1);
I referred Propeller C code initialization to http://forums.parallax.com/showthread.php/154127-MPU-9150-PASM-Driver
I also make quaternion code in Spin and find the Spin code also does not respond to Yaw.
Does anyone familiar with MPU6050, know whether the different initialization of MPU6050 causes no response of Yaw or not ?
Thanks,
Kaeru no Ojisan
A minor oversite:)
After movement I am seeing chaotic motion as before... on all axes.
Hard as it is to believe, I am wondering if there isn't a hidden serial problem. The program seems very sensitive to serial related issues. Occasionally, the order that I do things...
seems to affect the starting conditions that I see on the screen.
It wouldn't take more than an occasional dropped byte to create this kind of chaos.
To figure this out, you could take data that you know is valid and which produces known dynamic results and reports to the screen... feed that data to the program you have ported, rather than reading it from the MPU...the timing doesn't have to be perfect. If it is a serial problem, it should produce a pattern that you don't expect.
Before doing all that work, try lowering the Baud rate.
I get the same basic results whether I use 5V or 3.3V... the only exception is that on the Project Board you don't get the 5V you need from Vin when powered by usb.
Also, I am using Processing on a Mac... so my results could be a little different than what you see.
Can I confirm that neither Jazzed's MPU6050_q2 nor my MPU6050_quaternion20140702 does not make the cube stabilized ?
I can't believe that I have a hardware problem, because the DMP_6 program worked just fine. So it looks entirely possible that there is a slight difference between how the Prop is generating serial and how Processing is interpreting serial. And since my serial utility doesn't have a problem with the Prop signals, I'm guessing there is a problem on the Processing side... probably Java... probably nothing they can do about it.
I recently purchased a 3-axis camera stabilizer to use with my 'copters. The BaseCam board uses a MPU6050 as its sensor and displays the orientation with a GUI. The yaw (and other axes) are rock solid with the GUI.
I think it's pretty clear these sensors can provide really good position information. I'd sure like to figure out how to get similar results with a Propeller.
1) Where did the file we have been testing originate?
2) If it is a port of another file, please show the original.
3) Is it known to work as is without modification anywhere?
Not sure if this is helpful but the Processing code came from the FreeIMU project. I found the full FreeIMU Arduino & Processing project on GITHub. As far as I can tell this is the Fabio Varesano Association's project, maintained in Fabio's passing, by a group of interested developers.
The FreeIMU HW/SW project webpage also has a link to an archive of the above project.
Download archive: http://www.varesano.net/files/FreeIMU-20121122_1126.zip
FreeIMU_serial path from the project archive:
I've had success in using the FreeIMU_cube code with Jazzed's propeller code, but yes getting "quite jumpy results."
I've not had success with the FreeIMU_serial Arduino code on an Arduino Leonardo. Code compiles, I can see that Processing is sending its "v" char from it'd Setup function. The R/X LED on the Leonardo lights up about every second. But Processing does not get a response from the Leonardo. And, yes, I've updated the port to the Arduino's port ID.
Perhaps the FreeIMU_serial Arduino code could be translated to a SimpleIDE project? I'm out of time for the day, but will look into that later.
dgately
I started translating this one .... https://github.com/jrowberg/i2cdevlib
Not even sure how I got there now.
Again thank you for your great help.
Belows are not ported from Fabio Varesano Association, but from MPU6050_DMP6.
MPU6050_DMP6 is ported to mbed and Raspberry Pi.
https://mbed.org/users/syundo0730/code/MPU6050-DMP/
https://github.com/richardghirst/PiBits/tree/master/MPU6050-Pi-Demo
I think I2Cdev is mainly modified in these libraries.
Thanks,
Kaeru no Ojisan
But where did the first post MPU6050_quaternion.c file come from?
http://forums.parallax.com/attachment.php?attachmentid=109170&d=1402972063
My first post MPU6050_quaternion.c file is made by myself just referring to FreeIMU_quaternion.pde(Arduino code) + FreeIMU.cpp in http://www.varesano.net/files/FreeIMU-20121122_1126.zip
Regarding i2c_in and i2c_out code in my first post MPU6050_quaternion.c file, I referred to Andy's code in http://forums.parallax.com/showthread.php/155488-L3G4200D-3-Axis-Gyroscope
Now, that I've been able to run the "proper initialization" the old program I attached is horribly unstable. LOL. Maybe more tomorrow ....