FRC 5987 Open Alliance Build Thread

Welcome to team Galaxia 5987’s #openalliance build thread!

Our team is from Haifa, Israel, consisting of 32 team members.

Team Structure
We have two captains, one for the technical side and the other for outreach, and a lead for each of the sub-teams. The technical side is divided to two sub-teams: Mechanical (Doing Both CAD and building) and programing, while the outreach side does both media and outreach.

Our Schedule For The Season
We have a team meeting every day of the week, 16:00-23:00 on weekday and 10:00-18:00 on Friday and 16:00-21:00 On Saturday.
We divide our season to the following structure:
Prototyping: Weeks 1-2
CAD: Week 3
Building, Testing And Adjusting The Robot: Weeks 4-6
Testing Programing: Weeks 7-8

We will be competing in ISR2 & ISR 4

This year we have decided to join the open alliance project in order to force ourselves to lookback on our progress and because of our belief in sharing a way of growing. This thread will be updated 1-3 times a week depending on both our progress and workload each week.


Its time for the first update! We’re a bit behind on posting updates here, so we’ll start with our game analysis and decisions on priorities.

Kickoff Analysis

After a base analysis of the game, we arrived at a list of requirements for the robot which our prototyping process is built upon (sorted into groups, not ordered):

Required to successfully play the game:

  • shooting cargo from at least one location
  • intaking cargo from the floor (touch-it-own-it)
  • storing cargo (two)
  • climbing to the 2nd rung, and either the 1st or 3rd rung (to allow for flexibility in games)

Important for our strategy:

  • scoring from multiple locations
  • intaking cargo from the terminal
  • scoring in the hub regardless of the robot’s orientation
  • ejection of unwanted cargo
  • automatically counting number of cargo held, and distinguishing between colors
  • climbing to the 3rd rung

Nice to have but not required:

  • scoring from every position on the field
  • rapid shooting (back-to-back shots)
  • delivering cargos to the terminal
  • climbing to the 4th rung
  • intaking cargo while bouncing
  • scoring in both goals

We decided to postpone the decision on drivetrain type (WCD vs swerve) and which goal to focus on until we get the results of the prototypes by beginning of next week.

For climbing, our analysis of the game showed four “minimum” combinations of climbs in able to get the RP: 2&3, 4&1, 2&2&1, 3&1&1. Meaning that in order to consistently get the RP you need to at least climb the 2nd rung with 3rd rung almost guaranteeing the RP. For further reading on our analysis, @benjierex 's post is a good start. To achieve this, we ideally want a climber capable of climbing the 2nd and 3rd rung with an option to extend it’s capability to 4th rung if we have the time. If we cannot get to the 3rd rung, we need to add rung 1 functionality in case our partners can only climb to rung 2 to allow for the 2&2&1 option.

In order to test various ideas for the robot, we split the team into five prototyping groups:

  1. High goal shooter
  2. Over-the-bumper intake (horizontal rollers)
  3. Through-the-bumper intake (parallel wheels)
  4. Cargo conveyor
  5. Climber

We’ll have updates on the progress those prototyping groups have made soon!


We have been hard at work the past few days prototyping mechanisms, mocking up field components, and beginning coding!

Simulating Shooting Angles

For simplicity’s sake, we want to avoid an adjustable hood shooter if possible. In the programming subteam, we started tackling the shooter options in order to be able to shoot into the upper hub by changing the velocity without changing the angle of the shooter. We used MATLAB in order to check the trajectory of the cargo from different key positions in the field. We found that for shooting from all distances up until the launchpad 2 shooter angle positions are optimal. Further explanation can be found at @adamv 's post.


We have two main concepts for climbers:

  1. Stick on a wrist: A long pole with hook on both sides swinging the robot pole to pole, much like in SnowProblem’s RI3D build. We just finished our first medium-scale prototype of this climber, and are starting to test its viability. More to come on this front soon.
    Stage 1 Stage 2 Stage 3
    WhatsApp Video 2022-01-11 at 20.36.53

  2. Elevator and wrist: An elevator with a hook on top, which raises the robot to the 2nd rung. A hook on a wrist then locks on to the 2nd rung. With the robot fully on the 2nd rung, the elevator rises, disconnecting from the 2nd rung and then, using the wrist to change the angle of the robot, the elevator hooks the 3rd rung and pulls the robot to it. The wrist lets go of the 2nd rung and the robot is now hanging from only the 3rd rung. This mechanism is similar to ZouKeeper’s Ri3D climber Theoretically this concept can climb an infinite amount of rungs, making it very alluring.

