Team 177 | Bobcat Robotics | 2024 Build Blog

Welcome to the first ever Build Blog from FRC Team 177 - Bobcat Robotics!

We are excited to be publishing a public Build Blog for the first time in team history! Thank you for joining us as we tackle the 2024 FIRST Robotics Season.

Who Are We?

Team 177 Bobcat Robotics was founded in 1995 and is based out of South Windsor High School in South Windsor, CT. Our team currently supports around 90 high school students and ~20 volunteer mentors, along with 3 Teacher Advisors, and a very active Parent Booster Club.

Our teamā€™s primary sponsors and supporters for 2024 include:

  • South Windsor Public Schools
  • South Windsor Bobcats Boosters Inc.
  • Ensign Bickford Aerospace & Defense
  • Cox Communications
  • Pratt & Whitney/Raytheon
  • The Gene Haas Foundation
  • Labcorp
  • Curbell
  • Intuitive Foundation
  • WestCoast Products & Design teamwcp
  • TE Connectivity

The Bobcatā€™s Mission: ā€œOur Product Is Peopleā€

We work to inspire tomorrowā€™s STEM leaders and engage them in activities that build leadership, self-confidence, and effective communication skills. This is achieved by spreading the message of FIRST through community involvement, competitive spirit, and Gracious Professionalism. Success for us has been and always will be seeing progression in our studentsā€™ knowledge and problem solving skills inside and outside of the classroom. As our founding mentor Al Mothersele used to say, ā€œOur product is people.ā€

Team Structure

Our team is split into 6 main sub-teams:

  • Design

    • Models the robot in OnShape and delivers manufacturing drawings to Mechanical
  • Mechanical/Manufacturing

    • Manufactures our robot parts utilizing various manual and CNC machines in-house
  • Electrical

    • Designs and builds pneumatic and electrical systems for the robot, using the latest electronics components from various FRC vendors.
  • Programming

    • The team currently programs the robot in Java, using the WPILib framework.
  • Marketing & Business Administration (MBA)

    • Sponsorships, budget management, community outreach events and team fundraisers
  • Media

    • Work to develop and manage the team website, social media, apparel, and team videos & photos.
  • Three additional sub-teams are established during the season which focus on on-field performance, competitive intelligence, and partner/team support:

    • Drive Team
    • Scouting & Strategy
    • Team Help.

Important Links:

Competition Schedule

We will be competing at:

Build Blog Goals

  • A variety of student leads and mentors posting robot updates
  • Kickoff process documentation
  • Season goals definition (post game reveal)
  • At least one technical and one non technical post per week
  • Discuss dynamics of our team - ā€œHow We Workā€ including mentor and student partnerships
  • Discuss detailed prototyping and technical reviews for mechanical, software, electrical, etc
  • Discuss products being used
  • Sprinkle in work done in the pre-season
  • Students will address questions alongside mentors
  • Discuss how we help others
  • Discuss collaborating with other teams
  • Discuss how we ensure our team is having fun while still competing intensely

And much much more!

Since this is our first venture into build blogs, we will do our best to have consistent posts and updates. We openly welcome your questions and want this to be as interactive as possible.

You should also expect some fun stuff from us this season as we continue to open up our doors to other teams and our unique brand of Team Spirit.

In the meantime, hereā€™s a video of our teamā€™s history from our 25th anniversary celebration.

Stay tuned and Happy Kickoff!


ā€œBobCamā€ linkage designed by @velcro

Student Authors: @dh28567 , Pranay K.
Mentor Authors: @Akash_Rastogi, @Jake177, @velcro

32 Likes

2AM Update:

Weā€™re still prepping our posts from our Kickoff day of Crescendo, hoping to get some detailed commentary of our processes and our analysis posted sometime tomorrow. Weā€™ll also be sharing our teamā€™s guiding principles when it comes to mentoring, game analysis, setting season goals/expectations etc.

Most of us are currently tucked in at home while we wait out a heavy snow fall overnight.

In the meantime, hereā€™s some quick photos from our Kickoff:

https://www.instagram.com/p/C1xegYTPfYE/?igsh=OWFnazg0bTR1YmVh

image

5 Likes

SNOWDAY UPDATE!

Today was interesting because the snow storm hitting New England didnā€™t actually affect our meeting times all that much.

I am anticipating a more thorough game analysis post tomorrow due to some nuances we are noodling through, but I wanted to share posts from students regarding our preseason training and some information about our teamā€™s current challenges and hurdles we have to overcome.

Meeting Times

By @Akash_Rastogi

Some folks are always surprised to learn that our teamā€™s official meetings are actually quite limited, so a lot of work in CAD and software happens outside meetings, in addition toā€¦pretty much everything else. Our official season schedule is:

  • Kickoff 10am - 4pm with 1pm Lunch
  • Post Kickoff Wednesdays and Thursdays 6-8:30pm
  • Post Kickoff Saturdays 9am-3pm with Noon Lunch

Pre-season is a bit tight as well, which limits a lot of development work as a team:

  • October - December Thursdays 6pm-7:30pm

We sometimes add meetings when things are running tight or due to snow days, but this is pretty much the gist of it. Software and drive team unofficial meetings also happen at our practice field (generously donated by a local company in one of their facilities).

Regardless, here are a few items we worked on in the pre-season as a team or as individual projects, as well as some insight into our training methods.

Programming Update #1: Offseason Projects + Preseason Training

Weā€™re excited to get the season kicked-off and share our plans, but first letā€™s talk about what weā€™ve done in the offseason and preseason to prepare.

