Startup Delay

Once I enable teleop, it takes 5-6 seconds for the robot to start responding. Could someone please look at my code and see what’s wrong? It won’t let me post robot main so I just posted the three vi’s that I use the most

Thanks!

Begin.vi (57.9 KB)
Teleop.vi (43.7 KB)
Periodic Tasks.vi (82.4 KB)


Begin.vi (57.9 KB)
Teleop.vi (43.7 KB)
Periodic Tasks.vi (82.4 KB)

i’m pretty sure that this is normal. A lot of people experience this, us included.

Actually, I don’t think that is a normal place for a delay.

From memory, here is what I’m used to seeing.

Powering the robot will have a delay, waiting for the various devices to power up. LEDs will appear almost instantly and start blinking through their startup sequences. If you are tethered, you will have a communications light in about 15 seconds. If you aren’t tethered, it takes about 40 to 50 seconds for the wifi to be up.

After communications is up, the OS on the cRIO boots, and then the user program. As the user program boots it will run through Begin or other initialization code and start running Periodic and Vision.

At this point, the code should be able to process packets from the DS, and those should be disabled. Every 20ms, the DS receives a packet from the DS, either auto, tele, or disabled. It will process that packet as soon as it looks for it. The transition from disabled to tele should take one packet of delay. That transition will call disabled one last time as a shutdown condition, and I think the next packet calls the actual teleop.

In order to better debug this, can you describe more about when the delay happens? Is it each time you enable tele, the first time, or occasionally? Is it always the same amount of time? Do you have any messages on the Diagnostics?

If you know when the delay is likely to happen, then you can open panels to see what is going on, or watch the Charts tab of the DS to see what code is reported as running.

Greg McKaskle

Did you change Robot Main? Teams are supposed to leave it alone and put all their custom code in other places.

I do see something that might be the cause of the problem. You chose your own name for the drive motors device reference. You didn’t change the name from the default in Periodic Tasks, and you probably left it as the default in Disabled. Aren’t you seeing continuous errors on your Driver Station when the robot is disabled, saying that “Left and Right Motors” is not defined? Those errors will clog up the communication, and could possibly be the reason for things remaining unresponsive for a few seconds after being enabled.

One other thing: your ball density check isn’t in a loop. It’s only going to run once when the program starts up.

Thanks!!

One more problem: Once the “Shoot” motors are in a loop in periodic tasks vi, they run in short intervals, like the motors will turn on and off automatically once I press button 8 or 9. What might be causing this problem?

It’s because you’ve defined them as Drive motors, and that enables the Motor Safety. If you don’t set their value every 100 milliseconds or faster, the system will shut them off. That feature is designed to keep the robot from driving out of control.

You can disable the Motor Safety for those motors using the Safety Config function (it’s in the Robot Drive > Advanced palette).