View unanswered posts | View active topics It is currently Sun Oct 26, 2014 1:58 am






Reply to topic  [ 6 posts ] 
Arm motor burning out 
Author Message
Rookie

Joined: Wed Dec 11, 2013 3:37 pm
Posts: 12
Post Arm motor burning out
I'd post this in another thread I made about the same arm a while back, but alas it appears to have been deleted in the data loss.

We've now burned out a motor attempting to program and use an arm with our robot, and we're down to the last motor, so I'd like to be certain that we've fixed the issue before implementing it. We have a motor at the top of our robot attached to two arms that connect together to carry a container that will fill with blocks. See this image for a hastily drawn picture of the setup that should convey the idea slightly better.

Anyway, we burned out this motor attempting to use it - this has not happened before, despite using what we believe to be the same code in another competition and in previous practices. Here's the code for the arm:

Note: Negative values are upward. Positive values are downward. The purpose of the rather complicated power equation is to decrease the power put to the motor as the arm reaches the top, and thus has less force of gravity acting down upon it (this was an issue in practice as the arm would swing wildly around)

Code:
if(joystick.joy2_y1 < -10){
         motor[Shoulder] = (joystick.joy2_y1/(4-(nMotorEncoder[Shoulder]/360))); //If heading up, power decreases as height increases
         moving = 1;
         nxtDisplayCenteredTextLine(5,"Moving Up");
      }
      else if(joystick.joy2_y1 > 10){
         motor[Shoulder] = (joystick.joy2_y1/(5+(nMotorEncoder[Shoulder]/360))); //If heading down, power increases as height increases
         moving = 1;
         nxtDisplayCenteredTextLine(5,"Moving Down");
      }
      else { //If the motor is stopped
         nxtDisplayCenteredTextLine(5,"Not Moving");
         if (moving == 1) { //If it used to be moving
            stopped = nMotorEncoder[Shoulder]; //Find the value that it stopped at
            moving = 0; //It now is stopped - don't reset the last value
         }
         if (nMotorEncoder[Shoulder] > stopped && nMotorEncoder[Shoulder] < -50) { //If it's [the encoder value's] above the position it was at when it stopped
            motor[Shoulder] = -1; //Adjust slightly to compensate
            }else if (nMotorEncoder[Shoulder] < stopped && nMotorEncoder[Shoulder] < -50) { //Now if it's [the encoder's value] below,
            motor[Shoulder] = 1; //Adjust again
            }else if (nMotorEncoder[Shoulder] < -50) { //If it's at the correct position
            motor[Shoulder] = 0; //Ensure that the motor is stopped
         }
      }


Now, after about an hour of simply looking at code trying to discover the issue, we noticed that the value of the joysticks did not settle at 0 when left alone - they settled anywhere from -7 to 7. Thus, we thought that (because these motors have PID enabled) the motor was stressing attempting to push downward against the ground when it was at resting position. So, we added limits to the points at which it will allow movement (Past 10 or -10).

However, as I said, we have just 1 motor left and a competition fast approaching, so we're extremely hesitant to implement this until we're certain that we won't burn out another motor.

Any help? Does anyone see any issues, or know of a way to do this that will put less strain on the motors?


Last edited by FTC Participant on Fri Jan 17, 2014 11:00 pm, edited 3 times in total.



Fri Jan 17, 2014 6:51 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Arm motor burning out
The code is very hard to understand with the sign reversed. It sounds like when you pull the joystick back, the arm is actually moving upward? If the motor value is positive, does the arm move upward or downward? Assuming when the joystick value is negative (i.e. < -10), the motor will get negative power and the arm is moving upward. This means (4 - nMotorEncoder[Shoulder]/360) must be positive. I am trying to figure out what the motor power value looks like when the arm is moving up. Since the motor power is negative, I am assuming the encoder value also heads to increasing negative value which means nMotorEncoder[Shoulder] cannot be > 1440 and must be heading to the negative direction. Not knowing all this, I can't tell you if there is anything wrong with the equation. For your arm design, if power is removed, would it drop? If the arm can maintain position without power, you need to stop the motor when the joystick is within deadband (i.e. between -10 and 10). However, the last part of the code was assigning either 1 or -1 to the motor suggested that your arm may drop without power and you are attempting to give it a small value so it will "brake" and hold position. If that's the case, I am confused because it also suggested the encoder value is lower when the arm is lower (encoder value is higher when the arm is higher). This is in conflict with my assumption that the encoder is reversed (lower value when arm is high).
In other words, you need to describe in more details on your arm design and configuration.


Fri Jan 17, 2014 9:43 pm
Profile
Rookie

Joined: Wed Dec 11, 2013 3:37 pm
Posts: 12
Post Re: Arm motor burning out
Apologies, I'll try to answer all of your questions and then some.

