Thanks for the clarification. That's what I suspect. The RJ connector isn't just for I2C but has analog pins as well. So the inaccuracy isn't the gyro firmware but the NXT firmware because the NXT firmware is the one who reads the raw A/D and translates it to degrees/sec in integer. If that's the case, doesn't NXT have a raw sensor mode (raw value) where I don't tell NXT what kind of sensor it is and just ask for the raw value from the A/D? (The equivalent of SensorRaw[]). I am sorry about being ignorant on the internals of NXT, just curious on how this works.

So you are saying the raw value is in the unit of degrees/sec as an integer in the range of 0-1023? If that's the case, it is a very coarse and inaccurate gyro. (i.e. The gyro resolution is 1 degree/sec). The FRC gyro is spec'd at a resolution of 0.69 degree/sec.

First, it is not the gyro that determines how coarse the readings are. It is the NXT, as it is the NXT that does the conversion to digital values. All analogue sensors on the NXT will have readings between 0 and 1023.

Second. Using values between 0 and 1023 and a unit of degrees a second will tell you The difference between something that is rotating 1000 full circles an hour and something that is rotating at a rate of 10012 circles an hour. Or 1 extra rotation each five minutes. Or speed differences as small as 0,1 %. As minimum and maximum output values are fixed between 0 and 1023 there is a trade of between resolution and range. This goes for all analogue sensors. So the other sensor must have a smaller range

Third. Accuracy has nothing to do with coarseness. If I tell you that one liter of water weights 1 kilogram I am very accurate but nor very precise. If I state it weights 678.321 gram I am very precise but also very wrong. It is up to you to make the gyro accurate by interpretating it's readings well.

Fourth. The 0-1023 scale limits the coarseness of your readings. But this limit is not fixed. If you take the average of more readings you can decrease coarseness.

So stop nagging about this sensor. Try to understand it and it's limitations. Do they really bother you to reach your goals? Or are there other limitations in your system (robot, sensors, software) that bother you first. Then try to solve the problem that bothers you most. I can assure you it won't be the gyro.

Didn't mean to nag . I was just curious on how it works. I have a better picture now.

Thanks.

Tue Dec 07, 2010 1:25 pm

karan.hiremath

Rookie

Joined: Sun Jan 02, 2011 1:57 amPosts: 31

Re: Gyro Senosr

I haven't personally seen any issues with the Gyro sensor... it seems to work perfectly fine for me... i have it doing perfect 90 degree turns with a small buffer (1-2 degrees, based on how well the robot im using turns)

Arguments:target = # of degrees to turnbuffer = # of degrees to buffer +- the target, prevents "wiggle"power = motor power of the turnleftMotor = name of the motor on the leftrightMotor = name of the motor on the rightHTGYRO = name of the Gyroscopic sensor to use

The gyro is working fine for me now because I have written a calibration routine that will determine the bias as well as the noise level so that I can compensate for them. It is running straight and turning perfect 90 for me.

Sat Jan 08, 2011 8:55 pm

karan.hiremath

Rookie

Joined: Sun Jan 02, 2011 1:57 amPosts: 31

Re: Gyro Senosr

I'm using HTGyroStartCal(); to calibrate and as far as determining the noise, could you show how you did this? Sounds interesting

are you basically taking a series of values while sitting still and averaging them? i was thinking of doing that but didn't see a need to. Is there a particular reason you are doing so? I found a buffer to be ideal for the situations we are using them for, as we are also using line tracking which will make us relatively at the right orientation when at the bridge, and then i have the robot align itself to the line across the bridge.

We are using the gyro to calculate our heading. Since gyro gives you turn rate, we need to integrate it against time to get the heading. The gyro noise will cause the integration to cumulate error. In other words, the heading will drift even if the robot is not moving. Therefore, you must determine the noise range and make it into a deadband.

The gyro is an analogue sensor. If you want to know what it looks like on the inside, check out this article on my blog: [LINK]. There is only one chip on there and it's the sensor. It does not use an I2C interface (I know this for a fact because I wrote a driver for it).

Arguments:target = # of degrees to turnbuffer = # of degrees to buffer +- the target, prevents "wiggle"power = motor power of the turnleftMotor = name of the motor on the leftrightMotor = name of the motor on the rightHTGYRO = name of the Gyroscopic sensor to use

This code every time when you call getGyroData() return zero, becouse (currTime - prevTime)==0.And on my robot i have inif loop.

Please remember the NXT can run really fast. nPgmTime has a resolution of 1 msec. This is a long time for the processor. It allows your infinite loop to run multiple times before nPgmTime advances to the next msec. Therefore, when you do integration, you need to add a wait1Msec(LOOP_PERIOD) in your infinite loop where LOOP_PERIOD should be substantially > 1 (e.g. 10 or more).

Thu Dec 20, 2012 5:19 am

zerroTC

Rookie

Joined: Mon Sep 24, 2012 8:32 amPosts: 13

Re: Gyro Senosr

MHTS wrote:

zerroTC wrote:

This code every time when you call getGyroData() return zero, becouse (currTime - prevTime)==0.And on my robot i have inif loop.

Please remember the NXT can run really fast. nPgmTime has a resolution of 1 msec. This is a long time for the processor. It allows your infinite loop to run multiple times before nPgmTime advances to the next msec. Therefore, when you do integration, you need to add a wait1Msec(LOOP_PERIOD) in your infinite loop where LOOP_PERIOD should be substantially > 1 (e.g. 10 or more).

Thanks for information. I concluded that when i strat playing with above code.I can not found a good solution and i am working on that 3 days. If you have code for gyro sensore to navigate the robot with out drifts and errors, i will appreciate it?Thanks.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum