In auto we want to 1)move forward for two seconds, 2)stop driving and spin up our shooter motors for a couple of seconds, 3) then retract a pair of cylinders with shooter motors still spinning with about a second wait to make sure the cylinders have fully retracted, 4) and finally stop the shooter motors and extend the cylinders. see attached code
We use a stacked sequence to complete these tasks. It drives forward for 2 seconds just fine. The PROBLEM… in the seconds step the shooter motors (frontMotor and rearMotors) start for a split second and stop. Then after about the two seconds the cylinders (frontliftCylinder and rearliftCylinder) retract for a split second and then extend.
Why are the shooter motors and cylinders only acting for a split second in sequence 2 and 3?
Did you enable the motor safety on those two motors? If you did, that will shut the motors off if you don’t constantly set their values at least every 100 milliseconds. The safety is off by default on non-drive motors, and there’s usually not a good reason to turn it on.
Then after about the two seconds the cylinders (frontliftCylinder and rearliftCylinder) retract for a split second and then extend.
Are the lights on the Solenoid module turning on for the appropriate amount of time, with the cylinder itself just taking a while to respond? Or do the module’s lights also act for only a split second?
Show us your Begin vi and we can make a better judgement of where your problems might lie.
Periodic Tasks also runs during Autonomous. It might well be turning things off immediately after your autonomous code turns them on. If you don’t understand what to look for, post your Periodic Tasks vi and we can help you check for conflicts.
I don’t see where you’re turning off the motors or setting the solenoids back to Forward. If that’s being done in the False case, as I suspect, then we’ve found your problem. Before I start giving suggestions, I would like to verify my suspicions. Can you post the actual vi, and not just a screen capture of it? If you don’t want to share your entire Periodic Tasks, least give us a vi snippet of the relevant loop.
Alan- you are correct. Our false case, in Periodic Tasks, turns the motors off and sets the solenoids forward. So, are you suggesting we should turn motors off and set the solenoids forward in the true case of the Periodic task? Then deleting these actions in the false case of the Periodic Tasks.
attached is the Periodic Task VI and a screen capture…Please make any suggestions as to how to improve our code. Everything we know we have learned through CD. Learning code this way is kind of like learning calculus through youtube. We can usually make it work, but we’re not so efficient at it.
Moving the things out of the False case and into a final frame of your sequence should work. That’ll make it stop interfering with the auto code.
But I have a different suggestion. Since your Periodic Tasks code works properly, why not just make use of it in Autonomous as well? I’d add a boolean global variable and OR it with the joystick button into the Case block. To fire the sequence in Autonomous mode, just set the variable True for a half second, then set it back False, to simulate someone pressing the button. That way you don’t have the same function duplicated in multiple places, and if you ever want to change how the firing sequence works there is exactly one place to do it.
Works!!! I delete the code in the false case and added a sequence to the code in the periodic tasks.
Also, thanks for the suggestions of using global variables. I’m not going to try this before this weeks competition, but will play with them in the off season.
Help again!? We have another similar issue with the frontMotor not running in autonomous. The frontMotor twitches but does not stay on. I believe it is because in periodic tasks we have the frontMotor set to turn off in a false case. (see attached) I believe like before telling the frontMotor to be zero in periodic tasks is interfering with the frontMotors turning on in autonomous…true?
Is there a button press that executes the case structure? Since you can’t press the button during auto and periodic runs at the same time as auto the two will conflict.
In periodic task, you can set-up a case structure where when the robot is in auto, it does not do the function you have in periodic task. This structure would go over the entire function of what you’re doing when you press the button. There’s other ways, such as developing a global Boolean variable that executes your periodic task function during auto. I highly recommend doing the global Boolean method, after reading the posts before this.
There are better ways to integrate Periodic Tasks actions with Autonomous, but you’d have to completely revamp how you do things, and now is probably not the time to do that. The “cheap” fix is actually pretty easy:
Instead of setting the motor itself in your Autonomous sequence, set a global variable. Where the Periodic Tasks case is setting the motor value to 0, set it instead to the value of that global variable.
I’ve never used global data before so I watch a youtube video. I think I added the global variables, but don’t have access to the robot to check. I’ve attached screenshots with the changes I’ve made. Could you check to see if I’ve added them correctly?
I don’t understand what your “read global variable” loop is intended to do. It’s going to be continuously overwriting the global with the current motor value, which is likely to interfere with anything else trying to write the global. If that loop was newly added as part of implementing the global variable, remove it.
There is nowhere I can see that actually sets the motor value. You replaced the spot in Periodic Tasks where that was being done with another global variable write, where all you needed to do was replace the constant 0 with a read of the variable. The only places that should be writing the global are what used to be setting the motor value in the autonomous sequence.
I also don’t see why you added a rearMotors global. Was something interfering with it as well?
I cleaned up and attached the code with corrections. I can’t check the code on our robot until district championships, so I am relying on your feedback to get this running.
Why do you have the driver station writing a value to the frontMotors, my interpretation from Alan is to write your frontMotor global values from the periodic task to your motors. You can still have your driverstation determine what the value of the frontMotors.
We read from the driver station so that it is easy to tune the motors for a shot. Will it not work this way? Our shot was fairly consistant in our last district event and can set it in the global. Do I need to do this to make the global work? I’m new to globals.
Edit: I think I’m reading your code wrong. Your frontMotor values are suppose to be set in periodic task and you’re doing something that I can’t see in auto, correct. The code is fine. Sorry for the confusion.
