southwestroboticsprogramming / 2023_main_robot Goto Github PK

Multiple drive commands that only do one part (translation or rotation) should require the drive subsystem to properly override the teleop controls. This breaks parallel commands using a translation aspect and a rotation aspect.

Expected behavior
Parallel commands allow commands that will not override each other's movement.

Additional context
This but does not exist on main yet, but will when auto leveling is merged.

Yes

ShuffleLog should have an eyedropper tool to select a point on the field view and convert it to a point that can be used in commands like drive to point.

This would allow the robot to aim at an apriltag of choice through either a button or an autonomous feature.

Is this feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

If there are more than one ways to control the robot (i.e. Xbox controller, Joystick, 2 Joysticks), then there should be a selector that allows an input method to be chosen without editing the code.

My initial idea would be to have an input interface and implementations for each type. A SendableChooser or the ShuffleLog alternative would be the method of choosing.

It is not possible to select a field position when in Perspective view.

This would allow for entire subsystems to be turned off in the code using a value in NetworkTables. Unlike last year, the code should not need to be deployed for these to take effect.

If a subsystem is turned off when the code is deployed, perhaps the motor objects should not be created, preventing CAN error message spam if the subsystem is physically removed.

The NT*** classes should use the new NT4 API in 2023 WPILib instead of the old NetworkTableEntry.

Is this feature request related to a problem? Please describe.
When new tools are added to ShuffleLog, it is annoying to update the default layout.ini file.

Describe the solution you'd like
ShuffleLog should automatically dock all windows so that the layout.ini file is not needed.

The simulated gyroscope often reports a different measurement to that of the real robot. This seems to be because the gyro is used to reset itself.

Describe the solution you'd like
Each block category should have a color assigned to it so it is easier to distinguish between block types.

for drive also

Ability to control the swerve drivetrain with one or two joysticks (or both options)

Quite often, the pathfinder will drive the robot into an area that it thinks is impossible to pass through. This often isn't true so instead, it should keep driving on the last valid path that it produced.

Is this feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Messenger can hang on message write.

To Reproduce

1. Start MessengerServer, then start MessengerTest
2. Wait for MessengerTest to connect
3. Stop the MessengerServer process with ctrl+z
4. MessengerTest will eventually hang on writing

Expected behavior
Messenger client detects that the server is down and closes the socket.

Additional context
It makes the robot break (see MMR)

Add buttons for arm manipulation and auto-scoring

Hard Code the points to where the robot will drive.

Define the field positions in front of the grids for scoring

There are a few things that we could do with the swerve drive that could take it to the next level. Here are a few things that I would like to see added:

1. X wheel position to prevent defense (Automatically)
2. O wheel position to allow for rotation but not movement (Automatically)
3. Dead wheel mode -> Tell it that a wheel is not working, and the kinematics will adjust to make up for the power differential. This would probably also need to be added to shufflelog.

Describe the bug
The default window layout for ShuffleLog is not properly saved if the layout file does not exist. This causes all the windows to be randomly scattered around the screen.

To Reproduce
Delete layout.ini and open ShuffleLog

Expected behavior
There should be a default layout for all the windows so that it initially has a reasonable layout.

The lights on the robot serve a purpose beyond looking pretty. They should be able to indicate the state of the robot, being good or bad.

A system needs to be created for some light commands to override others, and be cleared after a period.

This should add the ability to swap the locations of modules without editing any code, allowing for module hot-swaping.

Checkbox

Use status logging subsystem in crucial subsystems.

Define the positions for scoring and picking up game pieces

The arm simulator is not physically accurate

Sometimes ShuffleLog does not detect the button panel, even if it is plugged in

This would allow the behavior of the swerve drive when no command is issued to be changed. Examples of this would be: if the robot isn't driving, the wheels should all face the center of the robot to prevent it from being pushed around on the field.

Is this feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

This would allow the robot to, at the press of a button or the request of an auto sequence, aim at one of the target sticks, and choose between the top and the bottom sticks

This would add the ability to click a button (I would think just an NTBoolean) and have it reset all of the offsets to make 0 be the current position.

NetworkTables tool does not work with WPILib changes to NetworkTables in 2023

Describe the bug
The panel to the right of the field view cannot be scrolled if the content is too long.

To Reproduce
Open all dividers to increase vertical height of the content, then resize the window so that not all content fits.

Expected behavior
It should be possible to scroll the panel vertically.

for driving

This would allow the robot to aim at a limelight target of choice through either a button or an autonomous feature.

This would add basic support for the limelight in standard mode (not PhotonVision) to detect the vision targets that FIRST says will still be on the field in a lesser compacity.

Information Resides in Discord programming channel, basically some team members want extra colors of lights.

There is currently no support for simulation.

A thing to note when implementing this:
Both simulation and the mode periodic should be called if it is a simulation, not just the simulation periodic.

@mvog2501 Will be taking care of this within the next day.

Describe the bug
If the definition of a block used in a saved sequence is changed, it can cause the sequence to become corrupted, and possible crash the robot code.

To Reproduce

1. Define a block with a parameter of some sort
2. Create and save a sequence using that block
3. Remove the parameter from the block's definition
4. Try to load the sequence; it will not be loaded properly

Expected behavior
The sequence either does not load, but does not crash, or loads without the corrupted block.

A possible solution would be to give each parameter a unique name so it can be identified if parameters are reordered, added, or removed, and to store it in JSON format to prevent deserialization errors. This would have the added advantage of making auto sequence files human-readable.

There should be a block in block auto that can reset the pose of the robot to a defined position. This would let us set the position of the robot for the start of autonomous.

Describe the bug
The robot drove off the field when pressing the top left button to score on the virtual button panel. The robot was rotated roughly 180 degrees off from the correct scoring location and upon click, the robot drove off the upper right hand side of the simulator. Other buttons had been pressed in the session and everything was working.

To Reproduce
I dunno.

Additional context
Pathfinder, Shufflelog, and Messenger were all running

Field view should turn vertical when the window is thin so you can see it better.

Make all constants that should be changed (not kD on the drive motors) so that they are tunable over networktables.

Describe the bug
They need dependency version updated, but some changes need to be made to ShuffleLog NetworkTables

The odo is wilding.