Example gyro code released.

[Kevin Watson]

I've written example gyro interface code and posted it here: http://kevin.org/frc. This code has been substantially revised since the version released earlier with the PID and scripting code. A substantial amount of documentation has also been written to support this code. As the programming interface has changed, this code will not work with the current version of robot.c. An updated version of robot.c will be released soon.

Here's the readme.txt:

The source code in gyro.c/.h contains a driver and supporting
software to interface a variety of inexpensive gyros to your
robot controller. This software was tested with Analog Devices'
ADXRS150EB and ADXRS300EB gyros. Data sheets for these devices
are included. Support for the ADXRS401EB is also included. By
default, this software is configured to work with a ADXRS150EB
gyro, sampling at 400Hz, downconverting to an update rate of
50Hz by averaging eight samples per update. These parameters
can be changed by editing gyro.h.
This software makes the assumption that when it's running, it
solely controls the analog to digital conversion hardware and
that only the gyro, on analog input one, is being sampled.
Calling Disable_Gyro() will disable the gyro software and
allow you to use the ADC for other purposes.
This source code will work with the Robovation (A/K/A EDU-RC)
robot controller and the FIRST Robotics robot controller.
Wiring-up the ADXRS401EB, ADXRS150EB and ADXRS300EB gyro
evaluation boards is straightforward. Grab a PWM cable and cut
off the male end and strip the three wires back a centimeter
or so. With a low wattage soldering iron, solder the white wire
to the RATEOUT pin, solder the black wire to the AGND pin, the
red wire to the AVCC pin, and finally connect a jumper wire
between the AVCC and PDD pins. Plug the female end into the
robot controller's analog input 1.
For optimum performance, you'll need to calibrate the scaling
factor to match that of your gyro's. One way to calibrate your
gyro is to mount it very securely to a hefty, square or
rectangular object. Mounting the gyro to a hefty object will
help dampen higher frequency vibrations that can adversly
effect your measurements. Place the mounted gyro against
another square object and start the included demonstration
software. To get good results, the mount must be absolutely
still when the "Calibrating Gyro Bias..." message appears on
the terminal screen. After a few seconds, the gyro angular rate
and angle will be sent to the terminal screen. If the angle
drifts rapidly while the mounted gyro is motonless, you need
to restart the software to acquire a new gyro bias measurement.
Again, gyros are very sensitive and must be still while the bias
is calculated. Once the gyro is running with little drift,
rotate the mount 180 degrees and note the reported angle. If the
angular units are set to tenths of a degree, the ideal reported
angle is 1800. If set to milliradians, the ideal angle 1s 3142
(Pi times a thousand). For every tenth of a percent that the
angle is high, decrease the GYRO_CAL_FACTOR numerator by one.
Conversly, for every tenth of a percent low, increase the
numerator by one. Repeat until you're satisfied with the
accuracy.
If you find that the Calc_Gyro_Bias() function doesn't do
a good enough job of calculating a bias for your particular
gyro, another option is to average the gyro bias for a much
longer period of time and manually set the gyro bias using
the function Set_Gyro_Bias(). An example that shows how to
do this is commented out in the accompaning user_routines.c/
Process_Data_From_Master_uP(). With a perfectly still gyro,
running this example code will display a running average gyro
bias that should converge to one value over time. Enter this
value into the call to Set_Gyro_bias() and comment out or
remove the call to Calc_Gyro_Bias(). Now perform the gyro
scaling factor calibration described above.
The included project files were built with MPLAB version 6.60.
If your version of MPLAB complains about the project version,
the best thing to do is just create a new project with MPLAB's
project wizard. Include every file except: FRC_alltimers.lib
and ifi_alltimers.lib and you should be able to build the code.
************************************************** **************
Here's a description of the functions in gyro.c:

Initialize_Gyro()
This function initializes the gyro software. It should be called
from user_routines.c/User_Initialization().

Get_Gyro_Rate()
This function returns the current angular rate of change in
units of milliradians per second. If desired, the angular unit
can be changed to tenths of a degree per second by modifying
the angular units #define entry in gyro.h

Get_Gyro_Angle()
This function returns the change in heading angle, in
milliradians, since the software was initialized or
Reset_Gyro_Angle() was called. If desired, the angular unit
can be changed to tenths of a degree by modifying the angular
units #define entry in gyro.h

Calc_Gyro_Bias()
This function forces a new gyro bias calculation to take place.
For best results, this should be called about a half second
after the robot powers-up and while the robot is perfectly still
with all vibration sources turned off (e.g., compressor). It's a
good idea to call this function whenever you know the robot will
be completely still for about twenty-five milliseconds. For
example, call this function just after you've completed a
straight line drive, and just before doing a turn-in-place.

Get_Gyro_Bias()
This function returns the current calculated gyro bias. For
extra precision, this software internally maintains a gyro bias
value that is the sum of GYRO_SAMPLES_PER_UPDATE samples of the
gyro's analog output. By default, GYRO_SAMPLES_PER_UPDATE is
set to a value of eight in gyro.h

Set_Gyro_Bias()
This function can be called to manually set the gyro bias. For
extra precision, this software internally maintains a gyro bias
value that is the sum of GYRO_SAMPLES_PER_UPDATE samples of the
gyro's analog output. By default, GYRO_SAMPLES_PER_UPDATE is
set to a value of eight in gyro.h

Reset_Gyro_Angle()
This function resets the integrated gyro heading angle to zero.

Disable_Gyro()
This function should be called when the gyro functionality is
no longer needed, thus reclaiming the time spent servicing the
timer 2 interrupt.

Initialize_ADC()
This function initializes the analog to digital conversion
hardware. This is called by Initialize_Gyro() above and
shouldn't be called directly.

