5987 Galaxia 2023 Build Thread

[AriMB]

Team 5987 Galaxia from Haifa, Israel welcomes you to our 2023 #openalliance build blog!

This will be our eighth year competing in FRC, and our second year as a part of the Open Alliance. We’re a team of about 30 students in 10th-12th grades from the Hebrew Reali School. Last year we had great success thanks in no small part to the Open Alliance, winning Israel District #2, finalists in Israel District #4, ranking 6th in the Israel District, and earning a trip to Houston. We’re hopeful to continue that success in 2023 at Israel District Events #2 and #3.

As a team, we’re looking forward to helping others by sharing our build process and learning from the discoveries of other teams. We’ll do our best to post updates as often as possible both in this thread and in the build blog on our website. Also check out our Youtube and Instagram for updates throughout the year. We won’t be posting live CAD updates since we’re using Solidworks, but we’ll do our best to share updates here with images and downloads. And our Java code is available on the team’s Github.

Links:
Team website
Youtube
Instagram
Github

[AriMB]

We’ll start with some updates of what we’ve been up to this offseason and how we’re preparing for the 2023 game. We asked team members to list what they’ve been working on, and as you can see we’ve been very busy!

New & Returning Member Training

We have 10 new members this year, who officially joined the team in July. All of the new members got a chance to see the various facets of the team, and went on to choose the subteam they wanted to join. Over the past few months they’ve gone through training to get up to speed on what they’ll need to know to be contributing members. Additionally, the returning members also got further training on more advanced team roles, like CAD, CNC, drive team, and other leadership roles. We pride ourselves on being a student-run team, so other than safety training which is carried out by mentors, all training was done peer-to-peer by the older students or returning alumni.

2022 Robot Improvements

As a part of everyone’s training, we decided to make major changes to our 2022 robot Stardust. These improvements were done with the Israeli off-season competition in mind, but more so to practice the entire modeling, manufacturing, assembly, programming, & testing procedure. Of the five mechanisms on the robot, we chose three to modify: the shooter, conveyor, and intake. For the shooter, we did a total rebuild, replacing our single flywheel binary hood position shooter with a dual-flywheel infinitely-adjustable hood shooter. The conveyor system was modified to be split into two independent zones to better control the ball positions inside the robot, And to remove the need of a mechanical stop before the entrance to the shooter. The intake was redone to use an older geometry that we were happy with but with different motors, gearing, and overall design. Although we had some technical problems at the offseason competition, we learned a lot through the process.

FRC 5987 2022 IOS Driver Practice 08/10

COTS Swerve Drive

Although we were very happy with our custom swerve drive in 2022, it took a decent amount of manufacturing after kickoff to produce. With the popularization of COTS swerve, we wanted to give ourselves the option to use a pre-built system and save the time and manpower during the season for other tasks. We ended up choosing the WCP flipped Swerve X because we felt it gave us the widest range of adaptability and customizability for the unknown game. We ordered the modules over the summer, assembled them, and built them into a simple chassis. It has proved an effective test bed for our swerve code, autonomous testing, and driver practice.

Prototyping Practice

One of the areas we chose to focus on for improvement this offseason was in our prototyping process. In the past our prototypes have been very hit-or-miss and we’ve often had to remanufacture or take steps backwards because of avoidable mistakes. This year we introduced some new prototyping resources for the team, including pre-made wooden build blocks (based on Ryan’s 3D printed clamping blocks), REV MAXPlanetary gearboxes, and the use of our school’s new low-power laser cutter. The combination of adjustability and rapid manufacturing allowed us to make effective prototypes for various intakes, grippers, and shooters. Some of these mechanisms we then went on to manufacture full versions to practice both manufacturing and our ability to recreate a final version with the same dimensions as our prototypes.

BOM and Stock List Improvements