Over-the-Bumper Intake

For the over the bumper intake we decided to take direct inspiration from 2020 robots and built a general prototype allowing us to easily change the positions of the rollers of the intake. Using the green compliant wheels we managed to get a decent control of the ball, but trying to center it using mecanum hasn’t worked so far.

Videos of the prototype (will be updated over time) are available here.

Through-the-Bumper Intake

For the through the bumper intake we took heavy inspiration from 2016 robots, trying to convert a face of the robot to a wide bumper using wheels arranged in a cone shape. While testing has been successful the problem with this concept is the balls bouncing from the wheels instead of being lead by them. To solve this we implemented an over the top roller to force bouncing balls into the wheels, making this concept a merge of the two types. We’re now working on improving the funnel wheels and investigating the possibility of moving the funnel wheels onto the intake to be deployed outside the bumpers.

More videos of the prototype are available here.


We started testing the high-goal shooter using a modifiable prototype with variable compression, wheel type/size, hood angle, # of motors, gear ratio, and flywheel mass. Our goal is to find one or two angles that give us the widest range by only varying flywheel speed. Our initial strategy requirements say that we want to be able to shoot from as close as possible, and up to 5m away.

In testing, we found a good combination of 4" colson wheels, 1x falcon at 1:1 with our 2020 flywheel, and 20mm compression. We first tested the minimum release angle that would allow us to score when touching the HUB; this came out to 69°. We then backed up the target until we got to our max range, which was ~3.5m. This is likely not enough range for our strategy, so in the coming days we’ll test a second hood angle for longer-range shots. Testing a number of hood lengths, we found that the longer hoods keep the ball in contact with the flywheel longer, increasing the max distance. We ended up with a hood arc length of 55° on a 272mm radius.

Videos of the prototype testing are available here.

Cargo Conveyor

We wanted to prototype a conveyor system to check the required compression, belt distances, etc. On the first prototype, we forgot that the belts not being centered on the ball means the ball has a smaller effective diameter, reducing the compression. While it does work, it doesn’t hold the ball securely enough for our satisfaction. We don’t want to completely remake the prototype, so we are working on modifying it to allow for larger compression so those numbers will be available when we go to design the real conveyor system. Meanwhile, we have attached the through-the-bumper intake to the conveyor inlet to begin testing system integration. (2)

More videos of the prototypes can be found here.

Computer Vision

We were able to create a small prototype of this year’s retro-reflective target, and successfully identify it using the PhotonVision grouping mode and a deconstructed PSEye3 camera.

Additionally, we have been working on automatic detection of cargo position and color. Using OpenCV, we were able to both identify cargo within the image based on color and differentiate it from other objects of similar colors (e.g. bumpers)

We’ll have more updates on prototyping results and strategy decisions coming soon


Thank you for sharing all of this! In your prototyping of the cargo conveyor did you happen to see what happened when you stopped a cargo from moving and let the belts keep spinning? Or stop the first cargo and intake a second cargo? I’m curious how the interaction is and how much it differs from power cells (which notoriously did not like to have belts spinning across them or stack up against each other)

This year’s cargo are much slipperier than the power cells (in a good way). They had no problem with belts sliding over them or rubbing one on the other. We could run the conveyor with the end blocked off and the cargo lined up one after the other no problem. We are planning on increasing the compression on this prototype in the upcoming days so that may make it a bit grippier, but I still don’t really expect a problem.

Awesome thank you!

We’ve been hard at work and have made a lot of progress in the past few days.

Strategy Decisions (an overview)

