Unwanted delay before autonomous code starts?

Technical Java
1

Hey CD!

For some reason, my autonomous code takes around .25-.75 seconds before it actually starts running. At our first competition, the robot started moving immediately after auto started, but at DCMP, the robot had a short delay before moving. Could someone look through my code to see what could be causing this?

My only conclusion could be that setting 8 drive TalonSRX’s into brake mode causes the short delay.

All relevant code is located here: https://github.com/team401/2017-Robot-Code/tree/master/src/main/java/org/team401/robot/auto

A quick rundown of how it works:

  1. autoInit() in Robot.java pulls the starting robot configuration from network tables, and then chooses an auto mode from them.
  2. A separate thread is created to start and manage the selected mode, which is basically a series of sequential or parallel actions. (AutoMode#routine())

Any help is appreciated!

2

I’m having similar issues, about the same amount of time delay between the auto starting and our autonomous running. It seems to only be a noticeable delay at competition however, when running auto in our practice room at school it’s difficult to notice the delay between hitting enable on the driver station and the robot beginning to move.

I wrote my own version of the wpilibj Command system, which adds more points where this issue could possibly be coming from, but it seems to be fairly reliable doing everything else, so I’m not quite sure what to think.

We will be conducting further investigation this week, if we find anything I’ll pop back into this thread and mention it in case you’re having the same issue.

3

We also wrote a system similar to command based and seemed to have about a 0.5 second lag before auto.

4

I’m beginning to sense a pattern

5

Do other robots seem to start before yours does?

If all robots are delayed, it could be a mismatched in FMS between the audible bell, and the signal FMS sends to the Robots. If that’s the problem, then don’t worry about it.

If you notice other robots moving, and yours doesn’t, then that’s a problem.

6

We’re seeing a delay between our first movement and our alliance’s first movement. Definitely something to be concerned about.

At the moment it looks like our current problem is because we have a logging system that starts when the robot enables, and part of the startup is it flushes it’s entire state buffer to a USB flash drive, which we believe is causing the delay, we haven’t tested this yet however.

7

Are you calibrating/resetting any sensors in the beginning of your autonomous mode? All sensors take a while to “calibrate,” which involves a total recalibration of the sensors faculties. Generally speaking, the sensors already calibrate themselves on robot startup, and what you’re actually looking for is “reset.” This was an issue for our team this year (gyroscopes take forever to calibrate), and so what I would recommend (as a make-sure-its-not-a-simple-solution check) is to search your code for instances of sensor calibration, especially in things such as PID loops and constructor methods.

8

I’ve figured out the issue. Turns out my ParallelAction class was causing some delay, not sure why. I’ll probably have to rewrite it or ditch the class entirely.

9