Linorobot ROS1: 9250IMU on Teensy 4.1

[Pito Salas]

The 9250 is a magical black box for me so I am a little scared of it :)

I was building a new Linorobot and again I found that my 9250 was not being detected. This time I was well equipped and was able to trouble shoot pretty quickly that the problem was that the code for "test connection" was not looking for the right device id:

/** Verify the I2C connection.
 * Make sure the device is connected and responds as expected.
 * @return True if connection is valid, false otherwise
 */
bool MPU9250::testConnection() {
    uint8_t device_id = getDeviceID();
    if(device_id == 0x38 || device_id == 0x71 || device_id == 0x68 || device_id == 0x39  || device_id == 0x3A)
        return true;
    else
        return false;
}

I modified the above routine to allow for device_id == 0x3A.

But here's the thing. Why did that work? Is it even a valid fix? And then I dug deeper into code like MPU9250.cpp and saw lots of mysterious math there. And googling around I found that there are other versions of MPU9250.cpp floating around. The whole thing makes me nervous. Is that code correct? How does one gain confidence in this setup? Is there a special  MPU9250.cpp for teensy 4.1? 

Where can I find (or is there) an "official good" and up to date copy of that particular "driver"?

[Chris Albertson]

The 9250 connects to an I2C bus.  Many other devices might be connected to the same bus.  Maybe in your case there are none, but there could be.   So those device IDs are possible bus address where you might have a 9350 connected.  I think there might be jumpers in the board to set the address.

As to if the code is correct, hopefully, you pulled it off someone's GitHub repository that is in active development.  That is the whole idea of git, you can look at the change history of the code and see where it comes from.  You should write a tiny test app that just dumps accelerations in x,y,z and rotatiions to the screen. then move the chip with you hand and see that the output is reasonable.  You should do this with any new sensor to make sure you understand his it works.

Finally, unless you want to forever have to treat these chips like “magic boxes” you will need to read the data sheet.   just google “mpu9250 data sheet” and you will find all you need to know.

OK, I just did, https://invensense.tdk.com/wp-content/uploads/2015/02/PS-MPU-9250A-01-v1.1.pdf. What you will see is the chips can do a lot.  It is a complex device

--
You received this message because you are subscribed to the Google Groups "LINOROBOT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linorobot+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linorobot/2192bd8c-0e87-45a2-b400-65c917532ad6n%40googlegroups.com.

[Pito Salas]

Hi Chris and all,

I was being a little tongue in cheek about the magical black box bit. 

It does worry me though that a different device id (which is not in the code) makes the connection appear to work. I just picked that number because when I scanned i2c devices it was one of several that came up.  But there was  nothing indicating that that particular device id belonged to the 9250 so that was just a shot in the dark that seemed to work.

Maybe the i2c protocol allows a device to pick a different number, or maybe there is a particular model/brand/variant of the 9250 board for some reason has a different device id.

But I agree I can do a little “hello world” testing of the sensor (without the whole ROS edifice) to do a sanity check.

Pito

To view this discussion on the web visit https://groups.google.com/d/msgid/linorobot/99172C9D-3497-4E73-9E84-F5D10A022A1E%40gmail.com.

[Chris Albertson]

Most of the tutorial on using i2c devices advise you to scan the bus.   We tend to buy the chip on undocumented Chinese made breakout boards.  I think the board design controls the “high order?” Bits of the address.    If you designed you own PCB you would not have to scan.