Offseason Projects:

Every year during the summer, we like to have our students work on projects that will allow them to better their understanding of programming and become familiar with new concepts or pieces of software. Hereā€™s what we did this summer:

Custom Vision System:

By @dh28567

As a team, we have usually used Limelights for our vision, and that is what we did last season as well because it was the simplest solution for us with the short time we had to play around with AprilTags. However, we did encounter a few issues with this last year like limited FOV and slightly inaccurate pose estimation due to our mounting. In addition to applying these lessons learned about physical mounting designs for 2024, we set out to fix these issues with a custom vision solution. We were planning on using Rust to make software using its NetworkTables implementation and OpenCV, but after putting a lot of work into this, we were unable to get the program working to the level we wanted, and have paused development on it for now. Our current plan is to continue using Limelights while we look into potentially adapting something like 6328ā€™s Northstar to work for our robot.

Adding on to this, we have been implementing our own Object Detection system, using the OpenCV Python library. This isā€”upon further researchā€”available in most languages, but Python is, by far, the most comprehensive. Our current model uses both shape and color to detect game pieces, such as the yellow cones (detecting for triangles) and the purple cube (detecting for squares) in the 2023 Charged Up game. We worked on OpenCV for object detection in 2022 as well, but did not end up using this on final autonomous routines.

New Base Swerve Code (+ Advantage Kit):

By @dh28567

Last year was our first year using a swerve drive train, and everyone on our team agrees that it was a huge success, so we will likely be continuing to use it for many years to come. Last year we used 364ā€™s BaseTalonFXSwerve code because we didnā€™t want to spend too much time getting it up and running, and while that worked fine for us (mostly), we would like to have our own swerve code base that we can use as a template for our future robots.

We decided to include some new features in this project as well, like 6328ā€™s Advantage Kit. After having some issues with our autos last year that we couldnā€™t debug, we decided that some sort of data logging would be something we would need this year, and we have heard very good things about Advantage Kit. Some other things that were updated from our previous swerve code are:

  • Simulation
  • New PathPlanner version
  • Phoenix 6/PRO
  • New WPILib version
  • Better comments/documentation

We have only had a very limited amount of testing with this code, but we did get the wheels spinning correctly when the robot is tipped on its side, and it drives around and follows paths in simulation. During our most recent test we werenā€™t able to get it to move at all despite not changing that much code regarding teleop and we have reached the conclusion that it must be some sort of licensing issue with the CANivore as the last time it functioned normally was before New Years. We are also aware of a small bug with some nonoptimal wheel rotations, we think it is just an issue caused by the CANcoders wrapping back around to 0 and will work to fix this issue shortly. The code for it can be found here: GitHub - BobcatRobotics/Bobcat-Base-Swerve: 177 Bobcat Robotics base swerve template

Inverse Kinematics:

By @AidenK

In previous years, our team has relied solely on PID loops traveling to prerecorded encoder setpoints to reach certain robot states. We knew we were leaving a lot of performance on the table, so, inspired by 6328ā€™s insane control system, we began to look into more sophisticated control methods. Unfortunately, math is hard, and implementing state-space control proved too advanced for a short one-person preseason project, but we found a nice stepping stone into model-based control: kinematics. In short, kinematic equations describe the relationship between your robotā€™s current state and the end effectorā€™s position. While the robot would still rely on several parallel PIDs, knowing these equations would streamline the process of setting the robot to scoring and intaking positions, as well as making code more readable. Thankfully, our 2023 robot is relatively simple, and is essentially a double-jointed arm mounted to an angled elevator. Ultimately, we were able to derive the equations using some basic geometry and trig. We hope to use this knowledge in 2024 to create more efficient control systems.

Quick thanks to @jonahb55 @bbonner @Connor_H and all of 6328 for inspiring our students to try new things!

Programming Preseason Training:

Taking a step away from the ā€œ1s and 0sā€ of programming, we found it important to include all members of our team, regardless of skill level, into our subteam. For newer programming students, we offer training and simple projects for them to work on to help them get an understanding of both Java and WPILib, as well as all of the other libraries we use for our code. Hereā€™s what we did this year:

Leveling System

We found it effective to include a ā€œlevelā€ system as every student has a different starting point. Some students came into the first meeting with a big smile on their face and a confident choice to be on the programming subteam, whereas other students were a bit hesitant. We wanted to make sure all students felt welcome and wished to accommodate each of these students to their own personal needs. We created a general structure of this system:

  • Level 1: Students who have little to no experience with Java
    • These students would start off with the Codecademy courses and gradually make their way up to working with Romis from Pololu
  • Level 2: Students who have experience with Java but not with FIRST Programming
    • These students would start off with Romis and continue on to helping with our Offseason projects once they felt comfortable
  • Level 3: Students who have experience with FIRST Programming
    • These students would start off with helping us with offseason projects
    • We did not have many students in this group

|214x213.77319587628867

Codecademy:

We found that Codeacademyā€™s ā€œLearn Javaā€ course was a good way to introduce completely new students to programming and Java. We had them complete modules 1-6 and 8-10, these cover a wide range of basic programming skills, and we felt that after this, they would be adequately prepared to experiment around on the Romis.

Romis:

Once students had a basic understanding of programming, we used the Romis to introduce them to WPILib. Their projects consisted mainly of learning how to write and deploy code from VSCode and create simple dead reckoned autonomous paths.

Mechanical Pre-Season Update/Training

