Usage of the gyro

Did any teams use the gyro this year for a purpose? If so, what for?

We use the gyro as part of our autonomous mode. It is interfaced into our custom circuit board (Motorola HC08 micro) to give us position data along with a rotation sensor on one of our wheels.

… And 111 did very well with it. I’d say using that techology and then the wilddraw interface, they have one of the best autonomous systems out there. :slight_smile:

As with many input devices, it’s a little hard to get them to work a first, but once you’ve got it, they’re awesome.

Our team used the gyro to detect angular changes associated with traversing up the ramp in autonomous mode. That is how our robot knows to stop at the top of the hill after it brings down the tote boxes. When the human player takes control, he is ready to reverse and knock down the remaining stacks.

Team 647 used the gyro in autonomous mode to make nice, consistent turns during auto. We didn’t use any other electronics or custom circuits to integrate the yaw rate for angular position. Instead, we connected the gyro output directly to one of the analog sensor inputs. By doing a little math we determine that by sampling the gyro count each program loop, and accumulating the count in a 16 bit counter, that after 5263 counts we had made a 90 degree right turn. For a left turn we initialized the counter at 10,000 and decremented the count down by the same number of counts. It works very consistently, and doesn’t seem to be very noise sensitive.

After Nats I’ll write up a little paper about how it works.

Bruce C.
Wednesday night, in Houston, looking forward to tomorrow.

647 - excellent - we did the same thing

I hope you also subtracted 127 from the gyro signal each time - to normalize it to zero :c)

team 578 used the gyro for two things - we integrated it like 647 stated, the result is a ‘compass heading’ in a 16bit register.

We also used the gyro signal for closed loop steering. Instead of taking the joystick X signal as the steering command to the motors, we subtracted the gyro output from the joystick X signal.

This told us the difference between what the driver wants the robot to do, and what its actully Doing! We then used this ‘error’ signal to command the voltages to the motors.

This made our robot steer like a giant servo - if you pushed the joystick slightly left, the robot turned left at a very slow and steady rate - if you pushed it hard left it turned left at the max rate of the gyro (about 75° per second)

and the great part - if you are telling the robot to go straight, and something tries to nudge it off course, or a wheel slips on the ramp, then the closed loop feedback corrects the power to the wheels 40 times a second to keep the robot going exactly where the driver commands it too.

We also used it in auton mode - but instead of the joystick X signal, we preprogrammed the direction. the bot stayed on course, no matter what it hit.

This is the first time our team used closed loop feedback for steering - its AWESOME!

for those of you who only speak PBasic, here is our code for closed loop steering - it uses the one joystick code to control the motors. Yaw is the signal from the Gyro (BTW the gyro was upside down on our bot)

'---------- 1 Joystick Drive ---------------------------------------------------------

'********************Gyro yaw rate closed loop steering ***************************
'compairs gyro signal to p1_x steering command to close the steering loop
if p1_sw_top=0 then gyro_override 'when button is pressed then close loop
AD: 'line following code jumps into here
yaw_error = (((2127 + p1_x - yaw) Min 2000 Max 2254)-2000)
yaw_command =(((1873 + yaw_error + yaw_error) Min 2000 Max 2254) -2000)
goto gyro_end


gyro_end: '************************************************************************

’ This code mixes the Y and X axis on Port 1 to allow one joystick drive.
’ Joystick forward = Robot forward
’ Joystick backward = Robot reverse
’ Joystick right = Robot rotates right
’ Joystick left = Robot rotates left
’ Connect the left drive motors to PWM15 and/or PWM16
’ Connect the right drive motors to PWM13 and/or PWM14
'NOTE: p1_x = 0 at full right, 255 at full left

drive_R = (((1873 + p1_y + yaw_command) Min 2000 Max 2254) - 2000)
drive_L = (((2127 + p1_y - yaw_command) Min 2000 Max 2254) - 2000)

and here is the code to use the gyro as a compass heading. angle is a VAR WORD (16 bits) and it should be initialized to 32,000 or some other number in the middle of its range

'update auto_mode time counter and angle integration*********
auto_time=auto_time+delta_t+1 'increment loop counter, including any missed loops
angle=angle+yaw-128 'add yaw sensor reading to angle integration
angle1: if delta_t=0 then angle2 'add yaw againg for eact count of delta_t
goto angle1

The line:

yaw_command =(((1873 + yaw_error + yaw_error) Min 2000 Max 2254) -2000)

contains yaw_error+yaw_error instead of yaw_error+p1_x on purpose, correct? Does it serve only to amplify the corrective measures that it takes when not turning fast enough (or too fast)?

Also: Is the difference between the gyro’s output and 127 a “linear interpolation” from 0 degrees/sec to ~75 degrees/sec?

ALSO also: Have there been any successful implementations of an accellerometer with a FIRST robot?

your interpretation is correct - In technical terms, this is a proportional feedback loop with a gain of two (the errror signal is added twice = 2X gain)

i f your bot is jittery (shakey) with 2X try it with 1X gain instead.

