eupn/bno055

Device-agnostic Bosch Sensortec BNO055 9-axis Sensor Fusion IMU driver

🕊 NO WAR 🕊

Hi there 👋

• 🦀 Rust
• Embedded Rust
• Cryptography
• Bitcoin

bno055's Issues

Example code building full example using delay

Hello,

I'm working on getting an example of this up and running, and am a little confused about actually setting up the device using the embedded_hal traits, especially because it doesn't seem to be explicitly included in the Cargo.toml dependency list.

Right now my example code looks like

use bno055::Bno055;
use linux_embedded_hal::{Delay, I2cdev};
use embedded_hal::blocking::delay::DelayMs;
use mint::Quaternion;

use std::error::Error;
use std::time::Duration;

fn main() {
    let mut dev = I2cdev::new("/dev/i2c-0").unwrap();
    let mut delay: dyn DelayMs = DelayMs {100u16};
    //    let mut delay = Delay {};
    let mut imu = bno055::Bno055::new(dev).with_alternative_address();
    imu.init(&mut delay).expect("Error initializing the IMU");
    imu.set_mode(bno055::BNO055OperationMode::NDOF, &mut delay)
        .expect("Error setting the IMU mode");

    loop {
        let quat: mint::Quaternion<f32> = imu.quaternion().expect("Error getting the IMU quaternion");
        println!("Quaternion: {:?}", quat);
    }

}

but am getting error relating to using the Delay. If I just use let mut delay = Delay {}; it compiles, but then immediately panics with

thread 'main' panicked at 'Error initializing the IMU: I2c(Io(Os { code: 6, kind: Other, message: "No such device or address" }))', src/main.rs:14:26

I'm pretty sure that my BNO055 is properly connected to the single-board computer (I'm using $ sudo i2cdump 0 0x28 which seems to show that I do have bytes being read in from a device at that address), so my next debugging step is checking that the delay struct I'm passing to init() is properly constructed, but am a little confused about what that should look like. I see in the docs that it looks like it should be a dyn DelayMs<u16> but am not totally sure how to go about building that. Any advice would be really appreciated!

std support

Hello,

First of all, thank you for this crate. It's very useful for quickly getting started with the BNO055!

I use it on an embedded linux and there's a couple of features that I plan to develop for my needs by forking the repo.
For example:

• std::error::Error implementation for Error
• serde serialization for the calibration data

However these features need the crate to support std, so I'll add it behind a feature flag.
My question is: since I'll develop this, will you be willing to consider merging this to your repo?
If so I'll cut the work in one branch per feature and submit merge requests.

I2c Device Ownership

Firstly, thank you for writing this! I just started playing with Rust on embedded and it's a real joy.

The Bno055 struct holds onto ownership of the I2c object, which precludes me from using multiple I2c devices (on a Pi, using rppal, which has non-Send I2c impls). I see a destroy method that returns back the I2c object, but recreating the Bno055 object each sync doesn't seem ideal because mode wouldn't persist.

Really hoping I'm just missing something obvious?

`embedded-hal 1.0.0` and `embedded-hal-async 1.0.0` support

Hello,
I love that this crate exist and I would love to develop it further for the needs of the @AeroRust community.

I want to discuss how we could implement both rc candidates for embedded-hal and embedded-hal-async, along side the existing [email protected]

Function signature for usage code

First off, thanks for making this library.

I'm new to Rust, and don't have much experience with the Result<> return type. I used code under the "Usage" portion of the README (ending with Ok(imu).
However, my compiler says:

the `?` operator can only be used in a function that returns `Result` or `Option`

I tried adding -> Result<(), ()> to the function signature, but I got different errors. What should the return type be?

My current code:

fn new() {
    let i2c_dev = I2cdev::new("/dev/i2c-1").unwrap();
    // Use the 0x28 address instead of 0x29
    let mut imu_dev = bno055::Bno055::new(i2c_dev, Delay).with_alternative_address();
    imu_dev.init()?;
    imu_dev.set_mode(bno055::BNO055OperationMode::NDOF)?;
}

Thank you!

Thanks for making this library. I’ve been reading it to learn embedded Rust, and the clarity and comprehensiveness makes doing so a great experience. I’m also considering using it for a project I’m starting soon.

Just wanted to let you know I appreciate the work you’ve done!

README example code seems to be outdated

This is the first example code in README.md:

// ... declare and configure your I2c and Delay implementations ...

// Init BNO055 IMU
let imu = bno055::Bno055::new(i2c, delay);

imu.init()?;

// Enable 9-degrees-of-freedom sensor fusion mode with fast magnetometer calibration
imu.set_mode(bno055::BNO055OperationMode::NDOF)?;

Ok(imu)

But the function signature in rustdoc is:

pub fn new(i2c: I) -> Self;
pub fn init(&mut self, delay: &mut dyn DelayMs<u8>) -> Result<(), Error<E>>;

So, imu's new function call and init function call will will fail since the wrong arguments were given.

SemVer broken from 0.3.3 to 0.3.4 due to embedded-hal dependency update

Hello,

It appears that this library accidentally broke semantic versioning recently, which was the cause of a confused set of errors around trait bounds. In particular, bno055 v0.3.3 used embedded-hal v0.2.7, but the update in cc365a9 led to the bno055 v0.3.4 release from a few week ago used embedded-hal v1.0.0. Those two libraries do not have compatible APIs around certain traits, which means that folks specifying bno055 = "0.3" (or basically anything besides bno055 = "=0.3.3" in their Cargo.toml file will likely see breaks.

I would suggest cutting a new 0.4 release with the updated embedded-hal v1 dependency, and yanking the bno055 v0.3.4 release from crates.io. Additionally, it may be useful to look at https://github.com/rust-lang/rust-semverver for CI tooling or just as a precaution ahead of future releases.

Thanks for your consideration, and if you have any questions or there's anything I can do to support this, please let me know.

Combination BNO055 and BME280

Hello,
Sorry, I have only very basic knowledge on sensor communications. I could run a bme280 and also BNO055, separately without problem. The problem is when I combine both and override the wiring. Then the BME280 does not work anymore.
As you see here, the BME280 uses different SDA and SCL than BNO055 and I don't know how to define the I2C communication for both sensors.
Many thanks for your help!

//+++++++++++++++++++++++++++++++++++++++++++++++ Start and test BME280 Sensor
Serial.println(F("BME280 test"));
I2CBME.begin(21, 22, 100000); // BME 280 I2C_SDA, BME280 I2C_SCL
bool status;
status = bme.begin(0x76, &I2CBME);
Serial.println("-- Test --");

//+++++++++++++++++++++++++++++++++++++++++++++++ Start BNO055 Sensor
Wire.begin(14, 15, 400000); // (SDA, SCL) (14, 15) are default on ESP32, 400 kHz I2C bus speed
pinMode(intPin, INPUT);
pinMode(myLed, OUTPUT);
digitalWrite(myLed, HIGH);
I2Cscan(); // check for I2C devices on the bus8
// Read the WHO_AM_I register, this is a good test of communication
Serial.println("BNO055 9-axis motion sensor...");

Mint is not no_std

Hi, thanks for putting in the effort to making this lib!

It looks like you added mint as a dependency in 0.3.0, but unfortunately, it doesn't seem to compile without the standard library and as far as I can tell, there is no feature to enable/disable to fix that.

Am I missing something obvious here?