11

I have never used an accelerometer before, but I am aware that they come with I2C, SPI and analog outputs. If I choose to use an I2c or SPI, device, will I accumulate errors due to communication time?

Is the fast sampling of an analog signal likely to get me a more accurate deduced position than using am I2C?

Will this be true for

  1. A robot moving in a room
  2. A robot moving in an outdoor terrain and is likely to slip and roll down a slope.

Also, I have no sense of Gs. I tried to move my hand around fast with my phone running andro-sensor in my fist and saw that the readings saturated at 20m/s2. What G can I expect my robot to experience if it is hit by another fat moving bot or bumped by a fast walking human?

Andrew
  • 560
  • 2
  • 10
  • 26
Lord Loh.
  • 575
  • 4
  • 16

3 Answers3

5

Increasing the sampling frequency of the sensor doesn't improve it's accuracy or precision. That is a feature of the sensor which you usually cannot change. If you try to estimate your position by integrating accelerations alone, you definitely will accumulate error over time, because every sensor is noisy. If you want to use the accelerometers to determine position or velocity, you should combine them with some other sensor that actually measures position (even with lower precision) or velocity. Then, you can combine these different sensor signals with a Kalman filter to obtain a reasonable estimate of where you are and how fast you are moving.

Considering G forces, consider that 1 G is 9.81 m/s^2, which seems a lot to me, in the context of small hobby robots, at least for indoor robots. Outdoor could be a different story, depending on how powerful your engine is. A saturation at 20m/s^2 should be enough.

Daniel Eberts
  • 821
  • 1
  • 7
  • 10
4

Think in terms of your control loop speed. A typical fast control loop speed is 1kHz. Some robots use a faster rate, some slower. Usually your control loop speed is higher than you really need it to be.

So each control frame lasts for 1000us. Within this control frame you need to:

  • Sample your sensors
  • Perform the control calculations
  • Send the new outputs to the motors

As long as you can comfortably do all of this within the time frame, you've got no problems. So how long does it take to read the accelerometer? If it's a 3-axis device, using 400kbps I2C, then it might take about 160us to read the data. That leaves you 840us to perform the calculation and update the motors. Even an 8-bit PIC can manage that.

About G forces. During an impact, they can be surprisingly high. For example, how much of a whack do you think it would take to break a hard drive? Probably not that much. Well a hard drive I had recently said it was rated for 75G max acceleration. So expect two robots colliding to produce at least several G. It's impossible to estimate accurately because it depends hugely on the mechanical design of the robots. If they are both completely solid like snooker balls, then you can expect very high accelerations. If they have some kind of flexible shell to them, then this will reduce the acceleration a great deal. But, the question is, do you really need to know the actual value of acceleration during an impact?

Rocketmagnet
  • 6,457
  • 5
  • 29
  • 54
1

From your question I figure you are trying to get your position from the accelerometers. Have a look at what sort of errors you are expecting before, and then maybe reconsider. Position estimation has very large errors, mainly due to the uncertainty in the orientation. The application in ships, planes, rockets etc use very expensive high precision navigation grade IMUs. The latency, which your question boils down to is not so much of a problem. More relevant is the synchronization between your other sensors (e.g. Gyros). Accelerometers are usually not used for position estimation (there are some cases where it helps, but only for short periods), but rather for compensating gyro drift in orientation estimation. You can also use them directly to estimate your orientation, but then your estimate is perturbed by dynamic accelerations.

Jakob
  • 3,054
  • 17
  • 36