OCCRA
Go to Post Aaaah - interpersonal dynamics - the root of most problems on most teams. - UCGL_Guy [more]
Home
Go Back   Chief Delphi > Other > FIRST Tech Challenge
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 12-19-2009, 01:33 PM
buddyb's Avatar
buddyb buddyb is offline
Registered User
FRC #1885 (ILITE)
Team Role: Programmer
 
Join Date: Dec 2009
Rookie Year: 2008
Location: Haymarket, VA
Posts: 65
buddyb has a spectacular aura aboutbuddyb has a spectacular aura aboutbuddyb has a spectacular aura about
[FTC]: Breaking DC Gearboxes Fix

I saw a topic a while back about teams ripping apart the gearboxes on DC motors, and have searched for it quite a bit, yet can't seem to find it. So, I hope that posting a new topic here is acceptable.

Near the beginning of the school year, our team (1885) started prototyping various shooters, but we had a slight problem: our gear ratio needed to be at least 9:1 to shoot the balls a decent range. We found that- if we stopped the program running the shooter with the power still on- RobotC automatically made the motors force the shooter to come to an immediate stop. This ripped two gearboxes to shreds after around 6 tests of our shooter.

However, we were able to find that if we turned the power switch off *before* the program, the shooter would come to a gradual stop, and not tear up any gearboxes. So, I took a few minutes to make some code that would rev a shooter down in RobotC. [[Attached]]

All it does is makes the power for the predefined motors approach 0 (in increments of 5) once every 200ms. Using this code, we haven't had a single gearbox rip apart on us (after running the shooter at 9:1 literally hundreds of times).

So, I hope you enjoy the code. A bit of set up is needed, but it should be worth the saved gearboxes.

