Welcome to the FRC 1884 Griffins 2023 Build Thread, presented by openalliance!
1884 is the oldest active team in Europe, based in London, England, United Kingdom. We’ve been active since 2006 providing a real-world collaborative engineering experience to students at our school. We’ve competed across the world from China to the United States. Students at our school enter FRC having gone through the pipeline of FLL to FTC honing their design, engineering, and programming skills to create better systems. We have students developing skills in CAD, Fabrication/Design, electronics, and programming to ensure the robot we send to competition is the best it can be while instilling real-world skills in our team members. We’ve greatly expanded our community outreach program over the past few years starting FLL and FTC programs at other schools and encouraging students to pursue STEM. We have also hosted an FLL regional for over a decade and are in the process of holding an FTC regional for the second time this year. Additionally, we are trying to raise a large amount of money this year to upgrade most of the machinery we have in our workspace and potentially acquire new equipment like a CNC Router.
Our team members have a variety of goals that we hope to support them all in achieving. Some are very competitive and hope to win regionals and advance to worlds, others want to develop their STEM skills to a more sophisticated level, and others value the collaboration and community we have in our FRC Program. Our program aims to support all of those endeavours.
In regards to OA, we’ve not posted across the first couple of weeks, but we hope to make our posting more regular for the rest of the build season.
We look forward to seeing everyone’s work over the upcoming season!
In order to be successful, we believe it is critical to have a comprehensive data-driven strategy that guides our design process over build season.
Following kickoff, we listed the different “robot skills” that are needed for different to be competitive in different aspects of the game. Skills can be defined as a specific action the robot or a part of it can complete i.e drive at 10 ft/sec. These skills include: general gameplay, alignment, and skills related to the charging station, defence, collecting game objects, manipulating the game objects, and delivering the game objects.
Here is a sheet with our final skill list: Link
We then went over the scoring guidelines for the game and linked the required as well as beneficial skills for each task that needs to be completed. The required skills are the ones that we cannot complete the task without. Skills like being able to drive are omitted from the required skills because we would not be able to compete without a drivetrain. The beneficial skills are skills that would make our lives easier if we had them. Skills such as alignment with different aspects of the field automatically would reduce the error rate of our drivers, as they could drive up to the game object and then let the program run.
Here is a link comparing skills to scoring objectives: link
We then compare our skills list to the list of scoring methods in the game to then work out what skills to prioritize. Tasks that give a lot of points and have a lower amount of skills required will be a higher priority compared to tasks that give a lower amount of points and have more skills required to complete them. Being docked and engaged during endgame only has 8 skills required and it gives 10 points while scoring in the middle row during Teleop gives 3 points and needs 19 skills. Not all skills are equal in difficulty and we take that into consideration in our discussions.
This gave us a sense of what would be required to complete every task as well as an initial idea of the complexity of the robot based on the skills that are required for each task.
On Sunday, we came together to talk about different strategies that we can employ during the three stages of the game: Autonomous, teleOp, and endgame.
First, we split ourselves into 12 different teams of 3 people to play a mock version of the Charged Up game. Replacing the robots with humans (Stubots), we played 1-minute games where we simulated what a game would go like. Teams were encouraged to bring a unique strategy to their match for others to see. During the matches, we had ideas such as ferry bots and defence specialists come up, but due to our setup, the most efficient gameplay was for every member of the alliance to work individually.
It’s important to keep in mind that we can walk and manoeuvre faster than actual robots. We noticed that the neutral zone between the loading zones of both alliances is incredibly crowded even with humans. Also, the fact that the loading zones most likely will not fit two robots side by side will also increase congestion.
We split ourselves into 6 different groups and each came up with different autonomous programs. We designed these programs to be “if we could only design one autonomous program, what would we do”.
We listed out the tasks and order that we sought to complete during the autonomous period as well as the points that we would get. This year the autonomous is only 15 seconds, which makes timing very important, and because you want autonomous to be precise, you often sacrifice speed for precision. With that in mind, we came up with how long each action would take on a high end.
These estimations are based on our data from previous years and understanding of expected drivetrain speeds and previous acquisition times. We were very conservative with our time estimates which means our strategies may end up taking less than the expected time, but we thought that was the best decision to ensure they were viable. Now having the time it takes for each action, we calculated how long it would take for each autonomous program.
The programs that leave the community and grab an extra cube would take too long, so our ideal autonomous program would be
- Deposit in top
- Leave Community
- Dock and Engage
Based on our estimated task times, we have just enough time (remember we were conservative with our task time estimates) to complete everything and score 21 points for our alliance.
For teleOp, each of the six groups calculated their own cycle time as well as game plan for the duration of teleOp. We factored in things such as ideal cycle time and realistic cycle time based on the traffic/defense we expect to face. Since a pin can last up to 5 seconds, and the time that we will be pinned would be shorter than that because the robot pinning must back away from us as well, we added an additional 5 seconds to our cycle times to factor in defense.
It’s important to note that some of these strategies carry through to the endgame while others stop at the beginning of the endgame. Because cycle times are 20+ seconds for most of these strategies, completing another cycle and then balancing on the charging station with 1 or 2 other alliance members may prove difficult. So then what is the solution?
Since driving up the charging station requires a lot less complexity than manipulating a game object, if we determined that both our alliance partners feel comfortable balancing and docking on the charge station within the endgame, then we would continue doing cycles.
An interesting strategy that we came up with was plowing the game objects to the edge of the loading zone for our alliance partners. To briefly some it up, we would take multiple game objects (cones and/or cubes) to the edge of the loading zone and leave it there for us and our alliance. The opposing alliance will have difficulty taking advantage of the game pieces we “plowed” due to the risk of a violation. Additionally, we calculated that for us it would increase the number of cycles we do in a given match by 2-3 based on how many game objects we play at once.
If you want a more in-depth explanation of the strategy, please checkout this chief delphi post where there is a more extensive explanation and discussion of the strategy.
As with other years, our team made a priority list to document the objectives we must complete and the priority of them to be successful in competition.
Link to our priority list: https://docs.google.com/spreadsheets/d/1IdM4k5ZIO25Y26bTqv_YVUImcw_YEJlgYLaPpM8Pkds/edit#gid=0
To explain our choices, we put drive as our first priority as without a working drivetrain, we could not do anything else. The charging station is our second priority because of its simplicity to earn points and ranking points.
The ranking point for the charging station requires 26 points earned through the charging station. Ideally, a robot charged and docked during auto gives 12pts and during Tele-Op give 10pts. So we need a robot charged + docked during auto and 2 robots charged and docked during endgame. This is much more achievable than having 15 game objects (12 if both teams go for the coopertition bonus) required for the necessary links to earn the ranking point.
This year, in addition to the priority list we also have a new idea called the Minimum Competitive Concept (MCC). The MCC is the baseline of what we need to do over the next few weeks, and we designed it to be catered to our skills. We aim to hit the MCC prior to the end of week 4 and then attempt to reach some of our extending priorities by ship date.
- After kickoff, we made a list of all of the “robot skills” that we might need during the season
- Using the skills that we listed, we discussed all of the skills that are needed to complete each scoring task within the game
- We then worked out what skills would result in the most points
- We created a priority list during the season of what needs to be done as well as the requirements that deem it as finished
- We will revisit our priorities at the end of week 4 to target the extending priorities
We began by researching designs from previous seasons such as the 2011 Logomotion and 2018 Powerup games.
After holding a team meeting we decided on 4 different mechanisms to design.
Clamp Design Group:
Our clamp design group began with a sketch of our base mechanism, with an indication of possible measurements and degrees of movement. This allowed us to then take our design and build an FTC scale model as a proof of concept which can be seen working in the following videos:
After proving our concept we began to work on an FRC scale model with a pneumatic piston for actuation. We built this prototype using extrusion connected to a linear slide for movement. We hooked a pneumatic piston to both sides of the mechanism and secured one of the ends in place using a bolt. The first element of this design is based on the idea that the piston will only actuate as far as the game piece allows it. Once the piston faces enough resistance (once it squeezes the game piece enough) it will stop moving, but still clamp with enough force to hold the game piece in place. The second core feature of the design is passive game piece alignment. Using 2 wheels secured on a set of free bearings, we connected our gripping pads to the end of the extrusion on each side of the clamp. We added a high-friction tape to the surface of the wheels to give the wheels more friction with the game pieces giving them better-clamping force. The bearings allow the wheels to move and rotate freely, meaning the game pieces will automatically orient themselves with gravity. This is particularly important because of the cone piece. The cone must be deposited in an upright position. This means that we have to create a mechanism to orient the cone after picking it up in the case that the cone is taken in after it is possibly knocked down. The wheel will use the cone’s center of gravity to pull the heavier bottom side of the cone downwards, orienting the cone in the correct direction for depositing.
Videos of the mechanism as well as photographs can be found here: https://drive.google.com/file/d/1sOgcokNEyHHF8PdZSfC9VtVF89TPrmTX/view?usp=sharing:
Passive Intake Group i.e Slap-Slap
Our mechanism reorients the game pieces into a position optimal for another intake to pick it up and transfer it with an arm. This design required a C-shaped cut-out from the robot but could be used while driving around the field. First, while driving, a metal bar slaps down the cones onto their side. This standardized the position of every cone being driven into the robot. Next, two extrusions at different heights rotate and push the game pieces upwards onto the belly pan of the robot. The extrusions can move 360 degrees on an axle connected by chain and gears to the core hex motor.
Challenges and Solutions
While prototyping the slap-slap mechanism, we encountered a few notable challenges in our design process. First, because of the configuration of the robot including the positioning of mechanisms such as arms, the belly pan, and swerve motors, it was necessary to fix the neo motor (27:1) at a distance farther from our intake. To work through this, we redesigned our intake to be completely functional with only one side. Even though this seemed like a setback, when testing the one-sided intake, it was sufficient to lift the cone and cube.
Another setback was when we lifted the cone, the underside ridges got stuck on the edge of the ramp and belly pan. To fix this, the best solution was to increase the power, and inherently force it on with speed. We did recognize the restriction against damaging game pieces, however, this was clearly not an issue as both the cube and cone were both intact and functional.
Furthermore, we experienced multiple challenges with our two sets of chains. First, they needed to rotate at an identical height from the motor through all of the gears. To work through this, we moved the motor gear down the axle to match the heights of the other chain. In addition, after the chains were fully in place, they were slightly loose and hit the edge of the belly pan while rotating. As a solution, we used a sprocket which allowed for higher levels of tension on the chain.
Mounting the motors onto the prototyped robot was more difficult than expected. Due to the size of the neo motor, and the fact that it could only be used with a 3:1, 3:1, 3:1 gear ratio (27:1), it was taller and did not fit the brackets. The motor was constantly shifting, even with shaft collars, bolts and nuts in place, as the motor did not fully fit into the designated bracket space. After changing the location and cutting down the bracket, the motor was finally secure as well as effectively powering the slap slap intake.
The main problem that we encountered was getting the cone into the same orientation each time we attempted to intake. There were a number of possibilities that would provide a result that wouldn’t allow us to have any control over intaking the cone. We originally attempted to place a piece of wood that would serve as a funnel; however, we quickly realized this was not a sufficient solution. We planned on utilizing wheels that would attach to a neo motor which would always funnel the cone into a static position.
Horizontal Clamp Intake:
We came up with this idea to be able to bring the cone/cube into the robot and be able to orient while driving to optimize our efficiency and score more points. The idea was to clamp onto an item very fast and flip it straight into a compartment in the robot where it would orientate and feed it to the arm. After discussing with the team we decided to change this idea and have the arm not flip and stay straight, mounted directly onto the arm instead of the robot frame.
The mechanism has 2 gears that rotate the two sides of the claw, it also has a grippy free-spinning wheel that will automatically orient a cone when it’s picked up while maintaining a good grip on the object. The intake is mounted onto the elevator and can open and close allowing it to pick up & release items.
There are many pros starting off with its versatility, it has the ability to grab cones from the floor and grab cones from the substation while also being able to release cones and cubes anywhere on the field. It is also very quick to grab, able to orient without external mechanisms, and is a very simple mechanism technically needing only 1 motor. Finally, the intake doesn’t take too much space and is generally pretty easy to mount;
Video of the working prototype (Cone):
Video of the working prototype (Cube):
Grapple Design Group:
This was our initial idea of the grapple method. The bar is attached to the center rod and moves within a 180-degree radius to align itself with the base of the cone. This was achieved using two strings attached to either end and those strings attached to a spring that sets it back into an equilibrium position before and after grappling the cone. The two claws mounted on the bar were powered by a piston and placed around a joint. This allows it to quickly extend and hold onto the cone due to the quick explosive power of the piston.
Below is the working video of our prototype.
Below is the video of the spring realignment system working.
Below is the video of the strength test of the piston.
After prototyping several different designs we held a team meeting where we discussed the different mechanisms and analyzed their success and compatibility with our game strategy.
A link to our analysis can be found here: https://docs.google.com/spreadsheets/d/1GYxFQ5155hmKMzYxu__6ZKBiE604PUXUv0hebZYSAog/edit?usp=sharing
We decided on combining the best parts of each design to become our final product. We then split off into two different groups and began prototyping our designs in CAD and have now begun assembling working models (still in progress). One of our main criteria for a design was weight distribution. Most of the designs proposed ended up using pneumatics which can become very heavy on the robot. We wanted to shift to a motor-based design that would save weight but not lose too much power. We ended up combining the two different clamp mechanisms and coming up with the following model:
As of today (January 23rd, 2023), we have split our group into 3 parts, 1 for each element of the mechanism (grip, movement, gear structure), and began assembling basic prototypes to test intake strength, clamping versatility, and movement stability.
Last season we dedicated a large amount of time to developing our swerve. After comparing designs, we concluded that swerve would be the best choice for this game. The high speed and omni-directional movement aligns well with our requirements. The size of our drivetrain changed dramatically over the course of the first two weeks of the season as we considered multiple parameters including fitting on the charging station, being good on defence, and fitting our other mechanisms. We concluded that it was best to go with a 28x28” drivetrain. This accommodates our charging station friction plate mechanism and manipulation/acquisition device. Furthermore, we went for a square frame because that makes the programming aspect of getting the drivetrain running much simpler.
Below is a drivetrain we built in pre-season. We put this together in less than 5 hours which was a huge accomplishment when compared to other builds.
This frame is 24x24”. When evaluating our other mechanisms we concluded that this frame was too small to be viable. However, the final structure will look very similar. A lot of time has been allocated to the dimensions of a super structure to mount mechanisms to.
The manipulator group is concerned with moving the cone/cube within the robot and scoring it.
The first part of our design process was to research previous games. Some of the key previous games we researched were Logomotion from 2011, Powerup from 2018, and Deep Space from 2019. At first, we had a brainstorming session which we narrowed down to 3 main ideas: 2 pivot arms (FRC team 971 Powerup), the pink arm (team 233 Logomotion).
We decided to rapidly prototype our designs from existing mechanisms we had on hand. We repurposed our climber from last year into a telescoping pink arm by mounting it on a pivot and replacing its gearbox. We also took our preseason four bar and redesigned it into a 2 pivot arm. After motorized testing of both designs, we noticed that the pink arm was most feasible, while the 2 pivot arm had too much complexity to control effectively.
Image of Pink Arm CAD
While we were testing our initial prototypes, we CADed the pink arm to start fabrication for a more finalized prototype. After prototyping, we realized we needed a backup design, so we took inspiration from the team Spectrum OA post to design a backup angled elevator. We calculated the geometry in fusion360 and decided to go with a 45 degree angle as opposed to Spectrum’s 60 degree because we wanted to have a lower center of gravity and shorter arm.
Last Friday, we started fabricating our MCC angled elevator and our pink arm. We are using ThriftyBot’s elevator and telescoping arm kits. We changed the designs slightly based on the geometry we calculated. Our angled elevator uses 35” extrusions instead of the default 47”.
Because our arm is a climber designed for vertical motion, we have had issues with it bending slightly when it is horizontal. This causes the arm to stick and move at a slower rate. We are researching possible solutions. One of our main ideas is to add bearing blocks to the inner arm extrusions. We will post CAD files when we have a finalized solution.
We decided to challenge ourselves with this mechanism. The WCP robot reveal video confirms that it is possible to stabilize and drive off the side and balance on the side of the charging station. However, we wanted to minimize the area we took up on the charging station to maximize our chances of fitting three robots on it at the end of the match. We considered numerous ideas but eventually decided upon using a friction plate. The friction plate would be a flat surface stored underneath the belly pan which would be actuated downwards towards the charging station by a piston system. Spatially, fitting everything below the belly pan was challenging so we continued to modify designs to accommodate for this lack of space. However, in our final design we decided to cut large areas in our belly pan to maximize vertical space. Our initial design went from a piston simply pushing down straight on the friction plate to considering varying the angle of the piston to modeling it of a braking system from a team participating in the boring competition. To support the weight of the robot we have turned to parts supplied by igus which should not break while undergoing the force of the robot. Another challenge we faced was piston selection. We wanted to maximize the normal force that the piston creates to maximize static friction to hold the robot in place. We did our calculations using this physics calculator: Toggle Joint and this piston force calculator: Piston Force Calculator
This is the linkage we are currently working with. When the piston extends it pushes out two carts that slide on the rail which expand the crossed beams downard to lower the pad. Being on a sliding rail this allows the angle of the pad to adjust by the extension of those beams. This should allow us to hang around 50% of our drivetrain off the charging station while maintaining balance. Again, this mechanism may seem unnecessary, but we wanted to challenge ourselves technically with a more rigorous design.
This year’s game has brought many changes to the approach we need to take as a team. Amongst those changes comes the AprilTag changes with which we have been hard at work testing. We concluded that the swerve odometry would be slightly offset by going up the charging station ramp and with error accumulating over time. Thus, we are working hard to use the AprilTag pose estimation to find out where we are to calibrate the odometry. We have also worked on using tools such as FRC path planner to maximize the number of auto programs we can make. To improve reliability with pose estimation (i.e. reduce ambiguity), we are testing two cameras on the robot. We’ve been exploring different methods to reduce ambiguity (such as choosing a camera with the least ambiguity, averaging the results, and more). We will post updates later in the season, see our github.
We also have worked on getting game piece detection with pixy cam to detect and pick up loose game pieces on the field. All the computer vision would also help during TeleOp as it is hard for the driver to see the game pieces at the single and double substations from the driver station.
We have had a lot of success growing our community outreach program over the past few years. If your team wants to start engaging in outreach, it is always beneficial to start small and local by perhaps running an after school program to introduce elementary students to robotics (Think First Lego League or similar). I have found that once your team is involved with outreach/community-service at your school, you can use your school’s connections to help create new opportunities outside of your community. For example, if one branch of your school participates in an FTC or FLL competition, come with them and figure out if there are any rookie and new teams there and offer to mentor them if they need help. In addition, we have found that if you want to send emails to jumpstart outreach, it is a good idea to have them go through the school so your team has more legitimacy. Opportunities come with time, so don’t try and rush into something that your team isn’t prepared to handle. In addition, hosting a small event at an assembly at your school is also a good way to reach your community with relatively little setup required.
This post is a very comprehensive summary of Team 1884’s work and learnings over the first two weeks of the build season. We hope to have most of the mechanisms manufactured and assembled for testing by early next week so that we achieve the MCC concept we discussed in our strategy section by the end of Week 4. If you have any questions about our designs/design process, strategy, and outreach work please let us know. Wishing everyone the best of luck for the rest of build season.
Team 1884 Griffins