Using a limit switch to limit motion

[ManicMechanic]

(This question is from a team member who's skittish about signing up for CD )

We use R/C tank commands to move an arm, but it damages the gears if we go past a certain point. Our design uses a limit switch to detect when we get near the breaking point. What we want to do is program the R/C controls to allow it to go in one direction (away from the breaking point), but not in the other direction (across the breaking point) when it hits the limit. That way, if someone keeps pushing the joysticks forward, it would stay in one place, then if they reverse the joy sticks, it moves back into the "safer" zone.

So far, the only thing we can get it to do when the limit switch detects the breaking point is to use motor commands to reverse the direction for a bit, then revert back to R/C. If someone keeps the joysticks pressed up, it goes up to the limit, then down, then wobbles up and down again, which we don't want. Is there any way to just disable the joysticks so it stops when it reaches the limit but comes back down when the joysticks go in reverse without wobbling?

We are using EasyC for Vex.

[AdamHeard]

Originally Posted by ManicMechanic

(This question is from a team member who's skittish about signing up for CD )

We use R/C tank commands to move an arm, but it damages the gears if we go past a certain point. Our design uses a limit switch to detect when we get near the breaking point. What we want to do is program the R/C controls to allow it to go in one direction (away from the breaking point), but not in the other direction (across the breaking point) when it hits the limit. That way, if someone keeps pushing the joysticks forward, it would stay in one place, then if they reverse the joy sticks, it moves back into the "safer" zone.

So far, the only thing we can get it to do when the limit switch detects the breaking point is to use motor commands to reverse the direction for a bit, then revert back to R/C. If someone keeps the joysticks pressed up, it goes up to the limit, then down, then wobbles up and down again, which we don't want. Is there any way to just disable the joysticks so it stops when it reaches the limit but comes back down when the joysticks go in reverse without wobbling?

We are using EasyC for Vex.

I am not familar with easy C, but put in an if statement like this (psuedo code);

if (Limit being hit AND motor being driven towards being hit [aka wrong way])
{
motor = 127;
}

This will cause the arm to stop when it hits the limit switch, but you can still drive it in the other direction (I'll admit the first time I tried this I just had it stop when the switch was hit.... So, the arm was stuck).

[DonRotolo]

If you are holding the joystick against the limit, then what code allows the motor to 'reverse' when it hist the switch? Don't let it do that, just make it so the motor won't see a PWM value on the "too far" side of 127.

Pseudo Pseudocode:

Do Tank Drive
While (Limit_Switch_Too_Far_Up=1)
  If Motor Input < 127, then Motor Input = 127
End While

Don

[RyanCahoon]

It sounds almost like your code may be fine, but gravity is pulling the arm down once power to the motor is removed.

Try using a PID algorithm (check the whitepapers if you need help on this) to keep the position static (this would require a sensor such as a potentiometer, however; limit switches wouldn't be enough). An alternate solution would be instead of turning the motor off when it reaches the top limit, to just apply a small constant force with the motor to keep the arm stable. Of course, this would not help if someone tries to push down on the arm or the arm's weight changes.

If you were using a FRC control system instead of VEX, a third *possible* solution that doesn't even involve programming would be to place the Victor into "brake" mode instead of "coast." Again, this is for FRC; I don't think VEX motors have this option.

Hope this helps. Try having your team member post his/her code too, it helps us when solving problems to know where you're starting from.

--Ryan

[slavik262]

It's possible it's a gravity thing, but if not:

If (input > 127 && limit == 1)
motor = 127;

else
motor = input;

This code simply stops the motor from going forward once it hits its limit.

replace "input" with your input, "limit" with your limit switch and "motor" with the pwm to the motor

If you want to take it to the next step, you could use a potentiometer to keep track, with the use of a variable, what the location of arm is and automatically have it slow down when it reaches a certain point, and stop when it reaches tht limit. Assuming the pot had a range of 0 to 255, the code would look something like this:

#define Upper_Value 225 //This will slow the motor once the arm reaches within 30 of its max
#define Lower_Value 30  //This will slow the motor once the arm reaches within 30 of its minimum
#define Slow_Speed //The speed in either direction which you want the motor to slow to once it reaches either value
unsigned short Pot_Value; //Declare a variable to keep track of your potentiometer value

Put these #defines at the top of your code. Wherever the name is used in the code, the value will be stubstituted in. Also declare a variable called Pot_Value to keep track of your potentiometer value

Pot_Value = pot_input; //Update the potentiometer value

if (input > 127 && Toplimit == 1) // If the top limit switch is pressed and the joystick is being pressed forward
	motor = 127;  //Stop the motor, regardless of input

else if (input < 127 && Bottomlimit == 1) // If the bottom limit switch is pressed and the joystick is being pressed forward
	motor = 127;  //Stop the motor, regardless of input

else if (Pot_Value => Upper_Value && input > 127) //If the arm is at or past the upper value and joystick is pressing upward
	motor = 127 + Slow_Speed; //Set the arm to forward slow speed

else if (Pot_Value =< Lower_Value && input < 127) //If the arm is at or below the lower value and joystick is pressing down
	motor = 127 - Slow_Speed; //Slow the arm to reverse slow speed

else //If the arm is between the limits
	motor = input; //assign the motor directly to your input

Again, replace "input" with your input, "motor" with the pwm to the motor, Toplimit with the top limit switch, Bottomlimit with the bottom limit switch and "pot_input" with your potentiometer input

Feel free to PM me if you have any questions.

[EricS-Team180]

Four excellent posts there.

When using pots, consider using a delta when setting position limits. That is, pots can slip and the readings at your starting and limiting positions may not be what you originally set them to be. You can make pot calibration a pit maintainence item, but you can also make the starting and limit positions, variables, rather than hard-wired values. If you measure the change in pot reading from your initial position to your limit position....then:
1)At the start of a match, you can read the pot's start position.
2)Add the previously measured delta and set your limits to be used for the current match.
This helps prevent hardware damage, if you pot mounting has slipped.

Limit switches can be a blessing and a curse. In 2005, we had a lift on our 'bot that used shaft encoders and limits for positioning. We also included a manual override that ignored the encoders and simply depended on the limit switches. During the course of competition, our operator chose to ignore our lift position pre-sets - based on the encoders - and position the tetras manually. This put a real pounding on the limits that those of us in the pit did not realize was happening. In a quarter-final match at Nationals that year, the upper limit broke. Since our operator was running manual override, and we did not use the encoders as a back-up "limit switch" we actually pulled the entire lift out of it's base while on the field. (if you're goin' down, you might as well go down in flames - ha!) So, keep a bunch of spares and expect to replace them from time to time

[billbo911]

EDIT: Please ignore my comments below, they DO NOT apply to Vex, only to FRC. Thanks to Alan for pointing out my error.


All of these methods work well. Each has it's own advantages, but......

For the sake of sheer convenience, the default code already has built into it, motor limit switch inputs. If you simply set a motor to 127 when it hits the limit, you will never be able to back it out until you power down. So, the limits in code prevent the motor from turning in one direction, while allowing motion in the other. There is a pair of limits for each motor, one for each direction. All you need to do is connect a limit switch to the correct digital input and position the switch where it is needed.
These are documented in one of the IFI manuals for the RC/OI. Get all of the manuals when you go to IFI, they are well worth it!

[Alan Anderson]

Originally Posted by billbo911

For the sake of sheer convenience, the default code already has built into it, motor limit switch inputs...These are documented in one of the IFI manuals for the RC/OI. Get all of the manuals when you go to IFI, they are well worth it!

How does one use the IFI-documented limit_switch() functions in EasyC?

[billbo911]

Originally Posted by Alan Anderson

How does one use the IFI-documented limit_switch() functions in EasyC?

Dang... I need to clean my glasses. I completely missed that.
Worst of all, it makes all the difference in the world. I guess I need to edit my post.
Thanks for catching me with my pants down.

[charrisTTI]

Originally Posted by EricS-Team180

Four excellent posts there.

When using pots, consider using a delta when setting position limits. That is, pots can slip and the readings at your starting and limiting positions may not be what you originally set them to be. You can make pot calibration a pit maintainence item, but you can also make the starting and limit positions, variables, rather than hard-wired values. If you measure the change in pot reading from your initial position to your limit position....then:
1)At the start of a match, you can read the pot's start position.
2)Add the previously measured delta and set your limits to be used for the current match.
This helps prevent hardware damage, if you pot mounting has slipped.

