Teleop Issue - Motor Control Seems to Freeze
 

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?

Re: Teleop Issue - Motor Control Seems to Freeze
 

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

Re: Teleop Issue - Motor Control Seems to Freeze
 

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.

Re: Teleop Issue - Motor Control Seems to Freeze
 

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

Re: Teleop Issue - Motor Control Seems to Freeze
 

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

Re: Teleop Issue - Motor Control Seems to Freeze
 

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)

Re: Teleop Issue - Motor Control Seems to Freeze
 

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.

Re: Teleop Issue - Motor Control Seems to Freeze
 

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

Re: Teleop Issue - Motor Control Seems to Freeze
 

We implement things like this using a state machine.

Re: Teleop Issue - Motor Control Seems to Freeze
 

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)

Re: Teleop Issue - Motor Control Seems to Freeze
 

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?

Re: Teleop Issue - Motor Control Seems to Freeze
 

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.)

Re: Teleop Issue - Motor Control Seems to Freeze
 

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?

Re: Teleop Issue - Motor Control Seems to Freeze
 

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).

Re: Teleop Issue - Motor Control Seems to Freeze
 

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".


~

Re: Teleop Issue - Motor Control Seems to Freeze
 

We have our kicker state machine running as a parallel task in the main.vi. That way it can run in both teleop and autonomous without delaying anything else. You can see this in this thread where this issue has been discussed already.

Re: Teleop Issue - Motor Control Seems to Freeze
 

The codes I have been testing are posted as images below.

Our kicker sequence is extremely dependent on the Watchdog Delay and Feed in that the solenoids need to be accuated in a certain sequence and needs the delays in as well. The kicker would not work without the solenoids accuating in order or the delays. The code itself probably explains it better than I can.

The first image is the kicker sequence within Teleop only. When our driver presses Button One on Joystick 3, our robot kicks. The problem with this code is that it seems to freeze the Tank Drive Joysticks.

The second image is the kicker sequence in Periodic Tasks. With this code, the driver can control the Tank Drive but the kicker sequence stops midway and does not complete itself.

I have not yet tried using global variables to fix this problem. I'll post up an image of that code when I make it.

Re: Teleop Issue - Motor Control Seems to Freeze
 

Hm, the codes I have posted above still seem to freeze up the joystick control when the kicker is activated.

Are there any other options or ideas that could fix this?

Re: Teleop Issue - Motor Control Seems to Freeze
 

Yes, the code you posted for Teleop will freeze your driver controls for the duration of the kick sequence.

Concentrate on fixing your Periodic code.
At what step does it stop working?

P.S.
The code left in Teleop on the outside of the Case statement (where you set the four solenoids) will override the Periodic code and mess up the kick sequence. Even without pulling the joystick trigger.
In Periodic that code outside the While loop only happens once per robot boot, but the Teleop outside code happens 50 times per second.

Re: Teleop Issue - Motor Control Seems to Freeze
 

Once you have the kicker code all in Periodic Tasks, you can delete it from Teleop.

Re: Teleop Issue - Motor Control Seems to Freeze
 

I think your problem may be the Delay and Feeds in your Periodic Tasks case. Right now, when you press the joystick button, it picks the true case and executes all the solenoid and watchdog vis in the order defined by the error lines. Since the delays total to 3 seconds, I think it will take 3 seconds to run this while loop once when you start the kicker sequence. I'm not sure if this disallows Teleop from running (I kind of doubt it, this it is running parallel to and independent of Timed Tasks in Robot Main), but it may cause some undesirable overhead. At the very least it will keep everything else in that 100 ms loop from executing properly (whatever else that is).

A state machine is probably what you want here, as it will execute each of these steps in the kicker sequence at the appropriate times without interfering with the rest of your code. We have a state machine for our kicker that stores a variable (enums are usually appropriate) for the current state, such as loaded, fire, wait, reload, wait, etc. or however your kick sequence goes. In periodic tasks, a case structure reads this state and picks the appropriate case, and it is these cases which contain the solenoid set VIs. For the timing you could use a tick count block to store a time when you first enter a state, and then go to the next state (write the next state to the state variable) when the desired time has elapsed. Actually, our state variable is jsut initialized outside the while loop and then fed back with a shift register, so only the state machine can change its own state. Hopefully that made some sense...

I've attached our Periodic Tasks.vi. Our state machine is in the 20ms loop, and reads the global variable Kick?, which is set to the joystick button in TeleOp.

Re: Teleop Issue - Motor Control Seems to Freeze
 

I believe the "watchdog delay and feed" blocks waiting for the specified time so the overhead should be minimal.


A state machine is a viable alternate way to do this sort of thing, but many teams have successfully used a concurrent periodic task.

We were successful using both approaches. We started out using state machines, then switched to using event-triggered periodic tasks. The periodic tasks approach is easier to look at and see the sequential flow. Makes it easier for peer review, particularly for inexperienced programmers.

~

Re: Teleop Issue - Motor Control Seems to Freeze
 

But doesn't this suspend the entire 100 ms loop for the whole 3 seconds? The watchdog may be fed, but that doesn't mean the code will still iterate at 100ms. In fact, that's why you need to feed the watchdog (I think?). I'm not entirely sure about how the watchdog works.

So is this concurrent periodic task the same kind of sequence structure or delay and feed structure that he used? Cuz I'm pretty sure both of those would still take the whole 3 seconds for one execution once its triggered, which may be fine if it's entirely independent of other tasks (like driving). And what do you mean by event driven? Our state machine could be classified as event driven in the sense that it waits for a button press to begin the state sequence.... Or did you set up some error handling in LabView? (something else I haven't really looked into at all)

Re: Teleop Issue - Motor Control Seems to Freeze
 

Yes, but it doesn't freeze up other concurrent tasks. The "watchdog delay and feed" releases the processor to go service other tasks while it's waiting for the specified delay to expire. It doesn't sit there burning cycles.


event-triggered. an event (the press of a joystick button) triggers the periodic task to go do something.

for example: you could set up your kicker as a separate 50ms periodic task that normally does nothing except check to see if the "kick" button is pressed. if the button is pressed, it goes through the kick cycle, taking as long as it needs. It can take as long as it needs because if it's in a separate periodic task, then it is run concurrently and doesn't prevent other robot tasks (like driving) from running.


~

Re: Teleop Issue - Motor Control Seems to Freeze
 

I compeletely removed anything related to the kicker sequence from Teleop and the code now works perfectly.

Thank you for all of the help, everybody! (:

Re: Teleop Issue - Motor Control Seems to Freeze
 

You problem may be in the sequence. I was having a similar problem triggering solenoids within the teleop, and the sequence itself was delaying drive operations from runnning in real-time.

I fixed this by using a few case structures and feedback notes to keep the extending solenoid enabled and the retracting solenoid disabled while the trigger was held and the inverse when the trigger wasn't held.

Timing operations can cause a delay.

Another option would be to make an entirely new SubVI in Robot Main so kicking runs in parallel with drive.