By Brian M.

Pre-Season has come to an end, and team 177ā€™s Mechanical sub-team is prepared and excited to crescendo into action! This year we welcome a new teacher to our metal shop, and with them many changes that we are taking in stride and using to our advantage. Along with a complete deep cleaning and reorganization of our machine shop, we are welcoming a new horizontal band saw and a new plasma-cutter table replacement to our shop.

Pre-season was not only a productive and educational experience, but a blast to all of our new and returning mech team students. New safety and education procedures were implemented into the shop which were gone through very thoroughly. Safety is fun here at Bobcat Robotics!

Our annual shop scavenger hunt came with a new twist this year as shop-seasoned returning members also had to reacquaint themselves with all the rearrangement and reorganization over the summer. Luckily, things are now clean and everything in the shop is slowly learning its new home. This cleaning and reorganization was truly needed for a team that has been in the same shop for 3 DECADES!

Some of our students have been working diligently on training themselves how to use our Tormach CNC machine. Previously an underutilized resource, we are hoping to deploy and utilize it this season to make more precise and replicable parts quicker and easier than ever before. In the transition period before our replacement CNC plasma cutter table is here, we are hoping that the Tormach can pick up some of the slack.

Along with training on our lathe, our various milling machines, and our numerous types of saws, we really tried to focus on team building and gracious professionalism within our sub-team, our team, and we also met with other teams to strengthen our friendship and connections with each other.

Student authors: @dh28567, @AidenK, Brian M.
Mentor authors: @Akash_Rastogi

Thanks for sticking around!

10 Likes

Quick update on the base swerve code: the bug where the modules would excessively rotate was fixed by simply enabling continuous input on the angle PID controller for the modules.

3 Likes

Shooter Trajectory Calculation Team Resource

Welcome back! Our team is in the midst of making some final strategy based robot architecture requirements which will then trickle down into mechanism requirements. These requirements get more granular and more specific the further you go downā€¦but thatā€™s a topic for another post.

During many discussions, we need to determine what kinds of shots on goals, such as the Speaker in 2024, are feasible based on a multivariate approach. This can include things like release angle, release height, distance, etc.

Note Trajectory Calculator by Team 177

We thought it would be useful to see what trajectories would be needed for shooting from various distances and heights. This google sheet should be copied (File>Make a Copy) or exported and used as shown below. You may need to be logged into Google Drive to copy.

Hereā€™s What it Does:

  • Given a horizontal and vertical distance from the Note release to the center of the Speaker opening, it will provide an initial velocity and angle to get the Note to the Speaker just at the highest point of the trajectory. This is a starting point. Ideally the velocity will be a little higher, and the angle will be a little lower so the Note is still moving up as it passes through the center.
    (blue is constant, yellow is input, green is result)
    You should only need to modify yellow cells.

  • Plots this trajectory, with the Speaker opening shown by two red triangles
  • Given a list of horizontal distances, it provides a list of initial velocities and angles for getting the Note to the Speaker center at the highest point, as mentioned above. (It uses the single vertical distance used above)
  • Plot the velocities and angles as a function of horizontal distances
  • Given a horizontal and vertical distance from the Note release to the center of the Speaker opening, and the shooting angle, it will provide an initial velocity to get the Note to the center of the opening. This lets you tweak for a flatter trajectory.
  • Plot the trajectory for any given initial velocity and angle.

Disclaimer - This is just an estimate, as it doesnā€™t include air resistance, effects of spin, etc. YMMV but this is a good place to start.

What Your Workflow Could Be:

  • Download the sheet to the format of your choice
  • Enter a horizontal distance and a height of the release point (yellow boxes on first sheet)
  • See roughly what the angle and velocity is (green boxes)
  • If you can achieve those with your robot, then fine tune on the next sheet. If not, pick a closer distance
  • On the next sheet, input the angle you want to shoot (yellow box near the bottom), and see what the velocity is (green box). Plug those numbers into the theta and v0 yellow boxes near the top, and see the trajectory.

  • Alternatively, put whatever you want in the upper yellow boxes and see the trajectory.

We hope this is helpful for other teams for this season and for future seasons! This methodology works well for us, but if you have alternative suggestions or enhancements, we would love to learn about those if you are willing to share!

Please ask @velcro if you have any comments, questions or corrections.

Mentor authors: @velcro
Intro: @Akash_Rastogi

Finger Guns Michael Scott GIF - Finger Guns Michael Scott Steve Carell GIFs

25 Likes

You have no idea how big a fan I am of that note trajectory calculatorā€¦

3 Likes

Should have added - this is just an estimate, as it doesnā€™t include air resistance, effects of spin, etc.

3 Likes

Will definitely be messing around with it once we get our field elements built

1 Like

@velcro This is a great tool, and something that can help make impactful decisions early.

I put some of the theoretical values from the lower table into the ā€˜greenā€™ boxes, to see what the arcs would look like. Mainly because weā€™re trying to keep our subwoofer shot under 60 degrees for packaging,

The entry vector for the note from some of the further distances is a bit too close to margin of error for me, but I think thatā€™s simply a matter of updating the coordinate system to put the goal in reference to the field wall? May also need to update ymax as well. Not sure what other elements of the sheet would be impacted by that though. I might also add a modifier to theta & v0 to ā€˜flattenā€™ the trajectory out a bit, but we first need to do some prototyping to confirm thatā€™s our approach.

This image is with x0 = -100 and y0 = 48
image

These values are based on the OnShape CAD for the speaker
image