Initialize_Timer_2()
This function initializes and starts timer2. This is called by
Initialize_Gyro() above and shouldn't be called directly.

Timer_2_Int_Handler()
This function is automatically called when timer 2 causes an
interrupt and shouldn't be called directly.

************************************************** **************
Six things must be done before this software will work
correctly on the FRC-RC:
1) The gyro's rate output is wired to analog input 1.
2) A #include statement for the gyro.h header file must be
included at the beginning of each source file that calls the
functions in this source file. The statement should look like
this: #include "gyro.h".
3) Initialize_Gyro() must be called from user_routines.c/
User_Initialization().
4) The timer 2 interrupt handler, Timer_2_Int_Handler(), must
be installed in User_Routines_Fast.c/InterruptHandlerLow().
See the accompanying copy of User_Routines_Fast.c to see how
this is done.
5) You must select the gyro you're using from a list in gyro.h
and if needed, remove the // in front of it's #define.
6) For optimal performance, you'll need to calibrate the gyro
scaling factor using the instructions above or those included
in gyro.h.

Eight things must be done before this software will work
correctly on the EDU-RC:
1) The gyro's rate output is wired to analog input 1.
2) IO1 must be configured as an "INPUT" in user_routines.c/
User_Initialization().
3) The call to Set_Number_of_Analog_Channels() must configure
at least one analog channel.
4) A #include statement for the gyro.h header file must be
included at the beginning of each source file that calls the
functions in this source file. The statement should look like
this: #include "gyro.h".
5) Initialize_Gyro() must be called from user_routines.c/
User_Initialization().
6) The timer 2 interrupt handler, Timer_2_Int_Handler(), must
be installed in User_Routines_Fast.c/InterruptHandlerLow().
See the accompanying copy of User_Routines_Fast.c to see how
this is done.
7) You must select the gyro you're using from a list in gyro.h
and if needed, remove the // in front of it's #define.
8) For optimal performance, you'll need to calibrate the gyro
scaling factor using the instructions above or those included
in gyro.h.



-Kevin

[Squall]

:yikes:

Thanks a lot! That's all I can say!

:yikes:

[thoughtful]

Nice! good thing we already ordered our gyro :D

Once again thankyou for the great code :D

[Tom Bottiglieri]

How could I use this with the accelerometer?

Does anyone know the sample rate for it?

[Kevin Watson]

Has anyone tried this code yet? I'd like to get a sense of how (if) it's working for teams.

-Kevin

[about_abot]

Has anyone tried this code yet? I'd like to get a sense of how (if) it's working for teams.

-Kevin

Kevin,

First of all, thank you for your undying effort keeping this huge event on track. I just started this year as a programming mentor and do not know the ins and outs of what has happened over the last few years with the code.

The programming student on the team is new, and he is a little anxious with everything. He first saw "C" just a few weeks ago and is feeling a little overwhelmed. I am guiding him through how to layout the functionality he needs to meet the required game rules and translate all of that into working code.

In one of your previous posts, you stated you were working on a new robot.c (and I hope a new robot.h). Do you have any idea when we would see that? Having that will help immensely since my role is to help and not perform the actual work instead of the student doing it himself.

Respectfully,

Gary D.

[Jon236]

Kevin,

Is this the same as the edubot guro code you have on your site?

[Kevin Watson]

In one of your previous posts, you stated you were working on a new robot.c (and I hope a new robot.h). Do you have any idea when we would see that? Having that will help immensely since my role is to help and not perform the actual work instead of the student doing it himself.
As the FIRST folks haven't sent our demobot back for us to test updates on, I'll post the changes (hopefully) sometime this weekend when my team has their 'bot moving around. If you want to make the changes yourself, only two things need to be done to get robot.c to work with the new gyro code:

1) Because I now return angular units expressed in milliradians instead of degrees, line 198 needs to be changed from:

heading = Gyro_Angle()*PI_MRAD/180L;

to:

heading = Get_Gyro_Angle();

2) The programming interface was expanded and many functions were renamed. To fix this, I would just drop the new version of gyro.c/.h into your build directory and let the compiler find the deltas for you (there will only be a few).

-Kevin

[about_abot]

As the FIRST folks haven't sent our demobot back for us to test updates on, I'll post the changes (hopefully) sometime this weekend when my team has their 'bot moving around. If you want to make the changes yourself, only two things need to be done to get robot.c to work with the new gyro code:

1) Because I now return angular units expressed in milliradians instead of degrees, line 198 needs to be changed from:

heading = Gyro_Angle()*PI_MRAD/180L;

to:

heading = Get_Gyro_Angle();

2) The programming interface was expanded and many functions were renamed. To fix this, I would just drop the new version of gyro.c/.h into your build directory and let the compiler find the deltas for you (there will only be a few).

-Kevin

Great! Thank you for your help. I will let you know if we get it to work this weekend.

:-)

Gary

[Kevin Watson]

Kevin,

Is this the same as the edubot guro code you have on your site?Yes, there's a version with demo code for the EDU-RC and one for the FRC-RC. Both have a common source file that will make it fairly easy to use a gyro. By making the modifications to robot.c above, or waiting for me to update robot.c, you'll be able to drop this improved code into the scripting software.

-Kevin

[Kevin Watson]

...I will let you know if we get it to work this weekend.
Cool. I have no idea if people are actually using the code I've published over the last month or so and would very much like feedback on performance, ease of use, etc...

-Kevin

[Tom Bottiglieri]

Kevin, the gyro code has worked fine for us. We are able to track heading, and stick to a heading. We arent using the scripting, for lack of need.

