Jump to content
I2Cdevlib Forums
NEW PROJECT ANNOUNCEMENT - PeriLib: I2Cdevlib reborn

All Activity

This stream auto-updates     

  1. Today
  2. ravi ravi joined the community
  3. Last week
  4. hammam hammam joined the community
  5. zxj zxj joined the community
  6. Seungsu Seungsu joined the community
  7. bigcat bigcat joined the community
  8. Earlier
  9. Cipu Eugen Cipu Eugen joined the community
  10. noha_amin noha_amin joined the community
  11. nachiketa3299 nachiketa3299 joined the community
  12. pengGY pengGY joined the community
  13. Yggdrasil.Sun

    Example code MPU6050_DMP6

    Yggdrasil.Sun replied to Mac9's topic in Arduino (ATmega)

    INT of MPU6050 must connect PIN 2 of Arduino
  14. Yggdrasil.Sun

    Arduino mega control 3 MPU6050

    Yggdrasil.Sun posted a topic in Arduino (ATmega)

    Hi everyone My graduation project is the design of robot arm. now I need three ATK-MPU6050 to solve problem of pulse losing of step motor, So I need angle data through DMP. I can run example of MPU6050_DMP to control one ATK-MPU6050, but it can't meet my needs. I need a class of mpu6050 and angle data through DMP. If you know how to control three ATK-MPU6050，I will appreciate you
  15. millerlogan

    Coinmama Support Number

    millerlogan posted a topic in I2C Device Library API

    Coinmama Customer Service instant help by the Coinmama technical team.if you have any error of coinmama contact our Centre.Coinmama Support   Number.if you need contact the team.we are independent service provider for coinmama and remove all issues.
  16. gautam1997
    Hello everyone. Thanks for your explanation jeff. I am building a robot that will drive straight and i intend to use the yaw angle error to make that happen. Right now I am at the yaw angle reading stage. I used the calibration sketch (attached below) and got the offsets. Then i plugged those offsets into DMP6 example of Jeff Rowberg library (thanks to jeff). I was expecting 0 readings for yaw, pitch and roll as i had held it still all the while. But the readings were 49.6(y) 0.6(p) -2.81(r). Can anyone tell me what might be the error? I did notice the comment above the offset setting part of dmp6 saying "supply your own offsets here, scaled to minimum sensitivity." Can the reason be that my sensitivity factor is not correct? // load and configure the DMP Serial.println(F("Initializing DMP...")); devStatus = mpu.dmpInitialize(); // supply your own gyro offsets here, scaled for min sensitivity mpu.setXGyroOffset(220); mpu.setYGyroOffset(76); mpu.setZGyroOffset(-85); mpu.setZAccelOffset(1788); // 1688 factory default for my test chip Can that be the reason? Tahnks in advance. MPU6050_calibration.ino
  17. NoobMaster69
    Problem solved. bus.write_byte_data(0x68, 0x1C, 0x00) 2g bus.write_byte_data(0x68, 0x1C, 0x08) 4g bus.write_byte_data(0x68, 0x1C, 0x10) 8g bus.write_byte_data(0x68, 0x1C, 0x18) 16g
  18. NoobMaster69 started following How to Convert the measurement range of MPU6050?
  19. NoobMaster69
    import smbus import time # Get I2C bus bus = smbus.SMBus(1) # MPU-6000 address, 0x68(104) # Select gyroscope configuration register, 0x1B(27) # 0x18(24) Full scale range = 2000 dps bus.write_byte_data(0x68, 0x1B, 0x18) # MPU-6000 address, 0x68(104) # Select accelerometer configuration register, 0x1C(28) # 0x18(24) Full scale range = +/-16g bus.write_byte_data(0x68, 0x1C, 0x18) # MPU-6000 address, 0x68(104) # Select power management register1, 0x6B(107) # 0x01(01) PLL with xGyro reference bus.write_byte_data(0x68, 0x6B, 0x01) I wish to convert the measurement range from +-16g of the accelerometer to +-2g and 2000dps of the gyroscope to 250dps. Any Gurus can help me on this? This is the register map for MPU 6050 https://www.invensense.com/wp-content/u ... r-Map1.pdf
  20. Tom1235
    Have you been able to work this out? I need a program for school that gives me an interrupt when a person with this sensor attached to his waist falls, and only when it gives an interrupt does it have to read sensor values. I can't however find a solution for this, was hoping you could help.
  21. Rjsamat started following Help needed
  22. Rjsamat started following Jeff Rowberg
  23. Rjsamat

    Help needed

    Rjsamat posted a topic in Other Platforms

    Hi every one is there some can help me in my project. I'm trying to make a DSLR gimble with a 2 servo motors. Gs90 and I have a arduino nano board and a MMA845x accelerometer with a joystick I need motors to stay in position that I stop and seep steddy and joystick to control the roll and the pitch. Please if anyone can give me code for this it will be big help. This gimbal is for my own use not for any youtube or any blog.
  24. Santiago Santiago changed their profile photo
  25. Santiago started following Arduino Sketch to automatically calculate MPU6050 offsets
  26. Santiago
    Dear Susan, renrr3, jrlin and anyone who might be confused about these calculations on the calibration function: I came upon this problem while trying to calibrate the sensor with a +/-16G range. It turns out that these constants rescale the offsets for the selected sensibility, as the values returned by the MPU6050 are in the maximum range. So, for a +/-2G accelerometer range (standard) it's necessary to divide the coefficients by 8 (16G/8 = 2G) and the gyroscope ones by 4 for a standard sensibility of 250dps (1000dps/4 = 250dps). In order to calibrate the sensor properly, I also had to change the constants 16384 by 2048. This is because the chip provides values between -32,768 and 32,767. With a range of 2G, the gravity acceleration is equivalent to the number 16384 (32767/2). If the range is 16G, then 1G is 2048 (32767/16). This explanation was provided by arduarn in the Arduino forum. You can check the original discussion here http://forum.arduino.cc/index.php?topic=535717 Best wishes,
  27. moi lois
    Once powered up is there a way to tap any value from the Gyroscope before it goto the serial bus?
  28. Mac9
    Hi All, I have down loaded all library file to run the above code, It compiles and down loads OK . When I run the sketch it stops with the message " MPU Connection failed" followed by "Send any character to begin the DMP demo". Then nothing. I have checked all wiring(at least 6 times) and the I2C address of the device which is 0x68. Help! Regards John
  29. Jeff Rowberg
    It would be valuable to the community to have the library updated to MotionApps 5.1 (or 6.x?) based on what InvenSense has most recently published, but this is not a small endeavor. I am tied up with my main day job and a few other side projects at the moment, so it will either have to wait or someone else will have to do most of the development for now.
  30.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  31.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  32.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  33.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  34.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  35. ifconfig
    I've been trying to learn the inns and outs of this library, with respect to the MPU6050 recently with the help of the docs, but it seems like they are hopelessly out of date. They were last updated in 2011, and it looks like the library has progressed rapidly from then. Can we get it updated? Thanks!
  36. ifconfig
    Granted, I'm new to this stuff too, but that is how I interpreted it. I think the values spit out in `int16_t` containers are unscaled, requiring the API user to divide by the given resolution, as per the MPU6050 datasheet. (p.13, section 6.2)
  37.    ifconfig reacted to a post in a topic: MPU-6050 Raw data meaning
  38. Brendon
    This might sound like a very silly question, so I apologize if this is something very simple but just cannot get my head around it. I am trying to understand what the data provides in terms of real time information, for example, the MPU-6050:Gyroscope - is a 16 bit data register with a range from (0 <-> 65535)There is a selection of ranges (±250, ±500, ±1000, and ±2000°/sec)If the range is set to ±250°/sec, is the reading 360/65535 = 0.0054 resolution?What does °/sec mean, if the sensor does not move and reads zero and then turned quickly does it mean it will be reading the angle at the set range? For example, if the range was set to ±2000°/sec and it was moved 200° would the read move from 0 to (2/65535 *200) and keep sending this value once the sensor stopped moving?Accelerometer - is a 16 bit data register with a range from (0 <-> 65535)There is a selection of ranges (±2g, ±4g, ±8g and ±16g)If the sensor is not moving, completely flat the reading will be 0?If the sensor is shocked at 2g will the max reading be 65535 (if set of 2g, with a resolution of 2/65535)If the sensor is shocked at 16g will the max reading be 65535 (if set of 16g, with a resolution of 16/65535))
  39. randika started following Need your help for complete this dmpGetTemperature() function in MPU6050_6Axis_MotionApps20
  40. randika
    Dear Jeff, Could you please help to complete the "dmpGetTemperature()" function in MPU6050_6Axis_MotionApps20 ? I unable to find any resource to complete this function. https://github.com/jrowberg/i2cdevlib/blob/900b8f959e9fa5c3126e0301f8a61d45a4ea99cc/Arduino/MPU6050/MPU6050_6Axis_MotionApps20.h#L680 An other thing I need to know in the DMP configuration, Do I need to change some configuration when I consider vertical axes as Y, instead of Z axes ?
  41. Muhammad Saad Jumani
    Hi everyone. I am doing a small project in which I want to collect readings of multiple gyroscopes and transfer them to a nearby computer for further processing. I have been able to connect MP 6050 to Arduino UNO and show the gyroscope readings on the serial monitor. I basically want to do the same thing, but without having to use printer wire (or any other wire) to connect Arduino to computer. What would be the simplest way to do it? can you guys recommend me any good guide or tutorial for that? I have no prior hardware experience except for making a few simple circuits. I am also open to learning/using platforms other than Arduino Uno (maybe NodeMCU, Raspberry Pi, etc) if that would make this any easier.
  42. danmoran
    check this https://github.com/danomora/mpu6050-vhdl
  43. anif zarus
    i am currently using the mpu6050 for a project. Now i need to interface it with odroid xu4. Since the mpu6050 requires 5v and the odroid power supply supplies only 1.8v, can i connect the power supply required by the mpu6050 from external source of 5V and connect the i2c interface and ground to odroid
  44. softtoytrev started following Cannot install library using IDE and include jendef.h file not found
  45. softtoytrev
    There are a heap of on-line sketches that require using your I2Cdevlib and the MPU-6050 libraries, so having installed the I2Cdevlib off the GitHub website, I get the above message when trying to compile to a Arduino Nano that requires the I2Cdevlib and the MPU-6050 libraries. I have removed the I2Cdevlib several times, and restored the libraries to different locations, however I now always get a message that says "include jendef.h file not found or not installed compilation terminated". I originally downloaded the I2Cdeclib in August and used the library with no problems, however I re-downloaded the library recently and find that it is now unusable. Can anyone help me with this issue please? Hutch_s_I2C_Accelerometer.ino
  46. fdc
    I trying to work with mpu6050 sensor with I2C communication in matlab and matlab software recognized the device(mpu=I2Cdev) but when i use readRegister () the result shows zero and i tried with different board the result is the same so how can i solve the problem? thanks
  47. softtoytrev
    Hello, Please accept my apologies if I have posted this request for help wrong, I don't normally need any help. I've been using Arduino for the past 18 months without any problems, but I cannot for the life of me, install the I2Cdev library. The recently installed i2cdevlib-master library is sitting in Dropbox/Arduino/libraries/ along with all of the other libraries that I use on a daily basis. The I2Cdev library has been downloaded from GitHub, but when I go to Sketch > Include Library > Manage Library the i2cdevlib does not appear in the list. I have removed all instances of the library from my laptop, and reloaded them thinking that perhaps the file has been corrupted but it still does not help me. Running the attached file gives this error: Invalid library found in C:\Users\TSedd\Dropbox\Arduino\libraries\i2cdevlib-master: C:\Users\TSedd\Dropbox\Arduino\libraries\i2cdevlib-master Any help with that I am doing wrong would be most appreciated. Hutch_s_I2C_Accelerometer.ino
  48. fakour.abolfazl fakour.abolfazl changed their profile photo
  49. kapludanger started following Different angle reading from 5 MPU6050
  50. kapludanger
    Hi All, I have 5 different MPU6050 on one mechanic. I'm using Jeff's DMP6 code and I am especially interested in pitch and roll values from "OUTPUT_READABLE_YAWPITCHROLL". I already calibrated All 5 MPU with "MPU6050_calibration.ino" All sensors gives me "0 degree" when they placed in horizontal position, with package letters facing up. Also I'm getting "90 degree"(almost) they placed vertical. When i place sensors in forexample 45 degree all of them shows different angles between 43-47, this error follows me in different angles. i have no error on vertical and horizontal planes but there is a non lineer error occurs between 0-90 degree and its not same for all. supply voltage and ambient temperature is same for all and i read sensors from 5 different comport. I suspect for calibration process and try a lot of time to calibrate each other but nothing changed. DMP6 code works perfect, there is no freeze or connection problem but this difference makes me crazy :)
  51. Jeff Rowberg

    PeriLib: I2Cdevlib reborn

    Jeff Rowberg posted a topic in Arduino (ATmega)

    I started the I2Cdevlib project in 2010 as a bit of yak-shaving intended to help with my Keyglove project, which at the time required access to nearly half a dozen I2C peripherals. It was a new protocol to me, but I saw value in creating an extensible device library rather than the independent and somewhat messy per-device implementations I’d seen. My happy little repository has grown to a reasonably well-known project with 4,868 forks as of the time of this post, thanks to the continuing interest of 58 contributors. I have the MPU-6050 IMU from InvenSense (now TDK) to credit for much of this interest, but others had an impact as well. However, I didn’t think ahead enough to set the project on a path that would cope with the level of interest that I2Cdevlib has since seen. I built the low-level interface code specifically on top of the Arduino Wire library, and specifically for register-based sensor devices. This has turned out to be severely limiting in certain cases, and to cause general headaches in many others. --- NOTE: THIS POST IS COPIED FROM THE ORIGINAL ON THE PERILIB DISCOURSE FORUM. THIS COPY IS LOCKED, BUT THE ORIGINAL IS NOT, AND I WELCOME COMMENTS ON IT OVER IN DISCOURSE. --- Shortcomings Laid Bare No doubt many developers who have used the I2Cdevlib code could point out numerous flaws in the project design. I’m here to concur wholeheartedly. Don’t get me wrong–there’s still a lot about the project that I like. But it would be a sad commentary on my evolving skillset if I thought everything I wrote eight years ago was still A-OK. Plus, there have been great improvements to GitHub during that time, and some fantastic new tools on the scene like Travis CI, which wasn’t around at all when I started. Here’s what I want to do better with this time. Fix #1: Repository Structure This is a big one. Although the Arduino IDE’s library manager wasn’t a thing in 2010, my choice to put everything into one repo has made it impossible to take advantage of it today. Actually, the original structure had only Arduino-specific code in it, without top-level folders for specific platforms. I decided to change this early in the project’s life, but instead of creating new repositories as I should have, I just moved stuff around and made the original repo more complicated. Oops. In addition to preventing integration with the almost any popular GitHub-aware IDE library manager available today, this also means every reported issue is in one giant bucket. There’s no logical separation for problems with the Arduino implementation of the MPU-6050 device code and the ESP32 implementation of the core I2Cdev hardware layer code. It’s a mess. This also means that anyone using the repo will necessarily have to pull down a huge amount of code that they will never use. Most people want the core hardware layer code and one or maybe two device libraries, only for the platform they’re using. Too bad! You have to download the entire fileset and move or copy only the pieces you need into your project or library folder. A monolithic structure also means there is no meaningful way to do commit-tagged versioning for official releases. The various sub-projects inside the repo are independent of each other, and it doesn’t make sense to call the entire thing “1.0.5” or whatever. The solution is to use a more flexible structure with a bunch of individual repositories for each logically separate component. For example: Arduino core hardware access layer Arduino MPU-6050 library Arduino ADXL345 library RasPi core hardware access layer RasPi MPU-6050 library RasPi ADXL345 library nRF52 core hardware access layer …and so on. These will also be under a GitHub organization account dedicated to this project, rather than my own personal account. It just makes more sense. Yes, we’ll end up with many more individual repos, but that’s not a problem. In any case, it’s a tiny price to pay for the benefits such a structure allows, including fixes for all of the problems mentioned above: Easy integration into library managers like the Arduino IDE and PlatformIO Per-library automated testing with Travis CI Per-library versioning and release tracking Per-library issue reporting Non-wasteful installation, no more cloning a majority of personally useless stuff Easy future expansion to new platforms simply by adding new repos It will also make it easier for specific contributors to “own” libraries that they commit or happen to be good at and interested in supporting. Trust me when I say nobody is going to fully grasp every aspect of every subproject on every platform in this kind of a repo, unless that’s their full-time job. But someone might be happy to assume responsibility of a library or two that they created and/or use regularly. Fix #2: Hardware Access Layer Code This is another big one. Using the Arduino Wire library (of 2010) as the foundation for everything else has made it practically impossible to add support for multiple I2C peripheral objects, timeouts, and some lower-level I2C functions. It also precludes the use of any other common peripheral protocols like SPI, UART, and 1-Wire, which is something I’ve wanted to do in some fashion for a very long time. For example, the SPI-supporting MPU-6000 sensor allows much faster data speeds than the I2C-only MPU-6050, while using virtually the same protocol. There’s no good reason the same library collection can’t support both. Further, the current architecture provides no easy way to independently choose which I2C implementation (Wire, NBWire, Fastwire, etc.) you want to use. You can switch by commenting or uncommenting certain #define statements in the I2Cdev core header, but this is unwieldy and non-obvious. All of the different implementations are bundled together in the same source files, which only gets worse as new implementations are added. The solution to both of these problems is to build reusable interface objects that are assigned to core and device instances when they are created. For example, on the Arduino Due platform, you could theoretically drive four MPU-6050 devices using the “Wire” and “Wire1” objects and both slave addresses on each set of two IMUs. You need only to be able to pass in the object you want to use. For example, here’s some pseudocode for it how might work for two Wire-based HAL instances powering four MPU-6050 IMUs: HalCore i2c0(&Wire); HalCore i2c1(&Wire1); MPU6050 imu0(&i2c0, 0x68); MPU6050 imu1(&i2c0, 0x69); MPU6050 imu2(&i2c1, 0x68); MPU6050 imu3(&i2c1, 0x69); With the correct class inheritance and abstraction, the top-layer “MPU6050” objects won’t either know or care what the underlying communication layer is. You could swap in NBWire instances for the “HalCore” objects just as easily. This implementation is not really more complicated than the original approach, but it has far more flexibility. Admittedly, supporting this on C-only platforms is not as straightforward due to the lack of classes and inheritance, but it isn’t impossible. Fix #3: Device Definitions The web-based database-driven register map and transaction analyzer are my favorite things about the original project, and they’re still online. The concept is great, but the implementation has turned out to be too inaccessible. Because of this, what could have been the most valuable aspect of this whole project has languished because I never quite managed to expose the creation/modification interface to the people most likely to do great things with it. To solve this problem and some related problems with version control of device definitions, I’ve decided to simply move everything into JSON files inside their own separate repo. Everything that was stored in the database can just as easily exist in this format, and this allows much greater transparency and the opportunity for easy new device contributions. It also provides a simple way for external projects to directly access device data for other purposes, and it makes it possible for Travis CI to automatically build code and documentation whenever a new device is created or an existing one is modified. The device definitions will be the heart of the whole project, responsible for a significant portion of code generation and required before any supporting repos, libraries, or examples can be submitted. As of the time of this post, I’m in the process of creating JSON schema definitions which will be used both for validation and for automatic form generation using the react-jsonschema-form plugin. This mechanism is clean, functional, and as easy as it possibly could be given the requirements. It also remains flexible if the schema gets new elements in the future, which will undoubtedly happen. The schema will be a work-in-progress for a while, but here are the known requirements so far: Unique device identification slugs Unique manufacturer identification slugs IC/module package and pin definitions for reference I2C address details (for I2C devices) Multiple protocol support (I2C, SPI, UART, etc.) Multiple simultaneous protocol variants (e.g. BNO080 IMU supports two different types of UART communication) Byte ordering definition at device level and register level Register-based protocol definitions (e.g. MPU-6050 IMU register map, structure, and multi-byte R/W behavior) Stream-based rigid binary protocol definitions (e.g. BLE112 module BGAPI protocol) Stream-based flexible text protocol definitions (e.g. WT12 module iWRAP protocol) Information about whether external pin signals are supported or required (e.g. interrupt, wake) My goal is to create the schema such that it can be extended to support new features when needed without breaking backwards compatibility. I know from experience that this is hard to do perfectly, but at least we’ve got nearly eight years of “wouldn’t-it-be-nice-if-we-could-only” experience. Fix #4: Hardware Analyzer Integration Here’s an area where a properly built peripheral library can shine, and where I always hoped to take I2Cdevlib. With an open and accessible collection of device and structure/protocol definitions, and a logic analyzer or even a passive sniffer like the Bus Pirate, it should be completely possible to have a simple Python GUI that spits out live, annotated analysis of peripheral transactions. Think Wireshark but for I2C/SPI/UART peripherals. This would not only be phenomenal for library development, but also great for troubleshooting. I’ll one-up myself here: with a cheap ATSAMD21-based MCU (not even Bus Pirate levels of financial expenditure) and a USB CDC interface, and a Chrome browser that supports the WebUSB specification, you could even run such a tool right in the browser. Note that WebUSB is supported in the Android version of Chrome. This means that you could have a powerful and portable protocol sniffer/analyzer with a cheap smartphone and $10 of external hardware running via USB OTG. (Yes, it might be easier to do the legwork with a real mobile app than trying to leverage Chrome, and I’m definitely open to that. There are some nice conveniences with a browser-only implementation though.) Think about this. With a bit of back-end data capture syncing, you could walk your smartphone and OTG analyzer over to a running device, grip RX, TX, and GND pins with spring clip probes, and just leave it there while you walk back to your desk and watch the data come in on the easier-to-work-with desktop version of the capture/analyzer website. I’m already salivating. But wait, there’s more! Reverse-engineering protocols is tedious. Even just translating a published specification from an API reference manual into source code (or JSON data, as the case may be) is mind-numbing work. The good news is that many protocols follow similar structural patterns, because there’s no reason to reinvent the wheel. With some intelligent guesswork, an analyzer tool could present some possible structural foundations to start from, and overlay them on top of a data capture for quick visual review. Start-of-frame bytes? Checksums? Type, length, or sequence bytes in a header? Pick the combination that seems to fit, then tweak the parameters until there are no misalignments. The front end of this would require some fancy programming in React (or similar), which admittedly I’m a bit rusty on, but the concept is not hard to grasp. I can see all of the moving pieces of this project working in my head. I know it’s technically possible. But it is a big project. Who’s with me?
  52. willcox
    Hi Lordarkam, I also had the freezing problem with a MPU6050 wired up to a Arduino UNO. Ran the test example software for the MPU6050 and the auduino would kick the raw gyro values. However as soon as I give the MPU6050 sudden bump, the arduino freezes and locks up. If I tilted the MPU6050. gently the readings would be fine. But any sudden movement or a slight bump will freeze. As per your suggestion in grounding the ADO, the freezing was eliminated and the MPU and Arduino became very stable. I can confirm that your solution works. Thanks very much.
  1. Load more activity
×