One of the problems that have persisted through the years was our stock lists were never accurate. The lists were never updated, which led to them becoming inaccurate as components got used in a matter of weeks during the offseason, and in a matter of days during build season. To combat that, we transitioned to a more efficient BOM and stock list. As opposed to a big, static list of our stock that would need to be updated manually, we moved to a digital list that automatically updates itself with the number of every unused COTS item. This was done by connecting the stock list with the system BOMs, so that whenever some system BOM contained a certain number of a specific COTS component the list would subtract that number off of that component’s unused count. Because this system can only be used for COTS components and not for custom parts, we’ve created a separate BOM program for custom parts only.

Organization

We spent a number of meetings over the course of the offseason cleaning and organizing our shop. We believe in practicing the way we want to perform, and that includes keeping our space tidy so we can find the parts and tools we need. In conjunction with the improved stock list described above, we also took all of our gears, pulleys, sprockets, and belts out of big unorganized boxes and built organized displays for them, sorted by type and size. This gives us an easier, visual way to check that our stock list remains accurate, especially through the whirlwind of prototyping.

CADathons

As a part of the preparations for the upcoming season and the inevitable season CAD week, we’ve conducted multiple CADathons using slightly modified versions of F4 CADathons 5,8, and 12. All CADathons were 2.5 days long and were conducted over the weekend, in teams ranging between 3 to 5 people, depending on the game. Like the real season, our CADathons used coopertition in that each member was “graded” against the other CADers, but they had to work together to design a complete and integrated robot. Even though the bots didn’t come out perfect, it was a big learning experience for us.

We went on to use parts of the CAD from our CADathons for manufacturing practice during our 3-day intensive season prep over the Hanukkah break. During these work days, we manufactured and assembled some subsystems to give new students practice manufacturing under pressure. This was a good warm up for our engineering team in preparation for build season.

Kickoff is in 3 days! We can’t wait!

[AriMB]

Kickoff Strategy Plan

Over the offseason, we ran a few practice kickoffs to prepare the team for the real deal. From this experience, we made a few tweaks to our kickoff plan from previous years that we hope will result in better engagement and a more thorough game plan. Much of this plan is borrowed from ideas shown by other teams, which we’ve adapted to suit our circumstances. Being based in Israel, our kickoff happens Saturday evening and the school week starts on Sunday. So our schedule is a bit different than most US teams, but the process should still be applicable.

Saturday (7:30p - 11:00p):

1. Split into groups of 6-7 students and read the manual. Each group specializes in one area of the game: Field & Game Pieces, Scoring & Ranking, Robot Rules & Fouls, and Game Procedure.
2. Groups fill out guided reading handouts according to their topic to help focus on the important details.
3. The whole team meets at the end of the night and each group shares what they gathered from the rules. As a team we try to answer any questions individual members have about the rules, and we’ll make note of anything that isn’t clear from our reading.

Sunday (4:00p - 11:00p):

4. Check again with the team to see if any new questions have come up or if anyone is unclear about the game rules. Possibly have everyone take a game rules test.
5. Split again into smaller groups, and each group lists all of the possible tasks or qualities a robot might have in order to play the game. This includes things like scoring tasks, ability to score from a certain location or within a time limit, intake abilities, etc.
6. All of the individual groups’ lists are sent to the team leadership, who compile them into a master list for the whole team.
7. Each group gets the master list and comes up with a number of different robot archetypes for playing the game. For each archetype, they decide how that robot will spend the match time and list the important qualities the robot needs from the master list. The group then decides how effective they think the robot would be, where it excels, and where it falls behind.
8. The team gathers again and each group presents their archetype ideas. When multiple teams have similar archetypes, they get combined into one major archetype with notes of the different sub-archetypes.
9. A healthy debate ensues on the merits of each archetype. At the end, the team votes using ranked choice to pick the two most preferred options. These are subject to veto by the team leadership with advice from the head mentors in the rare case of preventing major mistakes.
10. As a team, we break down the archetypes we chose in relation to the list of possible robot qualities. Each quality on the master list is marked as need (imperative to fulfill our strategy successfully), want (will greatly contribute to our strategy), nice (not a requirement but helpful if it doesn’t hinder any other requirements), or skip (not attempting or hinders our strategy).

