Orientation about adafruit_bno055 HOT 8 CLOSED

The problem is sustained lateral acceleration in a coordinated turn. You get the leans. If you use nxp or madwick then you feed in xyz acceleration into the algorithm. In a turn you can calculate the heading change in degrees per second and when you know the airspeed you can the calculate the acceleration and subtract it from the horizontal component to give you a virtual gravity vector. You can leave pitch unless you have a fast jet. It will not be perfect if you dont do a coordinated turn but mechanical gyros have the same problem, they also use gravity to errect and if you turn for 6 minutes it'll be out by a few degrees. Garmin g5 same issue.

from adafruit_bno055.

I persevered and worked out what I think I need. Which is 0x18 for remap config and 0x03 for sign. I then defined them as REMAP_CONFIG_P8 etc.
ThenI call bno.setAxisRemap(REMAP_CONFIG_P8 );
However, I tried all other configs and the remap function doesn't work as they make no difference to the output. Same for the AxisSign. Axis sign default is 0x00; So setting to 0x01 should invert one of the axis but it doesn't.

I added a function to read these two registers and I always get 0 so something is wrong.

For the test sketches I get roll pitch and yaw information and when I read out the accelerometer data I get data that agree with the axis printed next to the chip.

from adafruit_bno055.

On line 125 of the Adafruit_BNO055.cpp is part of the begin function. I uncommented out the default axis setting bits.

write8(BNO055_AXIS_MAP_CONFIG_ADDR, B00010010); // yxz
delay(10);
write8(BNO055_AXIS_MAP_SIGN_ADDR, B00000111); // xyz
delay(10);

And that works. So it works here but not when calling it via the exposed functions in the library. You need to put into config mode first and then into fusion afterwards. The exposed functions also do that but do not work or at least not once the unit is already in fusion.

Once this is done if I now bash out the acc data for each axis I now get 9.81 ms/s on my board z axis when upright which is the chips y axis - so that works. flipping the sign and then it gives -9.81.

Similarly I can get x and y to agree with what I wanted them to be (whether what I want is valid is another question).

from adafruit_bno055.

Hi,

I have similar problem and your tip helps me ;) By the way, I found out that the Adafruit registers of remapping does not fit to the official Bosh driver: https://github.com/BoschSensortec/BNO055_driver/blob/master/bno055.c (see row 9183). So I grab the number of the remapping I need and put it manually to the code and the result also was not as I expected. So I try randomly all the remap setting from Bosh and one of the was the one I was looking for.

from adafruit_bno055.

Glad I could help someone. TBH I thought that the BNO055 would be better hands down than mpu-9250 and doing it yourself with the fusion algorithm - but it didn't really work out that way for me. Specifically, I found that the issue with getting the axes all wrong meant that the heading (which is the whole point of AHRS) was unreliable and the calibration is completely black box an totally unrepeatable and changes with the wind. Getting the axes right is crucial for magnetometer because the weighting is highest when the tilt is <25 Deg which if you have the axes wrong is basically never satisfied. I also had trouble with the gravity vectors - in an aircraft the apparent gravity in a coordinated turn is always perpendicular to the aircraft floor - and so the IMU cannot work unless you know the lateral acceleration and take it out - you can do that with your own fusion but you cannot with this IMU and bosch do mention on the datasheet that this is optimised for human motion. So I wouldn't recommend it on any aerial platform.

from adafruit_bno055.

Looks like we are working on the same project ;) - I would like to create an artifitial horizon for the ultralight airplane. I did some test with MPU6050 and had the same troubles with remapping of the axises (I have the chip on the PCB which is oriented vertically, but the default setting is for the horizontal orientation) but even in horizontal orientation the roll information was strange in the turns (I tried it in a car). I found some project of an artifitial horizon on the internet where the BNO055 is also used: https://experimentalavionics.com/efis-ahrs-ver-2-0/ There is a discussion about that and the users probably have the same issue with the gyro drift caused by the coordinated turns in the air. As I gone through the code, thay try avoid it by overwriting the same calibration data every 5 seconds, because the problem is probably caused by BNO055 auto-calibration. But today I made a test with the default adafruit library and the BNO in my car hanged on a rope from the roof. I was riding around as fast and as tight as possible (to crate the highest lateral acceleration). As the BNO was hanging freely, it gets the same direction as the vector of the final force, which should simulate te same case as in the airplane in coordinate turn. After about 1-2 minutes were the data absolutelly OK without any drift, but I have to test it in the airplane to be sure. Did you do that test already? Or do you have better experience with the MPU9250 in the air? Are you using any library for that or did you create your own fusion algoritm?

from adafruit_bno055.

Here is another project (based on the first one) using BNO055 with different code. They say, that they solve the problem out, but I do not undestand the code much). For the last version they are using another AHRS: https://yostlabs.com/3-space-sensors/, which is probably also the BNO055 (based on the same dimensions and pins), probably with some software modifications inside the chip.

from adafruit_bno055.

You may both be interested in looking at the BNO080 which is also the same hardware as the BNO080 but with improved sensor fusion capabilities. It includes a number of different sensor fusion products, among which are ones with the gravity vector separated from the linear acceleration vector.

@Paulie92 I was specifically looking at making an AHRS demo for the BNO080's UART RVC mode, just based on how impressed I was with the performance for being so easy to use.

I'm going to close this; @DrJaymz a PR with any code you've added would be great to see ;)

from adafruit_bno055.