# Double Integration with the BNO055 for position data

I am trying to get position data(x, y, z) from the BNO055 IMU from adafruit. I have been given a library in java, so I can communicate with the IMU. I have been able to get heading, yaw, pitch to +/- 0.1 degrees and so I think I can do the same with positional data. My current code, measures a time elapsed in samples and then adds the new sample multiplied by the change in time. The problem with this is that the error is time^4 because i have to integrate twice. My goal is to get the position accuracy of +/- a half an inch. How can I change my code to get better accuracy.

I've heard things about sensor fusion, I don't exactly understand how it applies to my case, but I do have access to encoders on all of the wheels of my drive train.

• typeII or typeIII tracker – JonRB Jul 29 '18 at 11:24
• I googled that and got things fo Diabetes? – Archishmaan P Jul 29 '18 at 11:27
• your google-fu is weak – JonRB Jul 29 '18 at 11:31
• You can't avoid a double integration but you can use more accurate forms of numerical integration. Useful search terms : fourth order numerical integration, Runge-Kutta. But ultimately you can't eliminate drift without fusion with an absolute position. – Brian Drummond Jul 29 '18 at 11:32
• Well, I also have access to encoders on the wheels of my robot, can I incorporate those somehow? – Archishmaan P Jul 29 '18 at 12:24

How can you get ±½ inch position accuracy?

You probably can't, at least not for very long. Drift is a fundamental problem of inertial navigation. Ultimately you have to double-integrate accelleration, and the errors of that blow up quadratically with time. That's basic physics you can't get around.

Note that anything you do compute is only relative to the starting position. Any error in the starting position directly adds to any error computed later. Do you know your starting position to substantially better than ±½ inch?

Since the error increases with the square of time, after some finite time the error is larger than your limit and any results are useless. However, that also means the error is within acceptable range within some time limit. If you can work within that time limit, then using inertial navigation might work for you.

For example, I once did a project that tracked the motion of a golfer's head during a swing. It did this by inertial navigation using cheap MEMs sensors. The result became useless after about two seconds. Fortunately, that's all we needed, and we were looking for trends anyway and didn't need very accurate absolute position. This same setup would have been completely useless, for example, to map the golfer's movements as he walked along the green.

In practice, most inertial navigation is used to fill in between absolute position fixes obtained other ways, like GPS. The absolute fixes can be used to constrain the double integration errors, but still allow the intertial system to provide high-frequency details between absolute fixes. Really clever algorithms can use the inertial information to average out the jitter noise of the absolute fixes, while having the absolute fixes limit the time-growth of errors from the inertial system.

Look up something called a Kallman filter. It's good at interpolating between samples, with the occasional missing sample being reasonably well tolerated.

• I need it for 30 sec – Archishmaan P Jul 29 '18 at 14:53
• @Arch: then work backwards to find what acceleration error ends up causing 1/2 inch position error after 30 seconds. You'll likely find that such a low acceleration error is something you don't want to pay for. – Olin Lathrop Jul 29 '18 at 20:57