REV 2m Sensor init time is way too slow.

[OviedoRobotics]

The Rev 2m distance sensor can easily exceed the init stuck timeout if 4 or 5 sensors are used on a robot. This is especially bad when transitioning from Auto to Teleop as this time exceeds the auto to teleop transition time built into the scoring system. This appears to be a massive register dump to the ToF sensor chip, that once done does not need to be done again, but is done every time the opmode is changed automatically by the driver if the sensor is in the robot config.

[AlecHub]

What is the topology, CH, CH+EH, EH, EH1+EH2? Which hub(s) are the sensors connected to? Are there any RS485 connections between hubs?

[Windwoes]

This is a duplicate of https://github.com/ftctechnh/ftc_app/issues/684

[cmacfarl]

The timeouts may be overwritten if absolutely necessary. However do heed the comments here. These are members of the the OpMode class.

  //----------------------------------------------------------------------------------------------
  // Safety Management
  //
  // These constants manage the duration we allow for callbacks to user code to run for before
  // such code is considered to be stuck (in an infinite loop, or wherever) and consequently
  // the robot controller application is restarted. They SHOULD NOT be modified except as absolutely
  // necessary as poorly chosen values might inadvertently compromise safety.
  //----------------------------------------------------------------------------------------------

  public int msStuckDetectInit     = 5000;
  public int msStuckDetectInitLoop = 5000;
  public int msStuckDetectStart    = 5000;
  public int msStuckDetectLoop     = 5000;
  public int msStuckDetectStop     = 1000;

[OviedoRobotics]

What is the topology, CH, CH+EH, EH, EH1+EH2? Which hub(s) are the sensors connected to? Are there any RS485 connections between hubs?

EH + EH, and I believe it is 3 sensors on the USB connected hub, and 2 on the 485 connected hub. But really I don’t think it matters, the init is just slow no matter what the topology.

[OviedoRobotics]

This is a duplicate of ftctechnh/ftc_app#684

Yep, looks the same. I had a team call me in a panic between state competition and worlds Last season for help figuring out why switching op modes was taking so long. We eventually figured out it was the 2m range sensors.

[CubedETs]

We have the exact same problem. We are using four distance sensor for autonomous and found that when we went to the teleop time it took 5 or more seconds to init. This would put us behind every single time. When we tested the change in a different configuration with out all the 2 meter distance sensors it would work. When we tested it in the configuration with the sensors the init was always slow. We can not change configuration between autonomous and teleop it costs us more time than our slow init. We also can not have a fast init in teleop because we use sensors for our autonomous so, they have to be in our configuration. Please get this changed!

[1tree]

You may be able to avoid the delay by pushing the sensors to be held in a singleton class. The class should have an initialization routine that skips if called after it has been initialized.