Just wondering if anyone has had any experience or insight into my attempt to use the gyro sensor. What I'm trying to do is use the sensor value to calculate the present angle of rotation of my robot. I'm using the following code to achieve this:



So in the above code fIncline contains what the present angle of rotation of the robot is. I find this works okay, except that after some time of the robot going up and down the calculated value floats from what it should be - I expected this to happen to some level, however it's floating off by up to 5 degrees relatively quickly. I've played a little bit with the nGyroDeltaT value (ranges from 1000 msec to 50 msec). I'll continue to play with this, but I'm just looking for some other insight to this - i.e. if other people have attempted this, how did they do it; or what is a reasonable refresh for the gyro sensor, I think I've read before that the motors only update the encoder value every 70 msec or so... I suspect the gyro sensor is similar - if so, what is the delay?

Lots of questions, any input appreciated.

Thanks!

hi,

semiconductor inertial sensors have quite high noise, offset (bias) and drift values, depending on several factors. if you simply integrate the measured angular speed of a gyroscopic sensor, your result will always drift to some extent. therefore signal processing of inertial sensors always require some kind of compensation and filtering.

complexity of the required filtering depends on the application you want to make. the video on the top right of the robotc homepage shows an application where (I assume) little filtering is required: the person operating the remote control watches the position of the "gun" and automatically compensates any positioning error coming from the noisy reading.

for inertial navigation systems you will need to use complex mathematics with internal state values representing the physical properties of the object (the sensors are mounted on): position, speed, angular speed, acceleration. a quite simplified operation of one of the filtering algorithms:
1. calculate one "new" position, speed, angular speed, acceleration etc of the object based on the previous state values and the control signal (e.g. motor control)
2. calculate another "new" position from the noisy sensor readings.
3. "filtered new" position (speed etc) is a weighted average of the (1) and (2) results; in this case only weights need easy tuning.

Thanks for the reply... I think I understand what your getting at. Let me explain what all this is for, then I'll explain how I'm thinking of approaching it, based on your input. I've developed an autonomous tracked rover that moves around the main floor of my house avoiding any obstacles. One problem I have with the way I've built the rover is that if it starts to climb over something too steep it can tip backwards. I could re-design the robot, but I thought I'd give the gyro sensor a try first.

With this configuration I can't think of any other inputs to use to predict what the estimated angle would be (step number 1 in your algorithm). I suppose if I had access to what the actual power input to the motors is, I could make use of that - i.e. the motors are PID speed controlled so if the robot is going uphill one would expect the PID loop to push more power at the motors, thus giving me some kind of guess at the inclination. Alternatively, the rover is primarily moving about flat, level surface, so the prediction should always be 0 degrees inclination.

Now, perhaps I use 0 degrees as the predicted case and average based on this. Once the gyro does start to drift, then the constant comparing to zero should bring it back a bit. In addition, once the robot does start to climb something - i.e. a dog pillow - then the constant increase in angle should push the average away from zero consistently. I'll never know the "true" angle of inclination, but I'll have a reasonable enough sense of what it is at any time.

I will try this out, however I don't always get much time to sit down and do the programming so in the meantime I just thought I'd spit the thought out and see what people think.

Thanks for the input!

if I understand well you need a "dynamic" information on a quick change in tilt degree. you can then calculate a dynamic baseline for the gyro reading.

Hi Kublai.

Just looking at your posted code i think that you are badly integrating the rotational speed measurement from the gyroscope. Your time step is deltaT but deltaT is not the time elapsed between two consecutive readings because the robot need an additional time to read the sensor value and do the calculation; so try to use as deltaT the time elapsed between each cicle.

Marco.

Hi,

The above is very correct. Use npgmtime to get better time values. I wouldn't make the deltaT too small because then you'll also suffer from noise in the time. Use a waitnsec function to increase the deltaT.

Also, the gyro has the tendency to drift (at least mine does). For this reason I calculate a drift value during start up when my robot is not moving. It is expressed in rot/sec and I use it later on to correct the gyro readings.

Another thing is that errors build up over time. So the longer your program is running the less accurate the calculated angle of your robot is. You can correct your calculations by setting the angle to zero everytime your robot is driving on a flat surface. But there is a problem with that, you cannot use the calculated angle to detect this situation. You must use other information to do so. For example, you could assume that when the robot is moving and its rotational speed is close to zero that it must be on a flat surface.

The method using a predicted and measured value won't work in your situation. This will only work if the predicted value can be based on the robots state. In your case the actual angle (and thus predicted) depends on its surrounding. In other situations it is a very powerfull method.

AFAIK, you'd better use NXT Acceleration / Tilt Sensor (http://www.hitechnic.com/cgi-bin/commerce.cgi?preadd=action&key=NAC1040). This device would exactly fit your needs.

I found this dissertion :

A DISSERTATION
SUBMITTED TO THE FACULTY OF THE GRADUATE SCHOOL
OF THE UNIVERSITY OF MINNESOTA
BY
Byung Hwa Kim
"Reconfigurable computing platform for small-scale resource-constrained robot"

He has this algorithm posted, in RobotC. I played with this.. I had to adjust the battery level parameters a bit, it works very well.

With my rusty differential calculas... I had to dig into it and still trying to fully understand it.