Usage of the gyro

[Bruce C.]

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:
//members.roadfly.com/weaponeer/Yaw Rate Sensor Logic.doc

All on one line.

Bruce C.

[seanwitte]

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
endselect

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

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.

'constants
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

'initialize
yaw_ct = yaw_ct_base

'start main loop
DO

SERIN...

drive_L = 254		'start right turn
drive_R = 1	

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

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

debug ?yaw_ct		'display count value in debug screen

SEROUT..

LOOP

[KenWittlief]

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

[narenr]

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."

[Caleb Fulton]

Cool! That's great info for future reference...

Thanks!

[Bruce C.]

seanwitte,

Thanks for that bit of code and tutorial. That would certainly be more efficient than the way I started out. My excuse is that I am not a programmer. In fact, my favorite programming language is solder. I got my EE degree when we still designed with tubes. Nowadays I just try to give the students an idea, and let them run with it. Works good that way.

Thanks again,
Bruce C.

[GregT]

Care to listen to my input? Im glad to hear so

The gyro is all fun and good to play with, but quickly becomes unpratical to use as a sort of compass as suggested earlier. Here are my team's reasons for pulling our nav gyro off:

1) Our robot turns faster then the gyro can help us. Why slow your robot down so the gyro can handle the speed?

2) The basic stamp is too slow to use with the gyro by itself. If you have a spiffy custom electronics board you could probably sample it often enough to get reasonable data, otherwise random bumps in the carpet will screw the whole thing up.

3) Dead reckoning is just too dang easy. 10 mins of coding, 5 mins of calibrating and you've got a almost flawless auto routine that is just as good as gyro. "But someone can ram you in auto mode and throw you off" I know, but my guess is you gyro teams would be thrown off just as easily (or possibly worse as a large jolt could confuse the whole system and resulting in your robot doing something very stupid).

My thoughts.
Greg

[Caleb Fulton]

Many teams use external circuits because the BASIC stamp is too slow... Would they really say that it works if it doesn't?

My experience is that the more control the program has over what actually happens the better: dead reckoning, in the "DO THIS, DO THAT, STOP, DO THIS AGAIN" sense does not work with sensitive drive trains/batteries that change motor speeds/etc...

[imjustmatthew]

GregT is right, the Gyro without a custom board is a PAIN. Our core loop runs at about 33Hz and we got reasonably good data of the gyro (at least enough to work with). We simply "smoothed" the gyro data by averaging the last three values we recieved. However Greg is wrong that it doesn't help with dead reckoning, granted without some $@#$@#$@#$@#$@#$@#$@# stuff I don't know how to make our robot can't recover from an impact, we can tell the robot to stop, or shove hard, depending on where it is in operation. We originally had a second gyro, from last years kit, and VCU Regional didn't catch it, but apparently they cost more then $200 each and violate the rules. We were using the second one to detect pitch changes, so like other teams we could detect the spike associated with hitting the top of the ramp. This created a problem with our low sampling rate, until we noticed that the gyro is sensitive enough to get just a little "hang time" after it hits the top at full speed and we can use this to ensure we don't have a false reading. We also got the "Leadership in Control" Award, at VCU regional. Good Luck to all from 638, Operation Oxidation, of the Galileo Divison.

[KenWittlief]

I have to disagree with GregT

of course you cant turn your robot faster than the 75° per second limit of the gyro, and expect to get useful data out of it. Thats one reason we used a V turn instead of a 180° arc in auton mode, if you only need to turn 45° then a half second is not very long.

As for normal steering, you very seldom need to turn your bot faster than that, and if you do, have your closed loop steering selectable with an over-ride button. Having closed loop feedback steering makes the bot INCREDIBALLY more controllable - esp if you are trying to stack boxes, pick up a box...

and we also found it was very difficult to drive our bot up the ramp without closed loop steering - esp when we had two drive wheels and two castors - if you were half way up the ramp and one wheel started to slip a bit, by the time the driver corrected for it, the bot was going sideways

but when we close the loop with the gyro, the bot goes EXACTLY where you tell it to go, no matter WHAT!

as for integrating the signal in SW - 40 samples per second is not enough for you?! I dont understand your reasoning - any machine this heavy cannot change its rate of turn very quickly, certainly not 40 times a second - so the signal that is coming from the gyro is already 'averaged' by the inertia of the robots mass.

We did some playing around with the 'gyro compass' on our bot - we could set a limit so it would not turn past a certan angle in either direction - lets say 360°. You could start the bot out heading north, and spin it all the way around and when it hit 360° it would not turn any further - like it was hitting an invisable wall, then you could spin it all the way around the other way, and it would stop at 360 again - dead on - and you could do this for several minutes with no visable drift in the compass accuracy - it was really cool to play with.

If you were getting noise from the carpet in your signal while trying to use it for steering, then maybe you didnt have it mounted flat. If you mount the gyro angled, then it will respond to motion in two axis instead of the one you want.

I had also read that you need to add external filters and circuits and whatnot to make the gyro 'usable' - we didnt use any, and we had no problems at all. Our closed loop steering was very stable and useful, and our integrated 'compass' heading put our auton V turn dead on 45° every single time.

[imjustmatthew]

KenWittlief, Did you isolate the gyro somehow to reduce vibrations, we had it firmly mounted on one axis and got occasional spikes in testing. we considered trying to isolate the gyro from bumps and golts with some kind of padding, but didn't. Did you guys, or anyone else try this?

[GregT]

So you willingly slowed down your robot so you could use the gyro? Im just trying to say that it's not worth it. Sure it can probably be more accurate then dead reconing, but not more accurate enough to matter. To use it would have slowed down the time it took my team's robot to make it to the top (we can turn faster then the gyro's limit) so we dropped it from our autonomous design.

Its my opinion that the gyro is only useful when something unexpected happens. When something unexpected happens a gyro isn't usually enough to get you back on course. A gyro and a forward speed indicator of some sort would be a competely different sotry, but a gyro by itself is of limited usefulness.

Feel free to argue with me, these are just my opinions.

Greg

[imjustmatthew]

We thought of trying to get a distance base of sorts to work off a drive shaft, using either a magnent or bump and limit switch, but could get it to work. I think that to really be able to recorrect with a gyro you would need a forward speed sensor of sorts, but It seems that any such sensor on the drive train would be subject to an extreme amount of stress from vibration and impacts; at least on our drive train .

[Jared Russell]

We integrate the outputs to get position as well. No need for a custom circuit IMO...the RC was able to get within a fraction of a degree each time.

[Jonathanb]

We used the gyro to make our robot drive straighter and turn smoother.