Second pass at a button factory to facilitate robot debugging.

[dbadb]

• rather than new JoystickButton, we say mButtons.create
• defer Joystick creation and ownership to ButtonFactory
• RobotContainer refers to a joystick by its integer id.
• ButtonFactory automatically detects unit-testing
• Constants.OI now expresses intentions for device identity and expected button count.

primary goal is to reduce spewage in a variety of testing scenarios where the standard joystick configuration isn't present. Currently we only detect "default" and "noOI" cases. New cases should be added to ButtonFactory constructor.

[dbadb]

As before, I will hold off integrating this in order to minimize disruption. That said, it would wise to integrate this sooner rather than later and the integration cost seems minimal (just replace newly introduced 'new JoystickButton's with mButtons.create.

[binnur]

@dbadb what do you think about adding a command button lookup table to centralize button ID assignments? We can use java enum constructors to build and parse the lookup table. Pro:

• one place to review and manage all button assignments Con:
• doesn't eliminate the RobotContainer merge due to button behavior, but thinking we can setup bindings per configuration so we can always have a Production/Ship-ready vs. custom-machine binding configuration

        // For each command - build a binding map based on: config + port + button
        None(
            binding(kProduction, kPortId_ERROR, JoyStick_Button_ERROR)),
        Launch(
            binding(kProduction, kJoystickId, JoyStick_Button_1),
            binding(kTest, kButtonBoardId, Board_Button_10),
            binding(kTest, kJoystickId, JoyStick_Button_9)),
        DriveSlow(
            binding(kMyConfig, kButtonBoardId, Board_Button_2)),
        DriveFast(
            binding(kProduction, kJoystickId, JoyStick_Button_1)),

        ; // semicolon to state more to follow

[dbadb]

I believe that's reminiscent of last year's control panel implementation. I learned from students that they felt it was a bit too much overhead to continually maintain more than one configuration. I think your suggestion wouldn't suffer from the too-much overhead. And it might even promote some sense of "design" to the button selection process. I do favor a concise characterization for button-assignments. I also agree that your authoring representation would be synergistic with the ButtonFactory shim.

From the state of the code that's checked in at the moment, I surmise that the button-assignment is probably very-much-in-flux and the lack of boilerplate/overhead is felt to be a "feature" for students.

In my ButtonFactory pull request, i did at a collision reporting feature to at least report unintended collisions that might arise from the current, fluid, style.

thx, Dana

[binnur]

I feel it would be useful to simplify per-user setup for binding configuration. Aside from the spewage due to incorrect port/button mismatch, seems like every time I try to do any testing, I wait around while students spend time trying to remember which button is mapped to what... I can see managing configs getting overwhelming, but there maybe a simple way to map to a custom configuration that overrides button bindings per student. If this can be setup w/o changing the code during commits (similar to how we read the build info), it may provide a flexible but a simple setup.

[pietroglyph]

That’s a good idea! We could switch based on the username we put into the JAR manifest for build info.

On Sun, Feb 23, 2020 at 3:17 PM Binnur Al-Kazily notifications@github.com wrote:

I feel it would be useful to simplify per-user setup for binding configuration. Aside from the spewage due to incorrect port/button mismatch, seems like every time I try to do any testing, I wait around while students spend time trying to remember which button is mapped to what... I can see managing configs getting overwhelming, but there maybe a simple way to map to a custom configuration that overrides button bindings per student. If this can be setup w/o changing the code during commits (similar to how we read the build info), it may provide a flexible but a simple setup.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Spartronics4915/2020-InfiniteRecharge/pull/150?email_source=notifications&email_token=ACTINQWOMSLNNGXMACJKKYLREL7W5A5CNFSM4KZV2D2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWKKUI#issuecomment-590128465, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACTINQX3CLYRNFJJMJEWFNLREL7W5ANCNFSM4KZV2D2A .