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. :)

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_override:
yaw_command=p1_x

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
angle=angle+yaw-128
delta_t=delta_t-1
goto angle1
angle2:

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?

Gyro
 

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

All on one line.

Bruce C.

previous post
 

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

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.

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

Thanks!

Thanks
 

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.

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

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

We used it too
 

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.

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.

Did you isolate the gyro?
 

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?

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

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 :) .

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.

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

GregT - you need to go back and look at the Team 578...physics lesson photo again.

yes we slowed the turning part of our V-turn down enough to stay closed looped with the gyro

and we beat you to the wall

anytime you use feedback you must run 'slower' than the systems top speed - otherwise you have no room / margin for making corrections.

We could have made our auton mode even faster if we wanted to. We had the bot going back to the center of the field before making its 45° turn - and we also had the motors running at less than half speed while going backwards AND while turning.

We didnt have a full sized ramp to practice on, and we couldnt get enough carpet time at the events to adjust it any finer. If we had added a wheel revolution counter then we could have backed up until we barely cleared the ramp side wall, then turned just enough to start going forwards, continuing to turn as we climbed the ramp.

Feedback is like magic in engineering. You can take a sloppy, loose system and make it as fast, accurate and precise as you want by using feedback. MUCH easier to do than to try to build a system (bot) that is accurate and precise all by itself and let it run blind (open loop).

I forgot to mention:

DO NOT SHOCK MOUNT YOUR GYRO!

you dont want it padded from the frame - you want it firmly mounted so it moves exactly as the frame moves. If the gyro is wobbling around or is acting like its mounted on springs, then your feedback system is going to be wacked out!

also make sure you mount it on the most solid part of your frame, not anyplace that bends or twists when the bot is in use.

the gyro already has an internal bandwidth limit (filtering) so random impacts and vibrations will be averaged out over time - if something hits your bot so hard that it accelerates faster than 75°/S then you need to put bumpers on your ROBOT! - not on your gyro :c)

An extension to that:

Mount the gyro as low as possible to the ground to reduce jitter (vibrations are more exaggerated on taller superstructures).

I got the gyro hooked up, but I'm having a slight problem; when the robot is sitting still, the gyro reads 129 or 130...not 127...

Is there any way to "reset" it?

It is sitting at a slight angle because the robot itself is angled...would this cause the problem?

the gyro will only change its output when you turn on its axis of rotation

so when its sitting still, whatever it puts out is 'zero'

I suggest you have your SW read the gyro when the robot is first powered up, and use that reading (whatever it is) as your zero

also, you might want to code in a dead band, to ignore zero-1, zero, zero+1 when you are integrating the output

then the compass heading you are creating will not drift when the bot is not turning.

This is normal, and no there's not a way to reset it. Every gyro that we've examined here has it's own "normal" center value. I've also been told that some teams have seen the gyro have a different center value each time it's powered up, although I didn't see this myself.

To combat this problem, we had our custom circuit take 256 samples from the gyro on powerup and average them to determine it's center value. Worked perfectly. One word of caution if you try this: when the gyro first receives power, it's output will be all over the place for a few seconds, so you don't want to take these samples right away when your robot is powered up. Our custom circuit had a 4 second delay before reading the gyro and it worked great.

How did you guys find out the sampling rate of the RC? I'll trust that it is in fact 26 ms, but is there a data sheet somewhere, or does it depend on the size of the main loop of the program?
Thank you
-Bobby Sakurai

It's stated in the kickoff presentation by Bob Mimlitch on the FIRST website under Team Resources & Kickoff Workshop Archive.

I believe it's based on the radio packet transmission rate and is imposed by the IFI implementation of the Robot Controller, not the Basic Stamp itself.