Arduino: SerialUSB not declared in scope

[jonathanrjpereira]

MPU9250_Basic:20: error: 'SerialUSB' was not declared in this scope

define SerialPort SerialUSB

                ^

C:\Users\Jonathan\Documents\Arduino\libraries\SparkFun_MPU-9250-DMP_Arduino_Library-master\examples\MPU9250_Basic\MPU9250_Basic.ino:26:3: note: in expansion of macro 'SerialPort'

SerialPort.begin(115200);

^

C:\Users\Jonathan\Documents\Arduino\libraries\SparkFun_MPU-9250-DMP_Arduino_Library-master\examples\MPU9250_Basic\MPU9250_Basic.ino: In function 'void printIMUData()':

MPU9250_Basic:20: error: 'SerialUSB' was not declared in this scope

define SerialPort SerialUSB

                ^

C:\Users\Jonathan\Documents\Arduino\libraries\SparkFun_MPU-9250-DMP_Arduino_Library-master\examples\MPU9250_Basic\MPU9250_Basic.ino:113:3: note: in expansion of macro 'SerialPort'

SerialPort.println("Accel: " + String(accelX) + ", " +

^

exit status 1 'SerialUSB' was not declared in this scope

[Mikowhy95]

Just change SerialUSB to Serial declaration in .ino file. No idea why there is SerialUSB, but Serial works great :)

[iamchrisb]

@Mikowhy95 I'm not sure, but I think this comes from using the "native" serial port of the "arduino zero" as it is advised in this repo to use the zero (I believe the arduino due also has a native serial port).

[Mikowhy95]

@monstah You're probably right, you explained everything. :) Please tell me, can the code compiler for the Mega2560 malfunction? Function from SparkFunMPU9250-DMP.cpp:

float MPU9250_DMP::qToFloat(long number, unsigned char q)
{
    unsigned long mask;
    for (int i=0; i<q; i++)
    {
        mask |= (1<<i);
    }
    return (number >> q) + ((number & mask) / (float) (2<<(q-1)));
}

returns always INF. I think this is due to compiler malfunctions. And function

float MPU9250_DMP::qToFloat(long number, unsigned char q)
{
    return (double)number/0x3FFFFFFF;
}

Work as it should. SparkFunMPU9250-DMP.h says:

// Convert a QN-format number to a float
    float qToFloat(long number, unsigned char q);

[iamchrisb]

@Mikowhy95 hm, unfortunately I am not an expert on that, I am relatively new to the microcontroller world, I think. I didn't use the DMP lib from sparkfun until now, I tried a more updated source code from Kris Winer.

What firstly came to my mind, when I read the term "INF" was a devision with the number 0, so maybe a variable in the equation is just zero? Another suggestion would be a really large long number as long provides 32bit values without a floating point, of course, but translating it into a float may result in an "infinite float" because the value is bigger than the biggest possible float value. I dont know, it may all be bullshit due to its already late where I live. haha :D Sorry I can't be much of a help with this.

[Mikowhy95]

@monstah As you I can only guess. :) That's OK! Thank you for answering!

[iamchrisb]

@Mikowhy95 well, I did some quick research to try to understand what happens.. of course the DMP chip has no floating point unit, so there are no "real" floating point numbers.. they need to be converted into q number formats (as on of the comments in the code says) this may help a little bit, understanding the code: https://en.wikibooks.org/wiki/Floating_Point/Fixed-Point_Numbers

[Mikowhy95]

@monstah Yes, you are right! It means the point is between #30 and #31 bits. Due to representation of quaternions as a float between -1 and 1, the long int data coming from DMP have to be divided... by some constant. This was pretty easy to find it, because this long have its minimum and maximum what is representation of -1 and 1. Dividing long casted to double by its maximum we can receive float between -1 and 1. And this all was obvious. But why the hell algorithm is dividing by zero (return (number >> q) + ((number & mask) / (float) (2<<(q-1))) )?

[imakr]

@Mikowhy95 @monstah Hello ppl, i have been able to run this DMP on Mega board. First to my surprise, i received INF for Quaternions. Then after doing my research, was able to create a local function to convert the DMP's Q30 to float: float q30_to_float(long q30) { return (float) q30 / ((float)(1L << 30)); } This worked fine and i got my Q's printed as expected. After continuous running of this DMP over a period of time, i could see the qz value slowly drifting away(incremented in my case) eventhough the sensor was at the same position. Any idea on how to correct this?

[muhammetakkus]

I have same problem how can i solve it? Did you guys solve it?

[imakr]

can you please be specific about your problem @muhammetakkus ? which one are you asking about

[muhammetakkus]

@imakr I am getting this error 'SerialUSB' was not declared in this scope

[imakr]

@muhammetakkus Edit the line

define SerialPort SerialUSB

to

define SerialPort Serial

in .ino file.

[muhammetakkus]

@imakr this time I get this error 'printIMUData' was not declared in this scope but printUMUData declareded

[imakr]

@muhammetakkus this isn't an expected error. Please check for any typo's in your .ino file.

[muhammetakkus]

@imakr actually i was using platformio with atom but now i tried in arduino ide and it's done. Thanks your help..

[bboyho]

Hi,

Wrong Board Definition

Regarding the original question to this issue [ https://github.com/sparkfun/SparkFun_MPU-9250-DMP_Arduino_Library/issues/9#issue-243218927 ], make sure that you are using the correct board definition => [ https://learn.sparkfun.com/tutorials/9dof-razor-imu-m0-hookup-guide#installing-the-9dof-razor-arduino-core ]. The example code was written for the SAMD21. From your description, it sounds like you are using a different Arduino core. If the microcontroller does not have a native USB (i.e. Arduino Mega 2560), the Arduino IDE will be come confused and not compile.

Drifting Values

In regards to [ https://github.com/sparkfun/SparkFun_MPU-9250-DMP_Arduino_Library/issues/9#issuecomment-371396678 ], I am not sure why the values are drifting at this moment. I'm not expert but one assumption is that there may be some differences in the way the Arduino IDE compiles code for the ATmega2560 and the SAMD21?

Otherwise, it could be due to reading the certain sensor values and the code may require some sort of compensation. While the older 9DOF used different sensors, this section might provide some insight => [ https://github.com/Razor-AHRS/razor-9dof-ahrs/wiki/tutorial#unstable-yaw-aka-heading-aka-azimuth-readings--yaw-drift ].

[santaimpersonator]

@imakr If you are getting the quaternion values from the example firmware, I just updated the file to include the gyro calibration; part of that process was missed.

I am closing this issue since the issue is a board that isn't supported by this library. Please feel free to use our forums to reach out to the SparkFun community to see if someone has adapted this library to work with a different board (or your board).