@JesseK, Iā€™m glad you are finding this useful!
The way I set it up is independent of the field wall. The only dimensions are:
-Note exit to Speaker midpoint
-Height of Note exit off of floor
-Height of Speaker midpoint off of floor

If you know robot distance from the field wall and the distance of the Speaker center from the field wall, then the difference is the x0 in the spreadsheet.

In the first sheet, I am aiming to get the peak altitude right at the Speaker center.
To get max Y (height of speaker center) I used the Game Manual dimensions for the Speaker 5.6.1

The lowest edge of the SPEAKER opening is 6 ft. 6 in. (~198 cm) from the
carpet, and the highest edge of the opening is 6 ft. 10ā…ž in. (~211 cm) above the carpet.
That works out to 80.4375 for the center point, so I rounded.

The coordinates of the red triangles (Speaker opening endpoints) are in rows 24 and 25, and the X dimension is from Speaker center. I just eyeballed the +/-10 from a sketch, but you can change those to whatever you like.

I put some of the theoretical values from the lower table into the ā€˜greenā€™ boxes, to see what the arcs would look like.

Not sure what you mean here, but it points out an error. The x0 and y0 on the second sheet (F4 and F5) should be yellow, not green.

I might also add a modifier to theta & v0 to ā€˜flattenā€™ the trajectory out a bit

Thatā€™s what the second sheet is for. you can change theta and v0 to whatever you want to see what happens. If you want to go through the center and know your theta, then it tells you what v0 to use.

I hope this helps, please feel free to keep the conversation going.

2 Likes

Thanks for the additional information. The original post has been updated.

@velcro Great tool! How would I go about figuring out if we can reach the required exit velocity? Thanks

Glad you like it!

TL;DR - run your motor as fast as you can and see how far it goes!

You can calculate exit velocity, but it depends on a lot of variables.
The load of squeezing and accelerating a Note will temporarily slow a motor down from its free speed. The amount depends on the compression, inertia, and how quickly your motor controller can correct for the added load.
Wheels will slip on the note, depending again on compression, how long the Note is touching the wheel, and maybe how worn the Notes are and how dirty the wheels are.

Given those uncertainties, if you want to try to get a prediction for exit velocity, the starting point is wheel surface speed.
If you know your motor RPM, divide by 60 to get rev/sec
(I would start with 80% of free speed for estimating RPM, but I havenā€™t worked with Notes yet, so this is just a guess - people with more experience can chime in)
Wheel circumference is about 3.14*diameter, which is how far a point on the wheel moves in a revolution while moving in a circle.
To get velocity you multiply them.

RPM/60*diameter(inches)*3.14=wheel surface speed ( inches per second, or ips)

If you have two wheels on opposite sides of the Note, then the surface speed is the same as the Note speed (ignoring the uncertainties). There is no spin on the Note, generally speaking.

If you have a wheel and a fixed surface that pinches it (like a hood in previous shooters), then the note speed is only half the wheel surface speed. This is confusing, but think about a rolling Note. The top of the Note is moving at a certain speed (that is the part pushed by the shooter wheel) The bottom contact point is not actually moving with respect to the ground. It is rolling, but not slipping. That means the middle of the Note is moving halfway between the top and bottom speeds, or half the wheel surface speed. This makes more sense when you realize that with a single wheel shooter you have spin on the Note, and you want to know how fast the middle of the Note is going, not the edge.

As I said, the reasons are confusing, but if you play with it you can figure It out.

Hope that helps, let me know if you have any other questions.

2 Likes

Catching Up

It has been a few days since I last posted, so Iā€™m probably going to go a bit out of order here on topics. It may get wordy, but it is Saturday night and youā€™re reading this sentence, so maybe youā€™ll read a few more, who knows. Iā€™m making these as detailed as possible, but hopefully they wonā€™t be boring.

Our students have been awesome and have created a wide variety of content for our build blog for Open Alliance, but Iā€™ve been slacking at getting them edited and posted up. So, hopefully all of you donā€™t mind a few different topics being covered in the next few posts ranging from Kickoff and our teamā€™s ā€œGuiding Principles,ā€ to our most recent prototypes and field building.

Product of Process:

I wanted to quickly get a post down about our teamā€™s Kickoff processes. They arenā€™t much different from many others who are posting blogs, but despite our limited meeting times, we still dedicate our entire first week to determining a very tightly defined strategy, robot requirements, architecture, and then mechanisms.

Kickoff Outline:

We like to start our Kickoff meeting by saying the day is focused on WHAT rather than HOW. Before we get into things like brainstorming designs for mechanisms or laying out autonomous routines (HOW something can be accomplished during a match) we want to make sure we have a clear picture of all the gameā€™s aspects (WHAT can be accomplished during a match).

Before the game is revealed we work on some goal definitions with the team. This helps us to ensure the team is all aligned on what we will be looking to accomplish over the course of the season. This year, we broke these goals into three categories:

2024 Season Goals

  • Overarching Goals - These are guiding principles that we want to make sure are driving all of our actions.
    • Be safe
    • Act with Gracious Professionalism
    • Have Fun!
  • Competition Goals - We always strive to be competitive at the highest level of the program, but we also recognize that on-field results are just one of many ways to measure our success as a team.
    • Rank 1st after qualification matches at an event
    • End the season with confetti on the robot (This is how we like to phrase winning the World Championship.)
    • Execute autonomous routines consistently
    • Document and practice common pit procedures
    • Refine digital scouting system
  • Team Goals - These are areas that we want to make sure we are focusing on throughout the season
    • Encourage involvement from all students, regardless of experience levels
    • Try new things
    • Ensure team members are communicating effectively
    • Reduce single person dependencies
    • Maintain an Open Alliance thread on Chief Delphi

