FRC 3181 Pittsford Robotics 2023 Build Thread

Team 3181, Pittsford Robotics, is excited to be joining the Open Alliance for the 2023 season. Pittsford Robotics is based in Pittsford, NY with students from Pittsford Mendon and Pittsford Sutherland High School. Our team this year consists of around 50 students and 7 mentors. We will be meeting Monday, Wednesday, Friday, and Saturday, but may add more days if the time is needed.

New Things!

Our team recently was able to invest in the purchase of a CNC Mill, which will massively improve our machining capabilities. We hope this will allow us to both prototype and manufacture parts faster. We also have the new REV Swerve modules on preorder and will evaluate after Kickoff if swerve would be appropriate for this season.

Team Goals

Some of our main team goals for this season are:

  • Being more organized
  • Making it to eliminations
    • hopefully being able to captain during eliminations
  • Finishing robot around week 5 of build season
  • Improving robot reliability

Competitions

We will be competing at Finger Lakes Regional (Week 3) and Greater Pittsburgh Regional (Week 6).

Coming Soon!

You can expect a general update about software soon, and also a more detailed plan about our Kickoff plans and our general schedule. Update will mostly come from me and @Fletch1373 .

Team Links

2023 Fusion Link Coming Soon!
2023 GitHub
Website
YouTube
Twitter
Instagram

-Michael

8 Likes

I’m super excited to see the team taking this next step!

There will likely be a few of us posting or replying to questions/comments, so ask away!

Offseason Software

During this past offseason we worked on integrated 6328’s AdvantageKit in to our 2022 codebase. Using the IO structure of AdvantageKit also allowed for us to setup a drivetrain simulation quite quickly. It also has been a major help in debugging issues we had with our REV Radio Power Module and debugging our indexer logic. We’ve really loved using AdvantageKit and AdvantageScope and plan to continue to use it for this season.

Swerve

Our development for Swerve has mostly been done through the simulation, as we haven’t received our swerve modules yet. The code was inspired by 364’s Base Falcon Swerve, but adapted it to NEOs and has also updated it to fit the AdvantageKit framework. Because we are using SparkMAXes there is currently a ~112 ms delay on velocity measurements, which can cause difficulty for precise control. As of right now, we are planning on using the newest SparkMAX update that will let us reduce the delay on velocity measurements.

You can check out the code here: GitHub - pittsfordrobotics/REVSwerve2023: Development on new REV swerve modules

We also kept the new AdvantageKit structure that we adopted during the summer allowing us to set up a simulation structure from 6328, using flywheel simulators to simulate a swerve module.

Second Order Kinematics

While testing in the simulation, we found that the robot would skew when rotating and translating at the same time. This effect can be seen in the video below.

A solution that we decided we wanted to try out was second order kinematics. A paper that was released a while ago detailed the math that would be needed to perform these second order kinematics. We also had some help from Rembrandts in this thread. The results are quite good, as you can see below.

This is done through a custom class we created called BetterSwerveModuleState, which adds second order kinematics to the WPI SwerveKinematics. This classes uses the math from the paper to determine an omega value that we can use in addition to a feedforward value to eliminate skew when rotating and translating. We also made a BetterSwerveModuleState, which extends upon the WPI SwerveModuleState and adds an omega value that we can use to return an omega value.

If anyone has any questions, feel free to leave them below.

-Michael

6 Likes

Kickoff Plans

Saturday

Our plans include watching through the Kickoff stream until 2. Then we plan to work on a “mock” field with table and duct tape to run a robot simulation. While some students are building the field the rest of the team will be reading through the rules packet and working to understand that. Following that, we plan to watch the field walkthrough videos and follow allow on our own “mock” field.

We will then split in to groups of around 4-6 students to discuss strategy with leadership students and mentors spread around to encourage more discussion and to help keep people on track. This will be discussion of only strategy. We want to keep the discussion focused on strategy before looking at robot mechanisms, as that narrows our thinking. Mentors will also be intervening in this section to keep the team truthful to what we can accomplish in the time frame and resources that we have available. Teams in this time will research previous games and teams that have done well in those games to hopefully gain inspiration. We will also be looking at other Open Alliance threads and the Ri3D threads for further inspiration.