As soon as we get our encoders in, I will post how the PID works out.

[Kevin Watson]

Kevin, the gyro code has worked fine for us. We are able to track heading, and stick to a heading. We arent using the scripting, for lack of need.

As soon as we get our encoders in, I will post how the PID works out.Very cool. Which gyro are you using? Which method are you using to calculate the gyro bias? Calc_Gyro_Bias() or the manual method I described? Are you calculating the bias once at startup or are you actively tracking it with frequent calls to Calc_Gyro_Bias()? Sorry, 'bout all the questions, but I'd like to get a sense of how much drift people are seeing from a larger sample of gyros. I have some serious magic that I can throw at the problem if people can't use their gyros because of too much drift.

-Kevin

[Tom Bottiglieri]

For now, we are using the BEI gyrochip provided in the 2003 kit. This is for testing purposes, seeing as they are illegal for robot use. We are getting gyro bias at startup, with the Calc_Gyro_Bias() function (we plan to poll it more, but we have only done basic tests, seeing how we are learning this as we go). Our gyro use code hasnt really been developed, since we are waiting for our encoder delivery, and we are planning to tackle the PID system all at once. But in our initial tests, we were seeing a bit of drift; The heading would waver about +- 17 milliradians every 8 seconds. (I dont believe we had the scale factor set the right way, seeing as one rotation was giving us a heading of about 10000 mRads.)

In order to keep costs down, I was hoping to use the provided accelerometer in place of a yaw gyro for the bot. Im guesing this would work with the gyro driver you wrote, but is there anything I need to change? (yanno.. something that I would probably never be able to figure out on my own.)

As for the drift, we have explored 2 options. One was to mount the gyro to a piece of foam tape or rubber, hoping it would cut out motor/compressor vibrations. I think the gyro bias is being set incorrectly due to the vibrations, and since for now we are only polling for bias once, it may have ill effect on our code.

Any tips? Thanks.

[Kevin Watson]

For now, we are using the BEI gyrochip provided in the 2003 kit. This is for testing purposes, seeing as they are illegal for robot use. We are getting gyro bias at startup, with the Calc_Gyro_Bias() function (we plan to poll it more, but we have only done basic tests, seeing how we are learning this as we go). Our gyro use code hasnt really been developed, since we are waiting for our encoder delivery, and we are planning to tackle the PID system all at once. But in our initial tests, we were seeing a bit of drift; The heading would waver about +- 17 milliradians every 8 seconds. (I dont believe we had the scale factor set the right way, seeing as one rotation was giving us a heading of about 10000 mRads.)
Yeah, you'll need to set the scaling factor before you know how much drift you're seeing. I didn't think to add the old gyrochip as one of the options in gyro.h, but will look into it.