Monday (4:00p - 8:00p):

11. A group of the team leadership and experienced team members breaks down the robot’s qualities and requirements into 4-5 groups, each of which will become a mechanism. A mechanism lead and development team are assigned to each.
12. The entire team is asked to propose ideas for each mechanism. They list the solution’s pros and cons, requirements on the robot imposed by that design, and which requirements it satisfies and which it doesn’t.
13. The experienced members of the team debate the different ideas. They end up choosing one or two ideas for each mechanism team to prototype, ensuring all of the solutions chosen can work together in a single robot.

Rest of Week 1:

14. Each mechanism team builds basic prototypes of the mechanisms they chose to test the feasibility of the idea (as well as beginning to understand the mechanism geometry).
15. By the end of the week, the team decides on the general idea for each mechanism.
16. The team leadership and mechanism leads sits down together and CADs a “blockbot”, which defines the space requirements and inter-mechanism connections for each mechanism. This ensures there are no unintended interferences and everyone understands how the mechanisms connect together.

[AriMB]

Our strategy discussions took a while, but eventually we came to the decision that we want to focus on scoring both game pieces on the top row and climbing on the ramp both for auton and endgame. We eventually came up with the following lists of abilities we want the robot to have:

Need	Want	Nice to Have
Drive	Drive in any direction	Intake cubes from the human player
Positive control of both game pieces	Intake tipped cones from the ground (or straighten and intake)	Intake cones standing up
Intake cubes from the ground	Score both game pieces in the middle nodes	Score both game pieces in the low nodes
Intake cones from the human player	Engaged climb (individual)	Engaged climb (with alliance partners)
Score both game pieces in the high nodes	Autonomous leveling/tipping of the platform	Push dead robots onto the platform
Docking climb		Level the platform for other robots
Autonomous alignment with feeder

 

Based on these requirements, we broke the robot down into a few mechanisms, and a few options for each. We then discussed the positives and negatives of each, and chose some to prototype (!), and some to ignore (X):

• Drivetrain:
  • WCD
  • WCD with pneumatic wheels
  • COTS swerve (!)
  • Custom swerve with larger wheels
  • H drive (X)
  • Treaded tank (X)
• Cube Intake from the Ground:
  • Wheeled gripper (!)
  • Horizontal roller intake ala 2022 (!)
  • Pincher gripper with rotating fingers (!)
  • Vacuum (X)
  • Mecanum tower (X)
• Upright Cone Intake:
  • Expanding mechanism inside top hole (X)
  • Wheeled gripper (!)
  • Pincher gripper with rotating fingers (!)
  • Vacuum (X)
  • Mecanum tower (X)
  • Gripping from the base (X)
  • Lifting from underneath (X)
• Tipped Cone Intake:
  • Passive righting mechanism (!)
  • Dual wheel roller intake of some form - TBD (!)
• Raising Mechanism: Some combination of arms and elevators (2-3 DoF) to be determined based on the choice of other mechanisms

We’d like to use a COTS swerve (WCP SwerveX) for the drivetrain, as long as it is able to climb the ramp without issue. Since this game has relatively few different mechanisms, and due to the importance for this game of reliable intakes, we are giving each mechanism team a different intake design to test. Some of the mechanism options may work for both cubes and cones, but we’re starting by testing them separately. If we find designs that work for both and are close enough that they can be combined, that’s even better. At the end of our prototyping, the groups whose intake were not chosen will be in charge of the drivetrain, lifting mechanism(s), and any additional mechanisms on the robot.

We’ll have more updates on the progress we’re making on prototypes coming soon!

[Jancerem]

How does your team expect the Captain, First pick and Second pick have in their objectives, like what raw should score a captain or second pick, where should a captain or first pick, pick pieces in regionals/districts and champs?

[AriMB]

We didn’t do this exact calculation as a part of our strategizing.

Our goal for the season was to be an alliance captain or first pick at all of our district and DCMP events, and to make it to Champs. In general, we said we have to do the things in our need list to achieve that for districts, our want list for DCMP, and our nice to have list for Champs.

