3-axis gyro accelerometer MPU6050 problem

JanJor

Member
Dear Forum, and especially member MEMRAN,

I’ve an MPU6050 (ITG-PMU) that works with an Arduino, even as a compass.
BUT: I’m not an Arduino fan and I only used the Arduino to test the MPU6050. To this end I borrowed the info on the site http://diyhacking.com/arduino-mpu-6050-imu-sensor-tutorial/ and the program made by Jeff Rowberg, referred to on that site. As said, the MPU6050 works well.

In an attempt to use the 6050 with the good old reliable and easy to program Picaxe I found Memran’s Picaxe program for MPU6050 (in a 2013 response to Rocketdoc’s question).
Thus, I’ve connected the 6050 to a Picaxe 28X8 (not connecting the Interrupt line as was done in the Arduino) and downloaded Memran’s program without any changes.

As far as I can see, the program should work OK, even without the interrupt line, but it doesn’t. It responds to a certain extent to changes in the position of the 6050 so in that respect it works, but the results I get are extremely variable, both for the gyro readout as for the accelerometer readout.
I tried to figure out if the right registers are addressed, but according to Invensense’s datasheet MPU-6000 and MPU-6050 Register Map and Descriptions Revision 4.2 (Invensense produces 6050 but I’m not sure that my ITG-MPU was made by them) the addresses are OK.

Is there anyone on the Forum who experimented with the 6050 and got better results than I do?

Thanks in advance,

Ronald
 

westaust55

