Is your feature request related to a problem? Please describe.
I'm always upset when people ruin my auto routine by placing the robot wrong.

Describe the solution you'd like
We could fix this by adding LEDs to the robot which start as one colour then change when vision detects we are in the correct position.

Describe alternatives you've considered
We could also have a calibration period at the beginning of auto but this wastes lots of time.

Network tables are great for in match logging but not so great for post match analysis. Rerun might be good for this with its C++ SDK

Tracking issue for the shooter (double flywheel so Wom in built won't be used)

The vision code right now was copied from last year and is kinda shaky. Improvements would be appreciated

Describe the bug
In a rare edgecase the tests for behaviours fail due to an exception where tick returns false instead of true.

Environment
The only environment I have seen this occur on are Ubuntu based Linux distributions

To Reproduce
This cannot be consistently reproduced but in order to attempt it run ./gradlew build on an Ubuntu based LInux distribution

Expected behavior
This test should never fail

Additional context

Over the course of this year we have constructed a variety of different subsystems for our robot and we've discarded a lot of the prebuilt stuff within Wombat. In some places this has been justified and in others it has caused a lot of wasted time. A good example of somewhere this has been justified has been the shooter. Due to the way the shooter is designed in Wombat right now when creating a double flywheel shooter we split it out of the Wombat shooter. On the other hand we have split the Arm out in a way which is not useful and has wasted a large amount of time.

Currently Behaviours do not use the wom namespace from the root of the project.

Right now what should happen is if a behaviour is running is the new one that we schedule should take control of the system then after it finishes the default behaviour should retake the system. Currently the scheduler will not give control to the scheduled behaviour.

Tracking issue for the intake

Is your feature request related to a problem? Please describe.
I want to code a new climber

Describe the solution you'd like
This code implements the climber

Describe the bug
One test is failing for Windows users

To Reproduce
Steps to reproduce the behavior: I wish I could

Expected behavior
The tests pass

Additional context
At lest 2 people are having this issues

Is your feature request related to a problem? Please describe.
We need an efficient method for modular Vision Tracking within Wombat

Describe the solution you'd like
Implement Vision tracking using Limelight

Throughout the codebase setters are used very inconsistently. We have settled on a standard that setters should have the thing to set passed in.

Is your feature request related to a problem? Please describe.
I would like to add a autonomous-ish manual control to the intake to make it more user friendly.

Describe the solution you'd like
It will make the intake easier to control as a codriver.

Is your feature request related to a problem? Please describe.
Im always frustrated when people format there code wrong

Describe the solution you'd like
we add a formatter probably wpiformat

Describe alternatives you've considered
clang format could also work

Describe the bug
After the workflow to format code runs the GitHub Actions bot makes a push with it's token. Due to using the GitHub actions runner token this doesn't cause the on pull request or on push to trigger again.

To Reproduce
Steps to reproduce the behavior:

1. Open a pull request with failing formatting.
2. comments /format
3. See runs not triggering

Expected behavior
on pull request and on push are triggered.

Additional context
This is an intentional choice by GitHub to work around it we have to make a custom auth token for the actions runner.

Is your feature request related to a problem? Please describe.
We need a good way to control a group of motors in a gearbox through Voltage.

Describe the solution you'd like
We create a VoltageControllerGroup class

Describe alternatives you've considered
We migrate over to WPILib MotorControllers, though this will lose us the GetVoltage function until 2025

Additional context
Could be useful in creation of Double Flywheel Shooter

Full rewrite and optimisation of swerve code for the 2024 Season

Where we use Phoenix is giving us a ton of warnings from within Phoenix. Hopefully this is fixed in stable but if not we need to keep that in mind

Right now we just use a magic number it should be 2pi * radius of wheel

Describe the bug
When I bump the version to 2024.1.1-beta-3 I get the error

FAILURE: Build failed with an exception.

* What went wrong:
com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: org/gradle/api/flow/FlowAction
> java.lang.NoClassDefFoundError: org/gradle/api/flow/FlowAction

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 347ms

To Reproduce
Steps to reproduce the behavior:

1. clone the repository
2. bump the version to 2024.1.1-beta3
3. attempt to use a gradlew task
4. See error

Expected behavior
It succesfully executes the task

Environment
OS: Linux Mint
Caching: None (manually deleted)
Commit: 4dc4d7b
Shell: Bash in TMUX

Additional context

Swerve draws a large amount of power and right now to avoid the battery browning out the driver needs to put in a fair amount of work.

NOTE: this could just be cause the batteries we are testing with have no charge but its probably an issue anyways cause we aren't doing super long testing

Tracking issue for double arm development

Is your feature request related to a problem? Please describe.
I want to code Auto.

Describe the solution you'd like
This will run the auto for the robot.

Its very bad right now

Is your feature request related to a problem? Please describe.
The current encoder abstraction is confusing and complicated. We could simplify and improve it.

Describe the solution you'd like
We could do a rewrite of the encoder abstraction. As of now I'm thinking we keep an encoder class that either uses generics for the encoder type or you can inherit from to create each encoder.

Describe alternatives you've considered
We could keep the current one but it should probably be rewritten

Additional context
Mirror Issue here

add a variable for the cancoder can bus name so it can be changed from outside of wombat

PID is implemented in an inneficient way causing longer compile times. It should be refactored to split into a PID.h file and PID.cpp file.
This would allow us to reduce compile times.

We can possible also optimise what its actually doing under the hood, but not sure

Describe the bug
Git fails to fetch and apply commit. Succesfully fetches diff but hangs when trying to apply it.

To Reproduce
Steps to reproduce the behavior:

1. Clone and cd into the repo
2. add https://github.com/Superbro525Alt/2024-Crescendo.git as a remote
3. fetch the simulation branch from that remote
4. Run git cherry-pick e2854e33f7ad978bc3f014c897fef54108946785
5. See hang

Expected behavior
Git doesn't hang and applies commit

Additional context
This is greatly slowing development. Guessing this isn't a Git bug but me stuffing something up here

Throughout Wombat we use pointers in a variety of ways. At this moment we have settled on using pointers only to pass in subsystems to behaviours. Standardising this would be very important

Describe the solution you'd like
Refactor Wombat to use namespaces which correlate to include directory for internal usage

We should be using Encoders through inherited classes from the Encoder class but in some places we directly call them. This should be standardised

The obsessive usage of abstractions is good for us in many cases but comes with a performance cost so shouldnt't be used without good reason. VoltageController is designed to be able to create a lot of different voltage controllers which inherit from it but we only have MotorVoltageController and I don't see any obvious reason to have any other VoltageControllers. To this end I'd suggest just removing it entirely and creating the MotorVoltageController as an individual class.

Integrate pathplanner libraries in order to be able to create autonomous routines quickly

Tracking issue for the magazine

Is your feature request related to a problem? Please describe.
This will help students who have not used Wombat before, or would like to increase their understanding of Wombat learn more.

Describe the solution you'd like
Complete usage documentation here here