Scale error in gyro conversion about bno055_usb_stick HOT 6 CLOSED

Thank you for the detailed and valuable feedback! I did not perform any tests about this issue for now, but your claim sounds reasonable.

Maybe we can fix the code like
GYR_DENOM = 900
and
gyr.z = decodeVal(data[5], data[4], Constants::GYR_DENOM);
(as well as gyr.x and gyr.y)

I will look this issue by the end of next week. Please let me know if you have more suggestion.

from bno055_usb_stick.

Thanks for taking a look at this. I think your fix would work if it's just a matter of the conversions factor (I haven't tested it to verify yet, though).

After looking at the bno055 documentation some more, I am somewhat confused. First, it turns out that the choice of units is configurable on the device, but to avoid the ~1.5% error, the conversions are only valid when the device is configured for the corresponding units. In other words, the degrees per second conversion is valid when the device is configured to report angular rates in degrees per second. What is confusing to me is:

1. The default state of the device is to report angular rates in degrees per second.
2. It does not appear that this driver changes the units, so the current conversion should be valid.
3. It doesn't look like the format of the commands being sent to the device match with the spec in the documentation, so I'm not sure what they are actually doing.

I have not been too familiar with the implementation of the driver, and I am just now looking more closely at it, so I apologize if I am not understanding that should be obvious. I will let you know if I figure out what is going on.

from bno055_usb_stick.

Another update:

1. I was able to verify that the conversion factor is NOT the issue, so I think it is not necessary to make the proposed change (and in fact, it would make the scale error worse -- unfortunately, I wasn't careful in my initial testing and analysis -- the change in conversion factor to radians scales it by approximately the right amount, but in the wrong direction)
2. Unfortunately, I am also still pretty certain that there is a scale error in the measurements that is similar across devices. I ran four bno055 usb sticks simultaneously, and they all gave nearly identical measurements -- much closer to each other than to the ground truth.
3. The conversion factor (the denominator term) that gave the most accurate results for us was found to be 16.53. That's a difference of over 3%!
4. Given that I'm seeing the same difference on multiple bno055 devices, I still wonder whether there is an issue with the driver, but there is no longer an obvious potential explanation of the error.

I would be interested to know if you have any ideas of what might cause the error that we're seeing.

from bno055_usb_stick.

@kriskozak
Thank you for the interesting updates. I agree that this issue is no longer related to the conversion scale but related to the measurement accuracy of the device. I would keep the code as it is.

Unfortunately, I have no idea to improve the measurement accuracy itself and afraid that it might be difficult by changing the code. I might want to close this issue if you agree.

from bno055_usb_stick.

@yoshito-okada, yes, I think it's fine to close this issue.

For what it's worth, it seems that the reported measurements are inaccurate, but I'm a little doubtful that the inaccuracy is in the device itself. Unfortunately this is difficult to troubleshoot, and the revised scale fix mentioned above has worked well-enough so far, so I haven't spent any time investigating it further. I'm a little curious about whether you see the same error (I saw a nearly identical error in four different usb sticks).

Also, when I was looking into this, I saw that the protocol for communicating with the usb_stick is different than the protocol for communicating directly with the bno055 chip, and I was unable to find a manual or reference for the usb_stick interface. Do you happen to have any information on the usb_stick interface that you could share?

One interesting side note: I primarily use the gyro measurements to estimate changes in heading/yaw, so I'm less interested in the yaw rate itself and more interested in the integration of yaw rate over time. Usually it's safe to assume that there is no error in the time (or differential time), but I ran into a similar scale error issue on at least two different occasions that was actually caused by an error in the system time. The root cause was that chrony, which does clock synchronization using NTP, was running on the system, and the system time was wrong. To fix the time, chrony slews the clock, slowly, but fast enough to cause an error of several percent in the integration... Unfortunately that was not the issue this time...

from bno055_usb_stick.

@kriskozak
Thank you for agreeing to close this issue. If I get further reports that suggest the revised scale is better, I will think to add an option to switch the scale values.

Unfortunately I have no manuals or references about the protocol of the usb_stick. I just monitored commands from the official utility software from Bosch and copied them to my code. Please see #5 for details.

Time jump by chrony is definitely an interesting problem but I think it is not an issue of this package (maybe time system of ROS or your native operating system).

I would be happy to see you again in other issues or PRs.

from bno055_usb_stick.