If time permits we would like to run some game simulations with humans as the robot to get a feel for how the game would feel, otherwise this would be pushed to Sunday. This simulation works with each robot testing a strategy that we brainstormed so that we can get a feel for how the game works. This won’t be the most accurate or realistic method of determining how the game will feel, but it does give the opportunity for a better feel of the game to be gainedz.

Sunday

We want to start with a review of game and rule then have people start brainstorming mechanisms. We will then have people mock up initial prototypes and run more “simulations” of the game with the strategies that were thought of on Saturday.

At the end of the day we are going to vote on strategy and initial robot designs so we know what we can focus on prototyping and designing moving forward. These aren’t necessarily set in stone, but we’ll need to have another vote in order to change any strategy or robot design.

Week 1

We want to work on further prototyping initial mechanism ideas and also start mocking up some initial designs in CAD. We also we begin the work on our swerve chassis if the game allows for it; otherwise we will fall back to the tride and true 6 wheel WCD. The REV Swerve Modules are supposed to arrive around next week so we will begin work on the electrical board and chassis frame while we are waiting for modules.

If anyone has any questions or thoughts feel free to leave them below!

-Michael

6 Likes

I’m very excited to see you guys in open alliance this season! Looking forward to seeing you guys at Finger Lakes. It’s always a joy for my students to compete at your events.

Good luck this season! I hope you are able to reach your goals!

2 Likes

Kickoff

Wow, this game looks to be very hard! We’ve come to the conclusion, like many other teams, that this game will be an optimization game, basically who can be the fastest at doing everything.

Interesting Notes

  • With the average size of a 30”x30” robot + 3” bumpers, fitting 3 robots on the Charge Station will be tight.
  • There will likely be some traffic in the middle of the field as teams have to travel from opposite corners to get to their loading zone.
  • The Community will also seem to be pretty tight and there might be traffic there if there isn’t proper communication
  • Aligning to the Grid will be difficult as drivers will lack visibility meaning automation will likely be needed

Priorities for Design Going Forward

Manipulating both cones and cubes
Only grabbing pieces from the Shelf
Docking and Engaging on the Charge Station
Scoring at all positions

These are just some general priorities that we just want to focus on initially and once these are done, we can consider adding more features like grabbing from the ground, buddy climb, etc.

Chassis

We will building both the Kitbot and a custom swerve chassis this year to see the difference between the two platforms. Our current plans are for the Kitbot to run it in the 28.3”x28.3” and to run a 28”x28” swerve chassis and running the fastest MAX Swerve
gearing.

Depending on mechanism designs we might shrink the chassis to 26”x26” or even smaller as this would allow for more teams to easily fit on the Charge Station.

We’ve just received out swerve shipment and will be working on assembling it during the following week.

Software

Unfortunately, my GitHub account has been suspended for unknown reasons. So while other students might still be pushing code, our repository might be a little out of date.

Our LL2+ was recently flashed to the latest 2023.0.1 firmware and we are planning on doing some more testing with April Tags.

Going Forward

We plan to vote on initial mechanism designs later today We are running around 6 different groups prototyping different parts. If find that there are multiple designs that all look like they have potential, we will consider fleshing out more designs to see how they work with in a more developed.

Sorry for the long delay on this post, expect more frequent posts soon with prototypes, swerve testing, and April Tag testing.

-Michael

5 Likes

This is a great set of goals for the season!

Good luck gals and guys!

4 Likes

Goals we seem to set every year… Always making progress, but haven’t quite gotten there yet.

This year feels like the year though!

Week 2 Recap

Starting prototypes:

For our elevator, we started with 4 ideas, a scissor lift, a 4 bar, a dual custom virtual 4 bar (more explanation below), and a telescoping arm. A 3-stage pivoting elevator was suggested, which is currently still being discussed in comparison to the telescoping arm.

We removed the scissor lift idea first, as in the past, a scissor lift has proven to be not stable as well as difficult to wire.

We combined the 4 bar and the custom 4 bar teams, as they were both the same basic mechanism.

Another claw design we are looking at is the passive wrist idea from Ri3D Redux Passive Wrist Manipulator 2.0 and Pneumatic Tips | Ri3D Redux 2023.

