BNO055 ODR & Read times
Opened this issue · 15 comments
I've read (and learned a great deal from) a lot of your wiki. I have been playing with this sensor and was looking at the board on tindie and had a question on the ODR in fusion mode. Have you had any issues with the amount of time it takes to actually read the data out of the registers from this sensor? I am reading 26 consecutive registers to get quaternions, linear acceleration, etc, and the read time is all over the place from ~1 ms up to ~6 ms. With a 100 Hz ODR in fusion mode that seems kind of slow and is making my design difficult since I can't count on consistent timing and this sensor doesn't have a data ready interrupt.
The fusion mode only runs at 100 Hz; it's fixed.
What is your I2C rate? Try 400 kHz. What processor are you using? Try a
Cortex M4 like a Teensy. Or STM32M4f.
-----Original Message-----
From: abelsm2 [mailto:notifications@github.com]
Sent: February 9, 2016 6:32 PM
To: kriswiner/BNO-055
Subject: [BNO-055] BNO055 ODR & Read times (#4)
I've read (and learned a great deal from) a lot of your wiki. I have been
playing with this sensor and was looking at the board on tindie and had a
question on the ODR in fusion mode. Have you had any issues with the amount
of time it takes to actually read the data out of the registers from this
sensor? I am reading 26 consecutive registers to get quaternions, linear
acceleration, etc, and the read time is all over the place from ~1 ms up to
~6 ms. With a 100 Hz ODR in fusion mode that seems kind of slow and is
making my design difficult since I can't count on consistent timing and this
sensor doesn't have a data ready interrupt.
Reply to this email directly or view it on GitHub
#4 .
<https://github.com/notifications/beacon/AGY1qpeCDDEEC6fAhFIHqLQHoR2kvWmtks5
pipizgaJpZM4HW9sh.gif>
I'm running I2C at 400 kHz on a Particle Photon (STM32F205).
If I poll the sensor at 100 Hz sometimes it takes ~1 ms to read 26 consecutive registers and sometimes the sensor seems to pull the I2C clock low for a while between individual bytes of a multiple byte read, and in those cases it can take up to ~6 ms to read the same 26 registers. I am just surprised it takes so long to get data out of the registers since it doesn't seem to leave much time to do anything with the data before you are ready to poll for the next batch of data. The inconsistency is also making it difficult to poll other sensors in a predictable way.
The breakout i'm using does some voltage conversions so you can use it with 5V and other things and I am wondering if that is part of my problem, which is why I was looking at the breakout on tindie... that one seems to be just the bare 3V3 essentials. I have a Teensy 3.2 I could try hooking up but i'm not sure the controller is the issue.
I don't know why you are seeing such latency. I haven't taken a good look at
the BNO055 update rates. I too read 26 bytes but I usually output to a
serial monitor at 2 Hz so I would never notice if there was jitter in the
read times.
With an STM32 at 400 kHz bus speed you should see lightning fast reads. Hard
to believe you could be bogged down by voltage translation circuitry unless
the pullups are extremely weak or there is some other circuit error.
You must know that the BNO055 is really not a great solution simply because
the underlying sensors are not the best, let's say.
Have you looked at the EM7180? It allows user-selectable quaternion update
rates up to 400 Hz guaranteed and maybe higher if you want to push it. I
haven't looked at the read timing or consistency, but I do know the heading
accuracy at 2 degrees plus the warm start and use of MPU9250 data as input
produces a consistently superior orientation solution.
Kris
-----Original Message-----
From: abelsm2 [mailto:notifications@github.com]
Sent: February 9, 2016 9:25 PM
To: kriswiner/BNO-055
Cc: Kris Winer
Subject: Re: [BNO-055] BNO055 ODR & Read times (#4)
I'm running I2C at 400 kHz on a Particle Photon (STM32F205).
If I poll the sensor at 100 Hz sometimes it takes ~1 ms to read 26
consecutive registers and sometimes the sensor seems to pull the I2C clock
low for a while between individual bytes of a multiple byte read, and in
those cases it can take up to ~6 ms to read the same 26 registers. I am just
surprised it takes so long to get data out of the registers since it doesn't
seem to leave much time to do anything with the data before you are ready to
poll for the next batch of data. The inconsistency is also making it
difficult to poll other sensors in a predictable way.
The breakout i'm using does some voltage conversions so you can use it with
5V and other things and I am wondering if that is part of my problem, which
is why I was looking at the breakout on tindie... that one seems to be just
the bare 3V3 essentials. I have a Teensy 3.2 I could try hooking up but i'm
not sure the controller is the issue.
Reply to this email directly or view it on GitHub
#4 (comment) .
<https://github.com/notifications/beacon/AGY1qieJ2tpO7xzpor8jR_iegl9pPsEzks5
pisFDgaJpZM4HW9sh.gif>
I hadn't heard of it until I read one of your articles. I will definitely check it out. I need something that gives orientation but I am also looking for accel and gyro direct output to do some short distance motion tracking.
Your articles are awesome btw... keep up the good work!
The EM7180 auto calibrates the gyro such that at rest it reads 0, 0, 0 as it
should. We have just implemented an accel calibration routine such that the
calibration is stored in the EEPROM so it only has to be done once or at
least very infrequently, same with the other parameters which can be fetched
in a warm start mode. Makes it east to get calibrated (i.e., accurate)
orientation as well as scaled sensor output from subsequent power on.
Kris
-----Original Message-----
From: abelsm2 [mailto:notifications@github.com]
Sent: February 10, 2016 10:27 PM
To: kriswiner/BNO-055
Cc: Kris Winer
Subject: Re: [BNO-055] BNO055 ODR & Read times (#4)
I hadn't heard of it until I read one of your articles. I will definitely
check it out. I need something that gives orientation but I am also looking
for accel and gyro direct output to do some short distance motion tracking.
Your articles are awesome btw... keep up the good work!
Reply to this email directly or view it on GitHub
#4 (comment) .
<https://github.com/notifications/beacon/AGY1qhkHLz0mFFLQxRG3on-c0dwDfS-gks5
pjCEagaJpZM4HW9sh.gif>
First I would like to Thank you, Kriswiner, for your great work.
I have also faced problems with BNO055, I am reading multiple sensors and the latency of BNO is a big problem for me. I am using a custom board (Adafruit did not help me) with 1.5K pull-ups but the time to read the BNO varies from 1ms to 4ms (for 18 bytes). Change the baud to 100K also did not help me.
I have an M0+ (ATSAMC21E) and the most strange thing is that the BNO does not work when it is read by an I2C interruption (I am using ASF and waiting for the read interruption). The data is coming messed-up.
About the EM7180, buy it from Brazil is not really an option, I need to rely on goods from mouser or digikey, so I pay taxes and delivery only once... (you know, small budget).
I am using I2C to read the BNO, about the interruption, I mean inside the microcontroller (my ARM) but it was an ASF problem and I solved it. Let me try to explain it a little: If you make a blocking write (to tell from which register you want to start reading) and make a non-block reading, the ASF repeats the start command and the first I2C byte... But I guess this is not important to this discussion.
The fact is that the BNO has a big jitter and it does a huge impact in the system final performance, you might put an oscilloscope and a blinking led to measure the final transfer time.
About the EM7180, I would like to buy 2 of them, can you send it as a letter to Brazil?
So how can I pay you?
I've reading BNO055 data registers in the following order in fastest data output rate:
- bno055_read_euler_hrp(&eulerData); //Took 2 ~ 4 ms
- bno055_read_linear_accel_xyz(&acc); //Took 1 ~ 3 ms
- bno055_read_gyro_xyz(&gyro); //Took 1 ~ 3 ms
In worst case it sometimes took 11 ms ( < 100 Hz). Consider I didn't read other data registers and my Arduino code needs to do something else.
Does somebody have any solution to speed up I2C speed using BNO055?
Thanks in advance
I was talking about slow i2c. I know its working on 100 Hz.
Let me add no.4 to my previous comment:
- delay(10);
Apparently, BNO is a great SoC, but it has its problems, and the need of clock stretching is definitely one of them.
I have been working with it for a while and still have not find a way to solve this issue. If you do not stretch, the BNO fails in communicate. Probably this is because it has only a M0 running inside and it takes to long to fuse the inertial and magnetic data...