A note on these goals:

Every year this list includes winning a World Championship, but that doesnā€™t mean ā€œConfetti or bust.ā€ For us, including that goal means that we set our sights on being able to play the game at the highest level. Ultimately, we still frame achieving success in the competition setting as a method of serving our overarching goal of having fun. We never want to lose sight of the fact that the robot is the ā€œcampfireā€ that draws us together, and what we do around it is ultimately what matters.

Initial Game Breakdown

The team gathers in large groups to read the manual, extracting critical information in a cheat sheet format. We recommend that while reading the manual, teams write down questions they have, and as they continue to read, answer those questions on a board together.

Upon watching the game animation and looking through the manual, we came together as a group to create a comprehensive list of tasks a robot should be capable of doing and weighing the importance of these capabilities depending on how they would impact our ranking point (RP) scores in quals and matchpoint scores in playoffs. We know these are the two items we need to maximize to win matches and to rank high, ultimately leading to wins.It is critical to note this means writing down ALL tanks a robot CAN do in a match, it does not yet define what we are choosing to do.

Game Tasks List

  • Score NOTES
    • In SPEAKER
      • From CENTER LINE
      • From PODIUM
      • From SUBWOOFER
    • In AMP
    • In TRAP
  • Get ONSTAGE
    • Alone
    • With 1 partner
    • With 2 partners
  • Return to field from being ONSTAGE
  • Drive
    • On open field
    • Under STAGE
  • Actively control a NOTE
  • Acquire a NOTE
    • From the field
    • From the SOURCE
  • Play defense

One of the things that became apparent to us as we started digging into the details of this game was the connections between different aspects of the game. To help understand these connections, we went through a few theoretical scenarios.

  • Endgame - All three robots on an alliance can complete the ONSTAGE and TRAP
    • Scenario #1: All robots on one SPOTLIT chain, 1 TRAP - 21
    • Scenario #2: Each robot on its own non-SPOTLIT chain, 3 TRAPS - 24
    • Conclusion: HARMONY points are only worthwhile if a robot canā€™t score in a TRAP
  • AMPLIFIED SPEAKER - An alliance can score 3 NOTES in any combination of AMP and SPEAKER
    • Scenario #1: 3 NOTES in SPEAKER (non-AMPLIFIED) - 6
    • Scenario #2: 2 NOTES in AMP, 1 NOTE in SPEAKER (AMPLIFIED) - 7
    • Conclusion: AMPLIFYING SPEAKER is worthwhile as long as you can score at least 1 NOTE in the SPEAKER while it is AMPLIFIED

Drawing Conclusions & Making Some Priorities

image

Before we defined priorities for our robot functions, we laid out our conclusions and priorities for match play and tournament play.

  • Melody RP - For maximizing the number of notes scored, the speaker is more efficient than the amp. All 3 robots can score in it at the same time, and they can score in it from a distance. The amp can make this easier through the coop bonus, but isnā€™t required.
Detailed Student Analysis:

We began by looking solely at how to gain the most RPs. For the melody RP, we deemed it crucial to get the coopertition bonus early on in tele-op to avoid the risk of losing it from a lack of coordination when putting it off to the end of the first 45 seconds of tele-op. This would be essential for making the RP more attainable and in case of tiebreakers. Along with this, we believe that, when disregarding match points and focusing only on note quantity, scoring in the speaker alone would yield the best results, as numerous bots could score into it simultaneously and we could score from a greater distance away, thus decreasing cycle time. Cycle time was another major component we looked at for this RP, as quick cycles would mean both having accurate intaking and positioning while also avoiding defense. To account for this, we included automatic alignment on our list, in which we weighed goal and source detection over object detection. This would assist with distance shooting as well. In particular, we saw being able to pick from the floor as a priority. Even if human players canā€™t toss game pieces across the field like last year, being able to intake without clogging the source is crucial. Additionally, being able to pick up notes from multiple sides of the intake was included as a potentially important task to combat slowdowns from defense. We also felt that being able to travel under the chains of the stage (apx. 2ā€™4ā€™ā€™ tall) would be crucial to decreasing cycle time, as opposed to congesting the sides of the field or being more easily blocked by tall defense bots.

  • Ensemble RP - We donā€™t want to rely on both our partners always being able to get onstage. That means we need to be able to get onstage, and score 10 points without 3 onstage robots. The only way to do that without a trap requires 2 robots on the same chain, with a spotlight. This makes the trap important in scoring the Ensemble RP complete consistently.
Detailed Student Analysis:

When first looking at this RP, we considered the following combinations as the primary ways to rack up the 10 point and 2 onstage bots requirement: having the 2 onstage robots in harmony and scoring a spotlight, having 3 robots onstage with at least 2 in harmony, and having 2 onstage bots and scoring in the trap. Of these, we considered the latter to be the best way to get the RP, as it would require the least amount of additional steps with a sufficiently high point yield as long as we could consistently score in the trap. Having gained the harmony or spotlight points in addition to this would only be extra. Additionally, it would be more viable to leave a bot on the floor to score more notes for the sake of additional points.

  • Maximizing Match Points - Requires both amp and speaker for amplification. Cycle times can also be minimized by driving under the stage, and scoring in the speaker from as far away as possible.
