Kevin Watson's Kick-off Demo Code! [Archive]

View Full Version : Kevin Watson's Kick-off Demo Code!

Mr. Lim

10-01-2005, 10:17

Squall

10-01-2005, 19:39

I'm trying to find out what Gyro he used, or if it isn't the acelerometer

My team is gonna buy two Encoders, we just have to adjust the code so that it can work with our Encoders and we need to find out what's the gyro we need

Squall

11-01-2005, 10:29

Hey, I've email kevin with this question and he answered :

"The software should work with quite a few gyros. We
used one made by Silicon Sensing Systems, but you
should be able to use the popular Analog Devices
ADXLS150 or ADXLS300 gyros too by modifying
the GYRO_RATE_SCALE_FACTOR and
GYRO_ANGLE_SCALE_FACTOR #defines in
gyro.h. We used two Grayhill 61K128 encoders on
the gearbox output shaft."

I think that this info can be of use to a lot of teams, and this way we don't have to botter Kevin so much asking the same question.

russell

11-01-2005, 10:51

Is there not a gyro included in the kit?

Squall

11-01-2005, 11:02

No, the sensor that's included in the kit is the accelerometer, it's similar but it's not the same thing.

The accelerometer gives you the instant acceleration, and the gyro gives you the angular velocity.

CJO

11-01-2005, 15:32

P.S. I have re-posted this as a new thread here (http://www.chiefdelphi.com/forums/showthread.php?p=317501#post317501).

I have not had a chance to e-mail Mr. Watson yet, however, trying to integrate the Camera control system into the scripting code is becoming a real nightmare. The difficulty is in the serial port driver. The problem as I see it is thus:

1) There are really three different serial port drivers, they are:a) usr_SerialDrv.c
b) serial_ports.c
c) PicSerialDrv.c
"a" is the defaut FRC driver, no need to worry about it just delete it. "b" is Mr. Watson's serial port driver, allowing LCD screens and printf functions from the FRC controller. "c" is the serial port driver which comes with the camera. "b" and "c" really do most of the same things, put are not intrinsically compatible. My immediate solution is to call some parts of "b" from within "c," thereby leaving the camera driver intact and just adding certain functionality from the seril ports driver. Problem is, in even limited testing on the controller it has been doing some really weird things.

2) What the is the "Dynamic Debug Tool?" This phrase was included in the camera software. In the PicSerialDrv.c file there was this comment: This file contains an unsupported serial device driver for the 18F8520 micro. It was designed to be used with the Dynamic Debug Tool (DDT). The DDT is now apart of the IFI Loader (ver 1.8 or later) under the 'Options' menu. The DDT can be used to directly read and modify memory locations and registers of the user processor dynamically. The camera quick start guide specifies the the PicSerialDrv.c as a required file. Furthermore, the PicSerialDrv.c specifies that : You can put your own callback routine inside CheckUartInts. This will allow you to parse data from another device in real time. So, in fact, this is where I called Mr. Watsons code. The problem is, that the two drivers seem to be trying to do different things with the ports.

3) While trying to use interrupts (a switch attached to one of the digital ports) and the camera software at the same time, the controller keeps resetting itself, for no reason which I can identify.

4) Building on #3, the camera has what is esentially a state machine servicer (for lack of a better term) built into it; that is, calling camera_track_update() will tell you whether or not the camera has been successful in updating and tracking to a new position. To my mind, this should be handled almost like an interrupt, that is, when it returns 1, the camera track code is executed, but in the code provided, it sits in user_routines_fast in the sutonomous section, and simply says: if(camera_track_update()==1)
tracking = 1;
trakcing code
else
tracking = 0; So, if I understand it correctly, what it is really doing is sitting in the autonomous space and waiting for an update. Is this really the best way to do this?

5) Finally, the camera needs to be calibrated before use. This is done by hooking a PC up to the camera and running a JAVA script program to get exposure values. You then have to send these values to the camera in "User_Initialization()" by including the line camera_init ( yellow exposure, green exposure, red exposure ) The drawback to this is that it requires re-compiling and loading the code. Is there a way to set it so that you could use onboard switches to change the state of the exposure values without having to re-load the code? My only thouught so far was to have a pair of pushbuttons attached to the operator interface, and after pressing some button combination, the display byte gets set to the currently selected value and then the two buttons increment it up and down.

