Prepare for RobotInit deprecation by updating examples

[spacey-sooty]

Resolves #6622

[Starlight220]

Examples need to be updated.

[sciencewhiz]

Will exceptions thrown in the constructor be reported to the driver station? I thought that was one reason why we had RobotInit.

[sciencewhiz]

I don't think there's a safe way for the project importer to update a project, so this feels like it should have a longer deprecation cycle and not remove until 2027 with the new controller.

There's also 29 pages on frc-docs that need updating.

[calcmogul]

Will exceptions thrown in the constructor be reported to the driver station? I thought that was one reason why we had RobotInit.

Those should get reported as well:

  // From Main.java:
  public static void main(String... args) {
    // RobotBase.startRobot() initializes HAL, then calls RobotBase.runRobot()
    RobotBase.startRobot(Robot::new);
  }

  // From RobotBase.java:
  private static <T extends RobotBase> void runRobot(Supplier<T> robotSupplier) {
    System.out.println("********** Robot program starting **********");

    T robot;
    try {
      // Robot class constructor called here
      robot = robotSupplier.get();
    } catch (Throwable throwable) {
      ...
    }
  
    if (!isSimulation()) {
      // Write to FRC_Lib_Version.ini
    }

    boolean errorOnExit = false;
    try {
      // RobotBase.robotInit() called in here
      robot.startCompetition();
    } catch (Throwable throwable) {
      ...
    } finally {
      ...
    }
  }

  // From TimedRobot.java:
  @Override
  public void startCompetition() {
    robotInit();
    ...
  }

We used to promote robotInit() because there was initialization order issues with the HAL. That's no longer the case. The main difference now is whether FRC_Lib_Version.ini is written before or after user code.

[Starlight220]

Can you bring the equivalent C++ implementation? Due to value semantics, the split might be more important there and then parity should be kept.

[calcmogul]

In C++, it looks like RobotInit() is called immediately after the Robot constructor.

int main() {
  return frc::StartRobot<Robot>();
}

// From RobotBase.h:
template <class Robot>
int StartRobot() {
  int halInit = RunHALInitialization();
  if (halInit != 0) {
    return halInit;
  }

  static wpi::mutex m;
  static wpi::condition_variable cv;
  static Robot* robot = nullptr;
  static bool exited = false;

  if (HAL_HasMain()) {
    // Simulation-specific stuff here
  } else {
    impl::RunRobot<Robot>(m, &robot);
  }

  return 0;
}

// From RobotBase.h:
template <class Robot>
void RunRobot(wpi::mutex& m, Robot** robot) {
  try {
    // Allocates and constructs Robot once when this line is reached
    static Robot theRobot;
    {
      std::scoped_lock lock{m};
      *robot = &theRobot;
    }
    theRobot.StartCompetition();
  } catch (const frc::RuntimeError& e) {
    ...
  } catch (const std::exception& e) {
    ...
  }
}

// From TimedRobot.cpp:
void TimedRobot::StartCompetition() {
  RobotInit();

  ...
}

[PeterJohnson]

I feel like there should be another year before we deprecate it. What we should do first is update all the templates, examples, and documentation to not use/have it, and then we can deprecate it a year later.

[spacey-sooty]

So leave the template/example updates but remove the deprecation part of this pr?

[PeterJohnson]

Yes

[calcmogul]

myRobot just got renamed to developerRobot, so don't forget to remove robotInit() from there (removing the deprecation means that could get missed).

[KangarooKoala]

I might've missed some more spots with the doc comment on the constructor. The accurate part is mostly referring to the "function" part of the description- Is there a different wording that would make more sense for a constructor?

There were also a couple places that moved registering sendable children to the very end of the constructor, after some of the children were inverted. I think this is fine, but I'm bring that up just to make sure.

[spacey-sooty]

/format