[AriMB]

After finishing our strategy discussions, we went right into prototyping concepts to see which were more viable than others. We’ve been focusing on four ideas for intakes/grippers across both game pieces.

Roller Claw

This design is based on roller claws used in 2018 and 2019, and designs from various Ri3D and OA teams. Our original design used only a single set of wheels, but this wasn’t very effective at holding the cube.

FRC 5987 Roller Claw Prototype 1 10/01

We then added a second set of wheels in the back. The idea being that the outer wheels grab onto the game piece and center it, and the inner wheels compress it so it doesn’t fall out. As you can see from our very scientific testing, this design worked pretty well.

FRC 5987 Roller Claw Prototype 2 11/01

FRC 5987 Roller Claw Prototype 2 Testing 11/01

In an attempt to improve further, we tried a number of different types of wheels. First we switched to solid treaded wheels, but this proved a bit too aggressive and not compliant enough. We then switched to the blue compliant wheels, which we think give a good middle ground in compliance and traction. We also found that the gripper is able to shoot the cube reasonably far without any modifications. Depending on how reliable it is, this is something we may consider incorporating into our match strategy.

FRC 5987 Roller Gripper Prototype 3 11/01

FRC 5987 Roller Claw Prototype 4 11/01

FRC 5987 Roller Claw Prototype 4 Shooting 11/01

We then moved on to a roller claw that can intake the cones when standing up. We kept the same blue compression wheels but changed the geometry.

FRC 5987 Roller Claw Prototype 5 12/01

FRC 5987 Roller Claw Prototype 5 Testing 12/01

Using the information we gathered from both types of prototypes, we made a new version that would hopefully work for both cubes and upright cones. We’re not finished yet, but we’re pretty happy with the progress.

FRC 5987 Roller Claw Prototype 6 12/01

Dual Rollers

This design was also inspired by Ri3D and other OA teams. The idea is to sandwich the game piece between two sets of rollers. The first prototype was designed for cones, and worked pretty well from the beginning. With a bit more experimenting, we got it to work with cubes as well.

FRC 5987 Dual Roller Prototype 1 Cones 10/01

FRC 5987 Dual Roller Prototype 1 Cubes 10/01

We’re continuing experimenting with this concept, including adding the ability to self-center the game piece and being able to pick up tipped cones.

FRC 5987 Dual Roller 1 Tipped Cones 11/01

FRC 5987 Dual Roller Prototype 1 Self-Centering 11/01

Horizontal Roller Intake

In case we find the need to intake separately from our placement mechanism, we’ve been prototyping a floor intake for cubes. This is based on a very common FRC intake style for balls, and we are treating the cube like a slightly pointy ball.

FRC 5987 Horizontal Roller Prototype 1 11/01

Rotating Gripper

Based on this design from Ri3D Redux, we prototyped something similar using various methods for actuating the jaws and different grip materials. We found that this design requires a bit more precision than the other wheeled methods and sometimes doesn’t get as strong of a hold on the game pieces, but does remove the possible need to orient the cone before scoring it on the node.

FRC 5987 Rotating Gripper Prototype 1 Cubes 10/01

FRC 5987 Rotating Gripper Prototype 1 Cones 10/01

The mechanical and programming teams will be meeting all together in the next day or two to decide which concepts to proceed with and which to eliminate.

[AriMB]

After the meeting on Saturday, we had plenty of ideas to make each system better, more reliable and try some new intake prototypes. Like we said in our week #1 recap, we decided on a robot design that includes an intake attached to the chassis, and a separate gripper attached to the lifting mechanism (TBD). We chose a Rotating Gripper, as it is one of the lighter options and automatically orients the cone downwards. For the intake, we want it to be able to pick up both cubes and cones from the ground, and orient them in a way that the gripper can grab them. We decided to test two systems: Over the Bumper and Through the Bumper. On Sunday when we started testing, we found out that the Through the Bumper Intake was not working for us. Due to this and a lack of manpower, we decided to stop working on this prototype. Unfortunately, we didn’t take any photos or videos of it to show you. For the past 2 days we have been testing the Over the Bumper Intake and improving our gripper.

