search

FIRST-Tech-Challenge / SkyStone

FTC SDK
https://www.firstinspires.org/robotics/ftc/what-is-first-tech-challenge
277 stars 1.04k forks source link

Programatically initializing a new opmode. #144

Closed David10238 closed 4 years ago

David10238 commented 4 years ago

In previous years teams would use https://www.kno3.net/autonomous-teleop-transitioner to make the transition between auto and teleop nicer. Unfortunately this year it doesn't work, I believe the opModeManager.initActiveOpMode(transitionTo) line is what doesn't work. Is there any methods in the newer versions that is able to do the same or similar thing?

gearsincorg commented 4 years ago

Call me restrictive, and uncreative, but I think what this utility is doing is a really BAD idea.

Let's start with the disclaimer that the author put on the info page:

This utility uses a field in the OpMode class specifically marked "this is logically an internal field. DO NOT USE". It is possible that using this causes some form of instability, and you should use it at your own risk. So far, this utility has only been tested on ZTE Speed phones. However, it is a fairly simple process and should be stable.

Next is a comment in the code that reads:

Thread.sleep(1000); //Wait 1 second to prevent weird conditions

Adding time delays to prevent "weird Conditions" had never proved reliable. If you don't know how to properly avoid a race/timing condition, then "Don't do it"

And finally, in terms or "playing within the rules" I feel that this technique is violating some basic safety precautions, and if the robot was inspected rigorously, it would fail.

A key aspect of the Field inspection is that during autonomous (and teleop), if the refs direct the team to STOP the robot, it should respond quickly and completely. With this specific modification, the robot will NOT do that, it will transition to the Teleop Init state which does not ensure that the motors and servos are fully disabled. In other words, there is no guarantee that it would stop. It might, but it might not either. Essentially your opmode is refusing to respond to the Stop request.

Inspection Checklist says: Robot starts and stops when commanded by the Driver Station If I was inspecting, this robot would fail inspection. It may seem harsh, but safety is a primary inspection issue.

I think it's a good thing that this feature does not work any more.

cmacfarl commented 4 years ago

That utility is intervening in the opmode lifecycle in an unapproved manner.

I agree with @gearsincorg. What KNO3 is doing there is unofficial, unsupported, and its usage should result in a software inspection failure.

Won't fix.