Robot "twitching?"

Our robot is almost fully programmed but we’ve run into a problem, the robot’s drive motors and some other motors run themselves for a fraction of a second with no joystick input every now and then. It only happens when the robot is enabled in teleop and the only error messages we get are that the loop that robotdrive and one other motor are in is running to slowly.

I did fix half of the problem yesterday when a digital I/O port on the sidecar was being read by both the compressor and a digital read at the same time, that caused it to twitch a TON.

I would like to add that I tried a completely new project with just drive and it worked fine so it’s not the hardware or wiring.

Is this caused by the slow loop or is it something wrong with my teleop code? (40.2 KB)
Firing (72 KB) (40.2 KB)
Firing (72 KB)

FIRE is inappropriate for use in Teleop because of the delays embedded inside.
This code that calls it should be moved to a loop in Periodic where such things belong.

The reason you’re seeing the behavior that you are, is because you are losing control when Teleop essentially freezes up while processing your FIRE sequence. The last commands sent to Tank Drive will stick until the FIRE sequence completes.
Susequent joystick movements (like going to neutral) won’t be processed by Teleop until the FIRE sequence is finished 3+ seconds later.

The problem is that Fire has a number of large delays.

If the safety feature is active and the motors aren’t updated by that deadline, the motors will be set to speed zero. This is primarily to keep the robot safer when you hit a breakpoint in the code or get into an infinite loop, etc.

The other reason you don’t really want large delays in teleop is that it will cause the code to ignore the joystick for several seconds. Depending on what the robot and driver are doing at the time, this could be fine. In that rare case, simply turn off the safety config in Begin. Typically, the better solution is to move the delayed code out of teleop and run it in parallel, or make it into a state machine that performs the operations a little at a time over a number of teleop calls.

Both of these are valid approaches, but the easier of the two is probably to take the Safety code and place it into a loop in Periodic Tasks. Have the periodic loop read a global that tells it to fire, and in teleop, set the global instead of calling the function. Be sure to reset the global. You can also look at using a notifier if you feel up to it.

Greg McKaskle

I’m not sure what you guys mean by “run it in parallel.” How do I run the fire sequence when a button is pushed in teleop? We made “FIRE” so that multiple things would happen in sequence to shoot the Frisbees without many joystick inputs having to be received at a time. We want to run this sequence in teleop to shoot one frisbee after another until any discs loaded will fire.

Is this delay problem the reason the two motors (motor 1 & 2) don’t stay on when the sequence moves to the next frame?

All the stuff that feeds into FIRE including the joystick gets for axes and buttons, can all be copied and pasted into clear space in Periodic

Then put a While loop around it that never ends, and put a 10ms Wait in there so it doesn’t suck all the life out of the cRIO.

There’s nothing special about Teleop that gives it exclusive access to the Joystick controls. They can be read in Teleop and in Periodic Tasks, or other places, too.
The advantage of Teleop is that it only gets called whenever there are new joystick values to process, so it’s more efficient.
Run the loop in Periodic Tasks a little faster than the 20ms communication packet rate and it won’t matter that you’re sometimes reading joystick info twice sometimes. The duplicate info won’t be the the signal telling you to FIRE.

How do I do that? Just change the delay in the loop I made?

And thank you guys for all the quick responses!!

We were having the same problem and tried your safety solution but it didn’t fix it. Now it’s not responding at all.

I got the robot to stop twitching! Not by disabling the safety, but by moving the code I had running delays to periodic tasks. But now* the joystick values don’t ever get updated*. Without the compressor, the sequence runs perfect, just how i wanted it:)

but it didn’t fix it. Now it’s not responding at all.

All you did was disable the safety in Begin? And if you turn it back on?

Are there messages being sent to the diagnostics?

Greg McKaskle

Yes, yes and yes. More details here:
I don’t want to thread jack.

That probably means the Joystick Gets are misplaced.
Post the code you have now and we’ll help troubleshoot that.

Here are both Teleop and Periodic Tasks. Do you need begin for the compressor’s start?

The sequence in periodic works great, but no relay fired.

EDIT: It gave me an code of “-44027” when I put a probe on the error line in I’m not sure what that means, but it told me it’s an unidentified error. (37.5 KB)
Periodic (33.3 KB) (37.5 KB)
Periodic (33.3 KB)

No Relays were harmed in the running of this code, because those are solenoids. :slight_smile:

What kind of solenoid are you using?
The code assumes it is a single solenoid (one physical set of wires).
the solenoids we’ve goten in the kit the past couple of years have been double solenoids (two sets of physical wires).

Post your Begin so we can check that out too.

P.S. to your edit.
A -44027 error is “FRC: The DIO channel has already been allocated.”
That means you’ve specified the same DIO more than once in Probably the default DIO 1 came up twice.
You can get info on the mysterious error numbers by going to Help->Explain Error… and typing in the error number (remember to include the negative sign if appropriate).

Single, it’s the one from the kit, but we only connected one set of wires from the double solenoid, it works great thumbs up!

Here’s begin for ya! (54.6 KB) (54.6 KB)

You’re right, I was opening DIO1 twice instead of both 1 & 2! It works perfectly now! Thanks for all your help man!

I see the two DIO 1’s in there.

The Watchdog code isn’t necessary, it’s pretty circa 2009. The Safety Config took over that job.
Where are you feeding it? Unfed it will shut things down.

A double solenoid shouldn’t work treated as a single solenoid, because real singles have a spring return, while doubles do not.
I’ll have to try that myself at robotics tonight. Learn something new every day.

Is the first green LED on the Solenoid Module going on/off when you run your sequence? That’s the best verification that your code is working.

I don’t know if you already did it. But all you need to do is put a “dead area”. In other words what is happening is your joystick are actually sending a slight amount of value to the motors, even though they aren’t pushed. So just create a code that says if joystick value is between -.1 and .1 don’t move.
Hope this helps,
Alex Guckenberger