Detailed Student Analysis:

When putting more focus on matchpoints, our attention went towards the amp. It would be crucial to have our speaker amplified for as much of teleop as possible, and considering the extra time that would be needed to get up close to the amp for scoring, it would be good to have a bot putting more focus on amplification. Once the speaker is amplified, we would want to score 4 notes as soon as possible (ideally close to or under 10 seconds) and get ready for the next amplification, which would hopefully come close after the one preceding it. Obviously, defense has the potential to disrupt the timing of this cycle, which is why going under the stage chains, accurately scoring from a distance, and picking from the ground are all the more important. We also hope to use the protected zone when necessary.

Robot Action Requirements (Auto & Tele)

The next step involves taking these overarching targets and aligning them with Direct Required robot actions and Indirect Required robot actions. A short example of this is:

Some team might find it surprising that we actually split into two groups for this discussion. This is because we are a large team and it helps to split up the conversation into manageable groups. The other reason is that it helps to think about requirements for Tele-op and Auton independently so that students arenā€™t thinking of two very different situations at the same time - this can lead to decisions and priorities being difficult to arrange. The controls team leads the auton discussion while mechanical/design leads tele-op.

Tele-Op - This group tries to determine which robot actions are required for tele-op to maximize match points and ranking points.

Auton - This group determines which types of autonomous modes we want to develop to maximize match points and ranking points.

Both of these groups start defining in greater detail what our robot requirement might look like. We also define these requirements in the context of the different stages of our season:

  • Week 1 District
  • Week 4 District
  • DCMP
  • World Championship

The two groups then reconvene and discuss overlapping robot functional requirements based on strategy. Funny enough, there are times when a requirement does not come up during auton, but is identified by tele-op and vice versa.

Example from the Auton group:

The Auton group does this exact task with a multitude of potential auto modes and paths drawn by lead software/strategy students and mentors and then derives robot actions needed to accomplish them. By the end, we create a prioritized list of our autos. These often have fun internal names so we remember what they do, but in PathPlanner theyā€™ll be easier to read.

The result from the combined conversation:

If you have any questions about the process explained above, let us know!

On a personal note from Akash - 177 is the 8th FRC team I have been a part of, and I can easily say that this team has the most robust, well developed, refined, and best implemented analysis and design process Iā€™ve been a part of.

Thanks for sticking around for this long post. Tomorrow Iā€™ll put up more about what the Programming and Electrical teams have been up to since Kickoff, as well as a few scouting tidbits and Iā€™ll sprinkle in some prototyping photos/videos too!

Student Authors: Akshaj N., Adithya A.

Mentor Authors: @Akash_Rastogi, @Jake177, @Molly_Connolly

8 Likes

When dealing with auton designs - How do you capture intended strategic requirements without them becoming design requirements? So, in this one thereā€™s several ways to shoot, acquire, shoot (intake/firing on opposite sides, turning the chassis, scooting around and between the NOTESā€¦ turrets) obviously these have downstream impacts on design and it is difficult to not have it lead into design discussions during strategy discussion.

I think the strategic requirements for autos are purely based on a point analysis along with considerations like: auto path end positions, which event/milestone in our competition season weā€™re talking about, geometry based likelihood of making shots, as well as discussions of our predicted speed of performing the action and predicted student/mentor skills and ability, etc. We also make a long list of items that need to be tested in CAD and physical prototypes to determine difficulty levels - such as further possible shots. Noting the pros and cons of each proposed auto path as a group helps a ton with this. The exercise you see here starts with just the path on screen (proposed earlier by some of the more experience students and mentors). As a group we fill in the points earned, pros, cons, and what robot actions are required to complete the path/strategy.

You could say that the autonomous mode discussions can happen with a Weighted Objectives Table themselves, but we are typically brutally honest with ourselves from the start and stay self aware of team resources and skill levels. Our students are welcome to dispute our evaluations, and we absolutely welcome them to prove our assumptions wrong (it happens all the time). The mentors also play the role of managing student expectations here - we want to challenge them, but we donā€™t want to overwhelm or burn kids out - that is not fun.

At this point in the discussion, we do allow robot architecture to come into play because all our decisions should be derived from the above goal from the maximizing match scores and RP perspective. We still restrict students from locking into a HOW for each requirement (IE ā€œwe need a turretā€ is not yet an option, but it becomes a generic ā€œImplies articulated scoring mechanismā€ during our summary at the end of the night). Same goes for defining the requirements as ā€œIntake not on same side as outputā€.

A lot of that as you can imagine also happens because more experienced mentors and students are able to come to some conclusions a bit more intuitively than others. We donā€™t outright call these decisions, but we do lean heavily into team experience as everyone likely does.

It becomes a really subtle exercise in managing what the ā€œHOWā€ in each step is referring to as you get more granular.

All that to say - it depends, but we allow some robot architecture requirements to come into play especially if students are able to rationalize it and tie it back to the goals of maximizing scores and ranking points.

Hopefully that explanation makes sense at 1:30am EST :sweat_smile:

3 Likes

Programming, Prototypes, andā€¦Psoldering?

Weā€™ve gone over plenty of our strategy work since Kickoff, but what has everyone else been up to since? Weā€™ve only met 3 times since Kickoff for a total of 11 hours - hereā€™s everything weā€™ve accomplished so far and set targets for!

Predicting Software Needs:

Programming had one of the most productive kickoffs in recent memory. After watching the game reveal as a team, the senior programming students and mentors broke off to create a targeted list of development priorities for the season. We came up with a set of high-priority items for all of programming to work on, and smaller tasks for groups of 2 or 3 people to work on led by the senior programming students and mentors.

This type of priority setting on Day 1 helps us establish homework that can be accomplished immediately after kickoff and to determine the status of projects we began in the offseason which we predict to be critical to success in the season. Sometimes this may produce more work for us which may not be used on the final robot, but it prepares us for a variety of robot requirements and software/controls requirements we may need to be competitive at World Championships. This allows us to also make a lot of progress between meetings, especially between Saturday and Wednesday.

Whole group topics:

In the days after kickoff, we worked on all of these topics individually, and prepared to discuss them during our next meeting the following Wednesday.

Game manual cheat sheet

To both familiarize ourselves with the manual, and have a quick reference for field measurements and other relevant information such as AprilTag placement, each of us made our own cheatsheet for future reference. Students are not allowed to peek at their peersā€™ folders in our Google Drive for this exercise.

Potential Autos

We all drew out some potential autos that we might be running this year, ranging from incredibly simple to exceedingly difficult. In our Wednesday meeting, we discussed and ranked these autos in terms of priority, difficulty, and overall usefulness based on a points analysis, pros/cons, and robot action requirements. Students are not allowed to peek at their peersā€™ folders in our Google Drive for this exercise.

Some of these auto examples are discussed in the prior blog post.

2013 Retrospective (from the perspective of potential sensors to prepare for)

Since the game pieces this year are so similar to the frisbees from 2013, we decided to each pick a high-level team from that year (dibs on 254), and analyze their mechanisms, to get a better idea of what our robot might look like this year. With 2013ā€™s designs in mind, we devised a list of sensors and feedback we would likely want on the robot for various potential mechanisms so that we could hand off our requirements to the design team as soon as possible, and familiarize ourselves with how to use the sensors in Java.

For example - ā€œif adjustable shooter angle, then software team requires absolute encoder integration, and/or limit switch reset.ā€

Logging and simulation

This year, we are excited to use AdvantageKit. We look forward to using all of the debugging, simulation, and logging capabilities it has, but, due to its complexity and overall ā€œdifferentnessā€ from our typical coding style, we found it prudent to familiarize ourselves with it. So far we have already been using the Simulation functionality to view our PathPlanner autonomous paths.

Path Planning/Auto Alignment

Due to both a longstanding desire to automate TeleOp tasks and relatively bad sightlines for the drivers in the 2024 field, we want to automate as much of the fine control needed on the drivetrain as possible. We will be using many of PathPlannerā€™s built-in features, such as on-the-fly path generation with object avoidance, hopefully allowing for much more streamlined auto-creation and Source/Amp/Trap/Note alignment.

Individual topics:

Specific student pairs (1 upper and 1 underclassmen) were assigned topics to investigate and then teach all other programming team members.

Localization/AprilTags

Last season we had success using the built-in AprilTag detection on the Limelight 3ā€™s, and we will be doing the same thing this year. We will also pay much closer attention to the placement of the cameras, to allow for continuous tracking of multiple tags at any given moment.

Object Detection

For more advanced autos, particularly with regards to the center line, we will be running object detection on a Limelight 3 or using a global shutter Arducam running on a RasberyPi (or OrangePi), boosted with a Google Coral USB accelerator. We want to be able to detect if centerline notes have already been taken by the opposing alliance, so that we can go for other ones and avoid high-speed collisions with other alliances.

Prototyping

As the mech and design teams cook up some mechanism prototypes, we need to be able to quickly create code to run them. To do this, we made a repo with some simple motor control subsystems, such as running a motor at a specific velocity or a specific distance. We have it set up to be able to change constants such as CAN IDs or PID gains from shuffleboard, to limit the need to redeploy every time a change is made.

Having a dedicated few students to prototyping, electrical, and also having an easy to use adjustable UI/Dashboard makes prototyping a much simpler task that will also be quicker than waiting for a student to create quick on the fly programs or hooking prototypes up to existing robots with similar functions.

Example of the software requirements for the Prototyping Repository:

Intake Features:

  • Accommodate up to 3 motors - Rev Vortex/Flex OR TalonFX
  • Adjustable CAN ID, Motor Invert, Brake mode, Current limit, and FOC (Field Oriented Control) all on shuffleboard
  • Adjustable Idle run speed (feed-forward?)
  • Run intake in and out commands
    • Binded to two different buttons on gamepad
  • Updatable configurations for motors

Shooter Features:

  • Accommodate up to 3 motors - Rev Vortex/Flex OR TalonFX
  • Adjustable CAN ID, Motor Invert, Brake mode, Current limit, and FOC (Field Oriented Control) all on shuffleboard

To be added:

  • ā€œShootā€ command - run intake, stage with TOF sensor, shoot once at desired RPM
  • Pneumatics system
  • Add Falcon position PID control subsystem (for elevator, arm, wrist, etc.)
  • Add ability to run multiple of each subsystem depending on Shuffleboard input

Other Software Status Updates as of 1/14/24:

  • Swerve with FOC is up and running, need to head to practice field for proper testing of updated PathPlanner
  • AprilTag detection with the new tag family looks great with Coral and LL3, even at distances.
    • Next tests must include detection and localization from below 28ā€ and from various angles/distances.
  • Object Detection model for Notes is in the works - training on large datasets gathered on Chief Delphi and Roboflow. Using Yolov5 and Yolov8 - ensuring training dataset includes low light conditions and photos from below 28ā€ and various angles

