1-2 sec delay when entering new modes

[BigJ]

Hi all,

During the Wisconsin Regional our drivers told us that they had a 1-2 sec delay when teleoperated mode started before the robot would do anything. They (and my eyes) confirmed that other robots were indeed moving during this time. We dismissed it as we decided it wasn't a big deal. However, when we put an autonomous mode in we didn't think of this fact (and it almost cost us going backward over the center line). It seems that for 1-2 seconds when entering a new mode (teleoperated, autonomous, etc), the motors do not receive any signals. However, the code is definitely running, as the timers in our autonomous mode did things at the correct actual times. This 1-2 mystery seconds doesn't seem to happen when we are tethered on the practice field or in the pits. For now, we wait for 2 seconds at the start of autonomous, but I'd like to gain those 2 seconds back.

This leads me to believe that it has something to do with the mystical FMS, but as a programmer I know that something else can always be the problem. We don't have any watchdog errors or anything, and we don't do anything particularly intensive in the ___Init() calls. We are working off an IterativeRobot design in C++. We don't use the camera.

Any advice or thoughts is/are appreciated!

[mwtidd]

Originally Posted by BigJ

Hi all,

During the Wisconsin Regional our drivers told us that they had a 1-2 sec delay when teleoperated mode started before the robot would do anything. They (and my eyes) confirmed that other robots were indeed moving during this time. We dismissed it as we decided it wasn't a big deal. However, when we put an autonomous mode in we didn't think of this fact (and it almost cost us going backward over the center line). It seems that for 1-2 seconds when entering a new mode (teleoperated, autonomous, etc), the motors do not receive any signals. However, the code is definitely running, as the timers in our autonomous mode did things at the correct actual times. This 1-2 mystery seconds doesn't seem to happen when we are tethered on the practice field or in the pits. For now, we wait for 2 seconds at the start of autonomous, but I'd like to gain those 2 seconds back.

This leads me to believe that it has something to do with the mystical FMS, but as a programmer I know that something else can always be the problem. We don't have any watchdog errors or anything, and we don't do anything particularly intensive in the ___Init() calls. We are working off an IterativeRobot design in C++. We don't use the camera.

Any advice or thoughts is/are appreciated!

Have you tried changing your code over to simple robot? That may make a difference

[Ken Streeter]

Originally Posted by BigJ

During the Wisconsin Regional our drivers told us that they had a 1-2 sec delay when teleoperated mode started before the robot would do anything. ...

This leads me to believe that it has something to do with the mystical FMS...

We are working off an IterativeRobot design in C++. We don't use the camera.

Just as a data point, 1519 also uses the IterativeRobot in C++ and we do not have the 1-2 second delay problem.

Your description does sound like there is something in your init code which is causing the delay of 1 to 2 seconds. Have you tried running your driver station in the simulated match mode to see if you have the delay in that circumstance? I would suggest using the Driver Station to match the actual sequence that is encountered on the field. (Set the DS to Autonomous Disabled, then power up the robot. Wait for the connection to the robot, then enable the robot.)

[Joe Ross]

Originally Posted by Ken Streeter

Have you tried running your driver station in the simulated match mode to see if you have the delay in that circumstance? I would suggest using the Driver Station to match the actual sequence that is encountered on the field. (Set the DS to Autonomous Disabled, then power up the robot. Wait for the connection to the robot, then enable the robot.)

You can use the practice mode on the DS to go through the full sequence automatically.

[BigJ]

Thanks for the replies. I'll definitely try it when we get the cRIO back connected to the benchtop. The only thing we do in AutonomousInit is call a couple printf()s and a Timer Reset(). Nothing is called except maybe a printf in TeleopInit.

[BigJ]

I tried "running a match" once we got our cRIO re-hooked to the benchtop. There seemed to be zero delay on starting Autonomous and about a .3sec delay on starting Teleoperated (Not like what the drivers experienced).

[Danny Diaz]

Originally Posted by BigJ

During the Wisconsin Regional our drivers told us that they had a 1-2 sec delay when teleoperated mode started before the robot would do anything.

You know, I noticed the same thing with robots at the Alamo Regional. Or at least I noticed something that sounds related, I don't know if it is. There were a number of robots that took longer-than-normal to transition from autonomous to teleoperated, the vast majority of them didn't actually start any kind of motion until 2-3 seconds after teleop had started. I didn't have a good vantage point to see whether or not the robots weren't moving because the teams hadn't stepped up to control them yet, or if the teams really didn't have control. The time period between autonomous and teleop is nonexistent (which somehow surprised me, it shouldn't have), maybe teams weren't anticipating teleop as quickly as they should have. Even in the semis and finals, though, it seemed as if some robots were moving around much quicker than others once entering teleop.

-Danny