Comments (6)
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:
- The default state of the device is to report angular rates in degrees per second.
- It does not appear that this driver changes the units, so the current conversion should be valid.
- 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:
- 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)
- 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.
- 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%! - 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.
Related Issues (8)
- How did you find out the protocol? HOT 6
- Which BNO055 USB Stick version do you use? HOT 5
- [ERROR] []: start: open: Permission denied HOT 7
- Run directions please? HOT 2
- Does driver conform to REP-103? HOT 1
- Does this node work with the adafruit bno055 board? HOT 6
- Error- Incorrect Bosh IMU device response HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bno055_usb_stick.