Bosch BNO055 Intelligent 9-Axis Absolute Orientation Sensor

[wholder]

New 9 DOF sensor from Bosh with on-board sensor fusion using a Cortex M0.  The docs claim is can dynamically recalibrate the the accelerometer, gyros and magnetometer as part of the fusion algorithm.  Read more about it here:

  https://www.bosch-sensortec.com/en/homepage/products_3/9_axis_sensors_5/ecompass_2/bno055_3/bno055_4

and get C driver code, here:

  https://github.com/BoschSensortec/BNO055_driver

It looks like Mouser won't have any until about 6/15, but this device looks very promising to me.

Wayne

[Ted Meyers]

Whoa, that's cool.  I like that it has a 125 dps range on the gyro, most only go down to 250 dps (I've found that the lower the range, the better -- as long as you don't peg it!).  I can't help but fall in love with every new 9dof that comes out!

Ted

[wholder]

Yeah, I have a serious addiction to the "latest and greatest" 9DOF module quest.  If anyone's interested, the following Tindie site seems to have assembled breakout boards for the BNO055:

  https://www.tindie.com/products/onehorse/bno-055-9-axis-motion-sensor-with-hardware-sensor-fusion/

They were to of stock for a time, but recently restocked.  Not sure how long this new restock will last so get now if you're interested.

Wayne

[Ted Meyers]

So, I ordered one and received it a few days later.  It is a very well built and nice little board.  I did find some confusions figuring out the solder jumpers on the board, but the creator of the board was very helpful.  Once those details were worked out, it was really easy to use, and is a rock solid IMU.  I am very impressed.  Only issue is that it is a bit difficult to use with a 5V arduino as logic level converters are required.

[Wayne Holder]

Thanks for the info.  I ordered one, too, and received it a few days ago, but I haven't had time yet to hook it up.  It seems designed to mate with a Teensy 3.1 board, so that's my current plan.  The Teensy 3.1 runs on 3.3 volts, so that eliminates the need for level shifting.  

You said that it seems "rock solid" to you.  I'm very curious to evaluate it's alleged "self calibration" feature. What kinds of tests have you been able to run on it, so far?

Wayne

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/f1db7894-cfee-432a-8780-3db59cf8f06f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[jesse brockmann]

Ted, I ordered one as well.  Could you tell me what you had to do to make it work?  

--

[Ted Meyers]

My focus on IMUs is yaw, specifically I want to know heading.  My test procedure typically involves waving the IMU around and observing the yaw, pitch and roll (but mostly yaw), then placing the device on an edge of my table to get a known heading, followed by more waving around and putting it back on the table edge.  I'm looking for heading drift mostly.  Then I set it down and let it sit for a few minutes and repeat, looking for more drift.

The calibration feature seems to involve letting it sit, and then waving it around for a few seconds, it outputs a calibration status to indicate how well the calibration worked.  It seems to do well.

Ted

[Ted Meyers]

Yeah, so it is really built to sit on top of a teensy 3.1.  I didn't want to sit it on a teensy (even though I ended up using it with a teensy).  To use the 3.3v and gnd pins on the side with the SDA and SDL pins, you need to solder jumper the jumpers next to the 3.3v and ground pins.  Also, (and this is less obvious) if you want to use the pullup resistors that are on the breakout board, you need to solder the jumpers that are next to those resistors.  Two of the other jumpers are for setting the interface (I2C, UART, something else) -- I2C is default, and I would recommend using I2C.  The last jumper is for setting the I2C address (I think) -- I just left it alone.

Beyond that, I grabbed the example code linked on the tindie page and ran it on a teensy 3.0.  It should work, provided you have the libraries that it uses (should be easy to get, and you probably already have them).

It was a bit harder to get working on an arduino, as you need to set up level shifters and the example code requires some trimming to get down to a size that the arduino can handle, but I was able to get it working on an arduino as well.

Ted

[Jon Watte]

I got one too, but haven't hooked it up yet. I haven't yet made up my mind whether I'll talk to it from the Teensy 3.1 or the Pi. In either case, I won't use the "mating" footprint, as the Teensy is already pretty full with other things, but I have an unused I2C port on my Teensy carrier board.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/cca3b4b1-8cf3-4b20-abba-85e19a6c490a%40googlegroups.com.

[jesse brockmann]

Jon

I'm planning on using mine with a pi.  If you get it working let me know, and I'll keep you updated if I get it working.

JesseJay

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAJgyHGM-J1BgjfL8PgHZy2-Cyg9nudLe82LTHSRi7iuKXQTmrg%40mail.gmail.com.

[wholder]

The BNO055 is now in stock at Mouser:

  http://www.mouser.com/ProductDetail/Bosch-Sensortec/BNO055/?qs=sGAEpiMZZMtIHXa%252bTo%2fr2SMZuH5v3473jYOqmUidcJg%3d

Pretty amazing that I can buy a chip like this for only $11.

Wayne

[jesse brockmann]

Received my board today.      Also the same person has the EM7180 which sounds interesting as well.

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/6a3863aa-23d9-42ec-bd7a-c095a332dde1%40googlegroups.com.

[wholder]

Ada fruit now has a breakout board, too:

  https://www.adafruit.com/product/2472

Their version includes a 3.3 regulator and level shifters, so it looks easier to use with a 5V system like the Arduino.  Price is $35.  They've also done a nice tutorial with a library and Processing-based demo code:

  https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview

Bravo Adafruit!

Wayne

[Ted Meyers]

Wow, level shifters and a regulator for $35.  Nice!  No more being scared of toasting it with 5V.  (Sometimes it is just easier to use a 5v arduino).

I'm very impressed with the BN0055, I just tested it against a compass, and it seemed to be right on.  I also ran a magnet test, where I waved a small neo magnet past the sensor.  The (analog) compass was all over the place with the magnet within 6 inches, but the BN0055 didn't even seem to notice the magnet.  Maybe because it could tell from the other sensors that it wasn't moving.  So I moved both the magnet and the BN0055 at the same time for about a minute and then put the magnet an inch from the sensor and aligned with north.  The BN0055 read out within a degree of north (and my alignment probably wasn't perfect).

