Measuring velocities

4 views
Skip to first unread message

motters

unread,
Mar 15, 2007, 2:36:19 PM3/15/07
to Sentience
As part of the motion model within the simultaneous localisation and
mapping system we need to know the current velocity of the robot, both
in the forward direction and also the angular velocity. Traditionally
this is done with wheel encoders, but a better solution may be to use
inertial sensing from accelerometers.

I'm going to be experimenting with this device
http://blog.trossenrobotics.com/index.php/2007/02/01/phidgets-announces-3-axis-accelerometer/
which should work on both Windows and Linux systems as a method of
estimating changes in the robots velocity. When combined with stereo
vision this should produce a reliable and completely solid state
solution to the mobile robot perception problem.

With the accelerometer device mounted at some distance from the centre
of rotation of the robot it should be possible to measure its angular
velocity, which can also be fused with scan matching for even greater
accuracy. This effectively reduces the amount of noise within the
motion model, meaning that fewer particles are needed in order to
characterise the robots position uncertainty (which means less
computation is required and so the whole thing will run on more modest
processors).

motters

unread,
Mar 28, 2007, 2:02:24 PM3/28/07
to Sentience
After some initial experiments with the Phidgets 3 axis accelerometer
I'm beginning to think that this device won't be suitable for what I
imagined using it for. It's very easy to use the accelerometer to
calculate the orientation of the sensor in 3D relative to the
direction of gravity, but recovering usable velocities and
consequently positions seems to be infeasible.

To begin with these sensors have a low signal to noise ratio, meaning
that a large amount of filtering is needed in order to get usable
data. Even if the noise filtering was perfect you still need to
subtract acceleration due to gravity to get the resulting non-
gravitational component of the acceleration. Gravity varies slightly
from one place to another, so there is always going to be some error
here. In addition the analogue to digital conversion will introduce
further errors, and any data dropped over the USB communications adds
extra error on top of that. Although all these errors may be small
there is no way of recovering from them, so what begin as tiny
velocity errors due to inaccurate integration of acceleration values
over time soon turn into massive velocities. Just because the sensor
has stopped accelerating does not mean that it's not continuing to
move, so there is also the problem of determining when the robot is
stationary. All these problems add up to it being very difficult to
get reliable velocity and position data from this sensor.

So at the moment it's looking like conventional wheel odometry will
have to be used. This is a shame because inertial sensing would have
given a much more compact solution.

SpiglerG

unread,
Mar 29, 2007, 8:45:34 AM3/29/07
to sent...@googlegroups.com
Wouldn't it be possible to determine whenever the robot is still by adding acceleration to a variable each instant?
That would mean that moving at constant velocity gives an acceleration, a still acceleration value of about 0, a deceleration?
Last acceleration could be tracked to get the current velocity, and the deceleration would decrease the variable, which should go around 0, and below a threshold could be considered still.

Bob Mottram

unread,
Mar 29, 2007, 8:55:52 AM3/29/07
to sent...@googlegroups.com

That's the theory, but any error in the acceleration values - however small - leads to big errors in velocity.  Zero acceleration does not mean that the velocity is also zero.

There are a few assumptions which might be used to improve things.  First we can assume that the sensor is mounted flat on the robot, so that its Z axis is always roughly the direction of gravity if the robot is moving on flat surfaces.  We can also zero the velocity value when we know that no velocity commands are being sent to the motors.  Also, this is a very sensitive device, so even moving over an extremely flat surface is going to produce some small but measurable vibration, so even at constant velocity there will be small changes in acceleration, especially in the vertical (Z) axis.  The only problem is distinguishing small accelerations from the large amount of background noise.

So at the moment it looks as if getting velocities from an accelerometer is only borderline feasible at best, and more conventional measurement methods would give better results.

SpiglerG

unread,
Mar 29, 2007, 9:05:05 AM3/29/07
to sent...@googlegroups.com
I meant that summing acceleration(ideally) would lead to a value of about 0 when still.
However for the error measurements, as you wrote it's probably because vibration and too much sensitivity, but wouldn't there be any solutions to decrease sensitivity?
Maybe adding some lowdensity material on the sensor could decrase sensibility.
I don't know if i explained myself clearly, but the concept is:
putting the sensor in a medium density fluid could decrase sensibility, because the fluid would adapt to small misalignement to the ground and vibrations.

motters

unread,
Mar 29, 2007, 6:36:47 PM3/29/07
to Sentience

A useful reference on using accelerometers:

http://www.freescale.com/files/sensors/doc/app_note/AN3397.pdf

and this video would suggest that it is possible to get good position
values!

http://www.youtube.com/watch?v=yfp5HBUizOQ

Reply all
Reply to author
Forward
0 new messages