Limit switches can be a blessing and a curse. In 2005, we had a lift on our 'bot that used shaft encoders and limits for positioning. We also included a manual override that ignored the encoders and simply depended on the limit switches. During the course of competition, our operator chose to ignore our lift position pre-sets - based on the encoders - and position the tetras manually. This put a real pounding on the limits that those of us in the pit did not realize was happening. In a quarter-final match at Nationals that year, the upper limit broke. Since our operator was running manual override, and we did not use the encoders as a back-up "limit switch" we actually pulled the entire lift out of it's base while on the field. (if you're goin' down, you might as well go down in flames - ha!) So, keep a bunch of spares and expect to replace them from time to time

The actual switch should not be the hard mechanical stop. Design the mounting of your switches so that something else takes the force of the overdrive.

[billbo911]

Now that I have cleaned my glasses.....

One way that you can do what you need is to create you own functions like the ones in the FRC default code that I will copy in here. Just use these in place of the code you are now using that forces your arm back and then allows it to move forward again.

These examples are straight out of the default code and will need to be modified to match your existing code. These are examples only, and will not work "as is".

void Limit_Switch_Max(unsigned char switch_state, unsigned char *input_value)
{
  if (switch_state == CLOSED)
  { 
    if(*input_value > 127)
      *input_value = 127;
  }
}