and yes, the yaw sensor is linear from -75°/sec to +75°/S with 127 (or 128) being zero (not turning)

thats why you subtract 128 each time you integrate it - if the bot is not turning then ‘angle’ will stay the same.

PS - dont forget we had our sensor mounted upsidedown on the chassis - if you have the feedback backwards then the bot will go open loop on you (as soon as you tell it to turn a little, it will turn at full speed and not stop until you cross the zero point - not a good thing to do to your drive train).

Thanks for the info!

I’m still not clear on how the output relates to the angular rate…Is it, in fact, linear?

Team 116 also used the gyro. We intigrated it with a PBasic Stamp prossor to take load off the main prosser. It worked very well. In fact in a week or two we will be posting a white paper on the system.

Gunn Robotics Team (192) used the GyroChip as part of their positioning system, I believe. They have some super-awsome custom circuit boards, and won leadership in control in Arizona. They’re in Houston right now, so if you’re in Houston too, be sure to stop by their pit and ask for a tour!

Here’s a quick little description of the method team 647 used to read the gyro and make nice consistent 90 degree turns. It’s a little rough as it’s pieced together from some emails here on my laptop and done here in the hotel room in Houston after practice day. I’ll try to write up something a little more coherent when we get home.

We gave this explanation to our student programmer, and he ran off and started writing autonomous code, and we mentors haven’t caught up with him since!


Bruce C.
Engineering Mentor
Team 647 CyberWolves
2003 Lone Star Regional Winner

Well, that attachment didn’t work. Let me see if I can figure out how to attach a file. If the attachment below doesn’t work, try this: http:
// Rate Sensor Logic.doc

All on one line.

Bruce C.

yaw rate sensor logic.doc (25 KB)

yaw rate sensor logic.doc (25 KB)

The previous post has a small code snippet that shows how they’re summing up the gyro inputs to make the 90 degree turn:

drive_L = 254	' start right turn
drive_R = 1	

select sensor1			'select yaw rate sensor
	case 0 to 127		' turning left
		new_ct = 127-sensor1
		yaw_ct = yaw_ct - new_ct
	case 128 to 255		' turning right
		new_ct = sensor1 -127
		yaw_ct = yaw_ct + new_ct

if yaw_ct > 5262  then	‘count has reached 5262 and passed 90
	drive_L = 127  	‘stop turn
	drive_R = 127

debug ?yaw_ct		'display count value in debug screen

The code in the select statement can be simplified and the case statement eliminated. When the gyro is less than 127 the value of yaw_ct = yaw_ct - new_ct. Since new_ct = 127 - sensor1, the equivalent expression is yaw_ct = yaw_ct - (127 - sensor1), reduced to yaw_ct = yaw_ct + sensor1 - 127.

When the gyro is greater than 127 the expression is yaw_ct = yaw_ct + new_ct, where new_ct = sensor1 - 127. This also simplifies to yaw_ct = yaw_ct + sensor1 - 127.

So the following code will work the same way. I added a deadband around 127 for the gyro so that it doesn’t start adding up noise if the robot is sitting still. If yaw_ct was initialized to zero and some noise creeps in then yaw_ct may underflow and trigger the IF statement. If you initialize yaw_ct to something like 10000 then you can use it for both clockwise and anti-clockwise turns. 15,262 would be to the cutoff turning left and 4738 would be the cutoff to the right.

gyro_deadband 	CON 	4	'gyro deadband
yaw_ct_base	CON	10000	'base value for yaw_ct
yaw_ct_stop 	CON	5262	'yaw counts for 90 degrees

yaw_ct = yaw_ct_base

'start main loop


drive_L = 254		'start right turn
drive_R = 1	

if abs(sensor1-127) > gyro_deadband then 
	yaw_ct = yaw_ct + sensor1 - 127

'stop after turning 90 degrees
if abs(yaw_ct - yaw_ct_base) > yaw_ct_stop then	
	drive_L = 127  	'stop turn
	drive_R = 127

debug ?yaw_ct		'display count value in debug screen



Caleb - yes, the yaw sensor output is linear.

127 is zero degrees per second turn rate

128 is 0.586 degrees per second turn rate

191 is 37.5 degrees per second turn rate

254 is 75 degrees per second turn rate

and the reason its SO EASY to use the signal for a compass heading, is the SW samples the signal at a fixed rate (about 26mS)

so when you add every sample (subtracting 127 first) then you are integrating the signal, turning degrees/second into degrees!

the only difference is its not normalized into units of degrees - it comes out something like 65 counts = 1 degree.

Its a big number, thats why you need a VAR WORD to hold it - and dont forget that PBASIC always does math with 16bit registers anyway so you dont have to do anything special to look for things like

if angle >20000

Our team used the gyro as part of our autonomous mode to tell us when we have turned a full 180 so we would know when to straighten out. We integrated the values and did a bit of scaling to give us angle measurements from the 0-255. This allowed us to better control the “dead reckoning” and make it a little less “dead.”

Cool! That’s great info for future reference…