In order to keep costs down, I was hoping to use the provided accelerometer in place of a yaw gyro for the bot. Im guesing this would work with the gyro driver you wrote, but is there anything I need to change? (yanno.. something that I would probably never be able to figure out on my own.) I've already released TI accelerometer code. Here's the post (http://www.chiefdelphi.com/forums/showthread.php?t=33108). BTW, you can't use the accelerometer to detect yaw. It's great at measuring pitch or roll, though.

As for the drift, we have explored 2 options. One was to mount the gyro to a piece of foam tape or rubber, hoping it would cut out motor/compressor vibrations. I think the gyro bias is being set incorrectly due to the vibrations, and since for now we are only polling for bias once, it may have ill effect on our code.

Any tips? Thanks.Yes, set the scaling factor correctly (I'll try to update gyro.h to include the gyrochip) using the instructions in readme.txt. Then try the manual method I documented in readme.txt (also in gyro.h, I think). I have a ADXRS150EB that, once correctly calibrated, drifts only a few milliradians a minute, which is pretty good.

-Kevin

[neilsonster]

For now, we are using the BEI gyrochip provided in the 2003 kit. This is for testing purposes, seeing as they are illegal for robot use.

Where did you hear they are illegal? Check the Q&A (http://www.usfirst.org/frc/qas/FMPro) under ID 1118:

Q: Can we use Gyros from previous year's kits on our robot?
A: Yes as long as it passes the 2005 Part Use Flowchart and you account for its cost according to the cost accounting rules.


EDIT: Nevermind... I guess the Q&A people didn't look up the price...

[Tom Bottiglieri]

There shouldn't be a problem with you using the gyrochip on your robot.

Sweet, thanks for the info. I was under the impression it was illegal seeing as it was up for sale in a FIRST yard sale.

[Kevin Watson]

Sweet, thanks for the info. I was under the impression it was illegal seeing as it was up for sale in a FIRST yard sale.I've updated the gyro code to include scaling factors for the two different BEI GyroChip gyros that FIRST has included in the KOP in the past. The code can be found here: http://kevin.org/frc.

-Kevin

[CyberWolf_22]

I don't believe that the BEI gyro's are legal because the lowest price I have been able to find them for is approximately $350 which over the $200 price limit for additional electronics. If anyone has seen a gyro for sale cheaper then that, that would follow the vendor requirements that FIRST has laid out please post a link because I have 3 of them sitting in the shop that I would love to use on this years robot.

[kutty18]

I have some serious magic that I can throw at the problem if people can't use their gyros because of too much drift.

Hmmm..Magic?...We tried to calibrate the gyro, but there was too much drift. We mounted it to a square piece of wood, but we still had too much drift. Is there any way to control the drift?

Thanks

[Kevin Watson]

Hmmm..Magic?...We tried to calibrate the gyro, but there was too much drift. We mounted it to a square piece of wood, but we still had too much drift. Is there any way to control the drift?

ThanksWhat kind of gyro are you using? Did you try the manual method that uses Set_Gyro_Bias()? Just make sure the gyro is motionless as the bias is being calculated.

-Kevin

[kutty18]

What kind of gyro are you using? Did you try the manual method that uses Set_Gyro_Bias()? Just make sure the gyro is motionless as the bias is being calculated.

-Kevin

We are using ADXRS300ABG & ADXRS300EB-ND Gyros. Yes we tried the manual method that uses Set_Gyro_Bias()?

[Kevin Watson]

We are using ADXRS300ABG & ADXRS300EB-ND Gyros. Yes we tried the manual method that uses Set_Gyro_Bias()?How much drift are you seeing (you need to calibrate the scaling factor first).

-Kevin

[neilsonster]

I don't believe that the BEI gyro's are legal because the lowest price I have been able to find them for is approximately $350 which over the $200 price limit for additional electronics. If anyone has seen a gyro for sale cheaper then that, that would follow the vendor requirements that FIRST has laid out please post a link because I have 3 of them sitting in the shop that I would love to use on this years robot.

Ok, I just looked into this as well and you're right. The darn things are too expensive! (now we need to buy a new gyro..)

Edit: Actually, on second thought, does anyone know for sure if the fact that FIRST gave it to us in previous years makes a difference?

[kutty18]

How much drift are you seeing (you need to calibrate the scaling factor first)

The values for "rate" and "angle" are empty in the terminal window. Once in a while, "angle" is 0. When we manually set Bias, the values for "rate" and "angle" are gibberish...Also, sometimes, the dreaded "windows fatal error" screen comes up. We have followed the steps that was in the readme.txt file. And no changes to the code were made...except for, changing to the right gyro model #.

[Kevin Watson]

...Also, sometimes, the dreaded "windows fatal error" screen comes up.I think you'll need to find a different windows machine to use before you'll be able to make any progress.

-Kevin

[kutty18]

I think you'll need to find a different windows machine to use before you'll be able to make any progress.

Hey, thanks. We got it to work. We took it to a "quiet" place, and it worked fine. Maybe its those machines that messed it up...

[BradAMiller]

How much drift are you seeing (you need to calibrate the scaling factor first).

-Kevin

We used the code with the ADXRS300 as well and were seeing about 8 degrees of drift over 2-1/2 minutes on a motionless robot. We modified the code to average the bias over more than a single group of samples and increased the sample size to 16 to get the extra precision. That seemed to improve the results.

Can you tell us what you were seeing for drift over time? I just wasn't sure what to expect for results and so we tried these modifications.

Also, I have a question. You're locking the A/D onto Channel 1 to presumably eliminate that acquisition time when switching channels. How much time does actually take (for teams that want more than one analog input)?

And do you know what the conversion time is once the channel is switched?

Thanks again for posting the code.

Brad

[Kevin Watson]

We used the code with the ADXRS300 as well and were seeing about 8 degrees of drift over 2-1/2 minutes on a motionless robot. We modified the code to average the bias over more than a single group of samples and increased the sample size to 16 to get the extra precision. That seemed to improve the results.

Can you tell us what you were seeing for drift over time? I just wasn't sure what to expect for results and so we tried these modifications.
Without actively tracking the bias, you're getting performance that is about what I would expect from a ADXRS300. I'd be pretty happy with a gyro that only drifted a degree over the entire autonomous period. For reference, I have a ADXRS150EB that drifts a degree over about a minute and I tested an old GyroChip that did even better.


Also, I have a question. You're locking the A/D onto Channel 1 to presumably eliminate that acquisition time when switching channels. How much time does actually take (for teams that want more than one analog input)?No, I take control of the ADC hardware because I'm trying to be pretty efficient and not use up a lot of CPU time. You'll notice that in response to the timer interrupt, I read the ADC result register and then immediatly start another conversion. If you used the ADC after my conversion was done, I'd have lost the conversion result the next time the timer interrupt fires off. One way around this is to increase the timer interrupt rate and interleave the ADC measurements.


And do you know what the conversion time is once the channel is switched?I'm sure it's considerably less time than the timer interrupt period, but I don't know the exact value. The data sheet would be a good document to consult for this information.

-Kevin

[Tom Bottiglieri]

No, I take control of the ADC hardware because I'm trying to be pretty efficient and not use up a lot of CPU time. You'll notice that in response to the timer interrupt, I read the ADC result register and then immediatly start another conversion. If you used the ADC after my conversion was done, I'd have lost the conversion result the next time the timer interrupt fires off. One way around this is to increase the timer interrupt rate and interleave the ADC measurements.
-Kevin
Is it possible for us to use the ADC for say.. another gyro?

[Kevin Watson]

Is it possible for us to use the ADC for say.. another gyro?Yes, but why would you?

-Kevin

[agentfat2004]

Kevin

I am a member of team 335 and one of 2 programmers. I have only been programming for a year and hardly know C(only know what i have read in Books).
I was wondering how to use the cmu camera and the gyro together for locating and directing a robot during the 15s. here is the desired algorithm

field [1/2 field length][1/2 field width]
Initilize camera
Track_color(green)
move_to_green()
Map_position_to_array

[CyberWolf_22]

I had a question similar to Tom's in that by using another gyro not to measure heading, but instead use it as tip sensor. Also I would like to use the accelerometer(instead of quadrature encoders) in autonomous mode which with the locking of the ADC I can't do that.

[Kevin Watson]

I had a question similar to Tom's in that by using another gyro not to measure heading, but instead use it as tip sensor. The accelerometer is the sensor of choice to measure pitch or roll. The gyro code can be modified to interleave gyro and accelerometer measurements.


Also I would like to use the accelerometer (instead of quadrature encoders) in autonomous mode which with the locking of the ADC I can't do that.The encoders are a far better choice to measure distance than an accelerometer.

-Kevin

[Kevin Watson]

I was wondering how to use the cmu camera and the gyro together for locating and directing a robot during the 15s. Yeah, a lot of people want to use the scripting code with the camera code. I started on the merge a few days ago and can't really estimate when it'll be done because I don't yet fully understand what the camera code is doing. That coupled with camera code that's sprinkled throughout the default code instead of being confined to one source file makes the merge a bit of a headache.

-Kevin

[russell]

Wait.... You are going to make it so we can use that scripting stuff to control the robot with the camera? If so then that is absolutely the best news I have ever heard :yikes: :ahh: :D :) . I wish the default camera code was designed more for autonomous operation, rather than with a joystick and such. It would have saved me a lot of trouble.

[Kevin Watson]

Wait.... You are going to make it so we can use that scripting stuff to control the robot with the camera? If so then that is absolutely the best news I have ever heard :yikes: :ahh: :D :) . I wish the default camera code was designed more for autonomous operation, rather than with a joystick and such. It would have saved me a lot of trouble.Don't start celebrating yet. I haven't a clue if we can get this working.

-Kevin

[CyberWolf_22]

When I said using the accelerometer instead of quadrature encoders I meant to that it would be used along side the gear tooth sensors so that my team does not have to pay for the quadrature encoders they can use what is given in the kit. The accelerometer would only be used to integrate to velocity not position so that the teams could use only the sensors provided in the kit and have a little more knowledge of where there robot was going on the field.

[neilsonster]

I am having a bit of a problem with the gyro code at least I think I am... just to test out the gyro (a BEI Gyrochip ARQS-00075) I plugged it in and downloaded the code (edit: the newest frc_gyro code), and in the Terminal window for the Gyro Angle's output the value just keeps increasing infinitely. When I unplug the gyro while this is running it starts to decrease infinitely. To make sure the gyro was working I just tried doing an output of the analog value and it seemed to be fine. Any ideas? (sorry I don't have more exact information, I don't have all the hardware at my house!)

[Kevin Watson]

I am having a bit of a problem with the gyro code at least I think I am... just to test out the gyro (a BEI Gyrochip ARQS-00075) I plugged it in and downloaded the code (edit: the newest frc_gyro code), and in the Terminal window for the Gyro Angle's output the value just keeps increasing infinitely. When I unplug the gyro while this is running it starts to decrease infinitely. To make sure the gyro was working I just tried doing an output of the analog value and it seemed to be fine. Any ideas? (sorry I don't have more exact information, I don't have all the hardware at my house!)I doesn't sound like you read the readme.txt file.

-Kevin

[marccenter]

Is the BEI gyro really illegal to use? I am a rookie engineer this year and see that Kevin Watson has included configuration for it in his navigation code. Our team coach handed me the sensor, from last year's kit, and I have begun wiring it in. IF illegal, why? I saw that the BEI gyro can be purchased on the web. Wouldn't a team just
count it's price in the electronics price of it's parts or is there some rule about past electronics parts. It seems awfully silly to have to not be able to reuse last year's electronic parts.

[Kevin Watson]

Is the BEI gyro really illegal to use? I am a rookie engineer this year and see that Kevin Watson has included configuration for it in his navigation code. Our team coach handed me the sensor, from last year's kit, and I have begun wiring it in. IF illegal, why? I saw that the BEI gyro can be purchased on the web. Wouldn't a team just
count it's price in the electronics price of it's parts or is there some rule about past electronics parts. It seems awfully silly to have to not be able to reuse last year's electronic parts.No one seems to know what dollar amount to assign to the BEI gyro. I fired-off an e-mail to the FIRST engineering staff seeking clarification, but haven't gotten a reply (I suspect they're kinda busy <grin>).

-Kevin

[Joe Ross]

No one seems to know what dollar amount to assign to the BEI gyro. I fired-off an e-mail to the FIRST engineering staff seeking clarification, but haven't gotten a reply (I suspect they're kinda busy <grin>).

I asked for a quote direct from systron, and this is the respons I got:

Dear Mr. Ross:

Thank you for your interest in Systron Donner Inertial Division. The cost
for qty 1 AQRS is $325 each. Please note that Systron Donner has a $500
minimum order policy.

I have attached a data sheet for the LCG50. These units run $198 each for
qty 1-3.

Please let me know if I can be of further assistance. I will be happy to
provide a formal quotation.

Have a great day!

Sincerely,

Adrienne Warren
Marketing Coordinator
Systron Donner Inertial Division
(925) 671-6699 PH (925) 671-6647 FAX
awarren@systron.com
Website: www.systron.com

[Kevin Watson]

I asked for a quote direct from systron, and this is the respons I got...Okay, the semi-official, over-the-back-fence reading I got on the subject is that the BEI GyroChip gyro cannot be used if you purchase it new. It can, however, be used if you can find a source that will sell you a "used" one for less than $200. I suppose that if a team, for fundraising purposes, sold one of their gyros to a parent for anything less than $200 and that parent donated the gyro back to the school that would be kosher. Teams might also consider selling gyros to other teams. These are very nice gyros and I would really like to see teams use 'em instead of letting 'em collect dust next to the pile of broken drill motors in the storage cabinet.

-Kevin

[dlavery]

Okay, the semi-official, over-the-back-fence reading I got on the subject is that the BEI GyroChip gyro cannot be used if you purchase it new. It can, however, be used if you can find a source that will sell you a "used" one for less than $200. I suppose that if a team, for fundraising purposes, sold one of their gyros to a parent for anything less than $200 and that parent donated the gyro back to the school that would be kosher. Teams might also consider selling gyros to other teams. These are very nice gyros and I would really like to see teams use 'em instead of letting 'em collect dust next to the pile of broken drill motors in the storage cabinet.

-Kevin

Be careful about trying to get around the accounting rules by "selling" last year's used BEI gyro to a team member and selling it back to your (or another) team. See rule <R19>.

-dave

[Kevin Watson]

Be careful about trying to get around the accounting rules by "selling" last year's used BEI gyro to a team member and selling it back to your (or another) team. See rule <R19>. Dave,

How is it that you never seem to sleep, yet function as a (pretty) normal person who manages to keep the entire FIRST manual in your head <grin>?

Here's R19:

"<R19> Individual COMPONENTS retrieved from previous robots and used on 2005 robots must have their undepreciated cost included in the 2005 robot cost accounting, and applied to the overall cost limits."


Two things come to mind: 1) There are lots of BEI gyros around that have not been "retrieved from previous robots" and 2) Who knows what the undepreciated value of the BEI gyros is? FIRST certainly didn't pay >$200 for each one. If you can establish a value by purchasing one "used", I don't see a problem. Here's Q&A #1318:

Q:From ID 1118: The Gyros from previous year's kits appears to cost $300USD and therefore exceeding <R44> limit of $200USD for electronic components. (http://fastascent.com/Projects/Attitude_Control/Rate_Gyro_s/rate_gyro_s.html)

A:If that is the price, clearly R44 excludes them from being used. Find a used BEI gyro or find a cheaper gyro of another brand.



Here, the FIRST folks are clearly giving the okay to use one that is "used".

-Kevin

[Joe Ross]

Kevin, even if it is donated, it must be accounted for at the fair market value (section 5.3.4.4). Also, the person you purchase it from must meet the qualifications of a VENDOR (section 5.2), meaning they must have a federal tax id and must make their products availible to all FIRST teams.

I don't beleive your scenario meets any of these qualifications.

When FIRST says it's ok to get it used, I beleive you still have to get it per the other rules.

Question 1352 will hopefully clarify this.

ID: 1352 Section: 5.3.4.4 Status: Unanswered Date Posted: 1/25/2005
Q: I'm trying to clarify 5.3.4.4 and the answer to quesion 1318. Are there restrictions to buying used parts and accounting for the used price? Does the seller still have to meet the requirements of a VENDOR? Anything else we should know?

[Kevin Watson]

Kevin, even if it is donated, it must be accounted for at the fair market value (section 5.3.4.4). Also, the person you purchase it from must meet the qualifications of a VENDOR (section 5.2), meaning they must have a federal tax id and must make their products availible to all FIRST teams.

I don't beleive your scenario meets any of these qualifications.

When FIRST says it's ok to get it used, I beleive you still have to get it per the other rules.

Question 1352 will hopefully clarify this. "...section 5.3.4.4..."? "...must have a federal tax id..."?!? When I start to feel like I should call the family lawyer to get a ruling on something, I quickly lose interest in the proceedings. I'm gonna go back to my corner and write some more code...

-Kevin

[Jon236]

Kevin

Is there any reason why the edubot encoder code from your website won't work with the Hall effect sensors?

Jon

[marccenter]

Has anyone tried this code yet? I'd like to get a sense of how (if) it's working for teams.

-Kevin

Kevin,
I have tried the ADXRS300EB and the BEI gyrochip AQRS-0075-xxx
(two different units) with some problems.
I have measured a nominal 2.5 volts for both sensors and when
physically swinging both gryo's in opposite directions see the voltage
swing up/down as expected. So, from a gross standpoint, gyro's are
operational.
The software outputs a gyro bias of 4144? When, I swing the
gryo 180 degrees in one direction, slowly, and return to zero I cannot
get the gyro to indicate zero.
Have set #define to ADXRS300EB setting and #define to AQRS0075
and played with scaling factor without success.
Turned out long term Bias calculation - close to short term bias.
After powering up and gyro reading 0 degrees for 4 or 5 samples,
I swing the gryo 180 degrees slowly and return to zero.
Any suggestions, Kevin.

BTW, I really believe the ADXRS300 EB scaling is not 5 mv /degree/sec
but 7.5 mV/degree/sec. Plus/minus 300 degrees over 4.5 volt range,
is 300 degrees over 2.25 volt range (2.5 to 4.75 or 2.5 to 0.25 volts).
or 2250 mV/300 degrees which is 7.5 mV/deg.

Scaling for Plus/Minus 75 degrees/ second is 30 mV/deg/sec
Scaling for Plus/Minus 150 degrees/second is 15 mV/deg/sec
scaling for plus/minus 300 degrees/second is 7.5 mV/deg/sec

[Kevin Watson]

The software outputs a gyro bias of 4144?
To gain a few extra bits of precision, I oversample the analog output by a factor of eight and maintain that precision throughout all calculations. The bias should be around 8*512=4096. Sample rate and number of samples per update are both configurable by changing a few #defines in gyro.h.


When, I swing the gryo 180 degrees in one direction, slowly, and return to zero I cannot get the gyro to indicate zero.
How far from zero is it?


Any suggestions, Kevin.
Yes, just for grins, run the sampling rate up to 1600Hz and change the samples per update to 32 and try again. I've found it helpful to use a pushbutton(s) to force a bias calculation and/or heading angle reset. This code in the 38Hz control loop will do this for you:


static unsigned char old_io3_state = 1;
static unsigned char old_io4_state = 1;

// did user just push the bias calculation button?
if(rc_dig_in03 == 0 && old_io3_state == 1)
{
Start_Gyro_Bias_Calc();
printf("Calibrating...\n");
}