Kris Verdeyen

11-01-2005, 16:13

vtrehan

11-01-2005, 16:29

The CRS03-02 gyro "puck" costs $299 from newark: http://www.newark.com/NewarkWebCommerce/newark/en_US/endecaSearch/searchPage2.jsp?specialorder=on&Ntt=93C9882&newSearch=true&Nto=93C9883+&Nty=1&N=0&Ntk=gensearch

That's over the $200 / part limit.
If someone knows of a distributor that sells the chip itself for less, please post it.

You can use the ADXRS300 from Analog devices, it costs arround $50 and can be used with Mr.Watsons code. Heres the link, http://www.analog.com/en/prod/0%2C2877%2CADXRS300%2C00.html

stephenthe1

11-01-2005, 16:46

will this code work for last years controller? (the whole scripting thing). also, what are the parameters for? do they have a definition somewhere else in a .h file? also, what is the default setup of the robot (motors, etc.) that these commands will work with? or is this what the parameters are for. either way, we'll need a description of the robot layout.

CJO

11-01-2005, 17:08

Also check out this guy . . .
http://www.drrobot.com/products_item.asp?itemNumber=DTA5102

Squall

12-01-2005, 11:09

Mark McLeod

12-01-2005, 11:27

I've been looking for info on how to do that, Kevin told me that I should change that two variables that I previously posted, but I can't understand them, and I can't find that info on my Gyro DatasheetPost the model gyro you are using and we might be able to help with those parameters.

Anthony Kesich

12-01-2005, 11:46

Any teams that competed in the 2003 competition should already have a gyro. Its that ugly black rectangle they gave us. The spec sheets were not to hard to find (I'll post a link when I get it again) and it wasn't too hard to make a pwm adapter. Using it should save teams a lot of money.

-Tony K

Squall

12-01-2005, 13:35

Post the model gyro you are using and we might be able to help with those parameters.

Hi, We're using this one :

ADXRS150 from analog devices

It's datasheet can be found here :

www.analog.com/UploadedFiles/Data_Sheets/778386516ADXRS150_B.pdf

We kind of understand the values that we have in the datasheet, but we really couldn't find one that could match the ones needed to alter in Kevin's code.

Thanks for your attention

Kevin Watson

12-01-2005, 16:10

Has anyone been able to substitute the gyro ?

I've been looking for info on how to do that, Kevin told me that I should change that two variables that I previously posted, but I can't understand them, and I can't find that info on my Gyro Datasheet

Does anyone have an Ideia ?
Sorry, I haven't been around much. The hillside directly behind my house collapsed last Sunday and I've been dealing with the mess.

Anyway, the two variables are GYRO_RATE_SCALE_FACTOR and GYRO_ANGLE_SCALE_FACTOR. GYRO_RATE_SCALE_FACTOR should be set to a value equal to the gyros sensitivity in units of angular rate per volt divided by the ADCs bits per volt. Set GYRO_ANGLE_SCALE_FACTOR to GYRO_RATE_SCALE_FACTOR divided by the update rate, which is 50Hz.

So, for example, to use the Analog Devices' ADXRS150 evaluation board, which has a sensitivity of 12.5mV/degree/sec, take the inverse of that sensitivity (80 degrees/sec/volt) and divide by the number of ADC bits per volt (1024/5), which equals (80 x 5)/1024 = 400/1024 = 100/256. The GYRO_ANGLE_SCALE_FACTOR is then just (100/256)/50 = 2/256 = 1/128.

In the coming days I'll be working on cleaning up not only my house, but the code too <grin>.

-Kevin

Kevin Watson

12-01-2005, 16:23

Kevin's done a great job again this year! The IR and encoder code he supplied last year was outstanding, and I had a chance to quickly flip through his code providing gyro, PID, and navigation scripting. See http://kevin.org/frc/ the first link.

This year is going to be a LOT of fun! Thanks Kevin!
Thanks, but a lot of credit goes to Rich Petras who wrote the PID and scripting code. Rich is on the MER navigation software team and is one of the original MER "drivers".

1) I think you'll need to source two encoders (not in the kit) to work with this code. The gear tooth sensors included in the kit may not cut it, unless you buy two more, and are clever about aligning them to simulate a quadrature output. You don't really need more than one per wheel. You can garner your rotational information from the motors commanded direction.