That being said, I did find that large amounts of pitch and roll seem to cause the yaw to get off by up to 20 degrees (and it seems to get stuck at that offset).  That may have something to do with my failure to calibrate the magnetometer on the pitch and roll axis.

[Ted Meyers]

Ooooh, just ran the BN0055 sitting on top of my rover _WITH_ the motor running.  The BN0055 only changed by 0.1 degrees or so (and I'm not sure if that was because my test stand was moving or not).  My previous attempts at running motors while reading a magnetometer (Pololu MiniIMU) were not so good.  Maybe because my homegrown sensor fusion algorithm was just a bit buggy -- but whatever, I'm just happy to have something that works.  I still need to run a dynamic test, with the rover accelerating -- that was always disaster on my previous stuff.  This looks so much better, so I am optimistic.

Ted

[Ted Meyers]

Just out of curiosity, does anyone know what would happen if you used the adafruit board with 3.3v logic instead of 5v logic (since it has level shifters)?

Also, the board on tindie has an air pressure sensor, but the adafruit board does not (if you care about air pressure).

[Ted Meyers]

Okay, I found the details on adafruit (they tend to bury the technical details -- arg!).  Vin is 3.3 to 5v;  SDA and SDL work with 3.3v or 5v logic and there are 10k pullups on both pins.

Ted

[Ted Meyers]

Calibration:

The BNO055 autocalibrates in the background.  There are 4 status values for calibration that go from 0 to 3 (3 is best).  Gyro calibration is easiest, just let the unit sit still for a few seconds.  Magnetometer is the next easiest, rotated in a circle and add some roll or pitch rotation.  Accelerometer calibration is a pain -- you will need to rotate in yaw, pitch, and roll very, very slowly; fortunately, once you achieve a calibration of 3, it seems to stay calibrated (this appears true for gyro, mag, and accel).  It seems like the accel calibration isn't really very necessary (there is a factory calibration that seems reasonably good anyway).

I don't quite understand system calibration, it seems to have something to do with the magnetometer, mostly; once I get gyro and mag calibrated, system seems to pop up to 3.  Put a magnet anywhere near the sensor though, and the system calibration drops back to 1 or 2.  It's kind of a cool feature actually, you can really know when there is magnetic interference.  It also makes a really good magnet sensor, it could sense my little neodynium magnet from about a foot away.

I'm going to check out the Adafruit BN0055 library, I did an initial quick test, but the heading was way off, well I didn't give it any time to calibrate (and at least the test code didn't show any calibration status values), so that may have been the problem (also, I'm not sure it was in NDOF fusion mode).

Ted

[Wayne Holder]

Ted, thanks for the update.  I still haven't had time to get mine up and running, but I'm encouraged by what you're reporting.  I wonder how feasible it might be to build some sort of compact, motorized gimbal assembly  automate the rotations needed to calibrate the sensors.  Probably overkill, but would be cool if there was a way to make it work.  

Wayne

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/aa3c4a94-bc8f-4bf1-ac24-e98a2e33bb46%40googlegroups.com.

[jesse brockmann]

It looks like a great board.  I don't care about the 5v, or level shifters since I'm using 3.3v systems, but the thing I like about that board is the mounting holes!  I've got many breakout boards with no mounting holes.  It can be a pain to positively mount them.     Figures one comes out right after I had bought a different board.   Trying to get to point I can start testing mine as well.

JesseJay

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/42589d29-1688-4f44-99ba-094c005b3b57%40googlegroups.com.

[Jon Watte]

Does it remember the calibration after power-off? (I could find out myself, but the workbench is sooo cluttered right now...)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CANqFZg0Y8%3D6vYn-n4OR1%3D%3Dh2Nanc0AhVdbT%3DmELbHscbBqSD_w%40mail.gmail.com.

[Thomas Roell]

Ted,

have you found out what the calibration is ? They yslk about 3 offsets and one radius ...

- Thomas

[Wayne Holder]

The data sheet says this about saving calibration:

3.10.4 Reuse of Calibration Profile

Once the device is calibrated, the calibration profile can be reused to get the correct orientation data immediately after ‘Power of Reset’ (prior to going through the steps mentioned in the above section). However, once the sensor enters the internal calibration routine, the calibration profile is overwritten with the newly obtained sensor offsets and sensor radius. Depending on the application, necessary steps had to be ensured for proper calibration of the sensor.

Reading Calibration profile

The calibration profile includes sensor offsets and sensor radius. Host system can read the offsets and radius only after a full calibration is achieved and the operation mode is switched to CONFIG_MODE. Refer to sensor offsets and sensor radius registers.

Setting Calibration profile

It is important that the correct offsets and corresponding sensor radius are used. Incorrect offsets may result in unreliable orientation data even at calibration accuracy level 3. To set the calibration profile the following steps need to be taken

1. Select the operation mode to CONFIG_MODE
   
2. Write the corresponding sensor offsets and radius data
   
3. Change operation mode to fusion mode
   

Wayne

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAJgyHGO%3Dj0_p74V58YuzzevxtpkJ3EQWii2Un9n2VekHD0iD%3Dg%40mail.gmail.com.

[Ted Meyers]

Wayne,

Yeah, I have read that section of the datasheet a few times, and it doesn't make much sense to me.  I see in the datasheet where it specifies how to save the calibration profiles.  It almost sounds like the profiles are used to achieve a faster and maybe better calibration.  It does sound like the profiles are saved on the chip, but it does mention that they are overwritten (but I am unclear on whether or not the overwritten values are saved in non-volatile memory or are just in ram).  The best way to test might be to write a profile, power off and read the profile right after powering on again.  Even so, I'm not that interested in testing it until I find out if the profiles really makes a difference -- I mean, if I just have to spend a few seconds longer calibrating, then I'm good with that trade-off.

Thomas - The datasheet says that there are x,y,z offsets for the acc,mag,gyro, which makes sense.  The radius is a single value for the acc and mag (not gyro).  I didn't find any description of what this value represents; and I have no idea.

For now, I'm planning on  running some real world dynamic tests with the rover on Sunday (using the basic auto calibration).  I'm hoping to find out how well it can drive in a straight line and how well it can drive in a square.  If that goes well, I might try a squared figure eight (left and right turns -- woohoo!)

Ted

[Thomas Roell]

Thomas - The datasheet says that there are x,y,z offsets for the acc,mag,gyro, which makes sense.  The radius is a single value for the acc and mag (not gyro).  I didn't find any description of what this value represents; and I have no idea.

I am guessing now ;-) Looking at my magnetometer calibration matrices, they all turn out to be reasonable diagonal in form, so a simple XYZ scale operation. I wonder whether Bosch is simply taking sx/sy/sz and compute a single scale (or radius) using r = sqrt(sx*sx + sy*sy + sz*sz). Or perhaps from calibration use a running least mean sequares to get r, ox, oy, oz directly.

