Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Limit switches on a lift -- best practice (http://www.chiefdelphi.com/forums/showthread.php?t=109302)

F22Rapture 27-10-2012 15:16

Limit switches on a lift -- best practice
 
So, I'm porting over our 2012 Robot to Java and I was wondering about how best to use limit switches within the confines of the command-based template. OI runs the raise/lower commands while a button is being held. Would it be best to put the limit switch code within the subsystem methods like so:

Code:

private CANJaguar liftMotor1;
    private CANJaguar liftMotor2;
   
    private DigitalInput upperLimitSwitch;
    private DigitalInput lowerLimitSwitch;

public void initDefaultCommand() {
        // Set the default command for a subsystem here.
        setDefaultCommand(new ArmDoNothing());
    }
   
    public Arm() {       
        initCAN();       
    }

.....

public void doNothing() throws CANTimeoutException {
        liftMotor1.setX(0.0);
        liftMotor2.setX(0.0);
    }
   
public void raiseArm() throws CANTimeoutException {
        while(!getTopLimit())
            {
                liftMotor1.setX(0.1);
                liftMotor2.setX(-0.1);
            }
    }
   
public void lowerArm() throws CANTimeoutException {
        while(!getBottomLimit())
            {
                liftMotor1.setX(0.1);
                liftMotor2.setX(-0.1);
            }
    }
   
public boolean getTopLimit() {
        if(upperLimitSwitch.get()) {
            return true;
        } else {
            return false;
        }
    }
   
    public boolean getBottomLimit() {
        if(lowerLimitSwitch.get()) {
            return true;
        } else {
            return false;
        }
    }

(and as an aside, I've tested none of this, and I'm sure I probably did something wrong, but you get the point)

Or, would it be best to put the limit switch code within the Commands under execute() or isFinished()? Which I assume would go something like:

Quote:

protected void execute() {
while(!arm.getTopLimit()) {
try {
arm.raiseArm();
} catch (CANTimeoutException ex) {
System.out.println(ex);
}
}
}
or

Code:

boolean stop;
    // Called repeatedly when this Command is scheduled to run
    protected void execute() {
        if(arm.getTopLimit()) {
            stop = true;
        } else {
            stop = false;
        }
       
        try {
            arm.raiseArm();
        } catch (CANTimeoutException ex) {
            System.out.println(ex);
        }
    }
   
    // Make this return true when this Command no longer needs to run execute()
    protected boolean isFinished() {
        return stop;
    }

Are they all more or less equivalent, or is there one way that has significant advantages over the others? Also, am I doing this completely wrong :confused:

Ginto8 27-10-2012 21:24

Re: Limit switches on a lift -- best practice
 
To me, dealing with limit switches is a problem internal to the Subsystem - if it had to be dealt with by Commands, it would make every one of your Commands more complicated, which to me seems like insufficient abstraction. As for how to do it, I'd probably do something similar to how WPILibJ's PIDController works - use an internal TimerTask or Thread to handle the checking and overriding. That way, it doesn't matter what the Commands try to do - the Subsystem simply won't allow it to go beyond the limits.

virtuald 28-10-2012 15:20

Re: Limit switches on a lift -- best practice
 
A better way to do it is connect the limit switch directly to the Jaguar, so then you don't have to write any software to make it work :)

nighterfighter 28-10-2012 15:46

Re: Limit switches on a lift -- best practice
 
Quote:

Originally Posted by virtuald (Post 1191919)
A better way to do it is connect the limit switch directly to the Jaguar, so then you don't have to write any software to make it work :)

We did this in 2011, and when it worked, it was GREAT.

However there was a problem with the CAN software in 2011 where if a limit switch was pressed and connected to the jaguar when the robot was turned on, it would cause the scrolling CAN error. (Hundreds of error messages, resulting in a robot that couldn't move)

I'm not sure if this was fixed. It probably was.

And you might still need some software to prevent the lift from going full speed into the limit switch. Ouch.

F22Rapture 28-10-2012 18:08

Re: Limit switches on a lift -- best practice
 
We haven't messed around with direct sensor-Jaguar control yet, so I don't know how it all works, but I'm not sure it would work for our situation. We used a screw-style lift (lead screw) which needs limit switches on both the top and the bottom. We also used two motors to drive the lift, which means two Jaguars because the GDC doesn't allow running two motors off of one controller. Correct me if I'm wrong but the Jaguar only allows input from one sensor at a time; and we need it to be able to accept from two. And since we have two Jaguars that also means we'd need 4 limit switches unless there's some way to split or duplicate the signal to both of them.

ebarker 28-10-2012 19:48

Re: Limit switches on a lift -- best practice
 
The best way is to wire them to the Jag inputs, but if you are doing this for a FIRST competition I think the rule book requires you to wire them to the cRio and do the work in software.

Ether 28-10-2012 19:56

Re: Limit switches on a lift -- best practice
 

2012 Rule R58-J:

Limit switch jumpers may be removed from a Jaguar speed controller and a custom limit switch circuit may be substituted.




F22Rapture 28-10-2012 20:18

Re: Limit switches on a lift -- best practice
 
Quote:

Originally Posted by Ether (Post 1191942)

2012 Rule R58-J:

Limit switch jumpers may be removed from a Jaguar speed controller and a custom limit switch circuit may be substituted.




At that point, it's probably easier just to write the 10-12 lines of code it takes to control it with software.

So the general consensus was to put it on the subsystem side as opposed to in execute()?

Ether 28-10-2012 22:02

Re: Limit switches on a lift -- best practice
 
Quote:

Originally Posted by F22Rapture (Post 1191945)
At that point, it's probably easier just to write the 10-12 lines of code it takes to control it with software.

I believe what Rule R58-J is saying is that you can simply connect the limit switch to the Jag. That is a "custom circuit".



ratdude747 28-10-2012 22:59

Re: Limit switches on a lift -- best practice
 
Quote:

Originally Posted by Ether (Post 1191956)
I believe what Rule R58-J is saying is that you can simply connect the limit switch to the Jag. That is a "custom circuit".



Correct.

The reason they said "custom" circuit is that in spirit of the rule, it could be anything from a simple limit switch to some crazy ultrasonic circuit. You could even pop in a toggle switch for the rule cares.

However, if the lift is like some I've seen/built, then you may have more than two switches involved (like one for each intermediate point used). In that case, then you would have to do at least some of the switches in software, as the jag is only good for two switches.

Generally those two are designed to be your high and low points; these are the points where if you were to overshoot it by a considerable margin very bad things would happen (like stripping a gearbox, breaking an arm joint, accidentally firing a ball, etc.) However, if you choose to split your switches between hardware and software, there is no "wrong" answer in terms of functionality.

AlexH 28-10-2012 23:26

Re: Limit switches on a lift -- best practice
 


i like limit switches like this where when the switch is tripped it kills power to the motor in one direction but allows you to power the motor in the other direction

http://www.radioshack.com/product/in... rValue=Diodes

i've used that diode with 550 china drill motor at 5s to lift 30lb robots

Mark McLeod 29-10-2012 07:38

Re: Limit switches on a lift -- best practice
 
It should be noted that the previous custom circuit is not legal for FRC per R47.

It's okay for non FRC use, however you must make sure to use both switches and diodes rated for the current they will be passing.
Warning - potential fire hazard

Quote:

[R47]
Custom circuits shall not directly alter the power pathways between the battery, PD Board, speed controllers,
relays, motors, or other elements of the Robot control system (including the power pathways to other sensors or
circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to
the Robot’s electrical system is acceptable, if the effect on the Robot outputs is inconsequential.

dyanoshak 29-10-2012 10:24

Re: Limit switches on a lift -- best practice
 
Quote:

Originally Posted by F22Rapture (Post 1191935)
Correct me if I'm wrong but the Jaguar only allows input from one sensor at a time; and we need it to be able to accept from two.

The Jaguar can definitely read two limit switches at the same time. This is regardless of the communication mode (CAN or PWM).

Quote:

Originally Posted by AlexH (Post 1191972)


i like limit switches like this where when the switch is tripped it kills power to the motor in one direction but allows you to power the motor in the other direction

This is exactly how the limit switches are handled in Jaguar's firmware. There is one switch for Forward and one switch for Reverse (marked with an F and R). If only the R switch goes open-circuit, only the Reverse direction is stopped.

-David

jerry w 29-10-2012 13:05

Re: Limit switches on a lift -- best practice
 
be careful with while loops. such as;
Code:

while(!getTopLimit())
Remember that the top level loop is controlling robot communication with the field. When you add lower level loops, everything waits for those loops to finish.
It is best to use "IF" statements and avoid loops.

Andrew Schreiber 29-10-2012 13:12

Re: Limit switches on a lift -- best practice
 
Quote:

Originally Posted by jerry w (Post 1192031)
be careful with while loops. such as;
Code:

while(!getTopLimit())
Remember that the top level loop is controlling robot communication with the field. When you add lower level loops, everything waits for those loops to finish.
It is best to use "IF" statements and avoid loops.

Not always true any more. With the old IFI system it was but now we have a real time operating system. If you spawn off your limit checking code into a new process this while(!getTopLimit()) will function as expected. However, you would need to create a new process for the bottom limit as well. Because of the cost associated with context switches it may not be the best approach.


All times are GMT -5. The time now is 01:36.

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