We had a meeting Sunday with the team leaders and mentors to choose the final robot design based on the results of our prototyping:

  • We decided to focus on the high goal, as we are very happy with our shooter design. We want two hood angles to be able to shoot from a wide range of distances on the field.

  • We decided to go with a swerve drive because we feel confident it will give us speed and maneuverability advantages. The difficulty with this will be the motor limit, since we are using the old control system and swerve takes up 8 motors, but we think we will be able to design the rest of the mechanisms within the remaining limit.

  • We decided against using a turret because we didn’t want the added complexity, and since we should be able to align with the target using the swerve. It also helps us save a motor.

  • We chose the climber which we referred to above as “stick on a wrist”, based on Snow Problem’s Ri3D climber design. It will now be known on the team as the “Propeller Climb”

  • We postponed the decision on the over- vs through-the-bumper intake for a few more days to allow for more prototyping. Just yesterday we made the final decision to go with the over-the-bumper design. Both prototypes performed fantastically, but in the end we had to choose one and the over-the-bumper is slightly simpler and uses one less motor which gives it the edge.

Some more details on each of the mechanisms and their progress:


We will be using the swerve modules we developed in the offseason last year with minor changes. We finalized the design on those already and will be manufacturing the parts over the next week while the rest of the robot is developed in CAD.


We finished the shooter prototype fairly quickly because we were very happy with the results. We were able to consistently hit a target about the size of the bottom of the high goal funnel even shooting from 16ft away, using one Falcon without PID. To be able to shoot from the range of distances we want, our testing revealed we need two hood angles: 69° for close shots (5 to 11ft) and 54° for far shots (10 to 16ft). We are designing the shooter to have a pneumatically deployed flap that can be flipped down to increase the hood angle or flipped up and out of the way for the higher release angle. If we see that we don’t end up using the second angle, the flap can be removed entirely and we will have a static hood. The CAD for the shooter is already close to being done, well ahead of the schedule we set before the season.


We have the terrible fortune this year of having two intakes that work very well and needing to choose between them. Our through-the-bumper intake has a top roller to grab onto the cargo and four vertical wheels to guide the cargo sideways into the bumper gap.

Longer testing video:

Our over-the-bumper intake has two horizontal rollers with compliant and mecanum wheels to pick up and center the cargo. In order to prevent jams when intaking two cargo at once, the intake is purposefully biased to one side and the cargo enters the robot not-centered on the frame.

Both intakes quickly and effectively picked up and indexed the cargo, were able to intake two cargo at once, and weighed about the same. In the end, we ended up choosing the over-the-bumper design because it is slightly simpler and uses one less motor.


We designed a new conveyor prototype to better test the compression needed to securely transport the cargo. Based on the results of our previous prototype, we decided to use timing belts on only one side, with the other side being a flat surface covered in rubber. This has worked well with a compression of 15mm with 95mm between belts. Unlike 2020 where much effort was needed to get the balls aligned in a row without gaps between them, this year we can run the conveyor indefinitely with something blocking the path into the shooter and the cargo will line up on their own. We are now testing a final prototype which includes a 90° bend to ensure that the cargo will transition smoothly.


We finished the first medium-scale prototype of our windmill climber, which seems to work decently. We are still working on building a team version of the hangar, so for now we are testing the prototype by hand. We are able to grab onto the 2nd rung and lift up to grab onto the 3rd rung. Here is a video of our initial testing of the prototype:

We designed a custom latch to hold onto the 3rd rung from below instead of using a hook on the 3rd rung so it doesn’t have to line up as exact. We are still in the process of testing to see how much force it can hold.

We’re now working on the physics for a full-scale prototype in order to be confident the idea will work before the final mechanism is modeled in CAD.


We have started programming the subsystems of the robot. For each subsystem we create a pull request so that we can check each other’s work and catch as many errors as possible before we get the robot. For this purpose we have also been using wpilib’s physics simulations, for example in the shooter this year the closed loop control is state space with the moment of inertia of the shooter. From the CAD of the shooter we calculated J, the moment of inertia, and using the wpilib simulation GUI ran our command based code so that the shooter gets to a certain speed as shown by a graph in the GUI. We are currently doing the same for the climber to try to get a rough estimate of the PID constants and make sure that every minute of work on the robot counts.

On the vision side, we wanted to do vision with the Jetson but our J120 carrier board’s USB ports seem to be malfunctioning. This doesn’t seem to be a programming error as one of the USB ports doesn’t receive power, and the correct driver for the board has been downloaded. Therefore, we have pivoted to using RPIs.