2) There is no camera code in here. So for teams looking to use the some combination of camera navigation, navigation scripting, and position sensing via encoders and gyro, you'll need to fuse the two together. So don't get too excited about things being TOO easy. This is an understatement <grin>.

3) Will the included gyro code work with the accelerometer provided in the kit? Plug and play I hope?
The idea is the same: Sample the heck out of the analog signal and downsample (average), but fundamentally they are very different sensors.

I didn't pick up on what kind of gyro Kevin Watson used for the demo robot.We used a Silicon Sensing Systems gyro because we had two of 'em on hand for Rich and I to both be able to work with. We weren't too happy to see as much drift as we saw, so I'd suggest using the ADXRS150EB or ADXRS300EB, which I've had pretty good luck with.

-Kevin

Greg Ross

12-01-2005, 18:00

We weren't too happy to see as much drift as we saw...
Are you referring to the way the 'bot would twitch periodically as Dave was talking during kickoff? I wasn't sure whether that was intended or not.

Kevin Watson

12-01-2005, 18:12

Are you referring to the way the 'bot would twitch periodically as Dave was talking during kickoff? I wasn't sure whether that was intended or not.Yes, exactly. So that Dave could show that the 'bot was actively servoing, Rich setup the code to servo using the encoders and gyro for a few minutes after Dave hit the start button and the 'bot did its routine. The gyros during that time were drifting and causing the 'bot to think that it had moved away from its intended heading. This happens with all gyros to one degree or another and is just something that has to be dealt with. I'm working to tune the gyro code to minimize this effect, yet stay pretty efficient.

-Kevin

Ryan Cumings

12-01-2005, 18:42

Yes, exactly. So that Dave could show that the 'bot was actively servoing, Rich setup the code to servo using the encoders and gyro for a few minutes after Dave hit the start button and the 'bot did its routine. The gyros during that time were drifting and causing the 'bot to think that it had moved away from its intended heading. This happens with all gyros to one degree or another and is just something that has to be dealt with. I'm working to tune the gyro code to minimize this effect, yet stay pretty efficient.

-Kevin
Kevin, have you thought about trying wheel odometry to derive heading? I found this site last summer, and I have been so busy and not active with any robotics that I have not had a chance to see if it actually works.
Scroll down to the navigating section
http://www.geology.smu.edu/~dpa-www/robo/nbot/

Kevin Watson

12-01-2005, 19:15

Kevin, have you thought about trying wheel odometry to derive heading? I found this site last summer, and I have been so busy and not active with any robotics that I have not had a chance to see if it actually works.
Scroll down to the navigating section
http://www.geology.smu.edu/~dpa-www/robo/nbot/
Yes, you can use differential wheel odometry to derive heading, but its a headache because just a little bit of wheel slip will throw your heading off (and the error integrates too).

-Kevin

CJO

12-01-2005, 20:44

Just out of curiosity,

One of our big mentors is an aviation company. They have a bunch of parts from autopilot systems sitting around. Do you think it is worth trying to make this stuff work, or should we just shell out a couple of hundred for something which works.

Also, has anyone taken a look at RC helicopter gyros? I was searching and found some on a hobby shop site, the even had PWM cables attached. Thoughts?

seanwitte

12-01-2005, 22:49

Also, has anyone taken a look at RC helicopter gyros? I was searching and found some on a hobby shop site, the even had PWM cables attached. Thoughts?

