simbotics/simbot-base

A base robot with the most up to date utilities and starting components to get started on robot code as fast as possible

simbot-base's Issues

Move contributing information to CONTRIBUTING.md

Just copy and paste the current contributing information to a new file called CONTRIBUTING.md

Make contributing information detailed

I think something like contribution rules, how to contribute and open a pull request, coding rules and guidelines to follow, and how to submit changes are some good things to add just so there isn't confusion with anything.

Time Estimate: 2 hours

Port LED subsystem

Just port the entire LED subsystem for a 4-segment LED strip. This should also support more segments, and even just a singular length of LEDs, and should be highly configurable and easy to expand the types of LED modes.

Create vision subsystem

This will be used to handle all vision-related tracking. All from using the limelights to track game objects to tracking april tags on the field to know our position.

Integrate AdvantageKit and AdvantageScope

In a thread, Kaleb mentioned AdvantageKit and AdvantageScope by Mechanical Advantage.

This software and library combo allows the robot to be simulated, replayed and logged during a match, which could be used to diagnose programming bugs quickly and in more detail.

Useful Links

• AdvantageKit Installation Guide
• AdvantageScope Releases

Create an example subsystem

This should be a simple example of what a subsystem would look like and how it would integrate into the codebase while utilizing the proper tools.

Contributors, students, or mentors should be able to reference this example subsystem and truly understand how it works and how it meshes with the rest of the robot.

Make formatter use JDK 17

Right now, it looks like our formatting expects case statements to use case 0: as opposed to case 0 ->
This feels incorrect, but this might be the intended behaviour.

Create custom exceptions for each subsystem

Each subsystem should have a directory in it called errors that houses custom errors that can be thrown due to an error. We can be a lot more specific in our code when errors are thrown and can increase code readability and can make it easier to understand.

An example of this implementation can be found here

Port utilities

We have a util folder with a bunch of utilities ranging from vectors to entire sensor definitions. We need to figure out which can be copied straight over and which need to be adapted to a command-based architecture

may also include Logger/Dashboard

Merge checks

Simply check if the description of a pull request contains something along the lines of "DO_NOT_MERGE" and don't allow the PR to merge.

Something along the lines of the following should meet the criteria for this task:

name: Merge Check

on:
  pull_request:
    types:
      - opened
      - synchronize

jobs:
  check-merge:
    runs-on: ubuntu-latest

    steps:
      - name: Check PR description
        run: |
          PR_DESCRIPTION=$(curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
            "https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}" | jq -r '.body')

          if [[ $PR_DESCRIPTION == *"DO_NOT_MERGE"* ]]; then
            echo "DO_NOT_MERGE found in the PR description. Merge not allowed."
            exit 1
          fi
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Add PR templates

Update README with credits and contributors

Create automatic messaging of PR guidlines when a PR is created

This is just to ensure that contributors who create PRs are aware of how to structure one and what the guidelines are. A good example of how to execute this simply is with something like this for now.

I think right now something like referring people to here is good enough until we make a proper CONTRIBUTING.md file with guidelines.

Fix linting and build violations

Fix any errors in the linting and building workflows that are brought to attention. Just cleans up the codebase and ensures that all tests pass without issues.

Add Templates

• #13
• #14

Update README with contributing guidelines

Fix cutting of lines too short in formatter

Right now the google auto formatter seems to be cutting lines too short. It's actually reducing code readability and making things formatted weirdly

Create a Wiki for this project

Context

Port auto system to command robot

This is just to port over the auto system to use a command-based system. This should all be new code and I think we can say that we can move on from our old system which has served us many years. The migration to using WPILib commands over our old command-based system is critical for the integrity of our code which will hopefully serve us another decade or two.

You can find the requirements for this system in the following:

