Fix setpoint problem and adjust values for 7 different heights
Closed this issue · 29 comments
Currently having trouble with the setElevatorPosition command:
The following method does not seem to be working (line 63 of elevatorSubsytem.java in WIP)
public void setPosition(int position){ leftSRX.set(ControlMode.Position, position); }
It was discussed that we may be missing a function that tells the elevator to run or that the elevator itself doesn't "know where it is".
Any troubleshooting comments would be helpful
Yes, the arm and the elevator both stay up which means that they are staying at the setpoints.
https://www.chiefdelphi.com/t/talonsrx-position-control-mode-not-stopping/346268
Looks like a similar problem to ours
https://www.chiefdelphi.com/t/talonsrx-control-position-not-setting-elevator-position/346277
Got some responses back from the thread. Just committed the changes and will test at tomorrow's meeting.
Not sure how much it is going to change considering the setPosition() works with the operatorControl command
I'd highly recommend seeing the status output from the SRX using the Phoenix Tuner
Some good example code we could use
any luck?
We'll start with the test mode on the Pheonix Tuner and then go from there tonight. In the meanwhile, I'll look for other potential solutions.
current working code is still in WIP branch, right?
Yes. It would be good to get that merged soon to testing
I think a potential solution would be to switch the encoder to absolute instead of relative. After doing some research, I found that the .set() method that we are using to set the elevator height either takes in as a parameter encoder ticks or an analog value, depending on the sensor. Prior, we were giving it a value of -2000 which doesn't make sense for an analog value. Changing the encoder to absolute should fix this problem.
Problem has been fixed by making PID value nonzero. Still to-do with this issue:
- Test PID to make sure whatever value we choose is not random and will not negatively affect robot control
- Add all 7 needed setpoints for matchplay and test each - calibrate elevator speeds as necessary
- Figure out assignment of different setpoints to different buttons on controllers -----> speak to drive team about this, not previously decided in #83
- Potentially implement a corresponding elevator arm command to make sure arm is perpendicular to elevator and ready to place panel/cargo following elevation
@shashjar arm is not always perpendicular to elevator– it depends on whether you're manipulating hatch vs. cargo
@roshanr10 that's true - in general, we need to test whether we need commands for placing
To-Do for this Issue as of 02/17:
- Ensure all setpoints are working well with the command to set position while the elevator is in any starting position
- Assign setpoints to corresponding button - consider an additional manipulator gamepad for elevator and climber if necessary
as for extra gamepad, I'd recommend trying to avoid that b/c that may well increase cycle time
public static final int elevatorSetpointHatchLow = 0; // Bottom hatch position
public static final int elevatorSetpointHatchMiddle = -25300; // Middle hatch position
public static final int elevatorSetpointHatchHigh = -51300; // Top hatch position
public static final int elevatorSetpointCargoLow = -10582; // Bottom Cargo
public static final int elevatorSetpointCargoMiddle = -30638; // Middle Cargo
We have not yet measured the high cargo and the cargo ship cargo (cargo ship hatch is the same level as low hatch on rocket)
Have to re test these points.
@ashwinc12 arm set points have been made relative, and changed– could use more testing tho
do we need to work on carriage set points too?
what does this issue actually entail at this point?
@ashwinc12 @TechplexEngineer what else needs to be done for this to be considered closed?
closing due to stale activity, will reopen subtasks so we can actually follow along with what's happening