When the joystick is pulled back, the arm moves up, correct. We originally intended to change this, but by the time we got around to it the driver was used to it and preferred it that way. The value of nMotorEncoderShoulder decreases (becomes more negative) as the arm moves up.

So for example, at position -100, the power is (Joystick Value)/(4 - (-100)/360), so the joystick value divided by about 4.3 - this is good, it needs higher powers at lower positions to counteract gravity.

Now when it gets up to higher values, around -700 (The highest it will ever go to for our purposes, though technically it can turn about to -1000), the power will be (Joystick Value)/(4 - (-700)/360), so the joystick value divided by about 6 - a lower value for the lesser force of gravity. Not a drastic change, but it did seem to make a difference in testing.

The value of the encoder, because of hardware constraints, will always remain in the range between about -1000 and 20 - it zeros out at the low point, but that's slightly above what you can do if you push it back a bit.

Quote:
However, the last part of the code was assigning either 1 or -1 to the motor suggested that your arm may drop without power and you are attempting to give it a small value so it will "brake" and hold position.


This is correct.

With the current motor set up, the motor will drop if the power is released. If there's an easier way to brake than my current code, I'd love to know it.

Quote:
If that's the case, I am confused because it also suggested the encoder value is lower when the arm is lower (encoder value is higher when the arm is higher). This is in conflict with my assumption that the encoder is reversed (lower value when arm is high).


Crap, I don't know why the comments are like that. I think when I was writing that my "it" was the encoder value, but I see now that that's extremely confusing. Your initial assumptions were correct. Negative values are upward.


One thought I'm having now - will the low value used when attempting to keep the motor in place put strain on the motor? Will attempting to hold up the motor with that little power for a time (usually less than 2 seconds) burn out the motor?

And one other thing - when we were testing the code, using the 'Competition mode' joystick controls in RobotC, we found that the values of the joystick were generally not 0 when the joystick was left alone. They ranged anywhere from 0 to 7 in either direction. So that was when we changed the range at which the power would change from -1 and 1 to -10 and 10, because we thought that that might have been the issue - the arm pushing down against the ground and straining the motor.


Fri Jan 17, 2014 10:24 pm
Profile
Rookie

Joined: Wed Dec 11, 2013 3:37 pm
Posts: 12
Post Re: Arm motor burning out
Alright, so I ended up removing the code at the end that kept the arm stable when the driver wasn't controlling it. It simply wasn't worth the risk of the motor burning out, and the driver was generally didn't need the extra stability.

I kept a similar code in during the autonomous, because that did need stability, but the ~2 seconds of holding the motor still didn't seem to put any undue strain on the motor, and we didn't burn out a motor throughout the competittion.

We qualified, and I'm looking forward to our regionals :) Thank you for the help


Mon Jan 20, 2014 2:06 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Arm motor burning out
That's strange. Are you saying removing the code "motor[Shoulder] = 1" and "motor[Shoulder] = -1" prevents the motor from being fried? Was your arm really holding when the "motor[Shoulder] = 1" code was in? I can't imagine how much current was flowing through the motor with that low value that could fry the motor. After the season is over, I should put the motor output under an oscilloscope and figure out what's going on. That is a good scenario to learn about. Would you confirm that's indeed your scenario?


Tue Jan 21, 2014 5:38 am
Profile
Rookie

Joined: Wed Dec 11, 2013 3:37 pm
Posts: 12
Post Re: Arm motor burning out
I unfortunately can't confirm that for certain. We made a lot of attempted fixes before the competition in the hopes that one of them would work, and apparently one did. Lots of mixed variables, so I can't say with certainty that any one of them was the one that did it. I can, however, give a list of things that we did try.

1. Added the threshold code. I'm relatively new to RobotC (First year, but I worked with C++ in the past), so I wasn't aware of the necessity of a joystick threshold code. Once I noticed on my own the drift, I added the threshold in, but that wasn't until after the motors had burned out and I was looking all over the place for a possible cause. Because PID was enabled, any pressure causing the arm to push downward (possibly due the drift) would likely have been magnified, causing the motor to stall.

2. Took out the equation that calculated the power and just replaced it with a simple Joystick_Value/10. Because it was such a comparatively complex equation, we couldn't be sure that it didn't have some unintended side effect, so we took it out just in case. I think this is a rather unlikely cause, but it was possible and we didn't want to take any chances.

3. Finally, removed the stability coding that you mentioned, yes. To me this seemed like the most likely cause, because in research I did I found multiple instances of people saying that using low power with no movement is likely to burn out motors (like this and this and this (third post)), so I wasn't willing to take the risk.

Sorry I couldn't be of more help, but we didn't really have the resources to try different solutions until one of them worked :P


Sat Jan 25, 2014 4:25 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 6 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.