The gyros used in helicopters are integrated PID controllers. It takes an input from the receiver as the set point, compares it to the internal sensor value, and outputs the PWM signal required to match the rates. There are potentiometers to adjust the gain. As such, they aren't suitable for integrating the heading because you don't have access to the raw sensor output. I don't think they are high precision parts but I don't know for sure.

CJO

13-01-2005, 01:36

Thanks

Squall

14-01-2005, 06:20

Sorry, I haven't been around much. The hillside directly behind my house collapsed last Sunday and I've been dealing with the mess.

Anyway, the two variables are GYRO_RATE_SCALE_FACTOR and GYRO_ANGLE_SCALE_FACTOR. GYRO_RATE_SCALE_FACTOR should be set to a value equal to the gyros sensitivity in units of angular rate per volt divided by the ADCs bits per volt. Set GYRO_ANGLE_SCALE_FACTOR to GYRO_RATE_SCALE_FACTOR divided by the update rate, which is 50Hz.

So, for example, to use the Analog Devices' ADXRS150 evaluation board, which has a sensitivity of 12.5mV/degree/sec, take the inverse of that sensitivity (80 degrees/sec/volt) and divide by the number of ADC bits per volt (1024/5), which equals (80 x 5)/1024 = 400/1024 = 100/256. The GYRO_ANGLE_SCALE_FACTOR is then just (100/256)/50 = 2/256 = 1/128.

In the coming days I'll be working on cleaning up not only my house, but the code too <grin>.

-Kevin

Thanks a lot Kevin!