In any case what's interesting is that they model a scale factor for the accelerometer as well.

- Thomas

[Wayne Holder]

I believe you have to read the various calibration values and save them in memory your application provides.  See section 3.6.4, Sensor calibration data, in the data sheet.

Wayne

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/2cbd6f85-3e70-43b3-b263-0e5101f4cd7e%40googlegroups.com.

[Ted Meyers]

Testing report:  Rain interfered with my testing today, but I was able to make a few test runs.  The straight line test looked good, the rover seemed to pull a bit to the right when starting, could be an alignment issue, or an issue with acceleration affecting heading (I had some serious problems with that last year -- on my not-so-good home-grown fusion algorithm -- I blame the fusion algorithm).  More testing is in order, when not raining. 

 

I also tried to run a simple rectangle pattern, about 30 ft by 60 ft, but I discovered a flaw in my code.  How hard can it be to code a rover to drive in a rectangle? I just can't do it without having something screwed up.  Sigh.  This time, instead of turning each corner at 90 degrees from the initial heading, I had it turning 90 degrees from whatever the current heading happened to be.  That worked great for the first corner, but things started to fall apart after that.  That and I needed to dial back the proportional gain on the steering, it was way over correcting.

So, maybe I'll get the code right and the weather will cooperate and I can get some testing in this week.

Ted

[Ted Meyers]

Progress!  It turns out that writing some simple code to drive in a rectangle using heading and distance is more difficult than I expected (I really should have known better).  Anyway, once I accepted that I would have to write a PID control for steering, things went a lot better; still, it doesn't really steer better than +/- 1.5 degrees or so (I know this from inspecting the data logs).  That makes it hard to tell if the steering is off due to the sensor, or just the steering.  However, between the two sources of error, it appears to be off by less than 4 degrees overall, it does not seem to drift in heading, and seems resilient to external iron, bumps, and acceleration.

I've got a couple videos; this is a short demonstration of the sensor calibration: https://www.youtube.com/watch?v=Rdq-eC_6jVk

Here is the bot in action: https://www.youtube.com/watch?v=fwfny3e710U

Ted

[Jon Watte]

1.5 degrees seems like the order of magnitude I'd expect in play of a hobby servo/linkage plus wheel deformation.

Jw

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/3bfa9f24-59ea-42c9-9944-70fcd11f403f%40googlegroups.com.

[Ted Meyers]

Exactly!  Between that and the road conditions, I really couldn't get it to hold a heading any better, even after putting a couple hours into tuning the PID.  I think that a lot of the problem is in the servo deadband and play in the steering mechanism.  I was hoping to get a lot tighter steering, so that I could get a good idea of the heading error in the sensor.  Really, what I found makes sense, the datasheet lists the magnetometer as having an error of +/- 2.5 degrees, that added to the 1.5 degree steering error gives me 4.0 degrees.  The 4 degree number was obtained by noting that the worst cross track error over 30 ft was about 2 ft, giving an angle of about 4 degrees.  (Note that this is all hard to measure with any degree of accuracy).

I think that I could decrease the cross track error by using a different navigation algorithm, like a pursuit curve.  But for this test I wanted to keep things simple and track heading directly.

Ted

[Minuteman]

I don't want to give away any trade secrets here, but we get very tight steering by simply using the servo's built-in PID. The only catch is that you have to calibrate your null, or "straight ahead" setting first. Then steering is simply computed by the null + (heading error * k). Where k is just a gain that you figure out through trial and error. It is also good to set limits on the servo throw.

This method is possible because the servo is already using PID to hold a given angular position.

[Wayne Holder]

I use the same technique.  I have test code built into J5 that lets me do straight test runs while carefully tweaking the servo center position, which is then stored in EEPROM.  This works best if the test surface is perfectly level and smooth, as any kind of surface irregularity can bias the tests.  I also did my best to tighten up the steering linkages and replaced the steering servo with a better one and added an aluminum horn rather than the plastic one the car came with.  I also use a error * gain factor calculation and drive this with a type of "pursuit" algorithm for steering that's based on circle intersection, as this tries to keep J5 "on the line" rather that "aiming at the waypoint".

Wayne

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/3dfea230-d78c-47c1-a9bd-ecdaff8e3b6a%40googlegroups.com.

[Minuteman]

yup, I'm doing something very similar with the pursuit algorithm. I also scale my steering gain base on my speed. This helps it turn tightly at low speeds and lightly at fast speeds. 

[jesse brockmann]

Ted,

  I'm reading this sensor now with a Teensy 3.1, using the Adafruit library.  Could you share what settings you are using? (Or code if you're really nice...)  You're not doing any calibration other then the auto calibration correct?   I'm hoping to do more testing later today.

Thanks,

JesseJay

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/3bfa9f24-59ea-42c9-9944-70fcd11f403f%40googlegroups.com.

[Ted Meyers]

Jesse,

Sure!  I used the Kris Winer code (https://github.com/kriswiner/BNO-055/blob/master/BNO055%2BMS5637_Basic_AHRS_t3.ino) and seriously chopped out a lot of the bloat in it (its great code, just that there is a lot more that it does than I wanted).  I made a library out of that code, along the lines of the Adafruit library, sort of.  I,m attaching my code.

Ted

[Ted Meyers]

Oh, I am just doing the auto calibration: let the sensor sit still for a few seconds, then rotate it around the yaw axis, then give it some pitch and roll, that seems to get it calibrated just fine.

On Friday, May 15, 2015 at 12:48:45 AM UTC-6, JesseJay wrote:

[Borna Emami]

I have been testing the BOSCH sensor in IMU mode to understand the usability in environments where the magnetic field cannot be relied on. It appears like they are applying some deadband to the gyros.

Example, I can leave the sensor on the table and it will not drift at all.

However, I can make the heading drift but applying yaw very slowly. The sensor does not appear to see this rotation. 

Unfortunately, this will lead to the heading drifting over time for my application (Underwater ROV) as it can be very motionless but rotating slowly due to water currents.

Have you guys seen anything like this? Looking through the datasheet, there is no mention of it or if it is possible to disable this "feature".

Thanks

Regards,
Borna Emami

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/f3cd2a3b-5dfc-45e1-88f3-0f5e7467fffc%40googlegroups.com.

[Ted Meyers]

Borna,

So you are using IMU mode, which is non-magnetometer, correct?  I suspect that you are correct that they are applying some deadband.  It makes sense, as there will be a noise floor for the sensor.  Make sure that the gyro is set on its most sensitive range (125 dps).

Ted

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAF8FTVDED%3Dn-TbYYtNwt%2BuHqhyyzE5w%2B8CLod5dm6%2BDZL9d%2BTw%40mail.gmail.com.

[Thomas Roell]

Will 125 DPS be good enough for rover dynamics ?

Did anybody test with raw data ?

- Thomas

You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/5CAeROsWLZ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKPACzzrUBPzMTNuphuqQ%3D%2BOei1aLp9YvMLWr0zrb_9PFQ%40mail.gmail.com.

[in...@richards-tech.com]

I've seen this on other IMUs where gyro bias is being tracked continuously. A small rate of change in yaw may look like a bias shift and be compensated out. If the magnetometers are active, this should be corrected depending on how the chip fuses the sensors.

[Borna Emami]

Ted,

Yes, I am using the IMU mode that has no magnetometer.

From the datasheet, it looks like the sensitivity is controlled automatically in the fusion modes., I suspect that it is placed in full sensitivity mode when the sensor is stationary but have no way to know that.

I wonder what the intended appliaction is for this sensor. it seems like it would work ok for cell phones and even cars that are stationary at times however, the ROV application could have teh rover not "moving" but still moving very slowly due to the water currents.

May need to build a platform to can simulate the water movements to see how much the gyro drifts. as there is no way to find that with their  built in filtering. I wish there was a way to disable it.

Regards,
Borna Emami

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKPACzzrUBPzMTNuphuqQ%3D%2BOei1aLp9YvMLWr0zrb_9PFQ%40mail.gmail.com.

[Thomas Roell]

Jessey, Ted,

what operating mode did you guys use for the BNO055 ? IMU ?

I am asking as I some somewhat confused. If you use IMU mode and have a level driving platform, then AX/AY/AZ are only able to correct GX/GY. GZ is then free running as it cannot be really corrected. That would point to some very smart gyro calibration scheme inside the BNO055 (something which did bit me for the MPU9150).

The only way to correct GZ is to use the MAG.

- Thomas

[Ted Meyers]

Thomas,

That is correct, IMU mode; there is no absolute heading on the Z axis.  It does seem to calibrate for drift very quickly (within a few seconds).  It is a great sensor, but I wish I knew more about the inner workings.

Ted

[Thomas Roell]

See that's where I am stuck at. Traditionally with an EKF or such you cannot correct the z-axis gyro scale/bias via accel.

When you say calibrate, do you mean static calibration while the sensor is not moving or while the rover is moving ?

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/5CAeROsWLZ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKOL-sHin0TLtC%3DD1%2Bodj15eXZ3_9VVyJLSj%3DR-QA72TFw%40mail.gmail.com.

[Ted Meyers]

Most gyros that I've used require a static calibration step (to remove drift).  This typically takes several seconds.  The BNO-055 doesn't seem to require this step, or if it does it is on the order of 1 second.

[Thomas Roell]

Perhaps they do it adaptively by looking for local minima in the accel data. If the object does not rotate ax/ay/az should have an identical magnitude if you look at them as vector. If you'd rotate around the x/y plane then ax/ay should pick up a lateral acceleration. If you don't have any longitudinal acceleration that might work.

If one could now understand how they separate linear acceleration and gravity ...

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/5CAeROsWLZ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKOmOrVyT9VvEQXjv0DC-E-A9HoDe0F3sTDhYz5N_wvDaw%40mail.gmail.com.

[Minuteman]

I understand the attraction of the BNO055. It sounds very capable. However, if the goal is to get low-drift, accurate angular data around the Z axis, I would be happy to try to help with the MPU-6050. I spent many long hours working on it, and now I consistently get less than 1/2 deg per minute drift. 

[Thomas Roell]

Just for fun ... gyro scale calibration ;-)

Magnetometer (already calibrated) is counting the 360 turns, and correlates it do gyro deltas.

https://youtu.be/7glkFWrxyw8

- Thomas

On Thursday, June 25, 2015 at 8:48:37 AM UTC-6, Thomas Roell wrote:

Perhaps they do it adaptively by looking for local minima in the accel data. If the object does not rotate ax/ay/az should have an identical magnitude if you look at them as vector. If you'd rotate around the x/y plane then ax/ay should pick up a lateral acceleration. If you don't have any longitudinal acceleration that might work.

If one could now understand how they separate linear acceleration and gravity ...

- Thomas

On Jun 25, 2015 8:38 AM, "Ted Meyers" <ted.m...@gmail.com> wrote:

Most gyros that I've used require a static calibration step (to remove drift).  This typically takes several seconds.  The BNO-055 doesn't seem to require this step, or if it does it is on the order of 1 second.

On Thu, Jun 25, 2015 at 8:32 AM, Thomas Roell <bizz...@gmail.com> wrote:

See that's where I am stuck at. Traditionally with an EKF or such you cannot correct the z-axis gyro scale/bias via accel.

When you say calibrate, do you mean static calibration while the sensor is not moving or while the rover is moving ?

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/5CAeROsWLZ4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to diyrovers+unsubscribe@googlegroups.com.

[Thomas Roell]

Nathan, 

