-
Notifications
You must be signed in to change notification settings - Fork 11
Finished final tweaks for lift, also includes tests #78
Conversation
for example, outake -> outtake, adding "Button" to button names, and ensuring they all start lowercase
The 4 stages of lift are now mapped to POV for teleop. Also did tweaks like motor ports, slaves, etc. Also note that manipulator in OI is static now for default command in lift.
…otCode2018 into controller-docs
https://github.com/gabe-mitnick/RobotCode2018 Conflicts: Robot2018/src/org/usfirst/frc/team199/Robot2018/OI.java
PIDMoveButton = new JoystickButton(leftJoy, getButton("PID Move", 7)); | ||
PIDMoveButton | ||
pIDMoveButton = new JoystickButton(leftJoy, getButton("PID Move", 7)); | ||
pIDMoveButton |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the right track, can we get pidMoveButton instead of pIDMoveButton?
// intakeCubeButton = new JoystickButton(manipulator, getButton("Intake Button", 5)); | ||
// intakeCubeButton.whenPressed(new IntakeCube()); | ||
// outtakeCubeButton = new JoystickButton(manipulator, getButton("Outtake Button", 6)); | ||
// outtakeCubeButton.whenPressed(new OuttakeCube()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason you changed these comments to start with a tab rather than a space? Did you use the eclipse auto-formatter?
public static WPI_TalonSRX liftMotor; | ||
public static WPI_VictorSPX liftMotorA; | ||
public static WPI_TalonSRX liftMotorB; | ||
public static WPI_TalonSRX liftMotorC; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine for now, but according to Dean, there will be a master and two slaves, so just a thing to note right now so that we can change to names for readability later.
@@ -104,7 +88,7 @@ protected void execute() { | |||
// Make this return true when this Command no longer needs to run execute() | |||
protected boolean isFinished() { | |||
if(liftController.onTarget()) { | |||
lift.setTargetPosition(desiredPos); | |||
lift.setCurrPosition(desiredPos); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why this lift.setCur.... cannot be written in end()?
configSRX(liftMotorB); | ||
liftMotorC = new WPI_TalonSRX(getPort("2LiftTalonSRX", 7)); | ||
configSRX(liftMotorC); | ||
liftMotors = new SpeedControllerGroup(liftMotorB, liftMotorA, liftMotorC); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, the keys are a bit weird because 1) The keys are sorted alphabetically so the keys will not appear together and 2) Viewing "LiftVictorSPX" w/o the others might make people think that that is the only lift VictorSPX. I suggest changing to "Lift Motor Master", "Lift Motor Slave 1" etc.
@@ -52,7 +52,7 @@ public void attachToBar() { | |||
* stops the climber | |||
*/ | |||
public void stopClimber() { | |||
climberMotor.stopMotor(); | |||
//climberMotor.stopMotor(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some commands/other people may call this and expect it to work, maybe change the javadoc?
* @param newPosition - the new position meant to be set | ||
*/ | ||
public void setCurrPosition(Position newPosition) { | ||
currPosition = newPosition; | ||
} | ||
|
||
/** | ||
* Uses (insert sensor here) to detect the current lift position |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can insert sensor here now.
Couple of issues: Validity of constants that affect acceleration as well as PID constant tuning. On a separate note, all the commented lines with parameters on top of variables is for dynamic value testing ( part of junit ) .
@nelsonychs can you resolve conflicts in your fork, commit and push, so this can be merged cleanly? |
* All distances are - 1 foot for initial height of intake and + 3 inches for wiggle room for dropping cubes | ||
* Also, acutal distances are divided by 3 because according to cad, the lift will have a 1:3 ratio from winch | ||
* All distances are measured from bottom of cube and + 3 inches for wiggle room for dropping cubes | ||
* Also, actual distances are divided by 3 because according to cad, the lift will have a 1:3 ratio from winch | ||
* to actual height. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be clearer to just include the factor of 3 in the encoder's distance per pulse.
else if(ang == 270) | ||
com = new AutoLift(Position.SWITCH, this); | ||
if(com != null) | ||
setDefaultCommand(com); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what the above code is supposed to do. Note that initDefaultCommand() is generally only called by wpilib immediately after the subsystem is created. If the goal is to use the manipulator POV to control the height of the lift, you probably want a single DefaultLift() command that continuously reads the POV angle and attempts to maintain the corresponding height. You should also think about what the DefaultLift() command should do if no POV button is pressed?
On a separate note, a POV angle of 0 (which the docs indicate is "up") seems like an odd choice for going to the ground.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes more sense, what do you recommend I use to achieve that? Is there a way to call AutoLift from another command so that I don't repeat functionality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's what I'd do:
- Move the PID control of the lift out of the commands. It should always be running to move the lift to the desired height.
- Make the AutoLift() command just set the target height and wait until it is reached.
- Make the DefaultLift() command set the target height based on POV angle (and perhaps other input).
//1 second? | ||
for(int i = 0; i < 50; i++) { | ||
liftController.calc(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the PIDController's thread will also be calling calculate() periodically. This will be in addition to your calls via calc(). The combination could cause the test to be unreliable.
I recommend overriding PIDController.calculate() so that it only calls super.calculate() if Thread.currentThread().getId() matches the thread id being used by the simulator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assumed that would be the case as well, but after looking at the source code it doesn't seem to work that way. All enable() does is set an enabled boolean that doesn't necessarily start the thread. I'm positive the current way of calculating is only one thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thread (actually a timer that periodically runs a task on a separate thread) is started in the constructor here. Still positive? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I was positive was because I tested the loop by printing the current position rather than calculating after enabling the controller, it was zero all throughout. But the print lines were far faster than the calculating thread so I see now, I'll take your advice and implement calculate that way, thanks.
Tweaks include manip. mapping, ports, slaves, and also tests. Also added gabe's doc. commit for compatibility.