Quote:
Originally Posted by Bpk9p4
I really like this idea. The only problem i see with it is you can only do one command at a time. have you found a way to get around this problem?
|
You just need to be smart in how you lay out your commands, and remember they are very high level. Lets take a choo-choo style shooter which starts with the shooter released and a ball on top of it (for whatever reason). Also it takes ~3 seconds to load. Using something like beescript you could have a routine like this:
Code:
#Load the shooting mechanism
LOAD_SHOT
#Drive forward 5 feet
DRIVE 5
#Internal timer waits until 5 second mark if not hot
DELAY_IF_NOT_HOT
#shoot when ready
WAIT_ON_LOAD
SHOOT
#Make sure the shooter is down for start of teleop
LOAD_SHOT
You can write your LOAD_SHOT command such that it can drive the shooter motor and wait on a switch. If you do this, you don't start driving until ~3 seconds into auto, which is a problem.
Instead you can write your command to tell a different process the same thing, letting the script continue. It then can meet back up with the WAIT_ON_LOAD command to make sure its ready to shoot. In this way, both the driving and the camera code are running in parallel with the code to load the shooter.
Essentially you can write your commands to set off a parallel part of the code and continue. If all of the main robot actions are handled in a separate process, this becomes much easier to do (and it carries over to teleop).