// did the user just release the bias calculation button?
if(rc_dig_in03 == 1 && old_io3_state == 0)
{
Stop_Gyro_Bias_Calc();
Reset_Gyro_Angle();
}

// did user just push the reset button?
if(rc_dig_in04 == 0 && old_io4_state == 1)
{
// reset the gyro angle to zero
Reset_Gyro_Angle();
}

// save the current button states
old_io3_state = rc_dig_in03;
old_io4_state = rc_dig_in04;



BTW, I really believe the ADXRS300 EB scaling is not 5 mv /degree/sec but 7.5 mV/degree/sec. Plus/minus 300 degrees over 4.5 volt range, is 300 degrees over 2.25 volt range (2.5 to 4.75 or 2.5 to 0.25 volts).
or 2250 mV/300 degrees which is 7.5 mV/deg.

Scaling for Plus/Minus 75 degrees/ second is 30 mV/deg/sec
Scaling for Plus/Minus 150 degrees/second is 15 mV/deg/sec
scaling for plus/minus 300 degrees/second is 7.5 mV/deg/sec
Nope. It's 5.0 (+/- 0.4) mV/deg/sec.

-Kevin

[marccenter]

How far from zero is it?

-Kevin

Kevin, downloaded your new 01/30/05 code and everything seems to work right now. Bias was 32382. (512 * 64 samples per update = 32768)
32768(2.5 volts) -32282(Bias)=486. 486/64 = 7.59 a/d counts * 5 mV/count = 38 mV above 2.50. Null bias should equal 2.538 volts. Verfied with DVM. Hooray!
Sampling rate was 1600 Hz, samples per update
rate set to 64, ADXRS300EB utilized, #define TENTHS__OF_A_DEGREE.
#define GYRO_CAL_FACTOR = 1000/1000 (no change).

Simple 180 degree spin test executed. Learn bias at 0 degrees, verify
for 4/5 readings on terminal that angle = 0 degrees. Next, spun gyro 180 degrees - reading about 900 counts (90 degrees * 10 counts/degree).
Return to 0 degree position - read 0 counts (plus/minus 30 - remember,
very coarse test).

Next, tried the GEI GYROCHIP AQRS_00075. Changed the #define GYROCHIP_75 at top of gyro.h. Same spin test gave similiar results. Spun
360 degrees and back - similiar results. Sampling rate 1600 Hz, samples per update rate equal 64, #define TENTHS_OF_A_DEGREE, #define GYRO_CAL_FACTOR = 1000/1000 (no change).





Yes, just for grins, run the sampling rate up to 1600Hz and change the samples per update to 32 and try again.

-Kevin

Kevin,
Did you work some new magic in the new 01/30/05 software release, or do
you think the 1600 Hz, samples = 64 is what made this work? I did not
have time last night to experiment with various settings. I tried the
01/22/05 software and found my head bloody from beating it against the
wall to make it work. BTW, thanks for responding to previous e-mail and
publishing 01/30/05 release.

[Kevin Watson]

Did you work some new magic in the new 01/30/05 software release...
No, not really. In the earlier code/readme.txt, I documented a way to integrate the bias over a longer period of time and then set the bias using Set_Gyro_Bias(). The latest code just automates this process. The real magic will come when I get a Kalman Filter integrated into the code.


...or do you think the 1600 Hz, samples = 64 is what made this work?
Probably both. The new code, out-of-the-box, does a much better job of calculating the bias. Sampling at a higher frequency and down sampling with more samples also helps. I'd advise setting the sample rate to be as low as possible while still getting the performance you need.

-Kevin

[neilsonster]

Hi, I just wanted to let you know we implemented your code with the ADXRS300EB last weekend and it has been performing *perfectly* all week. Thanks for the excellent work :). Now the camera is another story....

[Kevin Watson]

Hi, I just wanted to let you know we implemented your code with the ADXRS300EB last weekend and it has been performing *perfectly* all week. Thanks for the excellent work :).
Cool!


Now the camera is another story....
Well, as Nietzsche said: That which does not kill us, makes us stronger <grin>.

-Kevin

[Mark McLeod]

Well, as Nietzsche said: That which does not kill us, makes us stronger <grin>.

Isn't Nietzsche dead?;)

[Kevin Watson]

Isn't Nietzsche dead?;)
Yeah, but I doubt it was the camera that did him in <grin>.

-Kevin

[ak_Knight]

Hi,
i used your gyro code with a ADXRS300. The user_routines.c executes pretty good, the gyro bias is mostly stable there is almost no change in angle. But the autonomous mode is giving us a lot of trouble. I am trying to accomplish two tasks, one give robot an angle and have to turn, like turn(90) and it should turn 90 degree, The other thing is being able to go in a straight line with out drifting. But after about 2-3 seconds in the autonomous i encounter an runtime error( the program state starts blinking red). Here is my user_routines_fast.c please take a look and help me out. :)


void User_Autonomous_Code(void)
{
/* Initialize all PWMs and Relays when entering Autonomous mode, or else it
will be stuck with the last values mapped from the joysticks. Remember,
even when Disabled it is reading inputs from the Operator Interface.
*/
pwm01 = pwm02 = pwm03 = pwm04 = pwm05 = pwm06 = pwm07 = pwm08 = 127;
pwm09 = pwm10 = pwm11 = pwm12 = pwm13 = pwm14 = pwm15 = pwm16 = 127;
relay1_fwd = relay1_rev = relay2_fwd = relay2_rev = 0;
relay3_fwd = relay3_rev = relay4_fwd = relay4_rev = 0;
relay5_fwd = relay5_rev = relay6_fwd = relay6_rev = 0;
relay7_fwd = relay7_rev = relay8_fwd = relay8_rev = 0;

while (autonomous_mode) /* DO NOT CHANGE! */
{
if (statusflag.NEW_SPI_DATA) /* 26.2ms loop area */
{
Getdata(&rxdata); /* DO NOT DELETE, or you will be stuck here forever! */

/* Add your own autonomous code here. */

if (counter < sec(2) )
{
move_Forward();
}
else if( counter < sec(4) )
{
pause();
}
else
{
turn_Right(200);
}

counter++;

Generate_Pwms(pwm13,pwm14,pwm15,pwm16);

Putdata(&txdata); /* DO NOT DELETE, or you will get no PWM outputs! */
}
}
}

