What cool things are you doing in software this year?

For teams looking for ideas…


Writing clean code and developing an agile work flow so we can focus on actually coding and solving problems as opposed to spending hours mired in bugs.


Are we allowed to offer suggestions/things I -wish- they were programming on? :wink:


This year we have an actual team of people working on the robot code, using GitHub issues, pull requests, and reviewing. 2020 we just had one lead programmer doing everything, and while the code did work, it led to variable names like “drivetrainLowLowSpeed” and “susan” and other general jankiness. This year we will hopefully have more than 1.5 people who understand the code, which should make us a lot more productive.

As for actual cool things, RGB LEDs everywhere, that will actually convey useful or interesting information. For example, a range of colors that will change based on the RPM of the shooter flywheel, different colors for different auto states, etc.


Continuing Efforts to use GitHub Issues and Project Boards to manage tasks.

Enforcing Pull Requests and Reviews before code is merged upstream.

Using the Gloworm+PhotonVision, and hoping to do both Goal and Game Piece tracking

We’re looking at what sensors we could take advantage of to potentially automate our climber idea.


Using photonvision for tracking gamepieces.
Using encoders and gyros to drive around.
Holding shooter speed constant based on encoder values.
Making controls more intuitive and trying to make a robot that is driveable with fewer buttons.

1 Like

We are working hard to accomplish holonomic trajectory-following on our Mecanum drivetrain with Path Planner 2.0’s “holonomic mode”. Our initial goal is a 3 ball auto but we may shoot for more if we have the time/ability :slight_smile:

  1. We started using Github Actions to test code on commits (docs)
  2. We started making classes for mechanisms as opposed to only using Robot.cpp & Robot.h
  3. We started using controller rumble for kicks driver feedback (docs)

Our first year doing swerve, we are using SDS MK4 and a modified version of their library .

Use PathPlanner to use a modified swerve controller command to consume PathPlanner trajectories so we can do both movement and facing in holonomic mode.

We will be using Axon to recognize the different cargo then give the drivers a button to lock onto it and change the swerve from Field Oriented Drive to Target Oriented Drive where left and right orbit the target and forward and backwards move towards and away from it and the rotation is handled by the command to stay facing the target.

1 Like

We have a constant jenny = .8675_309 that I think enhances the codebase a lot.


We will have a PID control our shooter this year which we didn’t have time to do last 2 years.

We are also going for path planning, but we will see how that one turns out


that is Einstein-quality code right there

You joke, but these are some names of autonomous modes on Einstein 2015.



We are doing a capture replay autonomous this year which should allow us to “record” our driver inputs and output them as our auto. Other than that, we plan to throw some LEDs to tell us various robot states and automate our climb… should be fun.


We tried a capture replay auto for the IR@Home challenges last year. It didn’t go very well due to wheel slip and the like. How do you plan on mitigating these issues?


We’ve integrated our gyro into our system to correct for potential issues with wheel slip. We plan on rigorously testing this method to make sure our results are consistent.

1 Like

3512 is planning on continuing to use our state-space controllers for our flywheel and drivetrain (for following trajectories) from the 2020/2021 seasons. However, our drivetrain now switches between two separate state-space controllers for this year. The newly written one will handle turning the drivetrain in place, which we plan to use in autonomous and for aiming when using vision. Our climber will use infrared sensors this year for checking software limits/switching between states for a possible automated climb. Good stuff. Looking forward to this year.

1 Like

What is the benefit of having two separate state space controllers just for the drivetrain?

1 Like

Ease of debugging and maintainability. They were originally together in one class, but ended up making it much longer and complex than it needed to be. We have logic within the subsystem code for the drivetrain to use whatever two controllers if certain conditions are met (if we give it a trajectory to follow or we tell it to turn in place until it achieves a certain angle).

1 Like

I don’t know that much about state space, but I feel like if there is only one system (the drivetrain) then there would only need to be one corresponding state space controller. What am I missing? Shouldn’t the same controller work for anything you want to do with the drivetrain?