Go to Post there should be a continuous cascade of knowledge spilling over to the less experienced team members and and continuous upward flow of members gaining experience. - ebarker [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rating: Thread Rating: 4 votes, 4.75 average. Display Modes
  #1   Spotlight this post!  
Unread 20-02-2007, 18:01
Cuog's Avatar
Cuog Cuog is offline
Registered Linux User: 390661
AKA: Alex
FRC #0422
Team Role: Mentor
 
Join Date: Nov 2005
Rookie Year: 2004
Location: Richmond, Virginia
Posts: 852
Cuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond repute
Send a message via AIM to Cuog
Re: Programming tricks (and former trade secrets)

I made the robot fight gravity actually it was a code w/ the accelerometer that would try and push back, but with no testing it made driving impossible because I got the direction that it corrects wrong, so it fights itself, oops

In the way of useful things I did this year, I got our omniwheel bot to drive mostly straight(still have to tune that) using a gyro chip that hopefully will self calibrate. The drive code also very nicely allows us to drive it FPS style with one joystick for translation and the x axis on the other for spin.
__________________
KK4KQO
http://voltair.us
Too many projects, too little time.
  #2   Spotlight this post!  
Unread 20-02-2007, 18:11
Robo_Coyote's Avatar
Robo_Coyote Robo_Coyote is offline
Cheap_Shot
AKA: Chris Chandler
FRC #1323 (MadTown Robotics )
Team Role: Mechanical
 
Join Date: Sep 2006
Rookie Year: 2005
Location: Madera
Posts: 115
Robo_Coyote is a splendid one to beholdRobo_Coyote is a splendid one to beholdRobo_Coyote is a splendid one to beholdRobo_Coyote is a splendid one to beholdRobo_Coyote is a splendid one to beholdRobo_Coyote is a splendid one to behold
Re: Programming tricks (and former trade secrets)

Our programer made our lift motor a 20000 position servo with a program that state level 1 is between position 5000, and 7500 and so forth. He also got most of our operational programing done first time ever for that.
__________________
2005- Uc Davis Spirit Award
2006 nationals second highest score thanks to 233, and 1184

We need a longer highlight list....... sigh

"To invent all you need is imagination and a pile of junk" - Thomas Edison
  #3   Spotlight this post!  
Unread 20-02-2007, 20:03
Kevin Watson's Avatar
Kevin Watson Kevin Watson is offline
La Caņada High School
FRC #2429
Team Role: Mentor
 
Join Date: Jan 2002
Rookie Year: 2001
Location: La Caņada, California
Posts: 1,335
Kevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond repute
Re: Programming tricks (and former trade secrets)

I've been working on a library that will work with version 3.0 of the C18 compiler. I'm almost there...

-Kevin
__________________
Kevin Watson
Engineer at stealth-mode startup
http://kevin.org
  #4   Spotlight this post!  
Unread 20-02-2007, 20:23
meatmanek meatmanek is offline
Programmer/physicist/mathematician
FRC #0868 (TechHounds)
Team Role: Programmer
 
Join Date: Mar 2004
Rookie Year: 2004
Location: Carmel, Indiana
Posts: 142
meatmanek is a splendid one to beholdmeatmanek is a splendid one to beholdmeatmanek is a splendid one to beholdmeatmanek is a splendid one to beholdmeatmanek is a splendid one to beholdmeatmanek is a splendid one to beholdmeatmanek is a splendid one to behold
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Cuog View Post
I made the robot fight gravity actually it was a code w/ the accelerometer that would try and push back, but with no testing it made driving impossible because I got the direction that it corrects wrong, so it fights itself, oops

In the way of useful things I did this year, I got our omniwheel bot to drive mostly straight(still have to tune that) using a gyro chip that hopefully will self calibrate. The drive code also very nicely allows us to drive it FPS style with one joystick for translation and the x axis on the other for spin.
Last year, we used mecanum wheels to drive our robot. I played with some code using the YRG to make the joystick always be relative to the driver, rather than the robot. Push forward on the joystick, and it goes down the field, push right on the joystick, and it goes right on the field, twist the joystick and the robot will turn. Unfortunately, our drivetrain was too fast, capable of turning about one revolution per second (without the rest of the robot, I don't know what it was with all of that). The YRG was limited to 80 degrees per second. I wanted to get another gyro, but we never followed through on that.

If you're using a DAA to control an arm, you might consider using a quadrature encoder. DAAs are prone to drift, and aren't very accurate when you integrate them twice to get position.
  #5   Spotlight this post!  
Unread 20-02-2007, 20:27
Cuog's Avatar
Cuog Cuog is offline
Registered Linux User: 390661
AKA: Alex
FRC #0422
Team Role: Mentor
 
Join Date: Nov 2005
Rookie Year: 2004
Location: Richmond, Virginia
Posts: 852
Cuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond reputeCuog has a reputation beyond repute
Send a message via AIM to Cuog
Re: Programming tricks (and former trade secrets)

I had to slow down the speed of our spin because at full speed the spin is roughly 2 rev/sec, not drivable at all, the YRG is on there to adjust the spin so that we spin reliably and dont over spin.

the DAA was intended to push back against another robot when they bump us, sadly it ended up fighting itself so thats something I'm going to try and fix on thursday otherwise it will just be scrapped.
__________________
KK4KQO
http://voltair.us
Too many projects, too little time.
  #6   Spotlight this post!  
Unread 20-02-2007, 20:50
kitscuzz's Avatar
kitscuzz kitscuzz is offline
Not alotta posts
AKA: Kit
FRC #1389 (Worst Case Scenario)
Team Role: Programmer
 
Join Date: Jan 2006
Rookie Year: 2005
Location: Home
Posts: 47
kitscuzz will become famous soon enough
Re: Programming tricks (and former trade secrets)

We were just proud to get so many systems to work together:

The adc is now working in conjunction with the gyro code to integrate 400 times a second (which needs a long long, but we made it reset every 360 degrees to prevent overflow).

I'm soon to add in the Dual Axis Accelerometer to account for tilt so that I can kill the gyro integration if the tilt exceeds a certain angle.

We used the eeprom and trig funtions in order to make field-oriented holonomic (which I almost had working perfectly when they tore it out of my hands to ship it... hardware team didn't get the robot done until yesterday... sadness). And we're working on sticking the gyro bias into the eeprom as well in order to prevent recalculation every time you turn on the robot.

The encoder (a banner IR sensor) counts the number of times a wheel turns in order to keep track of the height of the arm.

And we were going to do the camera, but the autonomous ended up being so enormous, that we had to abandon it. We made the whole thing with multiple light tracking, and we had a plan, but it was just too difficult to get it running straight without a working Dual Axis Accelerometer and perfect camera code that we had to give up. 15 seconds is not very much time.

Although it's not particularly useful code, anyone who wants it can PM me for the accelerometer and gyro code we made. It's a little too processor intensive if your planning on doing the camera, but it can integrate up to 6200 times a second to keep really close track of the gyro angle or velocity. For whatever reason, we couldn't seem to make it keep track of the velocity very well, but we cut the error on the angle down to .5 degrees for a full spin on the bot.

Last edited by kitscuzz : 20-02-2007 at 20:54.
  #7   Spotlight this post!  
Unread 20-02-2007, 21:16
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Programming tricks (and former trade secrets)

I wrote a two-shot arm control module--if the arm's potentiometer value is more than a certain amount, it will send full speed out to that joint, otherwise, it will send a slower value until it is within a "deadband". Unfortunately, I didn't get as much testing in as I wanted to because the gear that meshes with the worm-tooth kept losing teeth and the robot dentist got more and more agitated as the night went on...I nicknamed our 'bot "gear muncher" because I broke 3 gears yesterday and 2 the day before. Little brass teeth are littering the floor. Not Good. We have some hardened steel gears coming, though.

I also have an EEPROM solution in place--you move the arm to where you want it, then hold a button combo on the handheld and the robot saves that position to the EEPROM and will recall it when that button is pressed.

Of course, our code still isn't done. It's...functional...which is an improvement over last year.

JBot
__________________
Aren't signatures a bit outdated?
  #8   Spotlight this post!  
Unread 20-02-2007, 21:24
kitscuzz's Avatar
kitscuzz kitscuzz is offline
Not alotta posts
AKA: Kit
FRC #1389 (Worst Case Scenario)
Team Role: Programmer
 
Join Date: Jan 2006
Rookie Year: 2005
Location: Home
Posts: 47
kitscuzz will become famous soon enough
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by JBotAlan View Post
I also have an EEPROM solution in place--you move the arm to where you want it, then hold a button combo on the handheld and the robot saves that position to the EEPROM and will recall it when that button is pressed.

JBot
Hey, that's an excellent idea! Well now I have a solution for resetting the arm position before each match. The banner IR encoder solution I talked about is arbitrary, this will keep it in place.
  #9   Spotlight this post!  
Unread 20-02-2007, 23:17
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by kitscuzz View Post
And we're working on sticking the gyro bias into the eeprom as well in order to prevent recalculation every time you turn on the robot.
I'd recommend against doing this. The gyro bias can vary quite a bit based on a number of factors like temperature, voltage, etc. It's completely possible for it to be different every time you turn the machine on.
  #10   Spotlight this post!  
Unread 21-02-2007, 00:05
tdlrali tdlrali is offline
Registered User
FRC #0469 (Las Guerrillas)
Team Role: Programmer
 
Join Date: Sep 2006
Rookie Year: 2006
Location: MI
Posts: 377
tdlrali has much to be proud oftdlrali has much to be proud oftdlrali has much to be proud oftdlrali has much to be proud oftdlrali has much to be proud oftdlrali has much to be proud oftdlrali has much to be proud oftdlrali has much to be proud of
Re: Programming tricks (and former trade secrets)

We wrote some code that eliminates the need for a programmer...
More on this later
  #11   Spotlight this post!  
Unread 21-02-2007, 00:53
Astronouth7303's Avatar
Astronouth7303 Astronouth7303 is offline
Why did I come back?
AKA: Jamie Bliss
FRC #4967 (That ONE Team)
Team Role: Mentor
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Grand Rapids, MI
Posts: 2,071
Astronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud of
Re: Programming tricks (and former trade secrets)

In addition to debuting the scripting system I wrote in the pre-season 2006 (that we ended up not needing -- it was a very strange robot), I tried a few structural things.

The scripting is based on preprocessing direct calls to functions, instead of Kevin Watson's structure-based navigation code. (The preprocessing is so that the script will abort when autonomous ends.) It follows the idea of a lot of little loops: every command calls HEARTBEAT at least once, and that handles getdata() and putdata() calls. This all makes C-like syntax:
Code:
SCRIPT drive_half_field()
{
    CMD_UNFURL(NO_WAIT);
    CMD_DRIVE(FEET(20));
    CMD_TURN(DEGREES(90), RIGHT);
    CMD_WAIT(SECONDS(2));
    CMD_HOME_IN(); // Drives towards the light
    CMD_DROP(); // Drop that keeper!
    CMD_DRIVE(INCHES(-18));
    CMD_TURN(DEGREES(90), LEFT);
    CMD_DRIVE(FEET(20)); // And maybe crash into someone!
}
You can also stick in loops, ifs, or any other constructs, calls, or whatever you want. Just call HEARTBEAT if you go too long.
One of the big ones this year was that every mechanism followed a standard interface. Every mechanism had the following macros or functions:
  • NAME_Init() -- Initialize state
  • NAME_UserMode() -- Perform operator mode controlls
  • NAME_Sensor() -- Take sensor readings at the begining of the slow loop (autonomous or user mode)
  • NAME_Process() -- Handle control loops at the end of the slow loop
  • NAME_IsDone() -- For mechanisms that moved to a position, had it reached its position?
  • NAME_*(...) -- Any control functions (eg, Arm_GoTo(ANALOG val), Drive_1stick(UCHAR drive, UCHAR turn), etc)
This was facilitated by wrappers around getdata() and putdata() which handled this. Note that these functions are used in both autonomous and operator mode.

I also had my usually tools, namely pinouts.h (a configuration file of all the hardware I/O aliases and tweaking constants), Eclipse, and old code.

Also, I'm the operator this year, so I can make it as complex as I want. (Because I know how it all goes!) Ok, not really. There is a backup driver that I have to keep up-to-date.

Amongst the things I may do between now and our competitions:
  • Write a generic python script to generate lookup tables
  • Write another LCARS Dashboard for this year's robot (likely in python, so that I can develop on my Linux desktop)
  • Adding a real-time clock using one of the timers

Quote:
Originally Posted by benhulett View Post
Designed a "level code" to make the arm operator's job 10x easier
Ex: you push this button, the arm moves to level 2 and sets the motor to neutral (until you push another button)
We have that, too. We just used a pot, though.

Quote:
Originally Posted by tdlrali View Post
We wrote some code that eliminates the need for a programmer...
More on this later
Isn't that ironic? Writing code to keep you from writing code?
  #12   Spotlight this post!  
Unread 21-02-2007, 01:41
Japper's Avatar
Japper Japper is offline
Registered User
FRC #3692 (RocknRobots)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2007
Location: Rutland Wisconsin
Posts: 147
Japper has a spectacular aura aboutJapper has a spectacular aura about
Re: Programming tricks (and former trade secrets)

Me being the main programmer on a rookie team and not knowing what to expect, and not programming in over 10 years, I incorporated the following "different" features:

1. Neutral control/Panic button: Before we knew about the v14 fix for the run on condition, I was concerned about the robot running out of control as we had encountered this problem, so I added some code that puts both motors in Neutral by pressing either joystick trigger button. (we have a 2 wheel drive CIM motor system). I left this feature in the code in case in the heat of the moment, the operator needs to stop.

Quote:
if (p1_sw_trig || p2_sw_trig)
{
pwm01 = pwm02 = 127;
}
2. Scaling factor/ Turbo Mode: I found that our Cim motors run a little faster than we wanted for manueverability at full PWM output levels (0 & 255) so I used a scaling factor that is applied to the each drive wheel joystick Y position and then mapped each joystick wheel to act as a turbo button which would give us burst speed if we needed it. Consequently, we added raised casters in the back of our chassis to keep it from tipping as hitting the turbo button gave it a wicked (but cool looking) lurch like you see in funny cars on the 1/4 mile track...

Incidently, because the turbo mode is set for each drive wheel independently with the thumbwheel on its joystick, some pretty quick and possibly uncontrolled turns can be made.

Also, testing confirmed that if the operator holds down the triggers (neutral and puts both joysticks forward with both the turbo buttons on and then releases the trigger buttons that we could do a "hole shot" and a "wheelie"... well it looks cool anyhow...

The Y axis code (p1_y = (p1_y /speed) + plus_speed; & p1_y = (p2_y /speed) + plus_speed; ) is in there as we originally set this up for single joystick control and it works for that as well so I left the code in there. Here is what my crude code for that looks like:


Quote:
/******************************** Slower mode **********************************************
* The following code sets all PWMs to default lower speed (dictated by scaling factor *
* (speed) and then to full output level of each joystick when its wheel button is pressed *
* and held *
************************************************** *****************************************/

static int speed = 3; /* speed control scaling factor = PWM divided by this number */

static int plus_speed = 80; /* this value is added after speed control scaling factor to center and normalize
the PWM value (if speed = 2 use 64, if speed = 3 use 80, if speed = 4 use 96) */

if (p1_wheel < 60)
{
p1_x = (p1_x /speed) + plus_speed; /* adjust PWM by a factor of speed and add plus_speed to compensate */
p1_y = (p1_y /speed) + plus_speed; /* adjust PWM by a factor of speed and add plus_speed to compensate */
}

if (p2_wheel < 60)
{
p2_x = (p2_x /speed) + plus_speed; /* adjust PWM by a factor of speed and add plus_speed to compensate */
p2_y = (p2_y /speed) + plus_speed; /* adjust PWM by a factor of speed and add plus_speed to compensate */
}
3. Backlash Prevention: I put a simple normailizing feature on the drive wheel joysticks to center these and to prevent backlash on the motors due to a released joystick. I noticed that when the joystick was released from the forward position that it would kick the motor in reverse momentarily and I was concerned about blowing a fuse from the excessive current draw on this condition. So I added the following code:
Quote:
/**************************Backlash Adjust ************************************
* This section sets the joystick X & Y zero points if PWM is between 124 & *
* 130 to avoid backlash near zero crossings *
************************************************** ****************************/

if (p1_x < 130 && p1_x > 124)
{
p1_x = 127; /* normalize X neutral on Joystick */
}

if (p1_y < 130 && p1_y > 124)
{
p1_y = 127; /* normalize Y neutral on Joystick */
}

if (p2_x < 130 && p2_x > 124)
{
p2_x = 127; /* normalize X neutral on Joystick */
}

if (p2_y < 130 && p2_y > 124)
{
p2_y = 127; /* normalize Y neutral on Joystick */
}

4. Acceleration ramp up/down: We found that the acceleration was too quick so we added the following simple ramp up code:


Quote:
/************************** Ramp up Routines ************************************
* This section ramps the joystick X & Y PWM levels for smooth transistions of *
* acceleration or deceleration *
************************************************** ******************************/

#define ramp_speed 3

if(pwm01 > (p1_y+ramp_speed))
{
pwm01 += ramp_speed;
}
else if (pwm01 < (p1_y-ramp_speed))
{
pwm01 -= ramp_speed;
}
else
{
pwm01 = p1_y;
}
if(pwm02 > (p2_y+ramp_speed))
{
pwm02 += ramp_speed;
}
else if (pwm02 < (p2_y-ramp_speed))
{
pwm02 -= ramp_speed;
}
else
{
pwm02 = p2_y;
}
5. Motor Bias Adjustment: Also, I found that the motor bias was different with the two CIM motors especially since one was turned 180 degrees from the other wheel that the robot would track to one side with both drive wheel joysticks in the same position. I added corrections to these but as the motors heat up I couldn't count on this being a constant value so I incorporated a dummy plug to add a correction only if the dummy plug is installed. The code looks like this:

Quote:
/* ------------ correct for motor speed if rc_04 is low */

if ((p1_y < 255) && (rc_dig_in03 == 0))
{
pwm01 = pwm01 + 2;
}

if ((p1_y > 2) && (rc_dig_in03 == 0))
{
pwm01 = pwm01 - 2;
}
6. Troubleshooting aid: When trouble shooting my robot's motors and controls, I had a hard time seeing some of the joystick values in dashboard viewer so I mapped these to un0used PWM outputs so I could see what was going on which made it easier to figure this out...

Quote:
pwm11 = p3_wheel; /* show us the value of p3_wheel on dash board viewer as pwm11 */
pwm09 = rc_dig_in02; /* show us the value of rc_dig_in02 on dash board viewer as pwm09 */
pwm08 = rc_dig_in01; /* show us the value of rc_dig_in01 on dash board viewer as pwm08 */
Sorry to be so long winded but being a rookie and not programming in quite a while I am sure that my code looks a little crude to most of you professionals out there but it does work for what it was intended.

Some of these ideas that I used, I am sure you pros have figured out better methods for or used something similar and I am hoping that you share those ideas with me...

I just wanted to share a few of my ideas with you all...

Good luck to all in your competition!
  #13   Spotlight this post!  
Unread 21-02-2007, 00:39
htwiz2002's Avatar
htwiz2002 htwiz2002 is offline
Htwizard
AKA: Anthony Takata Bawahawba
#1290
Team Role: Engineer
 
Join Date: Jan 2004
Location: Chandler, AZ
Posts: 23
htwiz2002 will become famous soon enough
Smile Re: Programming tricks (and former trade secrets)

Well, This year I was set on programming autonomous, but I am hardly sure we will have a robot that needs it . It is 19% complete, and still in alpha stage, but I had promised myself that I would continue even though the robot is shipped (having problems trying to get the Controller to work without an OI, but I believe that that is default), and what I have now may interest some.

As I said, it is VERY incomplete, and not altogether working. It is a terminal interface to the controller (mainly for debugging purposes) that eventually will replace most programming that a team would need to do (as far as autonomous and some others, PWM mappings and others will still need to be modified every now and then ).

I have already integrated Kevin's Camera Processing routines, Serial IO routines, and EEPROM (still unverified, sigh) routines, and the interface is kinda cool. If you want some more info, check out the attachment.

The main features are (/will be):
- Easy autonomous programming by the end-user (a.k.a. the non-programmers) using the terminal interface
- Easy Drive controls altering/setting using the terminal interface
- QuickView info on various IO's (like pwms, DigIO, AnaIO, Battery voltage) through the terminal
- On-the-fly Calculation of field placement using camera, accelerometers, gyros, IR, yada yada...
- Easy autonomous programming... (wait, did I already say that?) using a (slightly) intuitive terminal interface
Did I mention that all of this is through the terminal interface?
Unfortunately, I haven't coded the IFI loader's interface menu yet, but HyperTerminal works absolutely fantastic for now, with auto-updating information on the fly and a much more user-friendly menu (I tried implementing a line-by-line menu; didn't work out at all, updated information tended to cause the menu to disappear rather quickly, yada yada.)

Still in Beta! If anyone could assist writing autonomous action code (read about it in the documentation) please PM me!
BTW, does anyone have a memory free count for the default code? I would like to post how much memory my "add-on" will take, and I forgot .
Also, I would like to add code for things like Gyros and Accelerometers, but since We do not have such things (working or not) I cannot possibly program for it. At the current time almost none of my program uses timers (forgot how, :stupidme and If I cannot use data from sensors, the code would be blind. anyways...
Like I said, 19% complete, still need LOTS of code, see attachment for more info.

Catch you all later!
Attached Files
File Type: rar TerminalInterface_0_19.rar (93.0 KB, 25 views)
File Type: doc Terminal.doc (91.5 KB, 40 views)
File Type: doc 7 - Robotics - Autonomous - Commands layout.doc (30.5 KB, 40 views)
File Type: doc frc_TerminalFunctionData.doc (41.5 KB, 33 views)
File Type: rar FRC_MASTER_V13.Bin.Rar (11.0 KB, 21 views)
__________________
TsAuKpAeTrA (Anthony)
  #14   Spotlight this post!  
Unread 20-02-2007, 21:31
kaszeta's Avatar
kaszeta kaszeta is offline
Registered User
FRC #0095 (Grasshoppers)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2002
Location: Lebanon, NH
Posts: 334
kaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of light
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by meatmanek View Post
Last year, we used mecanum wheels to drive our robot. I played with some code using the YRG to make the joystick always be relative to the driver, rather than the robot. Push forward on the joystick, and it goes down the field, push right on the joystick, and it goes right on the field, twist the joystick and the robot will turn. Unfortunately, our drivetrain was too fast, capable of turning about one revolution per second (without the rest of the robot, I don't know what it was with all of that). The YRG was limited to 80 degrees per second. I wanted to get another gyro, but we never followed through on that.
Get the ADXRS300EB gyro (or the Sparkfun breakout board equivalent, which is easier to wire), and you won't regret it. Last year we made a prototype holonomic drive, and it was way fun to drive, and user-centric coordinates allow you to easily do things like spin while driving.
  #15   Spotlight this post!  
Unread 21-02-2007, 16:13
buddy.smith buddy.smith is offline
Master Control
FRC #1795
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2007
Location: atlanta
Posts: 20
buddy.smith is an unknown quantity at this point
Re: Programming tricks (and former trade secrets)

Hm... We used mecanum wheels. We coded the usual translation routines, then used a third axis on the joystick (twist) for rotation.

We didn't design it this way, but what emerged was that driving in circular arcs was VERY easy, which the drivers love because of the design of the rack.

Other features...the arm's motion is limited by a pot, but if the pot fails (becomes disconnected), the arm will still be usable. I wish I could say we thought of this BEFORE the pot failed (wiring problem)....

I'd love to restructure the First code...I really don't like their coding style, but 6 weeks isn't enough time for that, so making the robot work was priority #1

--buddy
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Former FIRST student and mentor dies in a tragic rocket attack in Iraq today. Munkaboo General Forum 48 19-04-2005 12:21
Off-season competetions and former teams Venkatesh Off-Season Events 5 10-12-2004 17:23
Harry Potter and the Chamber of Secrets Ryan Dognaux Chit-Chat 33 01-12-2002 19:57
scouting tips and tricks Rick Scouting 1 08-01-2002 00:52


All times are GMT -5. The time now is 21:23.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi