FRC 1511 Rolling Thunder 2023 Build Thread

[Larry_Lewis]

Team 1511 is happy to join the #openalliance on Chief Delphi this year!

Background
Team 1511 is located in Penfield NY. We have been competing in FIRST since the 2005 season. We have actually been an open source team since 2009 when we started to document our design process on our Wiki, or as we like to call it our Wookiee. It serves as our engineering notebook and a way for our build subteams to coordinate efforts.

2023 Season Goals

• Build a World Championship competitive robot. We were fortunate to qualify for Championships this year due to being a Chairman’s Finalist. We would like to try to have a more competitive robot at Championships knowing that we will be attending this year.
• Improve integration amongst build subteams through better documentation and communication.
• Keep the robot design as simple as possible to reduce other technical challenges, increase robustness and reliability.
• Have a fully functional robot by our Rochester Rally Week 0 event on February 26th.

Competitions
We will be attending the following competitions.

• Finger Lakes Regional - March 16 - 18
• Tech Valley Regional - March 30 - April 1
• World Championships - April 19 - 22

Team Links
Robot CAD (Coming Soon)
Robot Software (Coming Soon)
Team Wiki (Engineering Notebook) (To be updated after kickoff)
Build Season Photos
Team Blog (To be updated over build season)

We look forward to sharing our experiences with other teams in this new format. Stay tuned for updates in the coming days!

[FIRST_Team_1511]

Happy kickoff everyone! Here’s what students on team 1511 have been up to since kickoff:

We started off by reading the game and design rules individually, then coming together as a group to discuss interesting rules and details that we wanted to mention. We then split up into smaller groups, one focused more on the design aspects of the robot and the other focused more on the strategy of the game. We were able to spend time analyzing the three different sections of the game before coming back together and playing the game on our freshly taped field as human robots.

On Sunday we started the day by splitting into groups of 3 or 4 students to come up with ideas of robot designs, and then shared those design ideas with the whole group. We began crafting our list of must haves for the robot and then used last years robot to see how both game pieces would interact with it. After attempting to run over the cone and cube in a multitude of ways, we split back into our design and strategy groups, where we began testing different design ideas and created a mind map.

Through our testing and discussion, we have been able to conclude a few things. First, we are primarily leaning towards using a swerve drive base this year, and we will most likely have a cutout in our bumpers for the game piece. We have not yet decided on an elevator or just an arm for our game piece mechanism but will be making that decision later this week. We found that the cube bounces off the robot moving full speed, while the cone tended to either fall over from the force or be pulled under the robot. We also planned out ideal times to drive across the field (~5 seconds), pick up the game pieces (~2 seconds), and score the game pieces (~4 seconds), and we will be aiming to achieve those times or make them faster throughout the build.

We’re so excited for the new season and can’t wait to see what other teams come up with! Here is a link for upcoming Week 1 pictures and videos!

Week 1 Kickoff and Prototyping

Morgan, Student Publicity Coordinator

[FIRST_Team_1511]

Finishing up Week 1

Week 1 has been filled with lots of prototyping and integration as we prepare to finalize plans for design on out robot! Here’s a look at what we have been doing:

Drive Base