• Create a "main" class to house the auto inner-workings.
• An auto chooser. Used to select the autonomous mode we want to run for the match via controller bindings.
• Integrate our drive system with the auto system. This will give capabilities of our robot to drive on its own.
• Create auto-only commands. These will sort of act like building blocks to create our autos and will only be accessible in the autonomous period.
• Create commands for our subsystems. Allows us to utilize our subsystems (arm, intake, etc) during our autonomous period AND our teleoperated period. These should technically already be made when making subsystems, but this should be on the list of requirements.
• Integrate PathPlanner with our codebase to create custom paths using an easy-to-use UI.
• Create an example auto using PathPlanner. This will just give an example to teams on how to use PathPlanner and use it in their codebase.

All of the above can be done in separate PRs and should all be relatively small (200-300 lines of code at the MAX).

Time Estimate: 8 hours

Port constants

These shouldn't change much in the switch to CommandRobot. Can probably straight copy-paste over.

• FieldConstants
• RobotConstants

Add unit tests for each component

Context

To start, just figure out how to run unit tests on robot code and make unit tests for our drive code since we'll be using a swerve drive for every robot. Future issues can add tests for other subsystems once we have a template for how to set them up.

Focus on testing state transitions. Behaviour in each state can change and is self-described in the state itself so unit tests are likely to change and not really prove anything. On the other hand, state transitions can be complex. Try to think of edge cases where possible. Feel free to whiteboard a state transition diagram if you're interested. Whatever helps :)

Time Estimate: Unknown

Add support for tank drive

Although we do have support for swerve drive, we should add support for tank drive as there are many teams who don't use swerve drive modules.

Time Estimate: 3 hours

Rename "IntakeGamepieces" enum to "IntakeGamepiece"

Literally just rename the enum in the intake subsystem to "IntakeGamepiece"

Time Estimate: 2 seconds

Add issue templates

Update pathplanner navgrid

Problem Description
The navgrid is still on the 2024 version for pathplanner

Desired Behaviour
It is the new navgrid/layout for the 2024 game

Alternatives considered
N/A

Additional context
N/A

Create CI workflow

Some reading for the interested
FRC-specific example
Can also look at last year for an example

This should include:

• Build
• Lint
• If you're feeling ambitious, auto formatting so we don't need to have a bunch of "fix formatting" commits
• If this is done after unit testing framework, include that here

Add Intake Subsystem to Robot Container

As of right now, the intake subsystem isn't in RobotContainer. It should definitely be in RobotContainer since intaking is pretty important.

You may also want to hook up some commands to triggers.

Time Estimate: 30 minutes

Port controller input

Probably just defining a bunch of triggers for controller buttons. We can figure out binding them to commands later.

Update README details before release

Before releasing this template/project we need to make sure that the README is up to date with the latest information and credits for the project

Time Estimate: 30 minutes

Fix automatic PR guidelines message workflow not being in workflows folder

Literally just move the workflow file into the workflows file

Add WIP disclaimer to README

Add a disclaimer on the top of the README to disclaim that the repo is still a WIP project made during the offseason and that all code is untested.

Port IO

Not sure how we want to organize this. Historically, we've always had IO in 1/2 files that handled all setup. WPILib suggests in its documentation to put IO in the subsystem associated with it. We may want to discuss which route to take.

Move intake scoring states to separate classes

Problem Description
Using the state design pattern as Cole recommended could help clean up the large conditional block used for scoring.

Desired Behaviour
Looking at how the LED subsystem does it, it seems like it'd be a good idea to do the same thing with the intake subsystem for both consistency and clarity, especially when the intake subsystem is the "example" subsystem.

Additional context
In addition, the state pattern can help reduce issues when switching states (ex. Intaking -> Holding, Holding -> Score Low, etc.) and in the future, could lead to a much simpler and more extensible intake where the only needed command could be setIntakeState.

Time Estimate: 30 minutes

Update vendordeps before release

Before releasing this project publicly we should update all vendor dependencies to ensure that we have the latest 2024 libraries that are latest and production-ready.

This is to ensure that we reduce the amount of bugs and issues with the libraries that we use on our robot

Time Estimate: 5 minutes

Port drive subsystem to command robot

Maybe a big ticket

• Create commands for each state
• Bind triggers to each command

Time Estimate: 6 hours