ALMOST READY FOR DEMO

First, I want to apoligize for how many hours I’m logging with this single devlog. I just wanted to get to a good stopping point so that I can share my full completed journey for each feature. (Unfortunately, this last problem took me nearly 4 hours to fix). I can hopefully make up for this by making this devlog long, detailed, and thorough.

Completed:

• Added a lot of configs such as robot mass, width, module locations, gear ratios, etc.
• I overrode the yagsl deadband and applied my own
• Adjusted and fiddled with tiny things here and there
• Added code that can switch your alliance during auto in code.
• Zeroed the encoders (took a while) and funny story, we tried putting in the value from phoenix tuner x thinking it was radians but it was degrees, so we used a radians to degrees conversion, but that just messed everythign up, when after like hours we found out that it was in rotations (0 to 1) and not radians.
• Fixed some controller axis inversion that happened in a specific alliance
• Tried to get the project to build by figuring out what the right dpendencies are
• Put in debugging code to try and fix the problem with reading pigeon values
• Followfunctioncommand and bounds system

I didn’t record time for this but I also helped prepare a backup roborio, did testing in sim and in the real robot, zeroed encoders, measured weight, and did other stuff with the real robot. I also made a controller guide which wasnt recorded.

FollowFunctionCommand (not tested yet however)

What this basically does is it takes a Function<double, double> and it converts the x value to time based on a ratio, and it take the output as the y value, and generates a custom autonomous trajectory that traces the function.

The reason I decided to do this is for a learning experience in autonomous paths, pathplanner, and the pipelien and all that.

Some struggles I had are that I started off with the completely wrong approach, treating it like a lazy command that goes to eahc spot as the time comes. But then I made it so that it instantly generates the path and it just runs the path, which is just a lot smoother and better.

Boundary System

Our demo space is a square area so I added a safety feature that keeps teh robot inside the space even if someone tries to drive it out. I also added overrides that someone on our demo team can use if it becomes finicky.

Since we added vision, I had to code a setup command (which was honestly the hardest part of doing this). I made it so that you pick two setpoints to make the robot face straight (which is more accurate than mannually aiming straight), then to go ot a spot on the boundary which the odometry resets to. I also added telemtry so the driver can see where the robot thinks its at and work with that.

The biggest issues I faced with this is because of some rules with how you use the SwerveInputStream type by yagsl. I removed the deadband thinking you didn’t need it since I had my own manual one, but it was required to make the robot face a certain heading. This problem took me a stupid amount of time to solve. I had to do human binary search through all my commits to see what couldve changed and what went wrong and allat.

TODO

• The highest priority is to get the real robot working and the pigeon values read. I won’t be recording hours for that though since its a hassle. Without the pigeon (imu), half my other features are useless.
• Set up the driverstation in our main laptop
• Finish and test the grapher
• finally remove the custom joystick overhead since well be using windows
• Add kid mode so peopel who want to try driving don’t accidentally mess with our setup buttons
• Maybe some other stuff I forgot to include.

Anyways thanks for reading my devlog, as long and boring as it is.

Signing off,
Ash-ioL