Getting IMU data
sskorol opened this issue · comments
Hi @borntoleave,
Is it possible to retrieve IMU data from Bittle programmatically? I want to get odometry for SLAM package integration.
Thanks,
Sergey
You can delete the macro for DEVELOPER, and use the code blocks inside to print out the angles. The format is yaw, pitch, roll.
#ifdef FIX_OVERFLOW
for (byte g = 1; g < 3; g++) {
yprLag[lag][g] = ypr[g];
ypr[g] = yprLag[(lag - 1 + HISTORY) % HISTORY][g] ;
}
lag = (lag + 1) % HISTORY;
#endif
#ifdef DEVELOPER
PT(ypr[0]);
PTF("\t");
PT(ypr[1]);
PTF("\t");
PTL(ypr[2]);
#endif
}@borntoleave and what about accelerometer data? Seems like it's not used in the code.
@borntoleave great, thank you!
@borntoleave to provide sufficient info to nav package I need to collect linear acceleration, angular velocity and orientation from IMU. Just want to confirm this info can be collected from Bittle. I see several examples with accel, but not really sure what’s the difference between common accel and world accel? I also see quaternion structure in code. Is it sufficient to determine orientation? Or I need to apply additional formulas against pitch, roll and yaw to compute it? And for angular velocity I guess I can use roll, pitch and yaw, right?
@borntoleave I want to try another IMU (10 DOF). However, i2c port on RPi is occupied by the NyBoard. Can I access NyBoard's i2C from RPi if I solder the sensor's pins to the available slots above the i2c groove socket?
You can connect external sensors to its port.
@borntoleave do you mean RPi port or those i2C port linked with a groove?
RPi port is already occupied with a hat. I just need to access an external i2C sensor via RPi.
Are you saying it's possible only if RPi switch is on?
As long as the I2C switch is not dialed at RPi, the I2C port of RPi is not really connected to the board's I2C network.
The switch can disconnect the I2C network from 328P and connect them to the RPi.
@borntoleave but even if it's not connected to NyBoard's i2c network, the RPi pins would still be occupied if we use Zero or A+ board as a hat. So we can't physically connect sensors directly to Pi's i2c. And if we switch the I2C network from 328P, we won't be able to control servos via OpenCat code anymore, as you have mentioned. So what would be your recommendation in this case? What's the best option of connecting i2c sensor to Pi mounted on top of 328P w/o loosing the main Bittle's functionality?
But SCL and SDA pins are occupied by NyBoard (2x5 socket) when Pi is used as a hat. And 2 extra SCL/SDA pins on Pi are intended to eeprom usage only. They won't work for common use cases. So how can I wire SDA/SCL between Pi (connected to NyBoard) and a sensor then?
SCL and SDA pins are occupied by NyBoard (2x5 socket) when Pi is used as a hat.
Yes. But they are not really connected to anything devices. So you can solder two wires to the back of the pins on the Pi.
@borntoleave well, I did it, but here's a new issue. When I run i2cdetect -y 1, it gives me the following picture:
By default, if I don't connect RPi to NyBoard, I have only a single 0x68 address occupied by my sensor. But when RPi is used as a hat, I see this weird matrix. 0x68 address doesn't work anymore (conflict?). How can I guess which one is mine now w/o brute-forcing each address? I'm also wondering why all those addresses are occupied? Is NyBoard really bind them for something?
Ok, from the above picture I see that 0x68 address is used by MPU6050. So that's a problem. 2 sensors have the same address. Any thoughts on how to resolve this conflict?
Made it work via software i2c bus. Details here: https://forums.raspberrypi.com/viewtopic.php?p=1968858#p1967861
@borntoleave I see you committed accel data printing feature. Have you also tried to output raw gyro data? I played with it a bit based on the provided samples but always got constant values like [0;0;1]. Also, wondering why there are int values and not float like for rpy?
Thanks for the note on I2C.
The IMU code is mostly from i2cdevlib. The raw gyro data is VectorInt16 gy and you may print it out similar to the example code.
The accel data is read from the register and is in integer type. You may divide some factors to get real accelerations in float.
I validated the updated code again on my board. The 'v' token prints the MPU data once and the 'V' token prints the MPU data for every loop. I got the readings changed with my movements.
@borntoleave what lib/tool do you use for plotting real-time data?
Regarding gy example: yes, I used it before, but as I've mentioned, I've been always getting 0, 0, 1 values. So that's weird.
The 2.0 branch has a switch case for printing gyros. token -v and -V