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

All Activity

This stream auto-updates     

  1. Last week
  2. daniel09 daniel09 joined the community
  3. 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
  4. Mac9 Mac9 joined the community
  5. Shelly Shelly joined the community
  6. virajshah virajshah joined the community
  7. Earlier
  8. MikeAlejo MikeAlejo joined the community
  9. advince advince joined the community
  10. RakeshS RakeshS joined the community
  11. hudha hudha joined the community
  12. drogus drogus joined the community
  13. 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.
  14.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  15.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  16.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  17.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  18.    Melika Barzegaran reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  19. 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!
  20. 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)
  21.    ifconfig reacted to a post in a topic: MPU-6050 Raw data meaning
  22. 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))
  23. randika started following Need your help for complete this dmpGetTemperature() function in MPU6050_6Axis_MotionApps20
  24. 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 ?
  25. 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.
  26. danmoran
    check this https://github.com/danomora/mpu6050-vhdl
  27. 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
  28. softtoytrev started following Cannot install library using IDE and include jendef.h file not found
  29. 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
  30. 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
  31. 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
  32. fakour.abolfazl fakour.abolfazl changed their profile photo
  33. kapludanger started following Different angle reading from 5 MPU6050
  34. 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 :)
  35. 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?
  36. 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.
  37. HinnaNayab
    Hi Everyone! I am stuck with the task of visualizing 3D orientation estimation of an object in Matlab. The data come from a sensor via serial communication to Matlab. So while the data is updating in real time, I want it to be graphically represented in 3D and update accordingly in the figure too. I am stuck with the task of visualizing 3D orientation estimation of an object in Matlab. The data comes from an IMU via serial communication to Matlab. So while thie data is updating in real time, I want it to be graphically represented in 3D and update accordingly in the figure too. I attempted to do it several times but since I am not an expert in Matlab, I couldn't achieve exactly what I wanted to. (One of the problems was the delay in updating the figure. I used q.plot (Quaternions) Many Thanks
  38. anif zarus
    I need to collect the data of abnormal driving pattern . I have used the mpu6050 sensor(acclerometer and gyroscope) and i have connected the mpu6050 to the raspberry pi and i am able to get raw data when calibrated. Now i need to calculate the driving pattern depending upon the data collected from the speed and movements of the car. Is there any package of python which would denote the driving pattern of the vehicle depending upon the data received. if not, how do i process the collected data.
  39.    zenman reacted to a post in a topic: Understanding raw values of accelerometer and gyrometer
  40.    lolizz00 reacted to a post in a topic: Arduino Sketch to automatically calculate MPU6050 offsets
  41. zenman
    I am occasionally getting an output of: "OTP bank is invalid" (line 310 of MPU6050_6Axis_motionApps.h) when I boot my device (esp32). It doesn't happen all the time, but once it happens simply rebooting the MCU doesn't seem to fix it. For some reason I have physically cut the power to the esp32 then restart it. It seems like something is being set in the mpu6050 itself that doesn't go away until power is cut off. I may be wrong. Has anyone experienced this and have a solution?
  42. zenman
    Aren't the negatives just indicating the direction? Whereas the pythagorean theorem is giving you a magnitude of the force. So if you move up with a force of 5 newtons or down with a force of 5 newtons, it's on the same axis so the magnitude of the force on that axis could be the same, but the direction would be different. Of course, take this all with a grain of salt. I honestly don't remember from trig class, if you have three different axis' is it still square root or should it be cube root?
  43. zenman
    Have you made any progress?
  44. zenman
    I'm working with the esp32 and I get similar FIFO messages, but it doesn't seem to stop it from working. I don't fully grasp how the FIFO buffer works yet, but it seems like the code resets the buffer and just keeps going. I don't seem to notice any problems in the numbers being outputted. Is it causes yours to hang? If you uncomment OUTPUT_READABLE_WORLDACCEL it should cancel out for gravity. I haven't really worked with that output yet, I've mostly been doing yaw/pitch/roll and quanternions.
  45. accelquestion
    To detect vibration I'm sampling the MPU6050 various times and averaging it with previous samples and the algo works very well, it's the following: Force = sqrt((currentX - lastX) * (currentX - lastX) + (currentY - lastY) * (currentY - lastY) + (currentZ - lastZ) * (currentZ - lastZ) ); However, the problem is the result is always a positive number, and since I've been studying accelerometers I've noticed they often give negative values too. So I'd like to be able to get these negative values. In the accelerometers initial state x, y can be negative depending on the axis, and y is never negative. I know x, y & z values can be changed by applying the DMP/quaternions/etc. Do I need to apply something like ypr or euler to get the proper G force? How do I get the full negative & positive values of G? Thank you for your time
  46. morkocberk
    Hello guys! I am new on these works :). I am working on a project and I need to calculate velocity from MPU-6050. Before calculating it I need to substract the gravity acceleration data from the orginal acceleration data. I found I2Cdev library can calculate linear acceleration, however, I couldnt start working the codes whatever I did. The problem is it says Fifo overflow and I didn't change anything on the codes. Can someone please send me the codes which is working completely on Esp-8266? I also wired up following the rules below; 3v3->Vcc Gnd->Gnd D1->Scl D2->Sda Is this true? If its please someone send me the working codes. Thank you very much for your helps...
  47. zenman started following MPU6050 with Arduino Wire length
  48. zenman
    Have you considered a wireless option? Using either web sockets or bluetooth is not overly complicated. You could have your IMU device connected to an esp32 then have it communicate the IMU data wirelessly to a second device (2 meters away)
  49. zenman
    I am experiencing the same thing. I don’t have a simple solution, but I have basically tracled it down to the yaw/pitch/roll algorithm. What I have found is that if you stick purely with quaternions and do not switch to yaw pitch roll, the flipping problem goes away. At least it does in the processing “teapot” simulator. My current issue is that I just don’t understand how to work with quaternions very well. Is anyone here well versed in quaternions?
  1. Load more activity
×