COmmand based software Interrupts

[otherguy]

In the Elevator subsystem:

How are the upperLimit() and lowerLimit() switches wired up?
If they are just limit switches that pull the channel low when the switch is closed (ground on the NC pin, signal on the C pin), then I would expect your GetLowerLimit() and GetUpperLimit() to return true when the switches are not pressed, and false when they are pressed. This is because there are pull-ups on the discrete input channels.

This would cause your MoveElevatorXXX commands to immediately end.


If you haven't already tested in your subsystem do what you think they should... add some print statements that call elevator.GetLowerLimit() and elevator.GetUpperLimit() from within Robot.TeleopPeriodic(). Without running any commands, press your switches and verify that the functions are retuning True/False when you think they should.

If that's not the problem, can you provide a real log of the output that you're seeing in the console when you run. I suspect that what was provided earlier wasn't real output from the robot. There's a lot more print statements in your code that I would expect to see that aren't in the log you provided. Having a real copy of the log will help us see how the commands are executing and potentially help narrow down where to look.

[Sparkyshires]

Originally Posted by otherguy

In the Elevator subsystem:

How are the upperLimit() and lowerLimit() switches wired up?
If they are just limit switches that pull the channel low when the switch is closed (ground on the NC pin, signal on the C pin), then I would expect your GetLowerLimit() and GetUpperLimit() to return true when the switches are not pressed, and false when they are pressed. This is because there are pull-ups on the discrete input channels.

This would cause your MoveElevatorXXX commands to immediately end.


If you haven't already tested in your subsystem do what you think they should... $@#$@#$@# some print statements that call elevator.GetLowerLimit() and elevator.GetUpperLimit() from within Robot.TeleopPeriodic(). Without running any commands, press your switches and verify that the functions are retuning True/False when you think they should.

If that's not the problem, can you provide a real log of the output that you're seeing in the console when you run. I suspect that what was provided earlier wasn't real output from the robot. There's a lot more print statements in your code that I would expect to see that aren't in the log you provided. Having a real copy of the log will help us see how the commands are executing and potentially help narrow down where to look.

Nah, I know they're wired properly, as I said the code works amazingly well, and I've tested both emergency situation and it works exactly as expected. We specifically wired it this way so if an issue arises, such as a wire coming loose, it'll act like it's hit(?) so it will stop the elevator. At least that's what the electrical guys told me. All I know is that logic is correct for our electrical set-up. The only issue that this code is giving us is that it will run two commands concurrently.

I'll get a proper log later, but yeah that was pretty much it :/ the only thing I changed was adding a printf to the isFinished command. When the new button was pressed it ran the:
old command interrupt
new command init
new command execute
new command isFinished
old command execute
old command isfinished
new command execute
new command isFinished
old command execute
old command isfinished

and et cetera.

[otherguy]

Your switches may be wired correctly... but that doesn't mean that your code is reading their states correctly. Hence my suggestion to check that it's doing what you expect. If you're confident that's not the problem, good. I can't make you check it. You're the one that's saying it's not working correctly, so It may be prudent to verify your assumptions.


Other things that could be wrong:

Which commands in particular are you referring to as "new" command and "old" command?

The reason I ask is in OI all the MoveElevatorXXX commands are started when you press a button. These are the command I thought you were talking about previously wrt your logs. They will only execute once unless you're repeatedly pressing the button in question. This is not consistent with the logs you've provided.



On the other hand, if the one of the commands that's running happens to be the DropElevator() or LiftElevator() commands, then there's a different explanation for what may be going on.

I have yet to come up with a case where WhileHeld() actually does what you want it to (if someone has a use case, please let me know). If I understand your code correctly, the way you're attempting to use this command is to have your Lift/DropElevator() commands run until you let go of the button. But what's actually going to happen is each loop iteration, you're going to start a new copy of the Lift/DropElevator() command. Since you have a call to stop the elevator as part of the command, you're going to be in this endless loop of driving the elevator, stopping it, driving it, stopping it, until you let go of the button.

Here's why using the joy1button4->WhileHeld(new DropElevator()); as an example:

1. Joy 1 Button 4 is pressed.
2. A new command is created and added into the scheduler (DropElevator)
3. The active command on the subsystem (elevator) is ElevatorIdle() and it's going to be canceled. Since a new
4. When the scheduler come around to execute the active command, it runs the execute() function, assume that you're not at end of travel on the elevator, so you're going to run the DropElevatorArm() function, which presumably commands a motor to move the arm.
5. assume isFinished on this command returns false.
6. the next time around (assuming the button is still pressed) a new instance of the DropElevator() command is created. It requires the Elevator subsystem, so all active commands on that subsystem are canceled.
7. The scheduler calls the end method on the first instance of the on the DropElevator command. This in turn calls the StopElevatorArm() function, presumably commanding the elevator motors to zero.
8. now it's time for the new instance of the DropElevator() command to run: the scheduler runs the execute() function, assume that you're not at end of travel on the elevator, so you're going to run the DropElevatorArm() function, which presumably commands a motor to move the arm.
9. and the cycle of starting and stopping this command repeats forever until you let go of the button.

What you probably want to do is instead execute the command WhenPressed, then call a command that stops the elevator (ElevatorIdle) When the same button is released.

joy1button3->WhileHeld(new LiftElevator()); 
joy1button4->WhileHeld(new DropElevator()); 
joy2button3->WhileHeld(new LiftElevator());

becomes

joy1button3->WhenPressed(new LiftElevator()); 
joy1button3->WhenReleased(new ElevatorIdle()); 
joy1button4->WhenPressed(new DropElevator()); 
joy1button4->WhenReleased(new ElevatorIdle()); 
joy2button3->WhenPressed(new LiftElevator()); 
joy2button3->WhenReleased(new ElevatorIdle());

[JefferMC]

Originally Posted by otherguy

Here's why using the joy1button4->WhileHeld(new DropElevator()); as an example:

1. Joy 1 Button 4 is pressed.
2. A new command is created and added into the scheduler (DropElevator)

A small nit. The DropElevator() will be constructed by the new operator when this line of code in OI.CPP is executed. A pointer to that object will be passed to the WhileHeld method of the CommandButton class for the joy1button4 object. It will retain this pointer for use later when the button is held, thus, the correct order is:

1. OI's constructor is called.
2. The DropElevator command is created and its constructor called
   ...
3. The button is pushed, triggering the WhileHeld
4. The DropElevator's Initialize method is called
5. The DropElevator's Execute method is called for the first time and will be called for every iteration until the button is released. To be honest, if Interupted() is called, or IsFinished() returns true, I'm not sure what the command based system might do with the fact that the button is still held.

The fact there is only one object created at Robot init (vs. one created every time the button is held) is only important if your command has member variables that might make a difference to you how many objects there are.