Chosen Designs

These designs were ultimately chosen to work on. Based on our team size and the prototypes that came out we have decided to make 2 different upper mechanisms this year. Both mechanisms allow for reaching all levels of the Hub and had promise so we decided to move forward with both. We are still working on our claw design, but here are our designs for an pivoting elevator and virtual four bar.

Dual Custom Virtual Four Bar:

This virtual four ball had a quite promising prototype which you can see below.

This design should be relatively simple mechanically, but the programming will likely be the difficult part of this one. Controlling linked arms seem to me that it’ll have more complexity than it seems, but I’m not necessarily sure where the complexity might lie.

Pivoting Elevator

For the elevator, we may need a pivot point to help raise the mechanism. There will be a some sort of claw at the end to manipulate the game piece.



This design is more complex than the virtual four bar and I also think it’ll be harder to program. Controlling a pivoting elevator will likely be difficult because you’ll have to account for the differing force of gravity and the position of the claw mechanism. The elevator will also face differing amount of resistance as the angle changes, which is suspect will affect the PID. Our team hasn’t done an elevator in a while, so this is just mostly speculation of what I believe will occur.

Chassis:

The 6-wheel and swerve drive chassis are both fully assembled, and electrical boards for both are being made.


The code has been written and tested in simulation, but we hope to get the swerve chassis fully running by this weekend.

Some interesting notes about our chassis and design in general this year. The electrical board that is being built will be able to transferred between both the swerve and tank drive with just a few screws (this is because we only have one spare RoboRio). Both upper mechanisms are also being designed to fit both chassis, so in theory we should be able to have two functional robots at the end of this season.

Software

I’ll detail this more in a later post, but because we are building both a tank and swerve chassis as well as two upper mechanisms we are doing some finagling to make the software work.

A quick explanation of the IO structure, each IO layer is a hardware abstraction layer which allows us to set whether it should exist or not based off variables that are set in the code. Therefor, by only adjusting a few variables in the code, we should be able to easily migrate between robot structures.


Located at: https://github.com/pittsfordrobotics/ChargedUp2023/blob/master/src/main/java/com/team3181/frc2023/Constants.java

Additionally, both of these designs seem like they’re going to have fun control structures, as fast and precise control on both of these mechanisms will likely be somewhat difficult.

-Hayden and Michael

4 Likes

Thanks for sharing all of this!! Keep up the great work.

4 Likes

Up and Swerving :tada:

Our swerve drive was finally finished being assembled this Saturday and with some fiddling we were able to get it running.

The battery was a bit low when the video was being taken, which is why there are stutters, but its otherwise is running amazingly!

I’d to thank @Wesley from Team 95, who had their swerve running way before us and was able to debug a missing chassisSpeeds.omegaRadiansPerSecond being subtracted from the omega feedforward value, which fixes our second order kinematics.

We also added Wild Stang’s Spectrum Corner which allows for us to mount brackets on the outside of the chassis and also prevent stuff getting inside the gearbox.

Swerve Structure

Our code is a fusion of 364’s Base Falcon Swerve and REV’s MAXSwerve Template.

Some notable features:

  • Steering based off absolute encoder
  • Adjusted driving velocity filtering for faster response time
  • Open and closed loop control
  • Custom second order kinematics
  • Swerve simulation
  • Gyro estimation

You can find our swerve code here: https://github.com/pittsfordrobotics/ChargedUp2023/tree/swerveTuning/src/main/java/com/team3181/frc2023/subsystems/swerve

Weird Issues

First, we found that the absolute encoder offsets weren’t being set, even though they were being called though code.

We found this is is because of a wrapper class that we are using to initialize the SparkMAXes, which can be found here: https://github.com/pittsfordrobotics/ChargedUp2023/blob/swerveTuning/src/main/java/com/team3181/lib/drivers/LazySparkMax.java

The problem was that the burnFlash() call was blocking the absolute encoder configuration messages, which is weird since it doesn’t block the normal SparkMAX configuration messages.

Another problem that we faced was our front right absolute encoders seemed like it was randomly disconnecting, but after some driving around, the problem went away. We are still likely going to take apart that module and make sure we have a good connection there.

Next Steps and Thoughts

We messed briefly with increasing the steering PID value for a snappier response. We started with the default in the REV template code of 1 and increased it up to 1.5, which I found to be much more responsive (but also probably a lot worse for the lifespan of the wheels). I would think that it would be better to increase the P value even more for a faster response time (at least until it start oscillating), but that something we can test out and for our drivers to decide as well.

We luckily haven’t had any problems with our wheels breaking yet, but we have yet to drive our robot continuously for a long time yet. I would estimate we had maybe around an hour of somewhat aggressive driving today while testing the robot.

We still need to characterize our chassis to find the static, velocity, and acceleration gains. We also need to tune the drive PID so that we can run closed loop control and hopefully get some autos running soon.

I’m gonna keep this cut it short for right now, but I’ll some more detailed write ups on our second order kinematics testing and PID tunings.

If anyone has any questions on our code or anything feel free to leave a comment below!

-Michael

6 Likes

Manufacturing

Just a short update, we’ve finished all of mechanism CADs and are manufacturing right now. We hope to finish early next week and start coding at that point.

Here are some images and links with our CAD designs:

KOP Chassis

This chassis will have NEOs, but we are just using AndyMark CAD.

Swerve Chassis

End Effector

Virtual 4 Bar

Pivoting Elevator

I’ll have more images of finished construction soon hopefully!

-Michael

Lots of Progress

Things are being assembled and we’re nearing a completed robot! Our arm mechanism will probably be done on Monday and with that completed we can assembled the entire robot and start testing.

End Effector

Our end effector is fully assembled!

From the programming side, there aren’t any sensors in the end effector, so we plan on using current draw from the 550 to determine if there is a game piece or not and which game piece we have. From our initial analysis, it seems doable and I’ll report with more details once we have something written up.

Tread Replacement

While we didn’t put any slew rate limiters on our MAX Swerve initially, it seems aren’t really related to that issue, as we never faced delamination. I suspect that the state of our wheels is ultimately more from wear and tear and not the lack of a rate limiter (although I would suspect it to help at least a little).
Old wheels


New Wheel

The first two wheels where in a much worse state than the other two, we’re suspecting this is mostly due to our robot having the battery and most of the electronics on the back half of the swerve chassis. Maybe we’ll have to do tire rotations during competition?

Charge Station Testing

This is our first drive up our half charge station. It seems that we’ll have no problem getting to the top. I did a little work with an auto balance, and it seems doable, I’ll try to get a video of it on Monday.

Once again if anyone has any questions feel free to ask!

-Michael
image

3 Likes

This thread died down a bit toward the end of build season when we started building less and testing more. I assure you all that there’s no shortage of work being done!

That said, we’ve completed both of our events for the season, Finger Lakes and Pittsburgh regionals, and have not earned a bid to Houston. Fear not, we’re keeping our heads held high and viewing this season as a success! We went 2-for-2 with the Team Spirit award this year, having never won any awards ever before! So that’s a testament to this team and I couldn’t be more proud.

Going forward, we’ll be evaluating the team organization and robot for potential improvements for off-season events and going into next season. Stay tuned!

3 Likes

Congratulations on making it into the elimination rounds! That’s another checkbox from your goals for this season.

1 Like

Thanks!

I just want to draw attention to Q74 at Pittsburgh as well. Our last match of the day, and it went far better than we ever could’ve expected! There was a agreement in place before the match where a member of the opposing alliance would be playing a bit more aggressively against us to test resiliency of both bots.

It was us and a couple ~20 seeds vs the number 1, 6, and ~45 seeds, and it ended in a tie!

You can watch it here: Qualification 74 - 2023 Greater Pittsburgh Regional presented by Argo AI - YouTube

3 Likes

How did you guys go about tuning your second order kinematics? I see that in your code you are multiplying the omega value by a floating number. Did you guys just guess and check or did you use something like sysid? If you did guess and check, what behavior did you look for?

1 Like

You can tune it by putting a the kV on smart dashboard and also disabling movement along either x or y. Then move and rotate changing the kV until you have no more skew. I’ve found that to get the best results you have to do this for both closed loop and open loop.

We didn’t use any tools like sysID, but I think you might be able to.