I'll take you up on that offer ;-) As far as I understand one has to get the gyro-scale adjusted (it's not 1.0, at least not on my MPU9150). And then you have to get the gyro bias as well, which can be done by sampling a bunch of entries while the gyro is not moving. The average will be the bias. The formula for the corrected output should be GZc = S * (GZr - B). One can also keep a running dGZr to avoid rounding errors, so if you have n GZr samples, dGZg = S * (sum(GZr) - n * B) ... However it seems that you want to integrate over more than just one sample to get rid of the non-zero noise.

Do you measure this bias before every run ? Or statically once, or once per day ? Do you use a predicitive bias drift factor ? A temperature based drift factor ? 

Will the gyro scale stay constant of is it temperature dependent as well ?

Why am I asking ... Killer Kitty this year used Gyro/RPM as a predictive step and GPS as a corrective step in a 6 state EKF (X, Y, SPEED, COURSE, RPM_SCALE, GYRO_BIAS). The big issue I ran into is that the GYRO_BIAS overcompensates, and sacrifices short term precision big time. Adding a GYRO_SCALE to a 7 state EKF did not work out, as the GYRO_SCALE would wander all over the place, and make the short term prediction useless. I suspect that was a math issue on my side, but I had read that this is an effect others had run into as well. 

Anyway, part of the EKF rationale was that my wheels would expand at higher speed (I do like to have things go fast, in case I did not mention). So for a dead reckoning approach a Z-GYRO, X-ACCEL & Y-ACCEL and WHEEL-TICK & COMPASS-HEADING might be more suited as there I can correct for the wheel expansion. For such an approach the internal EKF of the BNO055 is utterly useless ;-) 

But for modeling I need a better way to deal with the MPU9150, and this is why I want to understand why the BNO055 works so well with little manual calibration (at least less than what I had expected).

- Thomas

[Minuteman]

Thomas,

I don't worry about scaling the gyro output on a per-sample basis. I simply sum the output into a 32 bit (or larger) integer register. I do subtract-out a null value at each sample, which I will talk about later. But essentially, if you sample your gyro at 1kHz, and sum the output into an accumulator, you will see that the value of that accum at any time will be directly proportional the angle of rotation. If your rate is set for 250 deg/sec, then a rotation of 180 deg will result in approximately 23330000 in the accumulator. I call that the GYRO_CAL number. So, at any given time the angle, in degrees, is deg = accum / GYRO_CAL * 180. 