Prototypes

Design, mechanical, and electrical began work on shooter and intake prototypes. Electrical wired up motors for intake prototypes as the integration of this is a high priority in order to determine if Over the Bumper or ā€œUndertakerā€ intakes are easier to integrate and equally as effective.

We broke out our 2013 Ultimate Ascent frisbee shooter to retrofit it quickly for some early Note shooter prototypes. The results here were just to give students an early feel for how Notes behave when ejected from compressed systems with inertia. Additional prototypes to determine ideal compression and wheels are in the works.


The above intake uses 2" Thriftybot Squish wheels.

Intake prototype running with motors at 1:1 free speed.

More prototyping is in the works, but the majority of our geometry tests are also done in OnShape 2D sketches. Weā€™ll try to share more of those when theyā€™re a bit more fleshed out.

Hereā€™s our freshly CNC laser cut bellypan with mostly assembled SDS MK4i modules on our initial iteration of the 2024 robot. Just waiting to attach a few more Falcon500ā€™s.

Slow-motion Intake Video:

ezgif-4-317ee82a4a

Soldering Workshop/Wiring Prototypes

The electrical team had a busy few days of getting robots prepared to be able to run prototypes with new motors we just purchased. They also learned proper soldering techniques as we plan to create more custom circuits this season. Electrical students also update firmware and licenses on our control systems hardware and on all other devices on our practice Swerve base.

Hereā€™s a cool product weā€™d recommend for teams who like soldering. Very useful Omnivise.

Field Build!

Finally! A MASSIVE shout out to our carpentry and woodworking teachers, mentors, and volunteer parents who are almost done with all of our field elements! Your dedication is what makes our success possible!

Good night and keep warm!

Student authors: @AidenK, @dh28567, Pranay K., Goutham, Samarth, Zain L.
Mentor authors: @Akash_Rastogi

10 Likes

One more fun thing I got to do today that isnā€™t an entire blog post is visit our friends over at Team Paragon, FRC 571. I got them up and running with their new Omio X8 CNC router and showed them the CAD to CAM to Mach3 process.

These guys were absolutely fantastic alliance partners to us in 2023 with a very effective cube runner, and Iā€™m really excited to see what they are capable of in 2024 with additional resources.

If any other local teams need assistance with getting started with their machines, or need help with getting some parts cut by me or our team, please shoot me a PM or email me at arastogi (at) bobcatrobotics (dot) org!

Otherwise, if you arenā€™t in our drivable area, I highly recommend this resource by another friendly local team - FRC Team 7407 -

7 Likes

I wanted to get something important to our team posted up here this morning. This is not something that is codified in our team mission or by-laws, nor are they rules, but these are a few agreed upon guiding principles by our team.

These were gathered by current mentors, students, and alumni and compiled by our Lead Mentor - @Jake177

We welcome any questions you may have - either in this thread or at our upcoming events!

-Akash

12 Likes

Weā€™re back! Apologies for not posting updates for a while, weā€™ve been in the heat of prototyping, refining, trimming down and reevaluating, and fleshing out initial robot designs. Iā€™m working on a more comprehensive robot post, but in the meantime we wanted to share some of our scouting work.

Scouting

Welcome to 177ā€™s first scouting post! We are especially excited about this because it is only the second year where we are going to use a digital scouting app. We are very proud of the capabilities of our scouting app for Charged Up and we are excited to improve on them for Crescendo.

Building the Scouting App

Our scouting app has two parts - the frontend and the backend. The frontend is a static webpage hosted on Github pages (this is currently best optimized for mobile, specifically an iPhone 11 as that seems to be the most popular device for students on our team).

Link to 2023 Bobcat Scouting: https://lunar-academy.github.io/bobcat-scouting/

The frontend is a heavily modified version of team 2451ā€™s 2023 ScoutingPASS (GitHub - PWNAGERobotics/ScoutingPASS: A FRC Competition Scouting Application).

We thought that their implementation of the scouting app was really great (specifically auto-incrementing matches and automatically pulling team numbers using the TBA api), but we felt like changing certain design elements for better readability and ease of use on mobile specifically, namely changing button size, changing the font, and colors. We also changed some core components like replacing the grid for a simple table to tracking cube/cone scoring at the different levels for teleop, as the horizontal location of scoring in teleop isnā€™t super important for collecting data on a team for us.

We also removed the cycle time tracker, as we felt that it distracts scouters from tracking other, (what we felt were) more important things, like penalties, and general driver skill. None of the core logic of the app was changed, and there are screenshots below to show for comparison.

The backend for the app is entirely custom and mainly made with PHP and javascript. It runs on a laptop using XAMPP so as to not use wifi and interfere with robot communication on the field at competitions.

ScoutingPASS 2023

Bobcat Scout 2023

How it works

Once scouters are finished scouting, the frontend web page generates a QR code that is scannable by the backend. Once the QR code is scanned, it will be uploaded to a MariaDB database also running locally using XAMPP. This database will store all scouting data until it is ready to be exported as a csv file after which it can be pasted into Google Sheets for data processing.

Plans for Crescendo

This year, we plan on keeping the same core functionality of the app and changing the UI and input fields to correspond with the game. We arenā€™t done with it yet, but we will be posting more info on our 2024 Scouting App soon.

Watch our progress: Bobcat Scouting 2024 Crescendo

Student Author and primary App Developer: @Adithya_Anand

4 Likes