Linking problem: Arduino-cli on Arduino Nano "Undefined reference to 'MPU6050_Base::MPU6050_Base(unsigned char, void*)'"

[NICKNAME-wengreen]

#include "MPU6050/MPU6050.h"
const int MPU_addr = 0x68;
MPU6050_Base mapu;
int16_t data;  
void setup() {
  Wire.begin();
  Wire.beginTransmission(MPU_addr);
  Wire.write(0x6B);
  Wire.write(0);
  Wire.endTransmission(true);
  
  Serial.begin(9600);
}
void loop() {
  getData();
    Serial.print(" =>");
    Serial.print(data);
    Serial.print("\n");
  
  Serial.println();
  delay(200);
}
void getData() {
  Wire.beginTransmission(MPU_addr);
  Wire.write(0x3b);
  Wire.endTransmission(false);
  Wire.requestFrom(MPU_addr, 2, true);
//  for (byte i = 0; i < 7; i++) {
  data = Wire.read() << 8 | Wire.read();
//   data = 250<<8|196;
//  }
}

Error msg:

arduino-cli compile -b arduino:avr:nano
/tmp/ccYrPKuw.ltrans0.ltrans.o: In function `global constructors keyed to 65535_0_nmpu.ino.cpp.o.1932':
<artificial>:(.text.startup+0x7a): undefined reference to `MPU6050_Base::MPU6050_Base(unsigned char, void*)'
collect2: error: ld returned 1 exit status


Used library Version Path                                                                          
Wire         1.0     /home/brutalizer/.arduino15/packages/arduino/hardware/avr/1.8.5/libraries/Wire

Used platform Version Path                                                           
arduino:avr   1.8.5   /home/brutalizer/.arduino15/packages/arduino/hardware/avr/1.8.5

Error during build: exit status 1
make[1]: *** [Makefile:24: compileAN] Error 1
make[1]: Leaving directory '/home/brutalizer/projects/SpecularVR/MPU-6050/nmpu'
make: *** [Makefile:28: clrcompileAN] Error 2

Can someone,please ,help to solve the issue?

[oscarpnc]

Hi, I've got the same problem. In the meantime have you found a solution?

[SilasPeters]

Same issue here. I moved the relevant folders from the cloned repo into my repo, and included the header files through #include "MPU6050/MPU6050.h". I get the following errors in the MPU6050 example:

/tmp/ccGKejQt.ltrans0.ltrans.o: In function `global constructors keyed to 65535_0_Gesture_Implementation.ino.cpp.o.1931':
<artificial>:(.text.startup+0x7a): undefined reference to `MPU6050_Base::MPU6050_Base(unsigned char, void*)'
/tmp/ccGKejQt.ltrans0.ltrans.o: In function `setup':
/home/silas/Dropbox/Uni/InteractieTechnologie/Practicum2/Gesture_Implementation/Gesture_Implementation.ino:54: undefined reference to `MPU6050_Base::initialize()'
/home/silas/Dropbox/Uni/InteractieTechnologie/Practicum2/Gesture_Implementation/Gesture_Implementation.ino:58: undefined reference to `MPU6050_Base::testConnection()'
/tmp/ccGKejQt.ltrans0.ltrans.o: In function `loop':
/home/silas/Dropbox/Uni/InteractieTechnologie/Practicum2/Gesture_Implementation/Gesture_Implementation.ino:89: undefined reference to `MPU6050_Base::getMotion6(int*, int*, int*, int*, int*, int*)'
collect2: error: ld returned 1 exit status

exit status 1

Compilation error: exit status 1

If I am importing the library incorrectly, than for me the readme wasn't clear enough.

EDIT: I also changed MPU6050/MPU6050.h to include I2Cdev through

#include "../I2Cdev/I2Cdev.h"

Otherwise, it won't compile.

This probably means I am doing something wrong...

[jrowberg]

You should have a folder structure something like this:

• <userdir>/Arduino/Libraries/I2Cdev
• <userdir>/Arduino/Libraries/MUP6050
• <userdir>/Arduino/Projects/SomeProject/SomeProject.ino

Having the project in a Dropbox subfolder instead should be fine, but it might be good to start with the above. The fact that you needed to put a specific relative path (../I2Cdev/I2Cdev.h) suggests the I2Cdev folder, and likely others, isn't in the normal Arduino libraries folder and default include path.

[SilasPeters]

Ahh, that fixed my problem! I lacked the understanding that the current working directory is not per se in the include path. Moving all libraries to ~/Arduino/libraries fixed the required relative import, and as a result I can build everything now. I can't speak for the original problem of this issue, but it seems my cause is solved.

Thus, perhaps the errors in this issue occur because of meddling with the libraries to make them compile.

Thanks @jrowberg !