Teleop Issue - Motor Control Seems to Freeze

[billbo911]

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.

[helenajoy]

Originally Posted by Ether

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


~

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.

[helenajoy]

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?

[Mark McLeod]

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.

[kamocat]

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

[Aren Siekmeier]

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.

[Ether]

Originally Posted by compwiztobe

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... [which] may cause some undesirable overhead.

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

Originally Posted by compwiztobe

A state machine is probably what you want here,

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.

~

[Aren Siekmeier]

Originally Posted by Ether

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

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.

Originally Posted by Ether

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

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)

[Ether]

Originally Posted by compwiztobe

But doesn't this suspend the entire 100 ms loop for the whole 3 seconds?

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.

Originally Posted by compwiztobe

what do you mean by event driven?

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.


~

[helenajoy]

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! (:

[dotbran]

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.