Rotating Gripper

After analyzing the latest version of our gripper, we found a few problems. First, we needed to reinforce the main profile. It wasn’t strong or long enough for the pistons so we had to improvise their connecting ways. Another problem it caused was that the pistons were diagonal to the profile, which meant it needed to move in order to complete its whole movement capability.

Second, the linear motion of the gripper was unstable, the profile rocked side to side, and we effectively lost force from the pistons. Our original design used a slot along the length of the tube with bearing sandwiches (like a turret) to locate the moving profile. To improve this we put more sets of bearings on each side of the profile, with a second slot on the opposite profile wall for added support. Some testing with this configuration showed it was more stable but had more friction than we wanted, so its motion was rough and couldn’t be opened by hand.

After this, we decided to switch out the bearings for HDPE slider blocks. This solution worked very well. They reduced the friction significantly and held the profile more stable compared to the bearings. Using slider blocks instead of bearing sandwiches also made the system much easier to assemble. Its one flaw was that the motion was very dependent on the tolerances of the slot in the static tube, which started out not great and were liable to get worse over time.

FRC 5987 Gripper Prototype 2 Cube 15/01

FRC 5987 Gripper Prototype 2 Cone15/01

Once we were satisfied we had learned all we could from that prototype, we listed some improvements that can be made for the next version:

• Put the bearing on the outside of the profile (like a mini-elevator design) – this means we can make the main profile much smaller and lighter while not losing any stability or strength. This also reduces the manufacturing time because we don’t need to cut out a slot almost as long as the profile.
• As you can probably see from the videos above, we had a long rotating shaft at the tip of the vertical profile. This also causes difficulties with the stability of the profile and the compression on the game piece. We thought about moving the profile forward towards the other “hand” of the gripper without changing the piston length or stroke in order to maintain the easy collection of the game piece with this gripper.
• Our last idea is to shorten the length of the profile. This keeps all the positive elements of this system while making it lighter and smaller.

With these improvements in mind, the mechanism head CADed a new gripper prototype. If all goes to plan, this prototype will show the final geometry of the mechanism, so everything is ready for the real mechanism to be designed during our CAD week.

Look for more updates on this front coming soon.

Over the Bumper Intake

After the team meeting where we decided the robot’s overall design, we thought about how to improve our intake prototype. Our first prototype used two wooden plates cut on our router with vertical slots for the axles to be adjusted. We realized that these slots ended too high, meaning we couldn’t test with rollers as low as we wanted. So we re-modeled the plate and cut it again, this time with slots reaching almost to the floor. This new design allowed us to test the combination of rollers in more configurations, and lower the bottom roller to a spot we were happy with.

FRC 5987 Intake Prototype 2 Cones 15/01

FRC 5987 Intake Prototype 2 Cube 15/01

With further testing, we found that we would need to be able to change the horizontal position of the rollers as well. So we made a new prototype using the wooden clamping prototype blocks we designed over the offseason to connect profiles and rollers in adjustable locations. We also added funnel wheels to help center the cone and align it in a way that it can be grabbed by the gripper. The intake in this configuration was able to pick up cones tipped facing towards and away from it, but struggled with cones tipped sideways.

FRC 5987 Intake Prototype 3 18/01

Even more testing of the intake with many roller positions showed that we had a dead space in the intake which allowed the cone to get stuck inside. We tried adding a third roller to the intake, first passive then motorized, but it isn’t working as well as we hoped. We are still working on finding a solution to this problem.

FRC 5987 Intake Prototype 4 18/01

Field Element Construction

In parallel with our mechanism prototypes, we also have been building the field elements so we can test the robot and practice before competition. We finished building the Charging Station first, though it does have a problem that still needs to be fixed where it gets stuck sometimes when pushed all the way to one side. This allowed us to use our practice swerve chassis to check that the robot will be able to climb the ramp without special modifications. We’ve also been working on building the grid, which currently has the cube nodes and one set of cone nodes done.