Moderator
Some links to the data sheet (to save folks here having to search) and the code you used from another forum thread (and/or post your own code as currently used may help folk identify what could be going wrong.

Presume it is a 28X2 (not distant future part 28X8) that you are using.
 

eggdweather

Senior Member
Yes some code would be useful to try and help. Questions:

1. Your code is using the MCU6050 address of 0x68 ?
2. Your code is sending to register 0x6B the value 0 ?
3. Your code is writing to 0x3C a request for 14 values ?
4. Your code reads all 14 values ?
 

JanJor

Member
Westaust55 and Eggdweather, you’re right, I should have given the info below.
Main problem; even after a few minutes of total lack of motion, the 6050 keeps giving highly variable values for all variables.
This does not happen when I connect the 6050 to an Arduino; it then works flawless. So there must be something wrong in the program, but I can’t see what/why.
Thanks,
Ronald


http://pdf1.alldatasheet.com/datasheet-pdf/view/517744/ETC1/MPU-6050.html for the datasheet
https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-Register-Map1.pdf for the overview of registers

And here’s MEMRAN’s program that I used:

Code:
#picaxe 08m2
#com 3
#no_data

Symbol xa = w0
Symbol xa.lsb = b0
Symbol xa.msb = b1

Symbol ya = w1
Symbol ya.lsb = b2
Symbol ya.msb = b3

Symbol za = w2
Symbol za.lsb = b4
Symbol za.msb = b5

Symbol xg = w3
Symbol xg.lsb = b6
Symbol xg.msb = b7

Symbol yg = w4
Symbol yg.lsb = b8
Symbol yg.msb = b9

Symbol zg = w5
Symbol zg.lsb = b10
Symbol zg.msb = b11

Symbol temp = w6
Symbol temp.lsb = b12
Symbol temp.msb = b13

'Datasheet says address is $68 (01101000) however this is 7 bit
'format, so we must shift left to $D0 (11010000)
'hi2csetup i2cmaster, $68, i2cfast, i2cbyte
hi2csetup i2cmaster, $D0, i2cfast, i2cbyte
pause 1000

init:
	'set clock source
	'register 107 0x6B
	'reset / sleep / cycle / NA / temperature disable / [2,1,0] clock source
	'hi2cout $6B, (%00000000)'internal 8MHz
	hi2cout $6B, (%00000001)'clk source from X gyro
	'hi2cout $6B, (%00000010)'clk source from Y gyro
	'hi2cout $6B, (%00000011)'clk source from Z gyro
	'hi2cout $6B, (%00000100)'external 32.768kHz
	'hi2cout $6B, (%00000101)'external 19.2MHz
	pause 100
	
	'gyro full scale
	'register 27 0x1B
	'x-test / y-test / z-test / [5,4] full scale / NA / NA / NA
	hi2cout $1B, (%00000000)'+250 degrees/s
	'hi2cout $1B, (%00001000)'+500 degrees/s
	'hi2cout $1B, (%00010000)'+1000 degrees/s
	'hi2cout $1B, (%00011000)'+2000 degrees/s
	pause 100
	
	'accel full scale
	'register 28 0x1C
	'x-test / y-test / z-test / [5,4] full scale / NA / NA / NA
	hi2cout $1B, (%00000000)'+2g
	'hi2cout $1B, (%00001000)'+4g
	'hi2cout $1B, (%00010000)'+8g
	'hi2cout $1B, (%00011000)'+16g
	pause 100
	
main:
	'0x3B is accel X first register
	hi2cin $3B, (xa.msb, xa.lsb, ya.msb, ya.lsb, za.msb, za.lsb) 
	'0x41 is temperature first
	hi2cin $41, (temp.msb, temp.lsb)
	'0x3B is gyro X first register
	hi2cin $43, (xg.msb, xg.lsb, yg.msb, yg.lsb, zg.msb, zg.lsb)
	pause 100
	debug
	goto main
 
Last edited by a moderator:

eggdweather

Senior Member
That's easier to understand now, first cursory look tells me your device addresses are incorrect, they need shifting left by 1 bit. Also try the slow bus speed.
 
Last edited:

westaust55

Moderator
From section 9.2 of the datasheet:
The slave address of the MPU-60X0 is b110100X which is 7 bits long.
The LSB bit of the 7 bit address is determined by the logic level on pin AD0.
This allows two MPU-60X0s to be connected to the same I2C bus.
When used in this configuration, the address of the one of the devices should be b1101000 (pin AD0 is logic low) and the address of the other should be b1101001 (pin AD0 is logic high).
The full 8-bit i2c slave address is b7, b6, . . . . b1, R/W
Thus for the PICAXE (and any other micro-controller) the full 8-bit slave address is %110100x R/W.
For the PICAXE the R/W is always set as 0 within the users program commands and the firmware looks after set it to 0 or 1 depending on the command at the time (ie whether using Hi2cIn or Hi2cOut).

Therefore the $D0 in the Hi2cSetup command is correct as long as the pin AD0 is pulled low.

I presume the code has originated from post 24 by MemRan here:http://www.picaxeforum.co.uk/showthread.php?23851-Has-anyone-used-the-MPU-5060-3-axis-Gyro-I-need-help-setting-up-coding-for-it/page3&highlight=MPU6050
Rocketdoc indicates his (or hers) was working well at post 25 using MemRan's code.
 
Last edited:

eggdweather

Senior Member
Yes, but when reading from the device, doesn't the register addresses need converting with a shift left, for example does $3C need to be $78? to correctly read from that register address.
 

JanJor

Member
Dear Westaust55 and Eggdweather,
I believe that the addresses are correct, I get readings.
I already tested the i2cslow option but that does not improve the variability of the readings.
The VCC is the VCC of the stabilised 28X2 shield and the MPU is connected to the 3,3 V of the shield.
An additional small capacitor over the MPU-6050 VCC and ground also did not help.

I've now divided the readings by 100, and (of course) that improves things quite significantly. I think that the 16 bits A-D-convertors in the MPU-6050 may cause the problem; they may be too sensitive.

I think that I leave it as it is for the moment, unless someone has an idea about how to get a more stable reading using the Picaxe.
As I said earlier, in combination with the Arduino, the results are really surprisingly good and stable, but as also said before, Arduino is not my thing (much too complicated programming and "black box" libraries) so I'll stick to the Picaxe.

All; thanks for your help so far, and if someone manages to use the Picaxe in combination with the 6050 to e.g. build a robot that can balance on two wheels (as far as I can see, all two-wheel robots on youtube are Arduino-driven), I'd very much like to know how he/she did it.

Thanks,

Ronald
 

westaust55

Moderator
Yes, but when reading from the device, doesn't the register addresses need converting with a shift left, for example does $3C need to be $78? to correctly read from that register address.
No, for the internal registers the value given in the data sheet is used directly.
No shift left as there is no R/W bit in the bit0 position.
 

eggdweather

Senior Member
OK, thanks, got it now.
JanJor - which Arduino library were you using, it could be the library is reducing the resolution as you have done, or it could be applying smoothing. It would be interesting to look at the library to see what their doing after the raw device read.
 

hippy

Technical Support
Staff member
Could it also be that using the interrupt is somehow ensuring synchronised or more stable data where the free-running PICAXE code does not ?

When an input is changing by one bit, say fluctuating between $01FF (511) and $0200 (512), an update which happens mid-way between the MSB and LSB being read could return $0100 (256) or $02FF (767) which would appear to be far bigger jumps than they really were.

I don't know if that or something similar is happening but the boundary error would reduce as the value were divided down, would disappear with a divide by 256.

Perhaps you could give an indication of what readings you are getting with the Arduino and PICAXE so people can assess where the issue may lie.
 

tarzan

Senior Member
I think that I leave it as it is for the moment, unless someone has an idea about how to get a more stable reading using the Picaxe.
As I said earlier, in combination with the Arduino, the results are really surprisingly good and stable, but as also said before, Arduino is not my thing (much too complicated programming and "black box" libraries) so I'll stick to the Picaxe.

All; thanks for your help so far, and if someone manages to use the Picaxe in combination with the 6050 to e.g. build a robot that can balance on two wheels (as far as I can see, all two-wheel robots on youtube are Arduino-driven), I'd very much like to know how he/she did it.
I haven’t used the 6050 with Picaxe but have used the BNO055 sensor with a “black box” library from Adafruit.
When I was looking for a sensor for my balancing robot I said to myself that the Picaxe is really going to struggle with the maths involved to make a robot balance, this sensor has an in chip processor doing all that for you. It maybe the pathway to a Picaxe balancing robot.
 
Top