Additional note: Thanks to the NXT using 16-bit unsigned ints for Encoder values, it is highly suggested that you not use PID control on your shooter, or any peripheral using 9:1 or greater gear ratios, at that. When the encoder values overflow [the motors reach 32,565 faster than you'd think], the PID control algorithm slams the motor to -100 power (or 100, if you were having that motor go in reverse). This also tore up a few gearboxes.

Best of luck with your robots!
-Buddy
Attached Files
File Type: txt nt.txt (2.1 KB, 85 views)
__________________
FRC - Team 1885 - Programmer.

Last edited by buddyb : 12-19-2009 at 01:48 PM.
Reply With Quote
  #2   Spotlight this post!  
Unread 12-21-2009, 09:45 AM
PhilBot's Avatar
PhilBot PhilBot is offline
Get a life? This IS my life!
AKA: Phil Malone
FRC #1629 (GaCo: The Garrett Coalition)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2006
Location: Maryland
Posts: 690
PhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond reputePhilBot has a reputation beyond repute
Re: [FTC]: Breaking DC Gearboxes Fix

Since you're talking "power Switches" I assume you are talking about the DC motors, and not the LEGO motors.

So, I am surprized that Robot C is using 16 Bit ints for the encoder values.
Are you sure about that..?

The encoders report 1440 pulses per revolution, so it only takes 22 revolutions to overflow an int16.

The Hitechnic motor controllers actually report 32 Bit ints, so it doesn't seem logical to throw away 16 of those bits. (eg: LabVIEW uses all 32 bits)

However, I guess the real question is whether it's possible to put the motors into "coast" to let them slow down normally. The Hitechnic manual says that it is possible. Does Robot C need a flag for that?
__________________
Phil Malone
Garrett Engineering And Robotics Society (GEARS) founder.
http://www.GEARSinc.org

FRC1629 Mentor (2011 CMP Eng. Inspiration, 2010 Chesapeake Chairmans Award, 2009 Pittsburgh EI Award, 2008 Buckeye EI Award, 2006 Chesapeake Alliance Winner)
FTC2818 Coach (2011 CMP Divisional Finalist, 2011 MD Winning Alliance, 2010 MD & OH Winning Alliance Captain, 2009 MD Inspire Award and Championship Finalist).
FTC4240 Mentor (2011 CMP Divisional Finalist Captain, 2011 MD Winning Alliance Captain).
FLL Team NeXTGEN Mentor (2011 CMP 3rd place Strategy & Innovation, US Open 09, Champions Award: '11 MD, 09 PIT, 08 & 07 MD)

Reply With Quote
  #3   Spotlight this post!  
Unread 12-22-2009, 11:15 AM
buddyb's Avatar
buddyb buddyb is offline
Registered User
FRC #1885 (ILITE)
Team Role: Programmer
 
Join Date: Dec 2009
Rookie Year: 2008
Location: Haymarket, VA
Posts: 65
buddyb has a spectacular aura aboutbuddyb has a spectacular aura aboutbuddyb has a spectacular aura about
Re: [FTC]: Breaking DC Gearboxes Fix

Quote:
Originally Posted by PhilBot View Post
Since you're talking "power Switches" I assume you are talking about the DC motors, and not the LEGO motors.

So, I am surprized that Robot C is using 16 Bit ints for the encoder values.
Are you sure about that..?

The encoders report 1440 pulses per revolution, so it only takes 22 revolutions to overflow an int16.

The Hitechnic motor controllers actually report 32 Bit ints, so it doesn't seem logical to throw away 16 of those bits. (eg: LabVIEW uses all 32 bits)

However, I guess the real question is whether it's possible to put the motors into "coast" to let them slow down normally. The Hitechnic manual says that it is possible. Does Robot C need a flag for that?
Yes, I am talking about DC Motors.

I'm pretty sure that it 'throws away' the 16 extra bits; I had a program print the nMotorEncoders value to the NXT screen, and it overflew at 32,767 mark. There could have been an unseen conversion to 'short' (16-bit) somewhere else in the program (when I was passing the nMotorEncoders value to the print function?), but I certainly didn't see it. >.<

I've looked for a way to set the motors in to 'coast', but all I've been able to find is LEGO-specific functions (RobotC has LEGO and DC motors split up, EX. there's nPIDUpdateInterval for LEGO, and nPIDUpdateInterval12V for DC) for coasting vs breaking; no DC . I'll play around with a spare motor later on today, though, to see if any of this will apply to DC motors.

Thanks for the input!
__________________
FRC - Team 1885 - Programmer.
Reply With Quote
  #4   Spotlight this post!  
Unread 12-22-2009, 03:27 PM
DonRotolo's Avatar
DonRotolo DonRotolo is offline
Back to earth once again
FRC #1676 (Pascack PI Oneers)
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Montvale NJ
Posts: 6,397
DonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond repute
Re: [FTC]: Breaking DC Gearboxes Fix

Quote:
Originally Posted by buddyb View Post
Additional note: Thanks to the NXT using 16-bit unsigned ints for Encoder values, it is highly suggested that you not use PID control on your shooter, or any peripheral using 9:1 or greater gear ratios, at that. When the encoder values overflow [the motors reach 32,565 faster than you'd think], the PID control algorithm slams the motor to -100 power (or 100, if you were having that motor go in reverse). This also tore up a few gearboxes.
Good info, thanks.

A better design would account for the possibility of overflows and handle them gracefully, instead of allowing them to wrap like that.
__________________

I am N2IRZ - What's your callsign?
Also visit TARPN to see what's up!
Reply With Quote
  #5   Spotlight this post!  
Unread 12-23-2009, 09:59 AM
ethan_orion ethan_orion is offline
Registered User
FTC #0071
 
Join Date: Oct 2009
Location: Wyoming
Posts: 45
ethan_orion will become famous soon enoughethan_orion will become famous soon enough
Re: [FTC]: Breaking DC Gearboxes Fix

any suggestions (or example code) on how to achieve this slow down in labview?

thanks.
Reply With Quote
  #6   Spotlight this post!  
Unread 12-26-2009, 11:45 PM
buddyb's Avatar
buddyb buddyb is offline
Registered User
FRC #1885 (ILITE)
Team Role: Programmer
 
Join Date: Dec 2009
Rookie Year: 2008
Location: Haymarket, VA
Posts: 65
buddyb has a spectacular aura aboutbuddyb has a spectacular aura aboutbuddyb has a spectacular aura about
Re: [FTC]: Breaking DC Gearboxes Fix

Quote:
Originally Posted by Don Rotolo View Post
Good info, thanks.

A better design would account for the possibility of overflows and handle them gracefully, instead of allowing them to wrap like that.
Yeah. If you really need the PID control, though, maybe you could make a function to unset it, set the encoder values to 0, wait 10MS (for the changes to reflect in the hardware), then re-set the PID control?

It's the only thing I can think of doing; I don't really want to test it that badly, though. Sorry.

Quote:
Originally Posted by ethan_orion View Post
any suggestions (or example code) on how to achieve this slow down in labview?

thanks.
It's been quite a while since I've used LabVIEW, so, I'll try the best I can to recommend how to code it. If anyone wants to suggest something different, feel free.

I will assume that you can get this set up so that the revving down can run as a second task, of sorts. If not, I can try to find some examples online, if you would like.

We first need to do some set-up, though. Create a new boolean variable for the action you want to trigger the revving up and down with (likely a button). For each motor you want to rev down, create a number value that will contain its current power. Every place you set that motor's power, have it update the corresponding motor power variable to reflect the new power.

So, if you have Button 2 to set the motor's power to 75, have button 2 also set your custom Button 2 Power variable to 75.

Now that we're done with that, we can begin making the task.

Have an infinite (while) loop as the 'body' of the task; we want this monitoring the robot the whole time.

Inside of it, add a switch statement, and have it check the Button X Pressed boolean you made earlier.

If the condition is FALSE, have it wait 30MS (If it doesn't wait, bad things may happen).

If the condition is TRUE, have it begin another while loop. We want this loop to run until all motors we want to rev to 0 power are at 0. So, it would be until Motor 1 Power = 0 and Motor 2 Power = 0, etc.

Now, inside of the loop you've just created, have another switch statement for each motor you want to rev down (so, if you had two motors, you'd have two more switch statements).

In these switch statements, we'll want to check to see whether each motor's power is within 10 of 0. So, we'd take the absolute power of the motor value, and see if it's less than or equal to 10. If this is true, we want to set the motor's power VARIABLE to 0. (not the motor yet)

If it's false, however, you need to make *another* switch statement. [Fun, isn't it?] Have it check to see whether the motor power is positive or negative (using the variables we created earlier). If the power is positive, subtract 5 from the variable. (skip setting the motor for now). Otherwise, add 5 to the variable.

Now, get out of both of the switch statements we just created (so we're in the loop that checks to see if the powers are not equal to 0). In here, set the motor's powers to the variables.

In my messed up form of pseudocode, it will look a bit like this:
Code:
while(1>0):
  Is button x pressed?
    YES:
      while(Motor A Power [variable] is not 0):
        Is |Motor A Power [variable]| < 10?
          YES:
            Set Motor A Power [variable] to 0. 
          NO:
            Is Motor A Power < 0?
              YES:
                Add 5 to Motor A Power [variable] 
              NO:
                Subtract 5 from Motor A Power [variable]
        Set Motor A Power [actual motor power] to Motor A Power [variable]
  NO:
    wait 30MS
I hope this helps! If not, I can try to make something in LabVIEW up when I am allowed back in to School (around January 5th), and if you have any questions, feel free to post back here, or contact me directly.

Best of luck,
Buddy
__________________
FRC - Team 1885 - Programmer.
Reply With Quote
Reply


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
[FTC]: FTC Futures Forum at FTC World Championship gdo FIRST Tech Challenge 0 04-08-2009 05:46 PM
[FTC]: FTC]: FTC Champ Tournament - Ontario (Scoring Breakdown) Mr. Lim FIRST Tech Challenge 2 03-03-2008 10:54 AM
[FTC]: [FTC]: Ontario Provincial FTC Start/End Times cbhl FIRST Tech Challenge 8 12-16-2007 12:37 PM
FP burning out Max Lobovsky Motors 6 02-24-2004 06:52 AM
Burning IR sensors LittleProton Electrical 5 02-06-2004 08:02 AM


All times are GMT -5. The time now is 04:25 AM.

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


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