BNO080 how to measure angle as precise as possible

Sensors IMU & Motion
1

Hi all,

I am trying to measure the angle in on axis as precise as possible.

Currently I am using the MPU6050 and I do want to improve the measurement.

I started with my question on GitHub and Paul pointed me to this forum.

https://github.com/sparkfun/SparkFun_BN … /issues/49

Basically, I do want to determine a right triangle.

Therefore I am measuring the hypotenuse and the angle with the BNO080 SparkFun breakout board.

I think, I am suffering from the gimbal lock. Paul pointed this out and he’s probably right. My valuation is between -20 to 80° and especially around ~80° the error is noticeable.

I have to use an Arduino Due, so my computing power is limited.

Unfortunately I cannot predict in which position the device is during measurement.

I can be “flat” with y pointing to the front and x to the right, but it can also be flipped and x is pointing to the top.

The only thing I can assure, that y is pointing to the front, because the range finder is pointing in this direction.

Paul also pointed out, that it could be better if I get the raw values from the BNO and calculate the angle myself.

Can someone please explain why this would be better? I was hoping to the use the integrated ARM to load off the computing power as I cannot guarantee the time between calculations as I draw to a display …

I do have the chance to rotate the breakout board. Would it be better if I use pitch angle and not roll?

Any help is much appreciated as I noticed, that it’s getting quite complex to determine the angle precisely :slight_smile:

2

I’m sure it is possible to use an IMU to do what you’re looking for but a different product might be better.

We don’t carry any, but I think what you’re looking for is a digital inclinometer. Those are made specifically for measuring angles, would be a lot more accurate than an IMU and would likely require a lot less effort to get accurate results.

3

Thanks for your reply and your estimation.

I searched for digital inclinometers, I actually didn’t find too much. Can you recommend one?

I found the following:

https://www.murata.com/en-eu/products/s … er/scl3300

As mentioned, I am using an (custom) Arduino Due. So, 3V3 are convenient.

I would also prefer a digital interface. I’ve connected the display via SPI (DMA) and I hope this does not interfere with the inclinometer.

Unfortunately, this particular device is quite expensive.

I was expecting some specs about accuracy, but didn’t find it in the specs. Do I miss something.

Only found this. Angle output resolution 0.0055°/LSB

As far as I understand it, this only describes the digital resolution of an angle and not the accuracy of the sensor itself, right?

Thanks for your help!

4

Unfortunately I can’t recommend any, I’ve not ever actually used a digital inclinometer before.

I wish I had more information for you but we’re at my limit for knowledge on this subject.

If anyone else has any suggestions, please feel free to chime in. :slight_smile:

5

Hi phoefler,

I’ve been thinking about your problem. I do understand what you’re trying to do - and I assume you’re trying to measure the pointing of a ballistic launcher of some kind? Hopefully just water balloons? (If you’re actually trying to use this for some kind of gun or mortar, the support stops right here.)

The Euler calculations are done in the library, not by the BNO080 itself:

https://github.com/sparkfun/SparkFun_BN … #L406-L480

I think what you need to do is when you reach a ‘high’ pitch angle (> 45 degrees) you need to change which quaternions are used to calculate the pitch. I.e. instead of trying to measure pitch as the angle from horizontal, you start measuring it as the angle away from vertical instead. You’re attempting to make two soft sensors, one that goes into gimbal lock when vertical, paired with one that goes into gimbal lock when horizontal. You then need to decide which one you ‘trust’ most and choose between them depending on the pitch angle.

It’s an interesting problem but I don’t think we can offer you any more support or advice. The sensor and library are working as expected.

A completely different way of measuring the angle would be to use three ZED-F9P GNSS receivers linked together to provide accurate RELPOSNED information. There is a white paper written by u-blox that describes how this works:

https://www.u-blox.com/sites/default/fi … 093%29.pdf

If that doesn’t provide adequate accuracy, you might need a hybrid system. The GNSS system to give you a coarse measurement, and the BNO080 to give the fine measurement once you know approximately where your launcher is pointing.

I hope this helps!

Best wishes,

Paul

6

Hallo Paul,

thanks for your effort and your time to give me some guidance - I really appreciate your help.

I can assure you, that it’s absolutely not a weapon. You can think of it as special laser range finder, that interprets the measured values for a very special application.

As described, I have to determine a right triangle. It’s a handheld measurement device, so I think it’s not as complicated as the scenario you have described, but it can become tricky in some circumstances.

Simplicity is one big goal, that’s why the user should only trigger the measurement once. Of course I could measure two sides of the triangle, but that’s unfortunately not acceptable for this application. That’s why I am measurement the hypotenuse with a laser range finder and obviously the angle.