Sorry to hear about your home :(

My team didn't receive the Kit yet but we decided now that we're going to use a testing plataform and last year's kit so that we can start our programming tests.

And since we programers were just helping out with other stuff we decided to do a very simple GUI for your code, We'll be finishing it today and I'll post here.

Kevin Watson

14-01-2005, 11:29

Sorry to hear about your home :(
Thanks.

And since we programers were just helping out with other stuff we decided to do a very simple GUI for your code, We'll be finishing it today and I'll post here. I assume this is for the gyro code? If so, the conversions I gave you were in units of degrees, which is too course to use. Rich Petras wanted milliradians (pi radians = 180 degrees), so that's what the new gyro code will return. I've also built in the option of returning tenths of a degree by uncommenting some #defines in gyro.h:

/************************************************** *****************************
*
* TITLE gyro.h
*
* VERSION: 0.2 (Beta)
*
* DATE: 12-Jan-2005
*
* AUTHOR: R. Kevin Watson
* kevinw@jpl.nasa.gov
*
* COMMENTS:
*
************************************************** ******************************
*
* CHANGE LOG:
*
* DATE REV DESCRIPTION
* ----------- --- ----------------------------------------------------------
* 21-Nov-2004 0.1 RKW - Original
* 12-Jan-2005 0.2 RKW - Altered Get_Gyro_Rate() and Get_Gyro_Angle() to use
* long integers for internal calculations, allowing larger
* numerators and denominators in the GYRO_RATE_SCALE_FACTOR
* and GYRO_ANGLE_SCALE_FACTOR #defines.
* 12-Jan-2005 0.2 RKW - GYRO_RATE_SCALE_FACTOR and GYRO_ANGLE_SCALE_FACTOR
* #defines added for Analog Devices' ADXRS401, ADXRS150 and
* ADXRS300 gyros.
*
************************************************** *****************************/

#ifndef _gyro_h
#define _gyro_h
#define TRUE 1
#define FALSE 0
// MILLIRADIANS_PER_TENTH_DEGREE = 349/200
// ADC_BITS_PER_VOLT = 1024/5
// GYRO_RATE_SCALE_FACTOR = ANGULAR_RATE_PER_VOLT / ADC_BITS_PER_VOLT
// GYRO_ANGLE_SCALE_FACTOR = GYRO_RATE_SCALE_FACTOR / SAMPLE_RATE
// default parameters for Silicon Sensing Systems' CRS03
// sensitivity = 20mV/deg/sec
// #define GYRO_RATE_SCALE_FACTOR 625/256 // defaults to 625/256 for tenths of a degree/sec
// #define GYRO_ANGLE_SCALE_FACTOR 25/512 // defaults to 25/512 for tenths of a degree
// #define GYRO_RATE_SCALE_FACTOR 8725/2048 // defaults to 8725/2048 for milliradians/sec
// #define GYRO_ANGLE_SCALE_FACTOR 349/4096 // defaults to 349/4096 for milliradians
// default parameters for Analog Devices' ADXRS401
// sensitivity = 15mV/deg/sec
// #define GYRO_RATE_SCALE_FACTOR 1665/512 // defaults to 1665/512 for tenths of a degree/sec
// #define GYRO_ANGLE_SCALE_FACTOR 333/5120 // defaults to 333/5120 for tenths of a degree
// #define GYRO_RATE_SCALE_FACTOR 5811/1024 // defaults to 5811/1024 for milliradians/sec
// #define GYRO_ANGLE_SCALE_FACTOR 581/5120 // defaults to 581/5120 for milliradians
// default parameters for Analog Devices' ADXRS150
// sensitivity = 12.5mV/deg/sec
// #define GYRO_RATE_SCALE_FACTOR 125/32 // defaults to 125/32 for tenths of a degree/sec
// #define GYRO_ANGLE_SCALE_FACTOR 5/64 // defaults to 5/64 for tenths of a degree
#define GYRO_RATE_SCALE_FACTOR 1745/256 // defaults to 1745/256 for milliradians/sec
#define GYRO_ANGLE_SCALE_FACTOR 349/2560 // defaults to 349/2560 for milliradians
// default parameters for Analog Devices' ADXRS300
// sensitivity = 5.0mV/deg/sec
// #define GYRO_RATE_SCALE_FACTOR 625/64 // defaults to 625/64 for tenths of a degree/sec
// #define GYRO_ANGLE_SCALE_FACTOR 25/128 // defaults to 25/128 for tenths of a degree
// #define GYRO_RATE_SCALE_FACTOR 8725/512 // defaults to 8725/512 for milliradians/sec
// #define GYRO_ANGLE_SCALE_FACTOR 349/1024 // defaults to 349/1024 for milliradians

void Initialize_Gyro(void); // initializes and starts the gyro software
int Get_Gyro_Rate(void); // returns the current heading angular rate of change
int Get_Gyro_Angle(void); // returns the current heading angle
void Calc_Gyro_Bias(void); // calculates the current gyro bias
int Get_Gyro_Bias(void); // returns the current calculated gyro bias
void Set_Gyro_Bias(int); // manually sets the gyro bias
void Reset_Gyro_Angle(void); // resets the heading angle to zero
void Disable_Gyro(void); // disables the gyro
void Initialize_Timer_2(void); // initializes and starts timer2
void Timer_2_Int_Handler(void); // interrupt service routine for timer2
#endif

-Kevin

Squall

16-01-2005, 22:25

I assume this is for the gyro code?

It's not just for the gyro, it's kind of a general tool

What it does is just that we've selected some 'defines' that we have seen in your code that we think that should be something that not just us but all the teams are gonna have to change a lot during tests, and also at the competition, so our tool just grab those defines as put it on text boxes so that you can easy alter it without having to go trough all the code and find the right place.

Then you must use MpLab to compile the code.

We're translating this tool to English and comenting the code.

We're kind of late because we were having trouble with the Wireless serial device that you've mentioned in your site, we can make it work but only at 9600bps so we can't program our robot using Ifi Loader, can you give us some direction here ?

Thanks a lot

Kevin Watson

18-01-2005, 01:52

We're kind of late because we were having trouble with the Wireless serial device that you've mentioned in your site, we can make it work but only at 9600bps so we can't program our robot using Ifi Loader, can you give us some direction here ? The SMiRF wireless transceivers will only go as high as 38,400 baud, so they cannot be used to program the RC. They are, however, great for sending debugging telemetry back to your computer without a long serial cable.

-Kevin

Kevin Watson

22-01-2005, 03:38

I've updated the PID/Scripting code to include the latest gyro code, additional documentation and data sheets for compatible encoders and gyros. It can be found here: http://kevin.org/frc.

-Kevin