FRC 5987 Swerve Climbing Ramp 18/01

[AriMB]

We’ve been continuing to work on our prototypes, as our deadline to have everything finalized draws closer. Based on the results of our prototyping, we’ve decided on the general form of the robot. The chassis will be a swerve drive, with a ground intake that hands off to a pneumatic gripper, which is moved by a two-joint arm. Once the final prototypes are completed today, we’ll sketch out a “blockbot” which defines the space requirements and connections for each mechanism.

Ground Intake: Cones and Cubes

We’ve continued trying to improve our ground intake to be able to intake both cones and cubes from any orientation, and align them consistently within the robot. We were able to solve our problem with cones getting stuck while intaking by replacing the bumper and frame profile with a roller. This means the intake will have to be skinnier (to allow for 6” of bumper on each side) but it makes the system much more consistent.

Our biggest problem now is with the alignment of the cones. They enter the robot in a wide range of locations and orientations, which our gripper will not be able to manage. We tried adding a funnel with static walls and/or powered wheels, but it was not able to grab the cone consistently. Our current idea is based heavily on 4481’s spindexer prototype, which uses a rotating disk to align the cone.

FRC 5987 Intake Prototype 5 20/01

Ground Intake: Cubes Only

With our deadline approaching and the cone intake not yet at a place we’re satisfied with, we decided to have a separate group work on a prototype for a cube-only intake. According to our priority list set in the beginning of the season, intaking cubes from the ground is a must-do item, while intaking cones from the ground is only a want-to-do item, so it is important that we have a backup plan.

This prototyping group found that intaking the cubes off of the ground is extremely tolerant of varying geometries. Centering the cubes from a wide intake into a single position for the gripper, however, is nowhere near as easy. When under pressure, the cubes have a surprisingly high coefficient of friction and can squeeze into very small spaces, making them similar to the 2020 power cells.

Our current idea is a single over-the-bumper roller to intake the cubes, then a mecanum roller with walls inside the robot to center it. If this doesn’t work out, we will try a wheeled funnel, similar to what we used in 2020.

FRC 5987 Cube Intake Prototype 1 20/01

Pneumatic Gripper

Based on what we learned from our initial prototype, we made a new version that’s sturdier and more closely resembles what the mechanism on the robot will look like. Testing of this was a big success, and we are happy moving forward with the idea. The next steps will be to make the design smaller and lighter so that it can be attached to the end of our arm.

FRC 5987 Gripper Prototype 3 Cone 19/01

FRC 5987 Gripper Prototype 3 Cube 19/01

Double Arm

After some discussion within the team, we decided to use a double-jointed arm to raise and extend the gripper. This has the advantages of being lighter and simpler than most of the other options that were proposed, though it will be more difficult controls-wise for the programming team. We’re still working on the final geometry, but it looks like with both arms about a meter long we’ll be able to reach all of the scoring locations as well as inside the robot to take the hand-off from our intake.

To help the programming team get a head start on the arm’s control scheme, we built a medium-scale model for them to test code on. Here you can see it moving in open-loop, and they are working now on adding closed-loop control. Since this video was taken, we added more load at the end of the arm in the form of an old CIM motor to better stress the control algorithms.

FRC 5987 Double Arm Prototype Open Loop 20/01

[AriMB]

This week has been CAD week for us, taking all of the information we learned from the prototyping stage and turning it into a more finalized robot design. Once the blockbot is set, each mechanism lead models their mechanism individually according to the space restraints given, and then all of the mechanisms are integrated together.

At this point the CAD is half finished and will likely change more in the following days. We’re providing the CAD in its current form in any case to show our current progress.

Intake

Unfortunately, we weren’t able to get a tipped cone intake working to our satisfaction by the end of the prototyping period. We’re leaving room to add one later in the season, but for now we’re moving forward with a cube-only intake and we’ll pick up cones from the double substation.

