Keyboard support for robot diagnostics mode in Thunderscope - #3738
Conversation
| neg_key, pos_key = key_pair | ||
| if neg_key is not None and neg_key in self._held_keys: | ||
| return -1.0 | ||
| if pos_key is not None and pos_key in self._held_keys: |
There was a problem hiding this comment.
Add time-based speed ramping for movement. Or else robot will either move in full speed or zero speed.
|
This is blocked by motor firmware #3734 |
|
@GrayHoang ready to be reviewed now? |
|
This was a whole month ago? Only review if we need it, it's kinda a mess |
I think its pretty useful for testing robot movement, especially being able to test exactly forward/back/sideways. Maybe clean up the code if we want it or just close the pr 🤷 |
…into wasdqe-control
…into wasdqe-control
nycrat
left a comment
There was a problem hiding this comment.
@GrayHoang it would be good to get this PR ready to merge. It is really important to have this for easier testing without needing to bring a controller, and for diagnostics mode MacOS support. There are only a few minor issues left.
Description
Adds keyboard control as an alternative robot input method. Introduces a ControllerBase ABC that both HandheldController and the new KeyboardController implement, enabling the widget to treat them polymorphically. KeyboardController uses a Qt application-level event filter to track held keys, mapping WASD/QE to movement/rotation axes and X/C to kick/chip. A "Use Keyboard" button is added to the diagnostics widget alongside the existing "Detect Controller" button.
~ Vibe wrote the description.
Testing Done
Ran thunderscope diagnostics (on MacOS at least) and it works, can control robot with keyboard. TODO still requires testing for if controller support still works.
Resolved Issues
Length Justification and Key Files to Review
Review Checklist
It is the reviewers responsibility to also make sure every item here has been covered
.hfile) should have a javadoc style comment at the start of them. For examples, see the functions defined inthunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.TODO(or similar) statements should either be completed or associated with a github issue