Currently my team is having problems with our arm. We weighed our manipulator, and it weighs 19 newtons. (around 4.4lbs). We tried lifting our arm with 2 HS motors and 1 269 motors, and the arm can lift. I know that 2hs motors and 1 269 motor can hold 34lbs (around there) But the problem we are encountering is that the arm can’t hold its position. Like we always have to hold the joystick slightly to get it to stay at a certain height. Currently we are geared at a 1:7.
We are also using rubber bands to help with the load, but it still falls down. When we use too little it doesn’t really have an effect. But if we use too much the arm won’t go back down to its starting position, and doesn’t stay at certain positions yet. Should we still use rubber bands?
What should we do to fix this problem? I know we could change the gear ratio, but 2 hs motors and 1 269 motor seems like a lot of torque.
for pretty much any arm AURA builds we add a programmed “Arm Reverse”. Basically when no control is being sent to the robot for the arm we drive the arm up with a slow speed (its the equivalent of you hold the joystick forward a tiny bit)
If you are using joysticks though you might want to watch out because they don’t always center on 0 you might find only activating it when the joystick is on 0 fails instead activate it between -10 and 10
Use an encoder or pot to sense the arm position and then have the software control the motors to maintain the desired position in the absence of any user input.
We find that this wears out the motors. If you have current being sent through the motors, and they are not moving, there is a big possibility that they will burn out. In fact, that’s why motors burn out a lot of the time, because there is no counter-current being generated. If you want a more in-depth explanation, just google why motors burn out.
Now to answer the question posted, yes, this is a great example of where programming can be a lifesaver in driver control. Basically, you don’t want the joystick to control the arm directly. You want the joystick to control a variable which refers to the position of the arm. If that’s unclear, let me explain: Say you have a variable called armPosition. This variable holds the position that you want the arm to be at. A separate task keeps the arm at this position, so that you do not have to (of course, you will need a sensor for this, either a potentiometer, or an encoder). Yhat your joystick does, is change the value of the variable armPosition. Then, as soon as arm position changes, the task that keeps the arm at armPosition, will do its job, and keep the arm there. So you do not have to worry about how weight will affect the arm staying in position, and how much you haveto pull on the joystick. The program does it all for you. If you are using ROBOTC, I can help you with this, but if you are using EasyC, you’ll have to ask someone else because I have no experience with it.
On a non-programming basis for help, have you tried using latex tubing http://www.vexrobotics.com/products/accessories/structure/275-1262.html instead of rubber bands? Our team has found they work much better than rubber bands.
Where are the rubber bands attached? An idea that might work is to extend the arm past the fulcrum and attach the rubber band there; increasing the effective leverage the bands have on the arm making it easier for them to keep the arm from falling down.
picture:
…I
]]]]]]]]]]]]]()]]]]]]]]--------
…I
I = axle
] = arm
() = where the axles goes through the arm
------ = rubber bands
(ignore the dots before the I)
Second, is that gear ratio for speed or torque? (I’m assuming torque but it is always good to ask) Creating a complex gear train might work to prevent the arm from falling down. From what I have seen (and I could be completely wrong, there are way smarter people than me on this forum :o) the torque the engine produces when active has little to do with keeping the arm in a static position when the motor is off. The internal gear ratio and the resistance produced by the coil does, and this combined with the friction and the gear ratio between the arm and the engine produces the “staying power” which keeps the arm up. The torque produced by the arm is not strong enough to “break” the friction keeping those parts from moving and that is what keeps the arm from descending. Reducing the weight of the intake mechanism and arm could help also, as that would reduce the torque on the gear ratio and engines.
Hope this makes sense and is helpful,
I would also suggest Surgical Tubing instead of rubber bands because they can stretch about three times their length without perminantly stretching out.
First, it is really important that your are at least offseting your towers weight if not providing positive upwards assist. This way your motors are only really lifting the weight of the game objects. Assuming say 4-5 game objects that could be up to about 2-2.5 lbs of weight right there that your arm has to lift in addition to itself. Because of this your motors still need to be geared appropriately; 1:7 seems fine for this application **so long **as your arm’s weight is actually offset. If your really want to be certain that arm is staying where it’s at vex sells worm gears. These can’t be backdriven so they may provide an idea mechanical solution for you.
What I suspect I happening is that because you are using rubber bands to offset your 4.4 lbs arm when your arm is up the rubber bands are becoming loose and no longer offseting all of your arm’s weight. Then when you go try to place your arm into a position it will sink until the rubber band again are tight enough to offset your arm. Although I can’t see your arm so I don’t know if this is a problem if it is the case I would suggest moving your bungee point closer to your arm’s pivot point. Although this will require more rubberbands the total distance the bungee will unstretch as your arm goes up will decrease thus your rubber bands will not loosen as quickly and provide more constant force throughout your arm travel. Also worth noting is that the worse point when your arm needs the most assistance is at the bottom of its arc (presumably collecting) This is because none of the weight is supported over the pivot point. As more weight is supported over the pivot point the arm (theoretically) needs less assist.
Or you could just use surgical tubing and stretch it really tight so the difference in tension is negligable when the arm is up/down. (This is what I would do.)
Magicode how does this look? Could you post how the code should look because it would help me understand. Also we have a scrimmage tomorrow, and our driver would like to have the arm staying at the position then. Lastly I live in Hawaii so it will be difficult to have both of us communicate to get the code working by then, and also I don’t have robot c with me right now.
it is recommended to write code that motor would only start holding the arm when there is no command for lifting or dropping, and the height is above a certain value that the arm is needed to be hold at. Also, the output should varies between a certain range. for instance, 10 @ the lowest position, 20 @ the middle position, and 15 @ the highest position. these measures may reduce power cost and less heat would generate, compared with setting the output at the maximum value regardless how much force it really needs.
in addition, we have been using this method for two months and NONE of the arm motor had burnt out. therefore, you’d better check how heavy the arm is and what the minimum output is. the maximum output requirement of our robot is 20, and 10-15 is generally acceptable.
while(true)
{
while(motor[port2]= vexrt[ch2])
{
if(motor[port2] >15)
{
motor[port2] =0;
}
else
{
motor[port2] = 15;
}
}
}
How does this code look?
I really need to get the correct code working in the next 2 hours. So could someone please post how this code should look. You can tell that I’m trying.
*I don’t have robot c with me right now. (Labtop is at school)
I’m going to demonstrate this code with multitasking because I think that it makes it easier to add more functionality later, but it can be done other ways.
int armPosition = 0;
const int ERR_MTRPWR_RATIO = 5;
const int MTR_THRESH = 20
const int MAX_ARM = 3000;
const int MIN ARM = 500;
const int ARM_POS_CHANGE_RATE = 10000;
cont int JOY_THRESH = 10;
int motorPower = 0;
task keepArmStraight(){
while(true){
motorPower = (armPosition - SensorValue[armPot]) * ERR_MTRPWR_RATIO;
motor[arm] = abs(motorPower) > MTR_THRESH ? motorPower : 0;
endTimeSlice();
}
}
task main(){
StartTask(keepArmStraight);
while(true){
if(abs(vexRT[Ch2]) > JOY_THRESH){
if(armPos < MAX_ARM && armPos > MIN_ARM){
armPos += sgn(vexRT[Ch2]);
}
wait1Msec(ARM_POS_CHANGE_RATE / vexRT[Ch2]);
}
endTimeSlice();
}
}
Now I’ve written this code without ROBOTC in front of me, so there may be syntax errors or such, but the logic should be good.
You will have to tweak the constants to get the arm to stay straight properly. Plug in values and see which values work best. The constants are named as to be self explanatory, but if something is confusing, let me know. This is just example code, and to mesh this with other functions for the robot will require you to change it. Let me know if something doesn’t work, or you need more explanation.
Cool your online. So could you explain the code to me.
Where is the potentiometer part, and thank you so much for your help.
Where would I change the values?
const int ERR_MTRPWR_RATIO = 5;
const int MTR_THRESH = 20
const int MAX_ARM = 3000;
const int MIN ARM = 500;
const int ARM_POS_CHANGE_RATE = 10000;
cont int JOY_THRESH = 10;
const int ERR_MTRPWR_RATIO = 5;
const int MTR_THRESH = 20
const int MAX_ARM = 3000;
const int MIN ARM = 500;
const int ARM_POS_CHANGE_RATE = 10000;
cont int JOY_THRESH = 10;
const int ERR_MTRPWR_RATIO = 5;
the point of the program is to keep the arm at a certain position, right? Thsi means that the program must use the potentiometer to determine how far away the arm is from the value that you want it to be at, and set the motor power accordingly. This variable sets how much the motor responds to the error in the distance. For example, if you want the arm to be at position 2000, and it’s at 1600 right now. That’s a difference of 400, so so you want the motor to move at a high power (depending on how your gearing is set). if that difference was only 50, you want the motor to move at a lesser power. This variable decides how much the motor moves per unit of error. And looking at this now, I realize that 5 is much too high a number. You will need a decimal. Since an int can’t be a decimal, you might want to divide by ERR_MTR_RATIO instead.
const int MTR_THRESH = 20;
The threshold under which the motor should not move. You don’t ant your motor adjusting to an error of 5 in the potentiomer, because then it will keep jerking back and forth. If the motor power is too small, the motor just won’t move, and we don’t want the motor to be getting power and not moving. So this is a cutoff.
const int MAX_ARM = 3000;
Maximum potentiometer value to which the arm should go. You will have to physically put your arm in the highest position and see the value of the potentiometer.
const int MIN ARM = 500;
Minimum potentiometer value to which the arm should go
const int ARM_POS_CHANGE_RATE = 10000;
How fast you want the arm to go up when you move the joystick. Putting in a higher number will make the arm move slower.
cont int JOY_THRESH = 10;
The threshold below which the arm won’t respond to the joystick.