• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Calculating distance via acceleration

I'm pretty stumped on this one so I thought I might as well see if anyone has any ideas.

I am using Sun SPOTs, which are wireless sensor devices, much like the Berkeley motes. It has a STMicro LIS3L02AQ linear, three-axis accelerometer on it. I will use the SPOTs to control the movement of a iRobot Create.

What my prof wants us to do is to have one SPOT connected to the iRobot, and another SPOT in the hands of a user. When the user moves the SPOT in his hand, the SPOT communicates to the one on the iRobot and have the iRobot make the same movements. So the example he keeps talking about is if I were to hold a SPOT in my hand and move it around in a circle (roughly 2 foot diameter), the iRobot should mimic the movement by moving in a circle.

To get a distance, one can integrate the acceleration twice. And the professor said to do just that. However, there has been several discussions on the SunSpotWorld Forums and the conclusion (including from developers on the SunSPOT team) is that the A/D converter is 10-bit, and integrating the acceleration data twice has significant errors (drift) due to lack of precision.

We brought this up in class and he said just to play around with it and use a filter. Several people on the forums have done a lot of work with that, and in the end it just doesn't seem to be able to be done accurately enough. i.e. If you leave a SPOT sitting on a desk perfectly still, over say 10 seconds, the integration determines that the position of the SPOT has moved several feet.

So I guess my questions are:

1) What kind of filtering do I want to do with the x and y-axis acceleration data so that I can reduce the drift as much as possible after integrating twice to get position?

2) Or can I abandon the integrate twice for position thing and somehow use the absolute acceleration, relative acceleration, or tilt angle of the x,y,z axes to mimic the kind of movement I need to do (like move the SPOT in a circle and have the iRobot do the same thing)?
 
A colleague and I have played around with the same problem, actually. In the end, we decided to use better accelerometers that had improved noise margins. If that's not a possibility for you, I suggest trying the following:

1) Use a low-pass filter on the raw accelerometer data. If you have to do the computation on your little nodes, like we did, we tried selecting high-order bits... unfortunately, it didn't work well as I recall.
2) Use multiple accelerometers and average or otherwise combine the readings, possibly discarding outliers.
3) Calibrate your accelerometers if you can
4) I seem to recall having a problem with gravitational noise on our accelerometer data -- maybe you're having the same problem?
5) Try using instantaneous readings, and discard anything that changes too quickly -- for instance, a hand can only accelerate at a few m/s/s, and the hand's dA/dt is pretty small, too. Try setting maximum delta thresholds on top of filtering (discarding readings over delta) and see if that helps
 
Back
Top