And

void Limit_Switch_Min(unsigned char switch_state, unsigned char *input_value)
{
  if (switch_state == CLOSED)
  { 
    if(*input_value < 127)
      *input_value = 127;
  }
}

These two functions allow the motion to be limited in one direction, but not the other.

For your code, substitute in your PWM to be limited for "*input_value" and your limit switch input for "switch_state".

I assume someone on your team understands code, at least in a limited way, otherwise you would not have been able to get your code operating the way it is already. They should be able work with these.

[ManicMechanic]

Thanks for all the suggestions. Potentiometers are a bit beyond us (we're FTC, and I don't think Vex has a pot), but the gravity suggestion got us thinking that we need little or no motor input to back away from the limit. Before, we were running the motors at full power when we backed away, so there was lots of wobble. Slowing the motors, there was far less wobble, and it's now in the tolerable range.

[EricS-Team180]

Originally Posted by charrisTTI

The actual switch should not be the hard mechanical stop. Design the mounting of your switches so that something else takes the force of the overdrive.

<sigh> Too true. We were between a rock and a hard place (HA! no pun intended) on the location of those limits on the sliding mechanism (a series of drawer sliders). Spent all season dealing with it...a lesson learned in the end.

[slavik262]

Originally Posted by ManicMechanic

Thanks for all the suggestions. Potentiometers are a bit beyond us (we're FTC, and I don't think Vex has a pot), but the gravity suggestion got us thinking that we need little or no motor input to back away from the limit. Before, we were running the motors at full power when we backed away, so there was lots of wobble. Slowing the motors, there was far less wobble, and it's now in the tolerable range.

Potentiometers are possible with Vex. Anyways, there is simple code to limit your joysticks from going full force on the way down.

http://www.chiefdelphi.com/forums/sh...ad.php?t=59901

The entire thread is useful, but the simplest way to do it is located in the second-to-last post.

[ChrisH]

Originally Posted by slavik262

Potentiometers are possible with Vex. Anyways, there is simple code to limit your joysticks from going full force on the way down.

http://www.chiefdelphi.com/forums/sh...ad.php?t=59901

The entire thread is useful, but the simplest way to do it is located in the second-to-last post.

A little birdie told me that Vex will be selling pots early in the new year.