Problems with the HiTechnic Accel Sensor

[brickbuster]

Hi there,

I just bought the HiTechnic Lego Accel Sensor, and I have problems getting sensible readings.

My code looks roughly like this:

Code: Select all

AccelHTSensor s = new AccelHTSensor(SensorPort.S2);
int a0 = s.getXAccel(); if( a0>512 ) a0 -= 1024;
...
while(true) {
  int a = s.getXAccel(); if( a>512 ) a -= 1024;
  a -= a0;
  v += a;
  pos += v;
}


But upon the first movement (pushing the brick softly to the side) pos starts to drift/ v does not return to zero.
Is the sensor just not fit enough to integrate position data (and only good for pointing to the center of the earth)?
Can it be that my sensor is broken? (the tendancy to drift seems to be unequal for each axis)

Or is there something obvious I am missing?

Regards,
Holger

[gloomyandy]

Hi,
pretty much all sensors will have drift. There are some things you can do to help with this. You probably want to set a0 to be the average of a number of readings taking over a period of time (say a few seconds. also your integration loop should probably have a delay of some sort in it to ensure that you take readings at regular intervals, preferably this interval should be based upon the real sample rate of the sensor. At the moment there is a good chance you are picking up duplicate readings etc. Note that integration is prone to accumulate drift errors, there is a lot of work out on the web that describes different ways to do this sort of thing. Also note that with an accelerometer you need to take care to ensure that gravity is not being picked up as part of your reading. Any change in the angle of the sensor may result in this. You may need to integrate the results over all 3 axis to ensure that you can remove this source of error. Aswin (one of the leJOS developers), has done a fair bit of work in this area and will probably be able to provide some hints and tips...


Andy

[brickbuster]

Thanks for your hints, however:

* the brick is being moved around on an about level table, so I can rule out tilting.
* According to your suggested I added multisampling for the a0 calibration. But that didn't change the results.
* Is System.currentTimeMillis() reliable on lejos?
* I did take loop time into account (I omitted it in the post)

Code: Select all

while( true ) {
  long start = System.currentTimeMillis();
  ...integration stuff
  long took = System.currentTimeMillis() - start;
  Thread.sleep( 20-took ); // also tried 50 and 100
}


* From what I've read the sensor does 100 samples/sec and I measured that a call to getAccelX takes about 10msec.
* I should also add that I tried dumping 2 least significant bits from the sensor reading to avoid the sensor returning to -1 - but same problem.

[skoehler]

* Is System.currentTimeMillis() reliable on lejos?

In what way are you unhappy with System.currentTimeMillis() ?
It might have some granularity (I think it's actually 1ms, which is the lowest possible) and otherwise behaves exactly as you would expect it too.
leJOS also have System.nanoTime() (or whatever it is called).

* I did take loop time into account (I omitted it in the post)

Code: Select all

while( true ) {
  long start = System.currentTimeMillis();
  ...integration stuff
  long took = System.currentTimeMillis() - start;
  Thread.sleep( 20-took ); // also tried 50 and 100
}


What's the purpose of the Thread.sleep() in the end?

* From what I've read the sensor does 100 samples/sec and I measured that a call to getAccelX takes about 10msec.

Just a hint: If you read all two or three axes anyway, use getAllAccel() instead of calling the individual get?Accel() two or three times.

* I should also add that I tried dumping 2 least significant bits from the sensor reading to avoid the sensor returning to -1 - but same problem.

As Andy already mentioned, a drift is a pretty common problems. You will need to process the data in some way to get rid of the drift. One way to do this is to use a high-pass filter with an extremely low cutoff frequency. I think, a solution based on a leaky integrator may also be possible. Anyways: I have not yet seen your integration loop. If it doesn't take the time between samples into account, it will hardly work. It should look something like this:

Code: Select all

float sum = 0;
int val = getXAccel();
long time1 = System.currentTimeMillis();
while( true ) {
  val = getXAccel();
  long time2 = System.currentTimeMillis();
  sum = sum + val * (time2-time1);
  time1 = time2;
}


[skoehler]

Hi there,

I just bought the HiTechnic Lego Accel Sensor, and I have problems getting sensible readings.

My code looks roughly like this:

Code: Select all

AccelHTSensor s = new AccelHTSensor(SensorPort.S2);
int a0 = s.getXAccel(); if( a0>512 ) a0 -= 1024;
...
while(true) {
  int a = s.getXAccel(); if( a>512 ) a -= 1024;
  a -= a0;
  v += a;
  pos += v;
}


Why are you subtracting 1024 is the sensor returns values greater than 512?
I'm asking, because as the AccelHTSensor class that ships with leJOS 0.9.1 should already return signed values between -512 and 511.
Does it actually happen that the values become larger than 511 ? If so, that would mean there's some kind of problem here.

[gloomyandy]

As I said before doing this sort of thing is tricky and you will almost certainly get some amount of drift. I would suggest that you log the actual data being collected and try and work out what is going on (take care to ensure that your logging method does not disturb the actual timing of the calculations). What happens if you do nothing but just leave the brick in place for some time? Also I doubt very much if just using a level table is sufficient to ensure that things are correctly aligned. Small errors in the mounting of the sensor and or chip alignment may also contribute to the non vertical axis picking up some gravity component. As I said there is a lot of data on the web for how to handle sensors and techniques for dealing with sensor drift. Some of them may be of use to you.

The millisecond time is pretty accurate. But you need to remember that other threads will be being scheduled so that for instance between the call to the getCurrentTimeMillis and the call to sleep other threads may run (including system threads), which would mean that you sleep too long. Agian the best way to asses this is to add some form of data logging and determine for yourself if this is causing a problem. A more reliable way to ensure the sleep is for the correct period is the following....
Thread.sleep(1);
took = system.currentTimeMillis() - start;
Thread.sleep(20 - took);

The additional sleep ensures that other threads will have run. It is very unlikely that your thread will be pre-empted immediately after a return from the sleep call. NOTE: this is true only for leJOS it may not be true for other Java environments.

Oh and finally what exactly are the tests against 512 for? Why do you need to subtract 1024 if the value is above 512?


Good luck

Andy

[brickbuster]

Am am running lejos 0.9.0 which (sometimes) returns things like 1023 when resting.
So I assumed that [0...400] is for upward and [624..1024] downward (200ticks/g).

Right now I am upgrading to 0.9.1. However right now I am stumped
as there seem to be some linux shared libraries amiss. I'll report back as soon as
I have firmware 0.9.1 up and running

[skoehler]

Am am running lejos 0.9.0 which (sometimes) returns things like 1023 when resting.
So I assumed that [0...400] is for upward and [624..1024] downward (200ticks/g).

I just looked it up. In 0.9.0 the AccelHTSensor class was different. It returned values from 0 to 1023, with the 9th bit being the sign.
1023 is basically equal to -1 as you already have figured out. In 0.9.1 the class been fixed to something that makes much more sense.

For installation of 0.9.1, take a look at the official leJOS tutorial. You probably just forgot to build the libjlibnxt.so by running ant in the build folder.

[brickbuster]

After upgrading to 0.9.1, switching to float calculation and using a simple high-pass filter the reading begin to make some sense: Inert sensor is being correctly detected, however during movement values are still far away from reality.

I did not expect that one has to go into singal processing theory so quickly
Now I think I have to learn how PID correction (and Kalman filtering) works...

Thanks for your help,
Holger

[kirkpthompson]

Also, you may want to look at lejos.nxt.addon.GyroDirectionFinder.

-K

[Aswin]

Hi,

Integration is a pain. If you rely solely on integration you will always experience drift. However there are some ways to minimize drift.

Offset
First the offset (a0 in your program). You should calculate this on several readings, not just one. This is to cancel out noise in the measurement. The offset value should also be a float instead of an integer otherwise it may not be exact and an error in the offset will build up quickly in velocity. Also the velocity should be a float. I understand you already did this and that this improved things.

Timing
If accurate timing is an issue (I don't think so) I would calculate deltaT independently from the sleep timing. Here is an example.

Code: Select all

long now;
long lastTime=System.nanoTime();
while (true) {
      long now=System.nanoTime();
      if (lastTime==0) lastTime=now;
      double dt=(now-lastTime)*Math.pow(10,-9);
      lastTime=now;
      Thread.sleep(20);


Sensor mounting
I would not assume that your sensor is level, you might think it is, as you correct for offset and therefore get zero acceleration at stand still. However, if there is an alignment error on the sensor then the calculated offset is not the true offset but the sum off the true offset and the alignment error.
But even if the sensor would be perfectly level at stand still this doesn't mean that it remains level when your robot is accelerating or moving. Inertia of the robot and motors and friction in the drive system will tilt your robot. If you want to know if this is an issue you should keep track of the Z-acceleration. If it is no longer exactly 1 G when moving/accelerating then you know your robot tilts during movement. It will be very hard to correct for this in code as you cannot really distinguish tilt from acceleration.

Some tips.
Try to use proper units for acceleration, time and speed. Convert if needed. This will help to understand better what is happening and how big your problem is.
The NXTChartingLogger is a great tool to examine your sensors.
You can increase the query speed of sensor readings ( up to 1.4 ms instead of 10 ms) by adding this line of code before you instantiate the sensor.

Code: Select all

SensorPort.S1.i2cEnable(I2CPort.HIGH_SPEED);

[Aswin]

Here are some pictures that demonstrate the problems with integrating.

The pictures all show the velocity as calculated from integrating the acceleration measured by an accelerometer (MindSensors v3). The sensor was thoroughly calibrated. The dynamic range was set to 2G. Both pictures were taken in one run, right after each other.

The first image shows the sensor being completely level (as far as I could tell). The integrated signal, the velocity, drifts off quite quickly. After just ten seconds it seems that the sensor is moving at a speed of -0.13 m/s.


For the second image I did not move the sensor, but I carefully slid a piece of ordinary paper (about 0.125 mm thick) under the long end of the sensor (52 mm long). The signal drifts of the other way. After 10 seconds the sensor seem to be moving at .10 m/s.



This shows how huge very small changes grow when integrating.

[brickbuster]

Wow. This is tough. So I can assume my equipment to be operating properly (which is a good thing to start with )

But it almost sounds as if locaton awareness is not feasible with NXT Sensor equipment (Gyroscope is available)

Holger

[skoehler]

But it almost sounds as if locaton awareness is not feasible with NXT Sensor equipment (Gyroscope is available)

What makes you think, that this is special to the NXT equipment? Any hardware of this type has this sort of problem, I believe.
And it is usually counteracted with clever algorithms, filtering, other heuristics, and whatnot.

[brickbuster]

This was not ment as complaining against NXT sensors in particular. Sorry if it sounded that way.

It is more that Robotics Noobs should use other kinds of sensors (the ones provided with the NXT robot for example) for their first steps.