Currently with the JoystickButton class you can only do a .get() to return status; however, I want a way to simulate a real time button press to call a command that is binded. Something like button.click() or if there is a way to call a command that could also be sufficient.
I havenāt tested this myself, but you should be able to schedule a command via CommandScheduler.getInstance().schedule(my_command);, or by adding a ScheduleCommand to a command group via new ScheduleCommand(my_command)
I use the InternalButton class for testing. If you declare your buttons in RobotContainer as Buttons , you can instantiate them with either JoystickButton (not sim) or InternalButton (sim).
https://first.wpi.edu/FRC/roborio/beta/docs/java/edu/wpi/first/wpilibj/buttons/InternalButton.html
Awesome, so I can replace all joystick button instances with internal buttons? (of course change constructor)
It kind of depends, could you give some more insight as to how you plan to āpressā the simulated button?
Iām trying to replay button inputs from the driver, so I want a way to simulate the buttons being pressed again since all of our commands are connected by whenPressed bindings.
Does this work with the simulation GUI? Would be very useful to sim our controllers
Is your reason behind wanting to do that to ārecordā robot actions and play them back in autonomous?
I canāt speak to whether it works or not in the GUI. Iāve got a project setup to be able to unit test the command scheduler (and in turn, my own button bindings and commands) on my laptop separate from the built in simulator.
yes
I see. I guess Iāll just test it.
The best way, IMO, is to use the new WPILib simulator, hook up your real joystick, and start pressing buttons. This removes any need to modify your actual robot code.
If you use the command line, itās usually as simple as ./gradlew simulateJava from the root project folder.
For VSCode, follow these instructions:
https://docs.wpilib.org/en/latest/docs/software/wpilib-tools/robot-simulation/introduction.html
1 Like
Contrary to stereotypes not every teenager has an Xbox controller. Yes that is the best way but our controllers stay at the workshop so I am looking for a code based method less clunky than sending them to shuffleboard
I will argue that using unit tests with InternalButtons has benefits over simulating each function and manually testing them. You can run all your tests and figure out if you broke a previously existing feature, not just check new ones work.
More towards the intent of the OP, Iād recommend using the CommandGroups that are apart of the WPILib instead of trying to manually play back inputs for autonomous.
Ah, this wasnāt specified. Carry on then.
Iāve thought about adding āvirtualā joystick support to the simulator GUI but havenāt come up with a good user interface for it. I could e.g. make the button LEDs clickable, but the analog inputs are trickier. Any ideas?
An option between sliders and text input fields (or both at the same time?) would be excellent.
Keyboard input is supported right? Consider number keys for buttons 1-10 (feel free to expand on this)
Yes, keyboard input is supported. We would need a way to disable it though (because of text entry), or maybe I might be able to make it active only when that window is active.
I think Iāll need to make it a window separate from the joysticks window. So itās reassignable like the system joysticks are, and gives more room for things like sliders (the sliders would be the dual slider/numeric input like how analog inputs are done). There would need to be configurable settings too for the number of buttons/axis/POVsā¦
Iām going to try this. Thanks.
Excited for this!
Probably could be done faster and more reliably than me hacking it together by subclassing Button and SimDevice 