The problem, why I am running into gimbal lock, is, that I cannot predict how the device is held. When it’s held the “way it is build”, gimbal lock is not a problem or at least only at very high angles, which typically don’t occur. But when the user rotates the device and it is on edge, than the x-axis is at -1g (y-axis is pointing in direction of the laser).

If I understand your suggestion correct, I would have to mount an additional accelerometer. The new one has to be rotated, that it’s not in gimbal lock, when the first one is and vice versa.

I then, have to decide which one to trust if I am in certain angle ranges …

Would it be sufficient if I just yaw the IC on the PCB?

Would it be better if I put it on edge?

I am talks with muRata and I ordered a sample of their inclinometer.

It will arrive soon, and I hope I can bring it to live and see how it behaves. I am not sure, if it suffers from gimbal lock. As far as I understand the description, the SCL3300 is “only” an accelerometer but does the whole math for me and outputs the angle in degrees via SPI.

Unfortunately, the sensor is quite expensive, not sure if the results are that much better that to excuse the higher price.

I’ll get back once I’ve setup the inclinometer and did some tests …

Thanks for your help!

ph

7

Hi ph,

Ah, OK I’m really glad you’re not building a weapon! :wink:

I wonder if this would work:

When your user starts a measurement, get the BNO080 to do a quick measurement using the default chip orientation to work out roughly which way is up. If it sees a large value in roll or pitch then it changes the chip orientation so that Z points up? Have a look at page 42 of the datasheet (section 4: BNO08X Orientation).

To set the orientation, you need to be able to send an “FRS Write Request (0xF7)” using FRS Type 0x2D3E (System Orientation) followed by four 32-bit numbers to set the mapping (the Qw, Qx, Qy, Qz columns from the mapping table). The numbers need to have a Q-point of 30 ( https://en.wikipedia.org/wiki/Q_(number_format) ).

Now, this doesn’t look too tricky, but I can’t see an ‘easy’ way of doing it with the existing library functions. It might be possible to do it with sendPacket on CHANNEL_COMMAND but I’m not sure.

If you do manage to get a “setOrientation” function working, please send us a Pull Request as I am sure other people would find it useful!

Good luck,

Paul

8

Hallo Paul,

aah, now I got your idea. That sounds really clever - thanks!

Do you know how smartphones are solving this issue? Could be a similar mechanism as you’re suggesting. the iOS measuring app changes mode, when flat on table or on edge.

I’ll try to enhance the lib and of course send a pull request!

Best,

ph

9

Sorry for the delay… Here is at least a small update from what I am doing.

I’ve received a sample of the SCL3300 PCB sensor from Murata.

I tried to make a comparison between the MPU6050 (I am currently using), the BNO080 and the SCL3300.

The comparison is not perfect yet, as the sensors are not properly mounted. I am preparing a CNC part with some mounting screws, to align all sensors properly. I’ll post an update again as soon as possible.

Please find attached a picture of the structure.

https://ibb.co/gtrJRb5

I am reading the sensors every 250ms - there might be some delays due to drawing the display. But all measurement points are “at the same time” for alle sensors.

I took 5300 measurements for all three sensors over a total time of ~22min.

The acrylic glass plate was laying on a desk and I didn’t touch the desk or the sensors.

At the very beginning all sensors were calibrated or zeroed. So, all of them should read 0.00° in a perfect world :slight_smile:

I calculated the avg difference between the MPU and both other sensors, as MPU is the currently used.

In addition, I calculated the mean and the median for all three sensors.

SCL seems to be more stable and reliable by a factor of 10.

The calculation was done in R. The sensor readings were sent via Serial interface to a computer.

[1] "AvgDiff"
  avgDiffBno avgDiffScl
1 0.01676017 0.01645279
[1] "---------------------"
[1] "Mean"
          mpu         bno         scl
1 -0.01232272 -0.02774984 0.003956861
[1] "---------------------"
[1] "Median"
          mpu         bno         scl
1 -0.01210065 -0.02797784 0.005493164

Attached is a graph showing the sensor readings in degree.

Unfortunately, I was not able to attach the image, so I uploaded it to an image hoster.

https://ibb.co/qBfmV9P

Even that seems not to be possible.

https://ibb.co/qBfmV9P

10

Hi ph,

Many thanks for the update!

The SCL3300 is an interesting part - thanks for letting us know. (It is a shame it is SPI - otherwise we could have produced a Qwiic version!)

Best wishes,

Paul

11

As an additional comment, I did write an Arduino library for the SCL3300. (Should be easy enough to find.) That makes use of this sensor in sketches fairly easy, as the hard work has been done. My motivation for using such a high accuracy, low noise, and pricey SPI part is for telescope alignment. (Of course, if Sparkfun did a breakout board of this part, I’m sure it would cost less and be easier to wire up than the evaluation board sold by the manufacturer.)