Can i change the interrupt pin?
Closed this issue · 7 comments
Hi,
I've recently purchased a MPU6050 and i started to look for tutorials on how to use. Turns out that there's a lot more involved in this tniy sensor than I originally would have thought. After watching some tutorials, I've landed on this library, wich seems to be one of the best, since it uses DMP. From what i learned, Pin 2 is connected to the Interrupt pin on the sensor, while SDA and SCL are used for I2C. I've tested it on an Arduino Mega, and it worked really well.
My problem:
now I want to use an arduino pro micro, where the SDA pin is Pin 2!
Here's a pic of the pinout:
(https://europe1.discourse-cdn.com/arduino/original/3X/a/1/a189ab6e38490f5a7e4b03312c75241e60bc0857.png)
It's evident that i cannot use it for both I2C and Int, but i cannot find where pin 2 is declared for the interrupt function.
Am I missing something really obvious? Keep in mind that I still consider myself a almost-total beginner, and I do not have the experience nor the knowledge to deal with this issue.
What I'd like to know:
is it possible to change something somehere to get everything to work?
Thanks a lot for your help, I'm looking forward to your response
Hello @Fed-3
I understand the confusion about the INT pin in the MPU6050 module.
In the MPU6050 modules, the INT pin is an interrupt output pin used to signal the host (your board) when an event occurs within the sensor, such as data ready or motion detection. This pin is useful if you need to reduce power consumption or improve the efficiency, so the microcontroller do not have to periodically “read” the status. With this being said, the INT pin is optional.
Now moving to the INT pin definition on the boards. This is not something related to the library itself, but in the hardware you are using. In Arduino boards, the pins functions vary depending on the specific family and board you are suing, this includes communication protocols (I2C, SPI, etc.) and other pin functions such as interruptions. In this case, you must check the board datasheet or pinout looking for the available INT pins and determine if these pins do not interfere with other functions you need.
Hope this information is helpful for you! In case you have any other questions related to the library feel free to share it.
Thank you very much @xpeqex!
I'm not an expert, and from what I originally understood from the tutorials I've watched, the interrupt pin is used to mitigate the error of the sensor, slowly increasing over time, since the angles are calculated using integrals, the over/undershooting of the sensor accumulates over time. After your respone, I understand that I was completly wrong, but i learned something new nontheless.
I fell into this interrupt pin - rabbit hole because I wanted to fix the slowly increasing error, but I've not yet found a solution. I want to use the sensor for long periods of time, like 3-4 hours without recalibration, and even small errors would sooner or later show up. Do you have any idea on how I could approach this problem? No need to write code or long explanations, just point me in the right direction and I'll figure stuff out by myself. I'll really appreciate, no pressure thou. In these days I'm scouting the internet in search of solutions, I'll find something sooner or later.
Thanks again for your response!
Correct, the INT pin is not related to the issue you are facing. In fact what you are describing is a known issue called “gyro drift” or simply drift.
While there is no a direct solution due to the wide variety of sensors out there, there are a few considerations you may want to take:
- Calibration:taking a part of the INTEGRATED value of the Gyroscope, hence you end up building a constant drift. This is why the offsets need to be compensated with your own calibration values. Most of the example includes an autocalibration routine, however, you can obtain your own offsets and define them for a better functionality. You can find more information about the calibration in this post: #76
- Gyro Drift Compensation: you can add your own code to compensate the drift over time.
- Temperature Compensation: Temperature variations can affect sensor accuracy and introduce drift.
Additionally, when using these types of sensors for long term or where precision is critical, it is recommended using external references to recalibrate the sensor.
Thanks for your response @xpeqex!
I got rid of the int pin for now, since I don't need it right now and it was also introducing some kind of "freezing": looking at the Serial Monitor, if I had the Int pin connected, the outputs would stop to come out at some point or another. I didn't investigate into it, since i can just ignore it for now.
I tested the calibration code, and then the mpu6050_DMP6, and it worked flawlessly, apart for the yaw drift (as expected). Looking at the code, I couldn't help but wonder: in line 206-209, why there's no mpu.setXAccelOffset(xOff); mpu.setYAccelOffset(yOff);?
It seemed strange to me and I added these two lines of code, and everything seems to work fine. Is there a reason why I'm not setting the X and Y acceleration offsets?
You mentioned to use external references to recalibrate the sensor in the long term, what are you thinking of? I'll quickly explain to you what I'm trying to archieve: after watching this video about building a space mouse (https://www.youtube.com/watch?v=iHBgNGnTiK4&ab_channel=SalimBenbouziyane), I wanted to get it to the next level, implementing the rotation detection, since right now the sensor he's using only measures translation. You can see why having a consistan "0 position" is critical, and that's what I'm trying to archieve. Do you have any suggestions? I've started to work on this just a few days ago, so I'm still in a very early stage of the development.
As always, thank you very much for your answers and your knowledge!
About why there are no Acceleration offsets for X and Y axis in the example is an omission the original developers made, probably the original developer found that the sensor worked fine without adding these offsets. In any case you can add them without problem. Take in mind that this library is based on the work of https://github.com/jrowberg/i2cdevlib
The MPU6050's internal DMP (Digital Motion Processor) can handle some level of accelerometer bias through its algorithms. In perfect calibration, the accelerometer readings at rest should ideally be around 0g on the X and Y axes and 1g on the Z-axis (assuming Earth's gravity). The DMP might internally compensate for small deviations in X and Y offsets.
A suggestion for external references is adding a magnetometer to your setup can provide an absolute reference for orientation. This allows you to correct the gyroscope drift by using the Earth's magnetic field as a reference point.
There are out some filters that allow you to combine accelerometer, gyroscope, and magnetometer data which could be a great option in your application.
Thanks for your advice @xpeqex!
Unfortunately, I cannot use a magnetometer, since inside the device I'm goint to build there are magnets, but i got some other ideas: since the knob of the space mouse always returns at rest position if it's not touched, I think I could create a "Motion detection algorithm", that detects if the mouse is being used, and if not then it knows that the MPU6050 is in a fixed position, not moving. I think it's a bit rough and not very elegant, but functional nontheless.
Anyway, I'd love to discuss more about this project, but this is not the right place.
Thank you again for your quick responses and your valuable advice, you helped me big time!