Teleop Issue - Motor Control Seems to Freeze

[helenajoy]

Our robot has a kicker controlled with pneumatics and is tanks drive. When the trigger is pulled, we have a sequence of solenoids (two double solenoids) that control the kicker. So, the trigger is linked to a case structure. When the trigger is pressed, there is a sequence within the case structure that happens. This works fine.

The problem is that when our second driver pulls the trigger and kicks, the first driver can no longer control the tank drive.

I am think that this is an issue with the case structure being in teleop. So, I included a tank drive sequence within that case structure.

But that didn't work. Our tank drive still cannot be controlled when the trigger sequence is happening...

Any ideas as to how to fix that?

[Greg McKaskle]

It sounds like you have a lengthy sequence of code executing in the TeleOp. Since the TeleOp is busy, it cannot process new packets with joystick info.

There are two common approaches to this problem. One is to move the solenoid code into a parallel periodic loop. Then the TeleOp no longer does the work, but triggers it using a global or other notification and is then free to continue on processing joystick data. In the periodic loop, you can delay and take all the time you like to sequence the mechanism. The last thing it does is to reset the global and wait for the next trigger.

The other way of doing this is to merge this loop with the teleOp and build a state machine which ticks away at the solenoid waits with each call to teleOp, but never delays for more than 20ms. Actually, this is usually done simply by assuming that you will return a bit later and doing time comparisons to the last solenoid action and moving to the next step after enough time has elapsed, but by not using any delays.

Greg McKaskle

[Wolfgang]

Generally, when it comes to TeleOp, and Autonomous as well, you want to include as few structures or loops as possible, because it slows the code down. If you can program the solenoids without a case structure, that would probably help a little bit.

[Vikesrock]

Originally Posted by Wolfgang

Generally, when it comes to TeleOp, and Autonomous as well, you want to include as few structures or loops as possible, because it slows the code down. If you can program the solenoids without a case structure, that would probably help a little bit.

A Case structure does not have high overhead by itself. It is the code inside the case structure that is likely the problem.

[helenajoy]

Originally Posted by Greg McKaskle

It sounds like you have a lengthy sequence of code executing in the TeleOp. Since the TeleOp is busy, it cannot process new packets with joystick info.

There are two common approaches to this problem. One is to move the solenoid code into a parallel periodic loop. Then the TeleOp no longer does the work, but triggers it using a global or other notification and is then free to continue on processing joystick data. In the periodic loop, you can delay and take all the time you like to sequence the mechanism. The last thing it does is to reset the global and wait for the next trigger.

The other way of doing this is to merge this loop with the teleOp and build a state machine which ticks away at the solenoid waits with each call to teleOp, but never delays for more than 20ms. Actually, this is usually done simply by assuming that you will return a bit later and doing time comparisons to the last solenoid action and moving to the next step after enough time has elapsed, but by not using any delays.

Greg McKaskle

Okay, so how would I go about doing these two methods? I'm a bit unfamiliar with these processes...

[helenajoy]

Also - will we be able to utilize the joystick trigger with these methods.

Which would be the quickest and most efficient method? (we are in the middle of a regional right now haha)

[Vikesrock]

The quickest method to fix any issue you are not very familiar with during a regional is to proceed to Pit Admin or your Lead Robot Inspector and ask if they can find you some assistance.

Teams are just as friendly in real life as they are here on CD.

[Greg McKaskle]

Personally, I'd do the parallel periodic task loop. You will copy the code that does the solenoid and put it in the periodic loop. You still have teleOp code that checks the trigger, but now will just set a global. The periodic loop will check the global. Once the new code looks right, you can start disconnecting and deleting the stuff from Periodic.

Greg McKaskle

[Joe Ross]

We implement things like this using a state machine.

[kamocat]

Originally Posted by Greg McKaskle

Personally, I'd do the parallel periodic task loop. You will copy the code that does the solenoid and put it in the periodic loop. You still have teleOp code that checks the trigger, but now will just set a global. The periodic loop will check the global. Once the new code looks right, you can start disconnecting and deleting the stuff from Periodic.

Greg McKaskle

With those "functional global" refnum VIs, it means you don't have to use a global variable at all; you can acquire the joystick data in periodic tasks just as easily as you can in Teleop.
So yes, take all the code in Teleop that actuates this kicker, and move it to Periodic tasks, with a 20ms wait in the empty case of the case structure.
(The driver station only sends data every 20ms, so there's no need to check any faster than that)

[helenajoy]

In Teleop, I will keep the joystick code in but instead of the Button One (true/false value) into the state machine that currently holds my solenoid kicker code, I would wire it into a global variable and place the solenoid kicker code into Periodic Tasks? What would go within the global variable?

Or do I place the entire joystick code into Periodic Tasks - meaning I call the joystick in Periodic Tasks and link it to the solenoid kicker code within Periodic Tasks as well. And having nothing in Teleop?

Also, when I place the kicker code in Periodic Tasks, I place it in a state machine, right?

[kamocat]

Place the entire joystick code in periodic tasks.
There's only two main differences between Teleop and a loop in Periodic tasks:

1. Teleop should be able to execute in less than 20ms, whereas a loop in Periodic Tasks can take as long as you like.
2. The loop in Periodic tasks will execute regardless of what mode the Robot is in. (teleop, autonomous, disabled, etc.) With autonomous, this isn't a problem, because the robot does not receive updated joystick data during autonomous. (With Disabled it does, but all the outputs will be disabled. Depending on whether you use a time-based or sensor-based sequence, this might simply make the robot wait until it is re-enabled before kicking.)

[helenajoy]

I placed the joystick and kicker code in Periodic Tasks. The kicker is extremely dependent on the watchdog delay and feed - we tested it and it seems like the timing is off (even though the kicker code is exactly the same). I am wondering if placing the code in Periodic Tasks messed with the delay and feed function? If so, how could I fix that?

[kamocat]

Use a "wait" function (found in the functions pallette under Programming > Timing)
Its icon is a watch symbol.
You will have to specify your waits in milliseconds (1/1000 of a second).

Alternately, I suppose you could get the Watchdog reference in Periodic Tasks and still use the "delay and feed" function. However, I believe there is only one user watchdog, so make sure to use the same reference (as opposed to opening a new one).

[Ether]

Originally Posted by helenajoy

I placed the joystick and kicker code in Periodic Tasks. The kicker is extremely dependent on the watchdog delay and feed - we tested it and it seems like the timing is off (even though the kicker code is exactly the same). I am wondering if placing the code in Periodic Tasks messed with the delay and feed function? If so, how could I fix that?

You placed the joystick and kicker code in separate tasks (correct?). What iteration period (ms) did you assign to each of these tasks?

Please explain what you mean by "extremely dependent".


~