[FTC]: Breaking DC Gearboxes Fix

Other FIRST Tech Challenge
1

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

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

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

nt.txt (2.14 KB)


nt.txt (2.14 KB)

2

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?

3

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! :smiley:

4

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.

5

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

thanks.

6

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.

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

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:

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

Best of luck,
Buddy