• Calculated the diagonal length of the drive-base that strategy previously discussed in order to have plenty of space to maneuver the robot between the charge station and the grid
• Created a mock drive-base in CAD (also decided on having a welded drive-base)
• Due to debates with spacing issues, the drive-base sub-team has had to discuss with the lift and acquisition sub-teams, as well as drive team to compromise on the best frame perimeter (originally we had wanted a 24" x 30" but changed it to being 26.25 x 30.25", these dimensions could be changed again however)
• Created a list of materials needed to build the drive-base

Lift

• Brainstormed different lift implementations
• Did some prototyping with horizontal drawer slide and 2019 elevator
• Did 2D CAD analysis of different designs to indicate where the most amount of stress would be placed on the lift design when a game piece is being held
• Used a decision objective matrix to arrive at the final decision for lift (telescoping arm with pivot)
• Continued to prove out the design with “cartoon CAD”
• Worked with the acquisition sub-team to negotiate space based on the cartoon CAD design

Controls

• Used previous controllers as reference for what this years control design would be
• Voted on a control design and began making measurements for control dimensions
• Made a CAD drawing for controls
• Decided on using more switches this year instead of having more buttons
• PS5 controllers were picked

Programming

• Continued on AprilTag software which we used to calculate the position of the robot

On Saturday we met for integration where the different design and strategy groups along with all the mentors were able to meet and discuss everything that they had been working on. [something about key points/decisions made?]

Integration
On Saturday we met for integration where the different design and strategy groups along with all the mentors were able to meet and discuss everything that they had been working on.

• Parkable drive-base (don’t want the robot to slip if parked on charging station)
• When discussing vision, we made the point that camera mounts need to be robust and stable in order to prevent a shaky feed
• Decided that we need to be able to pick game pieces up while moving
• Need to be able to securely hold game pieces within the robot
• Use ThriftyBot modules for swerve (using ones we previously purchased)
• Decided on a bumper cutout of 12"
• Lift CAD analysis was done with a 10 pound weight on the end in order to test where the highest points of stress would be

[Larry_Lewis]

Code Repository
Now that we are starting to develop code we wanted to share our code repository. Keep in mind that this code is still a work in progress and if other teams use it, they should make sure they do so safely.
https://github.com/frc1511/thunderbot2023

[FIRST_Team_1511]

Week 2 Recap

Week 2 has been filled with lots of exciting decisions, prototyping, and CAD! Here’s a dive into what we did this week:

Drive Base

• Drive base dimensions have been finalized (24.25" x 32.25")
• There will be cutouts on the inside of the C-channel to allow for the swerve modules to rotate feely while still being structurally sound
• An FEA analysis of the drive base was done and showed that there was no significant stress on the area where the cutouts would be located
• Our diagonal distance is 49.468"
• Adding a Lexan belly pan to the drive base allowed for significantly less stress and improved the stability of the drive base as a whole
• Tested using cylinders in brick mode (when all four swerve wheels are turned toward the center) on concrete and Lexan to help stabilize the robot
  
  

Acquisition

• Decided that it would be better not to use a lead screw design for acquisition due to complexity, lack of prototyping ability, and potential for too much stress
• Gripping mechanism will use two sets of wheels to pick up game piece from the ground (4" wheels ended up being too big even though they held the cone better, so we chose 3" compliance wheels)
• At the end of Wednesday two cubes were popped most likely due to getting snagged on the back piece of metal of the acquisition design when prototyping
• Finished a CAD design of the mechanism
• Tested picking up game pieces from different angles and solved the problem of cube popping with further testing on Thursday
• Decided that acquisition will be powered by 2 NEO 550’s
• Use a hex shaft to change the angle of the mechanism and have the ability to keep the angle in place
• Need to have further discussion to decide if we will be picking up game pieces outside of the frame perimeter (original plan was to pick up inside of the frame perimeter which has a cutout for the acquisition mechanism to be)
  
  

Lift

• Created a detailed design of what the arm mechanism will be
• 67-69" reach when fully extended
• Dual ball screw actuation for a strong and speedy pivot
  4", 2.5", and 1" square tubes for each stage of the telescoping arm
• The posts for the arm are going to be 20-22" tall
• Created hard stops for each stage and added bearing blocks to the design
• Decided on a lead screw with a NEO motor to lift the arm
• Using a hybrid chain and belt system for extension and retraction (original plan was to go with chain the whole way through, but this proved to have spacing/clipping issues)
• Goal is to reduce the amount of shakiness within the arm as much as possible between stages of the arm
• Going to add large lightning holes to make the mechanism as easy to access as possible
• Rough weight check came in to 11 lbs
  
  

Controls

• Decided that controls should be to the right of the laptop
• Hinge will be on the right side and latch on the left (decided on a piano hinge)
• Closed laptop should be level with the surface of the controls
• Worked on CAD design for controls
• Decided on a battery style for controls to match the theme of this year’s game
• Using 4 solar panels that are 5.35" x 4.33" (used for bling only, not to charge anything)
• CAD of the battery terminals, interior controls, and exterior controls
• Worked on CAD assembly for all parts of controls
• Added design details to controls
• Switches and controllers have been ordered and are on the way

Overall
This week we were able to make significant progress in the design of our robot and CAD designs. We are planning on trying to have majority of the parts for our robot made by the team, and having a smaller amount made by one of our main sponsors, L3Harris. We are also looking to have a weight estimate for all parts of the robot so we can create our overall robot weight estimate in the near future. We also started a task list for what each of the subteams need to do, and dates that they need to accomplish them by to stay on track. We’re so excited for Week 3 and can’t wait to see what it will bring!

Here’s a link to pictures from our Smugmug this week: Week 2 (1-14 to 1-20) - rollingthunder

-Morgan, Student Publicity Coordinator

[JohnFogarty]

Why lead screws? Every application I’ve ever seen in the real world for lead screws are often for slower/precise movement… even some of the faster applications aren’t what I would consider fast enough for FRC use considering the weight of the rods themselves.

**Places I’ve seen lead screws used (3D printers, CNC machines, rapid travel mill tables)

What’s the speed you have calculated for moving the arm from it’s stowed position to max height/angle?

[Larry_Lewis]

Thanks for the question!
Those are actually ball screws instead of lead screws. But it is hard to tell from the picture.
We didn’t like the amount of torque that an arm driven at the shoulder would require. So we started to look at constant force springs and gas shocks to reduce the torque on the motor and rotation axis. But then we though about what if instead of just using the gas shocks we went with a linear actuator to save weight and reduce complexity.
The ball screws were chosen because they are more efficient than lead screws and are better suited for high speed applications.
When we did the math we could move the arm from it’s lowest to highest position in under a second. Which seemed plenty fast based on the robot design criteria we established after our strategy analysis and mind map.
But, we’ll have to see how it works in the real world once we have it fabricated.

[Ryan_Swanson]

We’re doing something very similar using a ball screw. In our case it’s just one ball screw mounted in parallel with 2 gas shocks. The arm is basically neutrally bouyant with the gas shocks, so the linear actuator is just for positioning with minimal load on it.

In our application we built a custom housing for the ball screw to help support it. My concern without using a housing would be shock loads from the arm hitting things. The housing we’re using includes some 3D printed supports, a brass bushing, and polycarbonate tube as shown in the pictures below.

[Larry_Lewis]

Thanks for sharing Ryan! Good point on the shock loads. Something that we will have to revisit to make sure we are ok there.

[FIRST_Team_1511]

Week 3 Recap

Week three has been such a productive week! We were running a few days behind schedule, but have been putting in the work to get back on track! Here are some details about how our week has gone:

Drive Base

• Completed our shop drawings
• Have bumper mounting hardware put on in CAD
• Created the battery box in CAD and sent the drawings to L3Harris
• Need to design a parking brake for the robot
• Want spares for cylinder mounts
• Drive base has been welded and we are working on final testing before we begin painting it

Acquisition

• Tested different angles for the gripper to be at when connected to lift, which helped to finalize our piston lengths
• Decided on a wrist mechanism for the gripper
• Have spares of the slide coming in (slide also had the problem of having small metal balls falling out when disassembling the mechanism)
• Sensor mounts will be 3D printed
• Make slight adjustments to the Lexan pieces holding together the acquisition mechanism
• Fabrication will start once final design changes are complete

Lift

• Make final adjustments to front sensor block, and make final adjustments of sensors
• Lift mechanism needs to be at least 0.25" inside frame perimeter to allow space for sensor panels
• Have some parts from L3Harris, other parts will be made by us
• Telescoping tubes have been sent to L3Harris where they will add the holes to them, and we will complete the rest here
• Lift has a 1-1.5" clearance inside frame perimeter
• Need to better refine the cradle of the mechanism and make sure that it is sturdy and can retain multiple hits

Controls

• Finalizing the location of switches and buttons
• Needed to raise up the laptop so it could be accessed easier during a match if necessary
• Handle and latches have been placed on the control system in CAD
• L3Harris drawings are almost fully complete
• Waiting for parts to come it before assembling

Robot Controls

• Finalizing the electrical parts of the robot
• Need to finalize a location of LED’s
• A panel will be put in front of the breaker to make sure robots can’t turn ours off mid match
• Sponsor panels will help to protect the inside of our robot
• Need to start planning out location of cameras and making sure that the camera mounts are in a secure location (the cameras should ideally be around the height of the April Tags)
• Continued placing electrical components in CAD
• Sensor placement needs to be discussed with each sub team

This week we also did some estimates of robot weight and came to a total of 136 pounds. We will be getting more accurate measurements of the weight, and trying to lessen the weight of our robot wherever possible. We are so excited for what week four will bring us and can’t wait to see what else we can accomplish!

Morgan, Student Publicity Coordinator

[AcesJames]

Hi Team 1511,

Nice write-ups on your progress so far. How did the team make the decision to use C-channel extrusion for the drive base? Is this the old AndyMark extrusion that came with the C-Base kitbot more than a decade ago? Back then it was held together with bolts and angular blocks in the corners of the chassis rails, though I see you’ve chosen to weld your frame together.

Almost all teams today seem to be using 2x1 box tube extrusion for their swerve drive bases (the modules act as corner gussets; no welding required) so I’m curious to hear your thought process. I think I’ve also seen in prior years that 1511 has often used sheetmetal parts, presumably made by a sponsor? Was that a consideration too?

Thanks!

[Larry_Lewis]

Great eye on the AndyMark C-channel! Yes, that is exactly what it is.

The big reason this year is cost. We had a bunch of it, and we are familiar with it. So that kinda made the decision for us.

As for the welding, we do that to save weight and keep it robust. One of our sponsors does this for us as gift in kind and does a fantastic job.

As you noted we have used sheet metal in the past. Especially in our 2015 robot. One of the things we have learned is balancing our fabrication resources that we have available to us. We currently only have two fabrication sources, our main sponsor L3Harris, and our shop. L3Harris can do our sheet metal parts with bends but we don’t send any CNC parts to them because they would take more of their time to do and would have a longer lead time. The sheet metal parts usually take them about a week and a half. If we put too many parts in there, we won’t get them fast enough. We balance that with our internal capabilities. We have a mill, lathe, plastic CNC, and 3D printers. We try to do as much as we can with those.

Sheet metal was considered but because of the pre-mentioned reasons we went with the C-channel. Thank you for your interest!

[peter_l]

Programming Update

Autonomous

This year, we have been preparing for some big improvements to our approach to programming Autonomous. Over the summer, we started work on ThunderAuto, a custom path-generation app for creating autonomous modes for Holonomic drive bases. It allows us to easily create paths using its Bézier curve editor and export them to CSV files for use on the Robot. The choice to create our own application over using pre-existing ones was to give us complete control over the process and to serve as a great learning experience. Since ThunderAuto is new, a few features aren’t fully implemented yet such as undo history, unsaved file dialog warnings, etc.

This season for programming Autonomous, our strategy is to make the robot’s task as configurable as possible. The plan is to use a custom mode-selection system on our Dashboard as shown below, that sends options over Network Tables to the robot.

Based on selections, an Autonomous mode will be constructed using multiple different ThunderAuto paths.

Vision

With the addition of AprilTags to this season’s game, we knew that we wanted to have software that could use them to help with accurately estimating the robot’s pose. We determined early on that running vision processing software on the roboRIO would not be ideal because of performance issues that we might encounter.

During the pre-season, we started writing AprilTag vision processing code into RollingRaspberry, our software for Raspberry Pi co-processors. Although not completely refined yet, we have been actively testing it and improving its functionality. One of the biggest problems that we’ve been trying to solve is resolving pose ambiguity, which we can hopefully reduce once we start testing with multiple cameras.

Automatic Alignment

Scoring can take some time, so why not try to make it easier for the drivers? We are planning to create a dynamic trajectory generation system for automatically handling alignment to the grid for scoring. After consulting with our drivers, we evaluated a few key things to take into consideration. Firstly, they requested an easy-to-use control interface – specifically something that is not 9 buttons corresponding to the 9 scoring locations. Other than that, they wanted peace of mind that they could override the path at any moment in case things go awry.

The current plan for the control interface is using the current position of the robot within the community to determine which grid it’s in front of. Then the driver can use the left, right, and down directions of the controller’s D-pad to specify which column of the grid to align with. This creates a simple interface that is easy to visualize and does not require much thought on the part of the driver. Automation can be easily overridden by moving either of the joysticks to initiate manual control of the drivetrain.

Github - ThunderAuto
Github - RollingRaspberry
Github - Dashboard

[FIRST_Team_1511]

Week 4 Recap

Week 4 is complete! Robot parts are being fabricated and we have begun to assemble our mechanisms! Here’s what we did this week:

Drive Base

• Drive base has been fully welded!
• We made sure that screw holes line up and filed down any rough edges
• Painted the drive base
• Updated the parking break in CAD and added bumpers
• Mounted swerve modules onto the drive base
• Discovered issues with the parking break, we planned to mount the bumpers at the highest possible height (7.5" off of ground) to ensure we can climb the charge station. However, this prevents us from using the parking break, as it would technically raise the bumpers and violate R402
• To fix the problem, we lowered bumpers by about 0.5" and have the parking break raise the robot 0.25", keeping the bumpers within the rules

Lift

• Completed all of the shop drawings and have L3Harris parts coming in
• CAD has been polished up
• Tubes are still being worked on at L3Harris before final assembly can be completed
• Tested the ball screws (video linked below)
  Week 4 (1-28 to 2-3) - rollingthunder

Acquisition

• Still in the process of fabricating some of the parts and still need some parts 3D printed
• Finished CNC parts
• Need to organize all the parts that we have, and know which ones need to be painted, so that when we have all our parts we can hit the ground running with the mechanism assembly
• Detailed CAD design can come after we finish getting all our parts

Controls

• Controls sheet metal parts arrived (were then cleaned and filed)
• Drilled holes for latches and handle
• Started painting the sheet metal parts
• Created an Arduino Analog and Digital table- updated it with test code

Robot Controls

• Started testing with a test board today
• Cameras still need to be placed in CAD (discuss locations for them with the lift sub team)
• Need to discuss with drive team if we want a camera on the acquisition mechanism

Week 4 has been a blast and we can’t wait to see what Week 5 brings!

Morgan, Student Publicity Coordinator

[RobotMark]

As a 1511 alumni I love this detailed open build blog! We had a very similar design for rhinobot in 2005 but had to switch to 1 lead screw because we couldn’t get them to be easily linked mechanically and prevent jamming. Do the ball screws fix the jamming or did you solve it in software?

[Larry_Lewis]

Good question Mark! The ball screws will back drive unlike the lead screw we used in 2005. So this will accommodate any misalignment. But it does cost us on control system. So we have provisions in the code to hold arm position.

[FIRST_Team_1511]

Week 5 Recap
This week we have been 3D printing lots of parts and starting our mechanism assemblies. Here’s a closer look at what we’ve been doing this week:

Controls

• Spray painted parts and worked on CAD for battery terminals and control holders
• completed CAD for solar panel platform
• locked laptop standard in
• piano hinge and latches were put on
• wired LEDs, Arduino board, and ethernet cord

Drive Base

• Worked on Lexan panels to protect the robot in CAD
• Designed mounting hardware for the Lexan panels
• Fabricated the superstructure
• Continued work on the parking break and decided to make them out of 1/8" aluminum instead of 1/2" aluminum, which helps to reduce weight without decreasing strength
• Parking break mounts were made on the CNC, and they were tested to make sure that they would fit on the robot

Acquisition

• Added another piston to support the wrist
• Tested on test board with code
• Needed to move the beam break further back on the mechanism
• 3D printed parts were not staying in position when the pistons moved so we have continued testing to fix the problem
• Brackets made for sensors
• Completed any CAD models
• Made a cradle for acquisition
• Manufactured version 2 parts

Lift

• Majority of parts have been manufactured
• Able to have aluminum cut on our CNC, which helps to significantly increase our part output
• Continuing to work on the final robot assembly

Electrical

• Mounting different electrical components
• Updated the physical copy of the Robot IO map
• Mounted compressors to the belly pan
• Assembled manifold solenoids and blocks
• Mounted the breaker and beam break
• Prepared pneumatics

We have started to run behind our original schedule, but we are putting in the work to have our robot assembled quickly! We hope to start more testing with programming in the coming week or so. We can’t wait to see what week 6 will bring!

Morgan, Student Publicity Coordinator

[Kevin_Leonard]

@peter_l

Screenshot 2023-02-01 075350.png768×302 68.7 KB

I love this idea, as figuring out which node to snap to with vision is something we’re trying to figure out as well.

A few things with it:

• Are you concerned with this visual the driver has to mentally flip the grid to match what they’re seeing from behind the driver station?
• Where does the selector start? Does it default to middle-top, so the driver can develop muscle memory of switching which node to score on without looking down at the screen?
• If the driver is at the far right of the middle grid, can they move over one more spot to get to the leftmost cone node on the right grid? Or would they have to realign to the apriltag on the right grid first?

[peter_l]

The dashboard page isn’t critical to the alignment functionality; it is just a way to visualize what the robot is trying to do. Our main goal of the alignment system is ease of use for the drivers, so we decided that for simplicity’s sake, we won’t activate the automatic alignment until the robot is in front of the correct grid. The D-Pad buttons are then just single presses to select which of the three grid columns the robot should go to. A worry was about how often a potential 9-column selection system would be used. The community is likely to have other robots in it at most times, so our drivers were naturally a bit hesitant about giving the robot lots of autonomous freedom.

The white box in the screenshot shows which grid the robot is in front of so that the drivers can verify where the robot thinks it is. When the robot isn’t in the community, the box disappears. The yellowish box in the screenshot appears when the driver activates the alignment system with the D-Pad buttons and points to the grid column the robot is trying to align with. The green box probably will be removed, as it’s not necessary for the drive alignment system. I’ve been working on a separate dashboard page that would better visualize the arm’s current and target position for our auxiliary driver.
We haven’t had the chance to test this system yet, so we aren’t sure whether the robot being in between grids will become a problem, but we’ll see. If it is, then we will obviously have to re-think some things about our approach.

[FIRST_Team_1511]

Week 6 Recap
This week we were busy finishing up our assemblies and making spare parts. Here’s a deeper dive in what we’ve been doing:

Controls

• Finished working on terminals and added them on to the case

• Brainstormed ideas for a laptop cover

• Did lots of cable management

Acquisition

• Designed a stronger piece to connect the wrist of the gripper to lift

• Disassembled the gripper to replace old parts with new, updated ones

• Made version two and…

• FINISHED THE GRIPPER!!

Lift

• Mounted the arm on the robot along with gripper

• In the middle of working on a hard stop for the arm

Drive Base

• Pneumatic and code issues were discovered while testing the parking breaks

• When the bumpers were on and the pistons were fully extended, the front was about 8" instead of the allowed 7.5"
  

  

• Height issue is planned to be fixed by moving the parking breaks above the frame

Electrical

• Finished making competition batteries

• Tested pneumatic system

• Turned the robot on for the first time
  

  

The robot is finally coming together and we are excited to see what week 7 has in store for us!

Sasha, New Student Leader