Five Second Delay at Beginning of TeleOp

[CorruptedArk]

Our team's robot has this issue that I haven't been able to figure out. At the beginning of teleop, we consistently have to wait around five seconds for the robot to start responding to user input. I've looked over my code multiple times, looked online for solutions, and I'm not sure what is causing it. I think it might be caused by the initialization of multiple threads, but similar code was implemented last season without this problem.

I use the SampleRobot template for extensive control over operation.

Here's a link to it on Github:https://github.com/CorruptedArk/MTR-Java-2015/tree/master/Mecanum2015/src/org/usfirst/frc/team1528/robot

Robot is the main class, and we've been using autonomous0() for autonomous and teleOpLoop0() for teleop.

Any insight on what could be causing this would be greatly appreciated.

[Mark McLeod]

Do you initialize any cameras at the start of Teleop?
That sucks up about 5-7 seconds.

[Jared Russell]

Line 371 of Robot.java

[CorruptedArk]

Do you initialize any cameras at the start of Teleop?
That sucks up about 5-7 seconds.

I don't initialize any cameras, so that can't be it.

[CorruptedArk]

Line 371 of Robot.java

That could be it. Do they go to disabled before teleOp during a match? I thought it went straight to teleOp from autonomous.

[RufflesRidge]

That could be it. Do they go to disabled before teleOp during a match? I thought it went straight to teleOp from autonomous.

Here are the mode transitions from the FMS Whitepaper (http://wpilib.screenstepslive.com/s/4485/m/24193/l/291972-fms-whitepaper):
Autonomous Disable - state prior to match start
Autonomous Enable - Autonomous period
Autonomous Disable - end of Autonomous period
Teleop Disable - end of Autonomous period, prior to start of Teleop period
Teleop Enable - Teleop period
Teleop Disable - end of Teleop/match end

[CorruptedArk]

Here are the mode transitions from the FMS Whitepaper (http://wpilib.screenstepslive.com/s/4485/m/24193/l/291972-fms-whitepaper):

Thanks, I didn't know about that. I think that's the source of our troubles.

[mwtidd]

Thanks, I didn't know about that. I think that's the source of our troubles.

The Timer.delays are something I've been combating for years now. I really believe the tutorials that utilize it do a disservice in the long term.

Yes, I can acknowledge that it helps teams get up and running quickly, but teaches bad practices, and has the potential to create really confusing scenarios when you start utilizing command based programming.

Here's a post I wrote on it last year...

http://www.chiefdelphi.com/forums/showpost.php?p=1401227&postcount=2

I realize that it's late in the season to change how you handle this, but in future seasons please reconsider using Timer.delay for anything other than giving the brain a break.