Teleop Automated Sequences

[s5511]

Our team uses Labview for robot code, and we want to have a button that the driver can press during teleoperated that starts an automated sequence. For example, our driver would press a button during teleop and the robot would automatically accelerate the shooter, actuate pistons, and shoot the ball.

How would we accomplish this functionality with our Labview robot code?

Thanks!

[Mark McLeod]

Easiest to put in Periodic Tasks where the delay won't break teleop and it would look something like this:

[Muzzle127]

Hi, we tried your example in frc 2016 and the sequence does not seem to have the correct timing. Any thoughts?

[Alan Anderson]

If it's only timing that seems off, you can easily adjust it by modifying the constants going to the Wait functions.

[Muzzle127]

We turned time up wait time sequence to turn motors on to 5000msec and the response is around 1ooo msec. It executes the sequence, but not at the right times programmed. We could just keep increasing the time, but that doesn't seem correct. The while loop execution is 20msec. Is periodic task timing controlled by another variable that would overwrite the wait time function?

[Alan Anderson]

The 20 millisecond wait in the outer While block doesn't affect the timing inside the flat sequence. It only matters when the condition to start the sequence hasn't yet happened, and all it does is ensure that the code doesn't use all the CPU time while it's waiting for the right input.

If you post your Autonomous code and tell us what you want it to do, we can look at it and tell you what you need to change to make it do that.

[Muzzle127]

It is the example code posted above, put into periodic tasks, with the times and references changed. Again, the code executes as if wait times are off by a factor of 10

[Alan Anderson]

Originally Posted by Muzzle127

It is the example code posted above, put into periodic tasks, with the times and references changed. Again, the code executes as if wait times are off by a factor of 10

"...with the times and references changed..."

Changed to what? Did Mark's example code actually match the servo and motor that you have on your robot? What timing do you want it to have, and what timing are you experiencing?

I can't help you if you only give me pre-interpreted and inconsistent information. For example, earlier you said 5000ms was giving you 1000, and now you call the discrepancy a factor of 10. You also referred to "motors" before, but Mark's code only has one motor. Please show the relevant part of your program, explain in detail what you're expecting it to do, and describe what you're seeing it do instead.

[Muzzle127]

Hi Alan, I've updated a screen shot of our periodic task code. So regarding time changes, physically on robot code executes much faster than the times stated. You see anything that would cause this?

Thanks

[RyanN]

Originally Posted by Muzzle127

We turned time up wait time sequence to turn motors on to 5000msec and the response is around 1ooo msec. It executes the sequence, but not at the right times programmed. We could just keep increasing the time, but that doesn't seem correct. The while loop execution is 20msec. Is periodic task timing controlled by another variable that would overwrite the wait time function?

You run the motor at 75% power for 100 milliseconds, then turn it off for 1500 milliseconds, then run it at 100% power for 1000 milliseconds.

The 100 ms will make the motor twitch and you might not even see that depending on what it's attached to.

I'm guessing the 1500ms off period is your delayed response time you're seeing. The code is working exactly as you wrote it to work.

Maybe it'll help if you describe what you think it should do because all I can do is look at your code and guess.

You're also missing motor refnum inputs in sequences 3 and 4 for Shooter 2.

Your maximum response time is 100ms or less.

[Alan Anderson]

Thank you for the screen shot. It's actually quite different from the example Mark gave. There's no way I could have understood what you were trying to do based on your previous descriptions.

Now for the second part of what I asked: what exactly are you wanting it to do, and with what timing? Give me a detailed script of which motor is supposed to run, at what power and direction, at each moment of the sequence.


Here's what I see the code doing:

• Wait for a button to be pressed on the joystick (it might take up to 100 milliseconds for the code to notice the button).
• Run the Kicker motor in reverse at 75% power for 100 ms.
• Stop the Kicker motor and run both Shooter motors in reverse at full power for 1500 ms.
• Leave the Shooter motors running and run the Kicker motor forward at full speed for 1000 ms.
• Stop the Shooter 1 motor and leave the Kicker and Shooter 2 motors running for 100 ms.
• Wait 1000 ms while the Kicker and Shooter 2 motors continue running.
• Leave the Kicker and Shooter 2 motors running with Shooter 1 stopped while waiting for the joystick button to be pressed again.

Here's what I see that doesn't look quite right:

• You have merged Mark's example with the existing 100ms loop in Periodic Tasks. That's probably okay, but it was intended to be its own loop.
• You're continually calling the RefNum Get functions throughout the sequence. It'll work, but it's a lot cleaner (and less wasteful of CPU cycles) to do it with a single RefNum Get for each motor and tunnel the RefNum between sequence frames the way the example shows.
• You are wiring the Error values as if to force sequential operation. I don't see anywhere that changes the code's behavior, although the Flat Sequence itself is meant to do sequencing (that's why it has the name it does).
• Shooter 2 is only controlled once, to turn it on.
• You are not turning off all the motors when the sequence finishes.

I don't see anything that matches your earlier mention of 5000 milliseconds.

[RyanN]

Here's what Alan is talking about. I also tried to interpret what you're doing by guessing, so this probably isn't correct.

Check out the logic on the last sequence frame... it doesn't do anything unless you want to wait a second between restarting the shooter sequence.

Another added benefit of putting your RefNum Gets before the while loop is you only have one of each, which reduces the likelihood that you misspell the name and have something bad happen (if you have a interference mechanical design, such as what our robot has). This way, the whole mechanism works or doesn't work.

[Muzzle127]

Thanks guys, we will try out suggested changes on Thursday night and see if we can get it working.

[RyanN]

Originally Posted by Muzzle127

Thanks guys, we will try out suggested changes on Thursday night and see if we can get it working.

To note, what I posted isn't a suggested change. I don't know what you want the code to do. I only based it off of what was definitely wrong in the code you posted earlier.