In order to center the cubes for the handoff, we are using a mecanum roller internal to the robot that slides the cubes towards the center. We found from prototyping that the cubes have a high CoF when compressed, so any surfaces they touch need to be made of a slippery plastic. In order to bring the cubes into the robot, we have two rollers that deploy outside of the robot.

FRC 5987 Cube Intake Prototype 2 27/01

Our original intake design was a pneumatically-actuated four-bar mechanism that moved both the regular forward roller and the internal mecanum roller. This worked well until we went to integrate it into the rest of the robot and found that the intake would block the gripper’s access to the cube during the handoff.

Instead, we are using a small motor-driven arm to deploy the front two rollers, with the mecanum roller fixed inside the robot. This will add a bit of complexity as the system now needs position control on this axis, but it’s the only solution we found that doesn’t cause integration problems with the arm and gripper.

Arm

Originally, our goal was to make the arm as short as possible, which meant mounting its axis of rotation high on the robot. This made both arms about 5ft long in total. This idea was presented at our first of two design reviews during the CAD week, and many of the mentors and alumni participating suggested lengthening the arm in order to lower its mounting point and therefore lower the robot’s center of mass. After consideration, we decided to take that advice and change the robot’s design accordingly.

The arm is now around 6.5ft long in total, with a mounting point only a few inches above the bellypan. The first arm is constructed from two 20x40mm tubes, and the second arm is a single 40x40mm tube. Because the arm reaches outside of the robot and interacts with the field elements, we want the mountings for both to be very strong. The “shoulder” pivot point is a 25mm (~1”) diameter aluminum tube, and the “elbow”pivot point is a 17mm (~0.67”) diameter solid aluminum axle. This is significantly heavier than the standard ½” hex shaft, but should prove much more stable and resistant to bending.

The gearboxes for both arms are mounted on the robot’s base. The “shoulder” joint has a ratio of ~60:1, and the “elbow” joint ~30:1. The torque for the elbow gearbox is transferred through a cluster sprocket on the shoulder axle, making it effectively a virtual four-bar whose base can be rotated. Both arms are connected to their gearboxes by two runs of #35 chain, both for extra strength and to make sure uneven chain tension doesn’t bend the arm sideways. This design allows us to keep a majority of the weight low on the robot and keeps down the weight of the arm.

Pneumatic Gripper

We were happy with the results of the pneumatic gripper from our prototyping, but it had one major problem. With one side fixed and one side sliding, the center of the gripper changed depending on how far open it was. To remedy this, we split the piston into two smaller pistons, and made each side move. This way the item being held is always lined up with the center of the gripper and the center of the robot, removing a variable we would otherwise have to account for in our ultimate goal of an autonomous placement routine.

[jonathano]

Why use two different pistons instead of one double acting cylinder?

[AriMB]

Originally that was the plan. But we wanted the two sides of the gripper to open symmetric to its center instead of one side moving and one fixed. To keep that constraint with a single piston we would need some complicated linkages. Easier to use two pistons, each with half the stroke.

[Zook]

I’m envisioning two racks on one pinion. And the cylinder pushing/pulling on a single rack. But that’s more custom parts and possible alignment issues.

[Aplbz]

Any chance you could publish the CAD for the gripper?

[avaricion]

Do you have any videos of the gripper working?

[AriMB]

We’ve posted some videos of the gripper prototype working. The real thing is still being assembled so we don’t have any videos of it yet (but we’ll be sure to post them when they’re ready)

FRC 5987 Gripper Prototype 3 Cone 19/01 - YouTube
FRC 5987 Gripper Prototype 3 Cube 19/01 - YouTube
FRC 5987 Gripper Prototype 2 Cone15/01 - YouTube
FRC 5987 Gripper Prototype 2 Cube 15/01 - YouTube
FRC 5987 Rotating Gripper Prototype 2 13/01 - YouTube

[AriMB]

We’ll have the full robot CAD published soon once it’s 100% finalized and a bit cleaned up. Meanwhile I sent you a PM with the CAD for the gripper as it stands now.

[AriMB]

CAD