Since the gyro output is linear, the accumulator is insensitive to whether the rotation is fast or slow (as long as the max deg/sec isn't exceeded).

Here is my basic routine for each gyro reading:

void read_FIFO(){

       sample = read_value_from_FIFO();   //read the latest z-axis sample. I use the fifo, but that isn't necessary

       accum += sample - null;           //add the sample to the sum and subtract the null

       if((accum > GYRO_CAL) -= GYRO_CAL*2;  //roll the accumulator at +180 deg.

       if((accum < -GYRO_CAL) += GYRO_CAL*2; // roll the accumulator at -180 deg.

       angle = accum/GYRO_CAL * 180;   // convert to degrees

}

I calculate the null at the beginning of each run. I sum 1000 readings and take the average. The gyro has to sit still for 3 or 4 seconds for this. The GYRO_CAL value can be calculated by summing the output while you rotate the gyro by 180 deg. Or you can sum over many turns, and divide by the number of 180 deg turns for a more accurate value.

You could probably use a 64-bit FP for the accumulator, but since arduino only supports 32 bit FP, I found it absolutely necessary to use a 32 bit integer to avoid roundoff and other errors.

If you follow that general outline, I promise you will get rock solid performance out of the gyro. There are a few other small optimizations that I make, which I can discuss later. 

Nathan

[Thomas Roell]

Nathan,

thanx for pointing out a few things. Your GYRO_CAL is essentially a GYRO_SCALE, except that you also bake a number of samples into it. The null is what I'd call a GYRO_BIAS.

Guess the INT32 vs. FP32 might be my issue. With a 24 bit mantissa for FP32 there is a loss of precision (actually it seems by 2 bits). The conversion to an angle though has to use FP64, or some tricky rescaling with FP32. I'll give that a try and see what the difference is to a FP32 accumulator that accumulates converted/scaled samples. 

I am using a 84MHz Cortex-M4. The whole sensor/navigation/ekf pipeline seems to use around 5% of the total available clock cycles. So using double vs float does not seem to be a real problem.

- Thomas

[Wayne Holder]

Nathan, I was always curious how you got such good performance out of a gyro, so thanks for sharing.  I'm frankly stunned at the simplicity of your approach.

Wayne

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/bd966248-9dd7-4331-aa76-b5b652bc324d%40googlegroups.com.

[Ted Meyers]

Funny thing is that I've actually run into this scheme (using integers to hold angles) in some 20+ year old C code.  We call it BAMS (Binary Angular Measurement System).  At first I thought it was just something we made up, but it turns out there is a wiki page on it: https://en.wikipedia.org/wiki/Binary_scaling.  One nice feature is that you don't have to worry about rollover at +/- 180 degrees, the integer math takes care of that for you.

Ted

[Ted Meyers]

Oops, I just realized that you are not using the full 32 bit range, so this is something different than BAMS.  You are just using integers to encode an angle.  Still, quite clever.

Ted

[Minuteman]

Thomas,

You are correct that GYRO_CAL is essentially my scaling factor, however there is no specific sample size baked into it. Because the sample rate is constant, integration of the turn rate can be approximated by summing the output and multiplying by a single constant. The total number of points integrated doesn't play into it.

Nathan

[Thomas Roell]

Nathan,

I am somewhat confused with this code. Your GYRO_CAL is about 233,300,000.

Now let's start this from the other side. Let's assume I have a perfect MPU6050, no bias, no scale, set at 250 deg/sec. The datasheet tells me in this setup I get 131 per degree per sec. Suppose now I rotate the MPU-6050 for 1 second for 180 degrees in total with a sample rate of 1000Hz (which if what you are doing), then I should have a value of 180 * 131 * 1000 in the accumulator, or 23,580,000. That is a factor of 10 off the value you are using.

However in read_FIFO() you have that:

accum += temp*10 - gyro_null;

So you accumulate 10 times the sampled value, to have presumably at 10x more precision on your gyro_null ...

Did I get this right ? So in reality the GYRO_CAL could be rewritten as 180.0 / GYRO_CAL to be a scale factor (as you use double to begin with when calculating the angle).


- Thomas

[Minuteman]

Ha, yes, that's exactly what I'm doing. I tried to leave it out to keep things as simple as possible. But yes, I multiply by 10 to get a bit more precision in the null.

Nathan

[Thomas Roell]

Oki.

So this is then about scale factor of 1.010715. My measured one is 1.008366. So about the same magnitude ... Good. I was starting to doubt myself.

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/5CAeROsWLZ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/36071d93-adde-4f3c-91b8-85d9105e734f%40googlegroups.com.

[Thomas Roell]

This one did raise my curiosity. Got some datasets for a few test runs where the rover more or less does a square and ends up going around 270 degrees (plus minus of course, 3 90 degree corners).

Put some of those logs throu a playback/simulation, that tracked a integer accumulator (64 bit signed), whereby I used 12 bits fractional prcision for adding the gyro_bias . A second parallel pass was accumulating the angle changes by converting the angle delta into floats, and then accumulating:

                        gyro_angle_zi = 0.0;
                        gyro_bias_zi = (((double)gyro_accum[2] * 4096.0) / (double)gyro_count);
                        gyro_range_zi = 180.0 * (32768.0 / 250.0) * gyro_scale * 1000.0 * 4096.0;

                        gyro_angle_zf = 0.0;
                        gyro_bias_zf = (double)gyro_accum[2] / (double)gyro_count;

(gyro_accum[2] is the accumulators for reading "gyro_count" samples at the start of the run to get the proper current bias).

And then after initialization this code was used to get the angles:

                gyro_angle_zi += ((entry->gz * 4096) - gyro_bias_zi);

                if (gyro_angle_zi > gyro_range_zi)
                {
                    gyro_angle_zi -= (2 * gyro_range_zi);
                }

                if (gyro_angle_zi < - gyro_range_zi)
                {
                    gyro_angle_zi += (2 * gyro_range_zi);
                }

                gyro_angle_zf += (((float)entry->gz - gyro_bias_zf) * (gyro_scale * (250.0 / 32768.0) * 0.001));
               
                if (gyro_angle_zf > 180.0)
                {
                    gyro_angle_zf -= 360.0;
                }

                if (gyro_angle_zf < - 180.0)
                {
                    gyro_angle_zf += 360.0;
                }

                printf("GYRO_ANGLE %f %f\n", gyro_angle_zf, ((double)gyro_angle_zi * (double)180.0) / (double)gyro_range_zi);

Anyway for a 50 second run, I get a delta of 3.5 degrees. With a 80 seconds run it got to about 4.5 degrees.

Now the interesting part. Moving the float accumulation to double did not really move the delta at all (despite going from a 24 mantissa to a 53 bit mantissa). Reducing the fractional precision from 12 bits to 6 bits also did not move the delta.


I did expect some differences, but by far not that magnitude.

- Thomas

[Minuteman]

Can you explain this a bit more? You got a difference in the angle between the integer and float accumulators. Do you assume that the integer value is correct?

What drift do you see when the gyro is sitting still? How does it compare between int and float? About how many deg/min?

[Michael Stephens]

I wonder if this is because some fractions aren't full representable in binary

On Jun 30, 2015 7:47 AM, "Minuteman" <nathan....@gmail.com> wrote:

Can you explain this a bit more? You got a difference in the angle between the integer and float accumulators. Do you assume that the integer value is correct?

What drift do you see when the gyro is sitting still? How does it compare between int and float? About how many deg/min?

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/015f6f5e-91cc-46b7-9f9e-9d8890bbf461%40googlegroups.com.

[Minuteman]

Now that I think about it, I should probably be multiplying by 8 or 16, but not 10.

[Thomas Roell]

Nathan,

I did not check into gyro drift. I was simply interested whether there was a difference at all. My assumption was that with your GYRO_CAL approach (taking away the * 10), you'd need about 25 bits to store the information (excluding the sign bit). So floats with 24 bit mantissa seem to be close enough. I also wanted to see whether there was any effect using more or less fractional precision adding the GYRO_BIAS (there are 6 bits available ...).

The idea was to compare this:

angle = sum(gz - GYRO_BIAS) / GYRO_CAL; // integer operation

vs.

angle = sum((gz - GYRO_BIAS) * GYRO_SCALE); // float operation

Again, I was expecting a small delta, but got a HUGE delta, and I even got a HUGE delta using "double" instead of "float".

I need to recheck that, as this does not make a lot of sense. Perhaps it's the divide vs. multiply that causes the issue. Perhaps it's the bitpattern for the float/double representation that makes the difference, or the rounding mode, or a gradual loss due to the small incremental changes that get added to a larger value. I simply don't know.

- Thomas

[Thomas Roell]

64 .... That's the max you can do with 32 bit signed ints. I tried 64 bit signed int's and a 4096 scale (i.e. 12 bits), but there was little difference in the end result.

- Thomas

[Thomas Roell]

Very good point.

My GYRO_SCALE at the end of the day reads like: (1.008 * DEG2RAD * 250.0) / 32767.0 ... (I accumulate data in rad/sec rather than deg/sec, I do have a non 1.0 scale factor on the z-axis gyro).

- Thomas 

[Minuteman]

Got it. I had some reason at the time for not using the whole 32 bits, but I was probably wrong. I do like to make multiple revolutions when calibrating the turn rate, so I think I would go with a 32 multiplier (instead of 64). It really just gives better resolution to the null estimate.

Previously, to avoid any multiplies related to the accumulator, I would take a 500 point null reading, but not average it. Then I would subtract that total after every 500 readings. I was paranoid about doing multiplies with my whimpy arduino.

[Minuteman]

I found that gyro drift is almost entirely dependant on calculation of the null value. When you get it right, drift is really low (assuming you use an integer accumulator). As a 2-bit programmer, I had to mess around a lot with different type casting of the numbers involved in the null calculation until I got something working well. Arduino is really sensitive to types and order of operation when precision is needed.

In general, though, I would avoid FP multiplies that get added to the accumulator. Although I always assumed that a double precision FP wouldn't care.

Also setting the proper calibration values for your specific gryo helps a lot. There are various routines out there for calculating those values.

[Thomas Roell]

Found 2 problems in my simulation:

(1) gyro_range_zi = 180.0 * (32768.0 / (250.0 * gyro_scale)) * 1000.0 * 4096.0;

     The factor "gyro_scale" goes really in as 1 / gyro_scale, as gyro_range_zi (or GYRO_CAL with Nathan's code) is used to divide the accumulated samples.

(2) gyro_bias_zf = (double)((int)(gyro_bias_zi)) / 64.0;

    If gyro_bias_zi is scaled by 64 as a fixed point number, then the corresponding floating point representation needs to be first converted to an int, before being divided by 64.0. Otherwise the effective bias is different.

With those 2 fixes, my 80 second run show and angle difference of 0.015 degrees if FP32 is used, and 0.0 if FP64 is used.

So IMHO no relevant difference.

- Thomas

[Ted Meyers]

Here is my analysis:

+/-250 deg/sec is stored in 16 bits, so the smallest value is 250/2^15 or 0.00763358 deg/sec. This is being updated at 1kHz,

so dividing by 1000 gives us 0.00000763358 deg/millisec. Now, a single precision float has 7.2 decimal digits of precision (24bits),

and we have to store +/-180 degrees (180.00000).  That means the 7 in 0.00000763358 is the first insignificant digit -- using

a single precision float will throw away most of the precision. Now, it will probably work somewhat because the 7 will get

rounded up, and if the angle is close to 0 (not 180) you get an extra 2 digits, but still there will be a lot of drift.

Please correct me if I am wrong.

Ted

[Thomas Roell]

Your math is correct. If you go an endless straight, then small rotations will not be picked up. Conversely noise will not be canceled out over multiple samples.

So unless you are bucketing somehow else (like average 10 samples), there will be a significant error.

The other interesting takeaway is that you want to scale from -180 to 180, rather than from 0 to 360.0, as this gives you an extra bit, the sign bit ...

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/5CAeROsWLZ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKMpU8%3D%2B0VQpCQUOHkS9iqGJg0za7T_Ghi1U2Ms8DgOodQ%40mail.gmail.com.

[jesse brockmann]

Thomas,

I'm using IMU mode.   One thing I've considered is starting in NDOF mode to get starting heading, then switching to IMU mode to get a starting heading reference.  But I've heard it can vary by as much as 3 degrees in this mode.   The NDOF mode seems to ignore the magnetometer most of the time for me since it quickly looses calibration.    Even with the calibration, I've seen weirdness in the heading.   That's why I stuck to IMU mode, which works pretty well from what I can tell.

I'll do more testing this year, and see if I get better results with it, and also try some other gyro's like the MPU9250, MPU6050, and others I've acquired while testing.  But based on my AVC results, it does work well enough already. :)  

JesseJay

On Thu, Jun 25, 2015 at 7:17 AM, Thomas Roell <bizz...@gmail.com> wrote:

Jessey, Ted,

what operating mode did you guys use for the BNO055 ? IMU ?

I am asking as I some somewhat confused. If you use IMU mode and have a level driving platform, then AX/AY/AZ are only able to correct GX/GY. GZ is then free running as it cannot be really corrected. That would point to some very smart gyro calibration scheme inside the BNO055 (something which did bit me for the MPU9150).

The only way to correct GZ is to use the MAG.

- Thomas

Regards,
Borna Emami

Regards,
Borna Emami

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/f3cd2a3b-5dfc-45e1-88f3-0f5e7467fffc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAF8FTVDED%3Dn-TbYYtNwt%2BuHqhyyzE5w%2B8CLod5dm6%2BDZL9d%2BTw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKPACzzrUBPzMTNuphuqQ%3D%2BOei1aLp9YvMLWr0zrb_9PFQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/1e205f19-4469-4101-9e35-d966d95840af%40googlegroups.com.

[H.B.F.G]

I know this thread is quite old, but hope someone still can give an answer.

I'm also testing the BNO055, only for Gyro readings for now. I have setup a fixed turntable turn the whole BNO+Micro to get reads around 30 dps.

I have tested the gyro sensor at 125 dps range, but my readings are different of 30 dps.

I did some calculus and looks my bench test is ok for 30 dps, however the BNO show higher readings. I then repeated the tests but using each available gyro range.

What I found is the 1 dps = 16 LSB is true but just for the 2000 dps range, and that is not mentioned in the manual!. I have spent 3 days trying to find out what's wrong until I did this tests.

So, now I find out the next:

2000 dps range, 1 dps = 16 LSB

1000 dps range, 1 dps = 32 LSB

 500 dps range, 1 dps = 64 LSB

 250 dps range, 1 dps = 128 LSB

 125 dps range, 1 dps = 256 LSB

Have someone realized this?  or I'm the only one that didn't know?  I have not seen this explaining when googling about BNO use....

[Ted Meyers]

I use the BNO in IMU Fusion mode, so the rates are not user settable.  I think that most people use one of the fusion modes (that is the best thing about this particular IMU; IMHO), which could explain why there isn't much discussion on gyro rates.

It may not be obvious, but I'd think that the datasheet would covers the LSB vs dps range, at least indirectly.  Since, the resolution is fixed at 16 bits, doubling the range will cut the reading in half (as you can see in your table).  It all makes sense, but finding it in the datasheet -- I don't know.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/dba779fd-aac3-4c84-ab1b-d1ecf1fbcad4%40googlegroups.com.

[Borna Emami]

What software are you using to talk to the BNO? the library might be normalizing?

Regards,
Borna Emami

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CADnZWKN8OUFfNFBRZFbJV6W7UftyfDzfUOFOAd8n6MRWXqok3g%40mail.gmail.com.

[Developer29]

Thanks!!

I'm using I2C, reading it directly in raw mode, no library's. I get the High & Low bytes of each axis.

Readings are then in -32767 to 32768 (16 bits).

Then I have to scale to proper engineering units (divide by 16 as datasheet say) to get dps.

For Gyro, I read:

X axis: Registers 0x14 and 0x15

Y axis: Registers 0x16 and 0x17

Z axis: Registers 0x18 and 0x19

I have repeated my tests, now using 125 dps range, I just divide by 256 and it works.

El jueves, 19 de octubre de 2017, 11:12:10 (UTC-5), Borna Emami (0x27) escribió:

What software are you using to talk to the BNO? the library might be normalizing?

Regards,
Borna Emami

On Thu, Oct 19, 2017 at 9:08 AM, Ted Meyers <ted.m...@gmail.com> wrote:

I use the BNO in IMU Fusion mode, so the rates are not user settable.  I think that most people use one of the fusion modes (that is the best thing about this particular IMU; IMHO), which could explain why there isn't much discussion on gyro rates.

It may not be obvious, but I'd think that the datasheet would covers the LSB vs dps range, at least indirectly.  Since, the resolution is fixed at 16 bits, doubling the range will cut the reading in half (as you can see in your table).  It all makes sense, but finding it in the datasheet -- I don't know.

On Thu, Oct 19, 2017 at 9:16 AM, H.B.F.G <diy2pr...@gmail.com> wrote:

I know this thread is quite old, but hope someone still can give an answer.

I'm also testing the BNO055, only for Gyro readings for now. I have setup a fixed turntable turn the whole BNO+Micro to get reads around 30 dps.

I have tested the gyro sensor at 125 dps range, but my readings are different of 30 dps.

I did some calculus and looks my bench test is ok for 30 dps, however the BNO show higher readings. I then repeated the tests but using each available gyro range.

What I found is the 1 dps = 16 LSB is true but just for the 2000 dps range, and that is not mentioned in the manual!. I have spent 3 days trying to find out what's wrong until I did this tests.

So, now I find out the next:

2000 dps range, 1 dps = 16 LSB

1000 dps range, 1 dps = 32 LSB

 500 dps range, 1 dps = 64 LSB

 250 dps range, 1 dps = 128 LSB

 125 dps range, 1 dps = 256 LSB

Have someone realized this?  or I'm the only one that didn't know?  I have not seen this explaining when googling about BNO use....

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/dba779fd-aac3-4c84-ab1b-d1ecf1fbcad4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

[Ted Meyers]

Huh, it just occurred to me that 16 LSB doesn't mean divide by 16, it means 16 Least Significant Bits.  That might have something to do with the misunderstanding.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/e8afb3ed-5f08-4623-9e6c-d1ea7fec337d%40googlegroups.com.

[Developer29]

It means 1 dps = 16 counts (or LSB); thus it means divide by 16. All library's (arduino, adafruit) do this way.

See extract below from one of known library that works for everybody.

    case VECTOR_GYROSCOPE:

      /* 1dps = 16 LSB */

      xyz[0] = ((double)x)/16.0;

      xyz[1] = ((double)y)/16.0;

      xyz[2] = ((double)z)/16.0;

      break;

I do know what LSB mean.

[Ted Meyers]

I think the difference in meaning is subtle.  How many degrees a bit (LSB) represents depends on the range, so you can't just divide by 16.  In this case, there are 16 bits of resolution, giving +/- 32000.  32000/2000 dps range = 16 LSB/deg.  But, 32000/1000 dps = 32 LSB/deg, etc.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/6ba9b361-43e2-421a-895f-be5c85f428c4%40googlegroups.com.

[Ted Meyers]

I think you're right -- I carefully read through the datasheet and it is at the very least misleading and ambiguous, if not outright wrong.  It is obvious to me that the scale should change in proportion to the range, but that doesn't seem to be specified anywhere, and it even looks like it says that scale stays constant regardless of the range -- which makes no sense.  I mean, the whole point of decreasing the range is to increase the resolution!

[Ted Meyers]

One more thing -- I just realized that more info can be found by looking at the BMI055 datasheet -- this is the actual gyro chip used by the BNO055.  It does contain the correct scale factor to use (which is not 16/32/64/etc -- the real values are 16.384/32.768/etc.)  It still annoys me that it doesn't give the range sensitivity used for some of the parameters (like zero-rate), but this datasheet is better.

[Developer29]

Yes, it depends on the range. But that is not mentioned on the datasheet.

The divide by 16 is correct for the 2000 dps range. I can confirm because the hardware & physics calculus of the test I did expect 30 dps, and now I have 30 dps reading at sensor.

In fact I do not use /16 but /256 instead with the 125 dps range.

As you mention, it should be 16.384 but if you read the datasheet it show 16 (integer) only.

I have contacted Bosch but they refuse to help if I use my public email. 

They want me to use my company email address in order to give any support. Duh.

Thank you all for your comments, I will look at the BMI055 to see for any else extra info.

[David nunya]

Excellent info regarding changing the divide by factor!

Has ANYONE found a fix for the mag dropping out of calibration?  I recently did a test of the (new?) USB stick version of the BNO055 by driving the truck on flat, then up and down a mountain with lots of curves, then flooring it (in a safe are) and subsequently slamming on the brakes.  But the <censored> mag was out of cal more than it was in!  For my purposes, it invalidated the readings, making the BNO055 useless, completely useless.  When you try to speak to Bosch about it, you get absolutely NO reply.  I like almost everything else about this chip but if the mag won't say in cal, what good is it?
/rant off/
Sincerely, how do you deal with this problem, especially in NDOF mode?  I've considered that when it drops out of cal, the program would reinstate that last know good values but as even the cal values are dynamic, would that really help???

side note: I have about a dozen of these chips in one form or another.  That's how badly I want it to work.

Thanks.

On Thursday, April 9, 2015 at 4:11:01 PM UTC-5, wholder wrote:

New 9 DOF sensor from Bosh with on-board sensor fusion using a Cortex M0.  The docs claim is can dynamically recalibrate the the accelerometer, gyros and magnetometer as part of the fusion algorithm.  Read more about it here:

  https://www.bosch-sensortec.com/en/homepage/products_3/9_axis_sensors_5/ecompass_2/bno055_3/bno055_4

and get C driver code, here:

  https://github.com/BoschSensortec/BNO055_driver

It looks like Mouser won't have any until about 6/15, but this device looks very promising to me.

Wayne

[jesse brockmann]

The magnetometer in bno-055 is the most flawed part.  First make sure to eliminate causes of magnetic interference by keeping imu far away from motors or servos.   I'd also suggest looking for a way to disable the auto calibration. It caused me lots of problems.

JesseJay

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/b9541eae-4e30-44f6-8f53-b620d7fd04bc%40googlegroups.com.