Support for MPU6050
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
why not MPU-6050 plus BMA180? if the problem is that the MPU-6050 "is not software ready", then you can use it as a gyroscope only and then use BMA180. It's supposed to be completely compatible with the old ITG sensor anyways. When the DMP is ready, a simple firmware change will be required to use it.
Re: Support for MPU6050
jphelirc wrote:It's great to see how MultiWii has evolved so time to give something to it again
Reason why ArduCopter project has not published anything new on DMP stuff is that there are some legal issues from manufacturer that people are trying to solve. In meanwhile project cannot use their digital blob so no DMP officially. Hopefully that will change soon.
Anyways, few my friends have asked from me MultiWii compatible board with all included. So we are working on one now. My question goes do you all want to see MPU-6050 on it or BMA180/ITG3205.
Plans for board are:
- ATmega2560
- ATMega8u2
- Onboard Switching regulator 5V/2A and 3.3v
- MSS5611 pressure sensor (thanks to fabio and roberto)
- HMC5883 compass
- Gyro/Acc packet (either ITG3205/BMA180 or MPU-6050)
- Expansion ports
- Info leds
and other usual stuff.
Why At2560, well it's fully supported but Arduino IDE and it's easily available. STM would be nice too but toolchains are not good for that yet and especially if thinking common users. Arduino is moving towards to ARM platform but who knows when and how. On many projects like MultiWii, AeroQuad, ArduCopter it's been proven that ATMega chips are well enough for doing things especially if software it well written.
Let me know what you all think and would it be reasonable to do it.
--jp
unless it's going to be given away for free you're wasting your time with obsolete 8bit garbage.
it has already been proven anyone can throw a bunch of cheap sensors on a pcb and declare victory.
I suggest focusing on actually writing that "well written" software, as none of the choices mentioned above (except multiwiI) come even close to being "well written". But then again, it's more of platform limitation than software's fault.
Using the "its easy for morons" excuse doesn't work either - nobody will write code for you for free, no matter how much hardware you give away. But if someone is somewhat interested but has to deal with 8bit trash like counting CPU cycles to make sure servo PWM output doesn't jitter, they lose interest quick. So this failmega2560 design is destined to run same old crap, provide zero innovation, and doesn't solve any current problems. Why bother?
I'd be curious to hear what reasoning you could possibly have for having 'yet another worthless 8bit pcba' thrown out there in Q2 2012?
p.s. accel in MPU6k works fine, why would anyone need another accel outside?
Re: Support for MPU6050
Hi,
i saw the MPU-6150 (http://www.lipoly.de/modellbau/elektron ... -6100A.pdf) someone knows the difference to 6050?
regards
felix
i saw the MPU-6150 (http://www.lipoly.de/modellbau/elektron ... -6100A.pdf) someone knows the difference to 6050?
regards
felix
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
comparing the datasheets, the noise performance of the two are different
61x0 says 0.2 deg/s-RMS
60x0 says 0.05 deg/s-RMS
low frequency noise and spectral density are not given for 61x0 but are given for 60x0
61x0 says 0.2 deg/s-RMS
60x0 says 0.05 deg/s-RMS
low frequency noise and spectral density are not given for 61x0 but are given for 60x0
Re: Support for MPU6050
so the 60x0 is better then 61x0?
i dont know much about sensors and how the MWC reads it .. but as far as i know mwc filters the sensor data.. do you think there will be a noticable difference?
i ask because the 61x0 is cheaper then the 60x0
regards felix
i dont know much about sensors and how the MWC reads it .. but as far as i know mwc filters the sensor data.. do you think there will be a noticable difference?
i ask because the 61x0 is cheaper then the 60x0
regards felix
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
sorry i can't comment on whether or not there will be any noticeable differences
back on the progress on the DMP...
http://www.youtube.com/watch?v=YbdN_C0oreI
back on the progress on the DMP...
http://www.youtube.com/watch?v=YbdN_C0oreI
Re: Support for MPU6050
looking good.
When will you integrate your code into current MWii code base?
When will you integrate your code into current MWii code base?
Re: Support for MPU6050
Indeed, looks nice.
How does dmp (quaternions? I assume) handle angles near 90/180/etc degrees? Do you have a video where you rotate the model fully 360" around one axis (pitch/roll)
Hmm.
Got the code moved to my system.
Should this (theoretically) work with MPU6000 on i2c?
Or would setup be different?
I'm not getting any useful data in fifo (none actually, blah).
How does dmp (quaternions? I assume) handle angles near 90/180/etc degrees? Do you have a video where you rotate the model fully 360" around one axis (pitch/roll)
Hmm.
Got the code moved to my system.
Should this (theoretically) work with MPU6000 on i2c?
Or would setup be different?
I'm not getting any useful data in fifo (none actually, blah).
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
dongs wrote:Indeed, looks nice.
How does dmp (quaternions? I assume) handle angles near 90/180/etc degrees? Do you have a video where you rotate the model fully 360" around one axis (pitch/roll).
It doesn't on the pitch axis, it won't be accurate beyond 60 degrees right now, only because of my own arcsin approximation
this is already using I2C, without using the interrupt pin. I'm not sure what you are asking
it really helps to double check your initialization. check that you are getting ACK when you are supposed to so you know it's at least replying, make sure the I2C does not become disabled
edit: I don't understand too much about quaternions to provide a better answer, I'm sure the raw data itself is very accurate
Re: Support for MPU6050
What I meant is i don't have any MPU6050 chips, so I'm using MPU6000 (SPI version) connected as I2C. It does respond, upload data, etc, I can read raw gyro values from it after doing all the DMP initialization, but I can't get any useful data in fifo.
So I thought if initial setup between 6k and 6050 would be different as in register contents and stuff.
So I thought if initial setup between 6k and 6050 would be different as in register contents and stuff.
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
The FIFO structure is already well defined. Are you getting "FIFO is ready"? Is the FIFO all zeros? Does the FIFO not match what you expect? Does it seem random? Noisy? Double check your endianness?
The registers are mostly the same, I think there are some differences in the internal DMP memory (not the same as registers) between silicon revisions according to the "Motion Processing" code that InvenSense provided. I don't even know how to tell which silicon revision I have but I think you can guess based on the date of manufacturing, I'm pretty sure I'm using the latest.
By the way, the roll axis uses arctan, it goes between -180 and 180 degrees just fine. My pitch axis will only go between -60 and 60 due to the arcsine approximation error.
The registers are mostly the same, I think there are some differences in the internal DMP memory (not the same as registers) between silicon revisions according to the "Motion Processing" code that InvenSense provided. I don't even know how to tell which silicon revision I have but I think you can guess based on the date of manufacturing, I'm pretty sure I'm using the latest.
By the way, the roll axis uses arctan, it goes between -180 and 180 degrees just fine. My pitch axis will only go between -60 and 60 due to the arcsine approximation error.
Re: Support for MPU6050
No, I'm not getting fifo data at all (actually one read gets fifo level of like 4, then nothing else after).
I'll look over it again, initialization is fine, they're all standard i2c buffer writes as you can see here
http://code.google.com/p/afrodevices/so ... _mpu6050.c
(under #ifdef MPU6050_DMP)
Unless I messed up pointers to 3d array when I got rid of dumb for loops, I'll look over it again but I think its fine.
I'll look over it again, initialization is fine, they're all standard i2c buffer writes as you can see here
http://code.google.com/p/afrodevices/so ... _mpu6050.c
(under #ifdef MPU6050_DMP)
Unless I messed up pointers to 3d array when I got rid of dumb for loops, I'll look over it again but I think its fine.
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
hmm... personally I would hook the I2C bus to an analyser right now and log the traffic for a second.
Re: Support for MPU6050
Yea, that was my next plan. I'm so lazy...
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
Hi,
i have a question for MPU6050 user's.
do you think this IMU on freeIMU 0.4v is better than an allinone board like sirius from multiwiicopter.com ?
cause i'm going to buy a new IMU for my quad, and have no idea how to compare this both.
thx in advance.
i have a question for MPU6050 user's.
do you think this IMU on freeIMU 0.4v is better than an allinone board like sirius from multiwiicopter.com ?
cause i'm going to buy a new IMU for my quad, and have no idea how to compare this both.
thx in advance.
-
- Posts: 31
- Joined: Wed Nov 02, 2011 8:58 pm
Re: Support for MPU6050
Hi didlawowo69,
I test ITG3200+bma180 and MPU6050, in my case, I find that itg3200 is less sensitive to vibration so I had better results with itg
Would require other users MPU say what they think
Matt.
I test ITG3200+bma180 and MPU6050, in my case, I find that itg3200 is less sensitive to vibration so I had better results with itg
Would require other users MPU say what they think
Matt.
-
- Posts: 31
- Joined: Wed Nov 02, 2011 8:58 pm
Re: Support for MPU6050
i have found someone like me who think that the LPF with MPU has no effect
Here http://www.rcgroups.com/forums/showpost.php?p=20902329&postcount=2859
someone else has the same problem?
Matt.
Here http://www.rcgroups.com/forums/showpost.php?p=20902329&postcount=2859
someone else has the same problem?
Matt.
Re: Support for MPU6050
No man, it works fine for me. But I don't use DJI frames.
-
- Posts: 31
- Joined: Wed Nov 02, 2011 8:58 pm
Re: Support for MPU6050
which lpf do you use dongs ?
Re: Support for MPU6050
none, (default) of 256hz
-
- Posts: 31
- Joined: Wed Nov 02, 2011 8:58 pm
Re: Support for MPU6050
If you don't use it how you can know if LPF is working or not for you ?
Re: Support for MPU6050
OK, I poked around with DMP code again.
dmpFifoReady() always reads 0x04, 0x00 -> fifo of 1024.
So.. It's always full?...
edit: Got it.
I had a 20ms delay after init, which would immediately saturate the fifo.
since the code never reset it again, it would just stay full.
Now im getting data in dmp_received_packet, time to play with it.
edit2: i'm getting quat data at like ~20Hz.
Is that the best this thing can do?
edit3: all working. still at 20Hz though.
I'm turning on a led each time a successful entry into dmploop w/available data and turning it off on exit.
this takes 1.5ms on STM32/72MHz (read data + calculate), then the rest is blank of ~55ms until next cycle.
dmpFifoReady() always reads 0x04, 0x00 -> fifo of 1024.
So.. It's always full?...
edit: Got it.
I had a 20ms delay after init, which would immediately saturate the fifo.
since the code never reset it again, it would just stay full.
Now im getting data in dmp_received_packet, time to play with it.
edit2: i'm getting quat data at like ~20Hz.
Is that the best this thing can do?
edit3: all working. still at 20Hz though.
I'm turning on a led each time a successful entry into dmploop w/available data and turning it off on exit.
this takes 1.5ms on STM32/72MHz (read data + calculate), then the rest is blank of ~55ms until next cycle.
-
- Posts: 26
- Joined: Mon Jul 11, 2011 12:47 pm
Re: Support for MPU6050
one of the settings determine the FIFO output rate, look around for "inv_set_fifo_rate" in the code comments and the settings are given in the documentation for "Embedded MotionApps Platform Functional Specification"
Re: Support for MPU6050
Cool, thanks
it's running at 200Hz now.
it's running at 200Hz now.
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
any news from MPU6050 support,
could you tell me if that works correctly, because my quad don't work fine :/
could you tell me if that works correctly, because my quad don't work fine :/
Re: Support for MPU6050
working good.. you may wanna try setting some DLPF. Some frames needs it to avoid some kind of resonance problems.
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
could you explain how to setup DLPF ?
Re: Support for MPU6050
didlawowo69 wrote:could you explain how to setup DLPF ?
There are some MPU-6050 LPF defines for the gyro in config.h perhaps that what he means?
Specifically:
//#define MPU6050_LPF_256HZ // This is the default setting, no need to uncomment, just for reference
//#define MPU6050_LPF_188HZ
//#define MPU6050_LPF_98HZ
//#define MPU6050_LPF_42HZ
//#define MPU6050_LPF_20HZ
//#define MPU6050_LPF_10HZ // Use this only in extreme cases, rather change motors and/or props
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
thx for this answer
could you tell me whiche config.h do you use for MPU > I2C address
could you tell me whiche config.h do you use for MPU > I2C address
Re: Support for MPU6050
didlawowo69 wrote:could you tell me whiche config.h do you use for MPU > I2C address
Please clearify your question.
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
could you write on the forum your config for MPU
it's seems the I2C address in the multiwii code is not correct.
it's seems the I2C address in the multiwii code is not correct.
Re: Support for MPU6050
Hi Guys,
I remember that there were some discussion about the incorrect acc scaling. It seems that finally it turned out that some revisions of the chip has half the sensitivity that described in the datasheet. Here is a small code to check chip revision and set the acc scaling factor correctly.
I remember that there were some discussion about the incorrect acc scaling. It seems that finally it turned out that some revisions of the chip has half the sensitivity that described in the datasheet. Here is a small code to check chip revision and set the acc scaling factor correctly.
Code: Select all
void ACC_init () {
#define MPU6000ES_REV_C4 0x14
#define MPU6000ES_REV_C5 0x15
#define MPU6000ES_REV_D6 0x16
#define MPU6000ES_REV_D7 0x17
#define MPU6000ES_REV_D8 0x18
#define MPU6000_REV_C4 0x54
#define MPU6000_REV_C5 0x55
#define MPU6000_REV_D6 0x56
#define MPU6000_REV_D7 0x57
#define MPU6000_REV_D8 0x58
#define MPU6000_REV_D9 0x59
#define MPUREG_PRODUCT_ID 0x0C // Product ID Register
#define MPUREG_ACCEL_CONFIG 0x1C
uint8_t _product_id = i2c_readReg(MPU6050_ADDRESS,MPUREG_PRODUCT_ID); // read the product ID rev c has 1/2 the sensitivity of rev d
if ((_product_id == MPU6000ES_REV_C4) || (_product_id == MPU6000ES_REV_C5) ||
(_product_id == MPU6000_REV_C4) || (_product_id == MPU6000_REV_C5)){
// Accel scale 8g (4096 LSB/g)
// Rev C has different scaling than rev D
i2c_writeReg(MPU6050_ADDRESS,MPUREG_ACCEL_CONFIG,1<<3);
} else {
// Accel scale 8g (4096 LSB/g)
i2c_writeReg(MPU6050_ADDRESS,MPUREG_ACCEL_CONFIG,2<<3);
}
acc_1G = 512;
Re: Support for MPU6050
if you look very closely at the mpu6050 chip if it has the initial ES at the end then it's an engineering sample with the different acc scaling.
Re: Support for MPU6050
Katch wrote:if you look very closely at the mpu6050 chip if it has the initial ES at the end then it's an engineering sample with the different acc scaling.
It's not an ES issue, but a difference between revC and revD
Re: Support for MPU6050
Looks like that code was lifted from diyclones code, and i don't think it covers MPU6050... at least in product IDs...
Like mine are product_id 0x28... Any way to find a list of all the stuff properly?
Like mine are product_id 0x28... Any way to find a list of all the stuff properly?
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
how to identify which version of MPU i have ?
Re: Support for MPU6050
didlawowo69 wrote:how to identify which version of MPU i have ?
Load the program, breakpoint on i2cread of product ID, then examine the variable? oh.. never mind I forgot this is obsolete 8bit hardware.
Maybe Serial.Print() it or something.
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: Support for MPU6050
on my MPU it's write MPU6150ES.
what can i do whit that ?
what can i do whit that ?
Re: Support for MPU6050
I just got my mpu6050 from flyduino.net. I using MultiWii 20120522. I noticed that the gyro x and y is mixed up, the acc x and y are fine. This is with the stock ACC_ORIENTATION and GYRO_ORIENTATION.
It seems that I can change these and would be able to fly. But is feels strange that they are mixed even tough the are on the same chip. Any idea ?
It seems that I can change these and would be able to fly. But is feels strange that they are mixed even tough the are on the same chip. Any idea ?
Re: Support for MPU6050
Never mind, I just learned that this is known and already changed in 20120622 if you select the FLYDUINO board. Thanks
Re: Support for MPU6050
Hi,
has anybody tried to run the dmp code for this IMU on an Arduino Pro Mini (328P) yet? If so, did you switch to constant time intervals or just poll the fifo fast enough? Is it faster/more accurate than the default MultiWii code? Faster = one still needs to convert the quaternions into euler angles for the rest of the code to work, right? Or has somebody invented algorithms which stay in "magic quaternion land" all the time?
has anybody tried to run the dmp code for this IMU on an Arduino Pro Mini (328P) yet? If so, did you switch to constant time intervals or just poll the fifo fast enough? Is it faster/more accurate than the default MultiWii code? Faster = one still needs to convert the quaternions into euler angles for the rest of the code to work, right? Or has somebody invented algorithms which stay in "magic quaternion land" all the time?
Re: Support for MPU6050
What about this news?
http://www.diydrones.com/profiles/blogs/invensense-releases-licence-to-allow-use-of-the-mpu-6000-dmp-proc
Invensense releases licence to allow use of the MPU-6000 DMP processor
Can we use DMP in multiwii?
http://www.diydrones.com/profiles/blogs/invensense-releases-licence-to-allow-use-of-the-mpu-6000-dmp-proc
Invensense releases licence to allow use of the MPU-6000 DMP processor
Can we use DMP in multiwii?
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Support for MPU6050
This is good news, the DMP should be able to handle some angular calculations I am told.
Re: Support for MPU6050
Most of the documentation is still missing ... but it's a start
Re: Support for MPU6050
I tried to measure the angle of accel. I configured AFS_SEL=2 (Full scale =+/-8G )
Then, I changed the value to the real angle
But, the result is a huge difference compared with the true angle. I don't know where the mistakes. Plz help me !!! Thanks so much !
Code: Select all
signed int ACCEL_XOUT_L = 0;
signed int ACCEL_XOUT_H = 0;
signed int ACCEL_YOUT_L = 0;
signed int ACCEL_YOUT_H = 0;
signed int ACCEL_ZOUT_L = 0;
signed int ACCEL_ZOUT_H = 0;
ACCEL_XOUT = ((ACCEL_XOUT_H<<8)|ACCEL_XOUT_L);
ACCEL_YOUT = ((ACCEL_YOUT_H<<8)|ACCEL_YOUT_L);
ACCEL_ZOUT = ((ACCEL_ZOUT_H<<8)|ACCEL_ZOUT_L);
ACCEL_X = (float)ACCEL_XOUT/4096;
ACCEL_Y = (float)ACCEL_YOUT/4096;
ACCEL_Z = (float)ACCEL_ZOUT/4096;
Then, I changed the value to the real angle
Code: Select all
R=sqrt(pow(ACCEL_X,2)+pow(ACCEL_Y,2)+pow(ACCEL_Z,2));
ACCEL_XANGLE= 57.295*acos(ACCEL_X/R);
ACCEL_YANGLE= 57.295*acos(ACCEL_Y/R);
But, the result is a huge difference compared with the true angle. I don't know where the mistakes. Plz help me !!! Thanks so much !
Re: Support for MPU6050
Angles are usually calculated using atan2:
For small angles this also works (MultiWii does it as an optimization???):
Code: Select all
ACCEL_XANGLE = 57.295 * atan2(ACCEL_X, sqrt(ACCEL_Y*ACCEL_Y + ACCEL_Z*ACCEL_Z));
ACCEL_YANGLE = 57.295 * atan2(ACCEL_Y, sqrt(ACCEL_X*ACCEL_X + ACCEL_Z*ACCEL_Z));
For small angles this also works (MultiWii does it as an optimization???):
Code: Select all
ACCEL_XANGLE = 57.295 * atan2(ACCEL_X, ACCEL_Z);
ACCEL_YANGLE = 57.295 * atan2(ACCEL_Y, ACCEL_Z);
Re: Support for MPU6050
I am trying to get my new quad all tuned and as soon as I hooked it all I can't get a signal from my roll stick. Any ideas how to troubleshoot this
I was flying this board with the same transmitter no problem, just got a new receiver.
http://www.youtube.com/edit?video_id=6AjiWInQ_mc&ns=1[
thanks!!
I was flying this board with the same transmitter no problem, just got a new receiver.
http://www.youtube.com/edit?video_id=6AjiWInQ_mc&ns=1[
thanks!!