It took a bit longer than we’d hoped, but we finally finished the CAD of our robot. The delay has pushed our build schedule back a bit, but we think it’s important to have the robot designed properly to save ourselves time fixing problems later on.

The robot has dimensions of 26.75 x 32.75 inches, and weighs in CAD around 100 lbs. We were hoping to have a smaller and lighter robot this year, but with all of the other requirements we put higher on the list, that wasn’t really possible.

If you’re interested, you can download the robot CAD as a STEP file here (90.2 MB).

Intake

The intake consists of three rollers, one with compliant wheels, one polycarbonate tube, and one with mecanum wheels. The first two rollers grab cubes from outside the robot and pull them over the bumper. The third mecanum roller then compresses the cube against HDPE walls to center it inside the robot. All three rollers are powered by a single NEO motor, with a 3.33:1 reduction for the first two rollers and a 10:1 reduction on the mecanum roller. Since the intake has to rotate above vertical when stowed, its rotation is also powered by a NEO with a 32:1 reduction.

Arm

The arm has been by far the hardest part of the robot to design. Having to fit it into the tight space constraints we set made for a very difficult packaging job, and being as long as it is means it has to be built stronger than the rotating mechanisms we’re used to. In the end the CAD is done and manufacturing for it has started, but the delay cuts into our buffer time that we set aside before our first competition.

Gripper

The gripper is based heavily on the prototype gripper we made, the main difference being the pneumatic cylinder split in two. I talked some about why we chose to do this in a previous post.

Part Tracking

Every year, we struggle with keeping track of parts: what’s been designed, what’s waiting to be manufactured, what revision of each part needs to be made, where do the finished parts get kept, etc. Over the years we’ve been steadily working to improve how we approach this problem; we started using a standard part numbering system, added revision numbers, and kept boxes for each subsystem’s parts.

This year we made two more big improvements. After being manufactured and checked by our head of QC, parts get marked with their P/N and put away for safekeeping. Large parts get their P/N written on them directly with permanent marker; small parts get put in a ziplock bag with their number written on the bag. This has helped us keep track of the finished parts and minimized people asking “where’s that part”.

The other improvement we made is a shared BOM table. This was done in the form of a Google Sheet shared with everyone on the team. When the CAD is finalized, all of the custom parts get added into the BOM with their quantity, material, and necessary processes. A bit of fancy filtering and conditional formatting allows everyone on the team to see the status of every part and update it as things get made. You can see a copy of our BOM from mid-build here.

Manufacturing

Even though parts of the CAD weren’t finalized until recently, we’ve been working on manufacturing the parts of the robot that were finalized. Of our non-COTS parts this year, about 95% of them are made in house, with about 25% each made on the CNC router and 3D printers and 33% made on the lathe.

There are lots of cool parts to share, here are some of my favorite so far:

[shewejff]

Thanks for sharing your design and build process. There are a couple things you may want to consider with the gripper change.

First, if you are using the same diameter pistons between your prototype and redesign, your new gripper will squeeze with half the force of your prototype. In the prototype, the squeezing force on the cone/cube of the moving side was both pistons combined, and the static side was reacting back with that same force. In the redesign, the force on each side of the cone/cube will be only one piston, not two. Try doing free body diagrams of each component. If you like the force of the prototype, you may want to consider upping the piston diameter of the final gripper to get the same force.

Secondly, the final design may not end up being as centered as you think. The cone/cube is in an unstable middle position between two “equal” forces. The two pistons won’t have the exact same force or activation speed, so the cone/cube could drift to one side or the other while driving.

[AriMB]

Thanks for the note. We actually were planning on switching to one piston so it’s okay. We were originally using two for the prototype because the linear slider mechanism wasn’t sturdy enough to handle the uneven loading. Once we built a better prototype, we found that one piston gives enough force. We then split it back into two with each being half the stroke in order to get it to close in the center.

You’re right that this method doesn’t specifically constrain it to the center and might allow it to move side-to-side a bit. But it’s certainly a lot better than having only one side move and the other static. And we think it will be good enough this way instead of adding some heavy linkage to ensure it stays dead center.