/************************************************** *****************************
* FUNCTION NAME: Process_Data_From_Local_IO
* PURPOSE: Execute user's realtime code.
* You should modify this routine by adding code which you wish to run fast.
* It will be executed every program loop, and not wait for fresh data
* from the Operator Interface.
* CALLED FROM: main.c
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/
void Process_Data_From_Local_IO(void)
{
/* Add code here that you want to be executed every program loop. */

}

/************************************************** *****************************
* FUNCTION NAME: Serial_Char_Callback
* PURPOSE: Interrupt handler for the TTL_PORT.
* CALLED FROM: user_SerialDrv.c
* ARGUMENTS:
* Argument Type IO Description
* -------- ---- -- -----------
* data unsigned char I Data received from the TTL_PORT
* RETURNS: void
************************************************** *****************************/

void Serial_Char_Callback(unsigned char data)
{
/* Add code to handle incomming data (remember, interrupts are still active) */
}



/************************************************** ****************************
/USER FUNCTIONS/
************************************************** ****************************/


/************************************************** ****************************
* FUNCTION NAME: move_Forward, move_Backward, pause
* PURPOSE: Routine handling (name speaks for it self)
* CALLED FROM: user_routines_fast.c
* ARGUMENTS: none
* RETURNS: none
************************************************** ****************************/
void move_Forward(void)
{
set_Right(160);
set_Left(94);
}

void move_Backward(void)
{
set_Right(94);
set_Left(160);
}

void pause(void)
{
set_Right(127);
set_Left(127);
}

void set_Right(int value)
{
pwm13=value;
pwm14=value;
}

void set_Left(int value)
{
pwm15=value;
pwm16=value;
}

/************************************************** ****************************
* FUNCTION NAME: sec
* PURPOSE: Handles the program loop so that we work in terms of seconds.
* CALLED FROM: user_routines_fast.c
* ARGUMENTS:
* Argument Type Description
* -------- ---- -----------
* number_of_seconds int The amount of seconds to be converted
* RETURNS: INT
************************************************** ****************************/
int sec( int number_of_seconds)
{
return number_of_seconds*38;
}




void turn_Right(int angle)
{

int temp_gyro_rate= Get_Gyro_Rate();
int temp_gyro_bias= Get_Gyro_Bias();
int temp_gyro_angle = (int)Get_Gyro_Angle();

if ( ((int)Get_Gyro_Rate) > angle)
{
Reset_Gyro_Angle();
}

while( temp_gyro_angle < angle )
{
set_Right(160);
set_Left(127);

temp_gyro_rate= Get_Gyro_Rate();
temp_gyro_bias= Get_Gyro_Bias();
temp_gyro_angle = (int)Get_Gyro_Angle();

printf("Gyro Bias=%d\r", temp_gyro_bias);
printf("Gyro Rate=%d\r", temp_gyro_rate);
printf("Gyro Angle=%d\r", temp_gyro_angle);
printf("Gyro Required Angle=%d\r", angle);
printf("--------------%d\r");

}
}

[marccenter]

Kevin,
I tried working last night with all three gyros and none worked
like the last time. So, first time was bad. Second time was like
a good dream. Third time was bad again.

Gryo angle had drift and bias reported unusual numbers. Voltmeter
on output agreed with gyro angle drift output. I can't remember
the number right now (like 3.0 volts). At one point I measured
a solid 4.98 volts powering one of the gyro's over the PWM
cable.

Same laptop. software, gyros, FRC controller -- the works.

Has there been any reported FRC_Board sensitivity to electical noise
like issues? Should I be extra careful with noise sources? Should
I get away from using A/d channel 01?

I didn't have any caps to place on output to see if that would help
to stabilize the gyro output. Will all three gyros flaky performance,
however, I am leaning away from viewing the gyro's as the problem
but the FRC controller.

Have you tried same software on multiple platforms yourself and/or
seen strange problems like this on FRC controllers?

I hope some of the high school student's end up reading this thread
so that they can see how difficult it can be to make what seems to
be something simple work properly.

[marccenter]

Follow up to previous message.

I went home to try the gyro software on a new controller.
So, same software, gyro, different FRC controller.
Gyro operational again. Rotate 180 degrees and get
1800 on display. Return slowly to 0 degrees, get
0 on display. No gyro drift.

I suspect some funny issues with the FRC controller
that we are using in our old robot. When I get a chance,
I will power up the 2005 FRC controller and see what
happens with the gyro.

I will continue to explore different angles as to the reason
for the differing results and update this message accordingly.

[Code\\Pilot]

This may seem like a weird question, but oh well... How do you wire the BEI AQRS-0075-FIRST gyrochip?
I read the readme but it only gives instructions for wiring other gyros. I suppose you need to wire the white cable to rate out pin1, the ground black wire to common pin2, and the red wire to +5 VDC input pin3. I think that is how it goes, but i just want to make sure is right before i blow something out. Any quick reply will be greatly appreciated.
Thanks.