FTC Codesim [SYNTH-295]

[BrandonPacewic]

Task

SYNTH-295

Support FTC codesim in the Fission simulator.

Symptom

I don't think we have ever actually supported any variation of FTC codesim. Now we do.

Solution

Follows the same type of structure as our FRC codesim although its much simplier. FRC codesim requires and relies on the whole WPILib stack built against the actual manufacturer APIs. The FTC SDK is direct so we can simply setup a clean-room shimmed version of the handful of base classes we want and compile a team's raw .java OpMode source file directly with JDK.

This pr sets up just a handful of FTC classes needed to run a very basic TeleOp Arcade drive mode for dozer. It would be very easy for us to add more support later, this is just the initial scaffolding.

This PR does not setup any autonomous mode testing in FTC.

Verification

You may want to use this version of Dozer as it has labeled wheel joints.

• Run cd simulation/SyntheSimFTC && ./gradlew build.
• Run ./gradlew run --args="--src ../samples/FTCDozerArcadeDriveSample --opmode ExampleDozerArcadeDrive".
• Open up the fission dev server while that is running.
• Spawn Dozer in Fission, configure Brain -> FTC.
• Configure Assets -> Simulation -> Wiring Panel.
  • Make the wiring panel look something like this:

• You then should be able to drive with WASD on simulated code.

---

Before merging, ensure the following criteria are met:

• All acceptance criteria outlined in the ticket are met.
• Necessary test cases have been added and updated.
• A feature toggle or safe disable path has been added (if applicable).
• User-facing polish:
  • Ask: "Is this ready-looking?"
• Cross-linking between Jira and GitHub:
  • PR links to the relevant Jira issue.
  • Jira ticket has a comment referencing this PR.

[PepperLola]

Is there a reason the FTC and FRC code simulation needs to be distinct on the Fission side? especially if they're going to be the same after systemcore. A lot of the system looks like it's a duplicate of the WPILib sim when it doesn't need to be (e.g., the web worker for the websocket looks to be pretty much exactly the same except for the WS endpoint?).

[PepperLola]

Also, the roborio config modals are unused and I'm deleting them in my next PR, so there's no need to adapt that for FTC. I think ideally everything should work the same on the Fission side between FTC and FRC (since I don't know what would necessarily need to be different; the configuration is pretty flexible already?).

[BrandonPacewic]

Is there a reason the FTC and FRC code simulation needs to be distinct on the Fission side? especially if they're going to be the same after systemcore. A lot of the system looks like it's a duplicate of the WPILib sim when it doesn't need to be (e.g., the web worker for the websocket looks to be pretty much exactly the same except for the WS endpoint?).

I combined both the web workers, those were mostly duplicated.

I believe everything else here is split correctly. WPI has a whole flow graph of SimInput/SimOutput/SimFlow/Nora-type etc. FTC has none of this and is simply motor power out, gamepad in. No bidirectional flow whatsoever.

Once we know what systemcore is going to look like we can likely move both FTC and FRC codesim to be the same process.

[RoushilS]

Very glad to see FTC support in Synthesis!

[PepperLola]

As far as I can tell, the only difference between the FTC brain and the WPILib one is that FTC handles gamepad input. When it comes to code sim, I think that should ideally be handled on the robot code side (the split of responsibilities should be the same between FRC and FTC code sim). At that point, we could keep all of the configuration we provide for FRC and use it for FTC, meaning users wouldn't have to learn how to do things separately. It would also be easier to maintain since we wouldn't have to maintain two systems that functionally do the same thing.

[PepperLola]

Are the Qualcomm files in SyntheSimFTC derived from the real library? If so, they need to retain the copyright notice

Also, FTCState and WPILibState are exactly the same except the WPILib one uses a "SimAutoReconnect" user preference and exports some constants. I would rather we reuse whatever we can and just change WPILibState to always automatically reconnect

FTCTypes are identical as well except for the added DcMotor, which I think should just be either a PWM or a regular SimDevice so we can reuse WPILib sim stuff.

Since we have complete control over the websocket spec for FTC code sim, it would be nice to have it match the WPILib one (e.g., use <> to denote inputs/outputs, same names, etc.). Ideally we would just treat the DcMotors as PWM devices on the Java side and then nothing in Fission would have to change.

Could we also have a human write the documentation?

Since we don't support configuring the websocket url/port, I don't think it makes sense to let users pass in a port to the op mode runner.

[BrandonPacewic]

Are the Qualcomm files in SyntheSimFTC derived from the real library? If so, they need to retain the copyright notice

These shims were written from a decompiled signature list, the actual source content of these files is all closed source. Since we are effectively reimplementing an API for interop this falls under fair use.

[azaleacolburn]

Everything look great; I have a few nits about the java code, but they're not blocking imo.