5987 Galaxia 2023 Build Thread

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:
  • 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!


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?

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.

1 Like

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.


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.

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.

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.

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.

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.


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.

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.

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.

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.


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.


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.

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.


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.


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


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.

1 Like

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.

1 Like

Any chance you could publish the CAD for the gripper?

Do you have any videos of the gripper working?

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

1 Like

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.

1 Like


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).


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.


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.


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.


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:

1 Like

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.

1 Like

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.

I want to note something here that we discovered the hard way, in hopes it might be in time to help another team. We bought the SwerveX Tube Mount Flipped modules this summer and are using them on our robot this year. When we were designing the robot, we downloaded the CAD for the modules from WCP’s website and used it in our design.

What we didn’t realize at the time was that the model on the website is for the “updated” version of the model, which can work with either gears or belts, instead of the original module. The updated module is significantly smaller than the original, so when we went to assemble everything we found that we hadn’t left enough space for our larger original modules. There wasn’t any note or indication on the website that there was more than one version of the same module. We had to make some pretty big clearance holes to adapt our robot to fit, hopefully it didn’t negatively impact the robot’s rigidity.

So if you’re using the SwerveX Flipped modules, double check to see which version you have and that you’re planning for the right one. You can see the difference between the new version CAD (on the product page) and the old version CAD (on the examples page).

1 Like

The robot is in the process of being assembled, so I wanted to do a bit of a deep dive into the design to show some parts I think are cool or unusual, and we’ll include some assembly pics as we go. This is going to be a rather long post, so I’ll split it into details.


This is a pretty standard swerve chassis, using the WCP SwerveX Flipped Tube Mount modules. Note that these are the original version and not the newer version, which caused us some problems (see above). The chassis also includes polycarbonate shielding to protect the front swerve modules and act as a “floor” for the intake.


The intake has two motorized degrees of freedom: actuation in and out of the robot, and rotation of the rollers. We chose to have the intake motorized instead of pneumatically actuated because it needs to pass over 180° to stow inside the frame perimeter, and the design didn’t have a good mounting place for a pneumatic actuator.

The intake’s actuation is powered by a NEO in a custom 9.6:1 gearbox. The final stage is a 18:66 #25 chain reduction, which directly drives one of the side plates. Ideally it will be position controlled using the NEO’s internal encoder, but as a fallback it has hard stops at the top and bottom of travel which it can be run into.

The intake rollers are also powered by a NEO in a custom gearbox. The power is then transferred through a belt reduction to the rear mecanum roller, with a final reduction of 11.9:1. From there, a belt “up-duction” of 3:1 rotates the middle tube roller, which is then belted 1:1 to the front compliant roller. The tube roller was originally meant to be 60mm OD polycarbonate, but we accidentally bought acetal instead which shattered so we switched to 50mm PVC with a rubber covering instead.

The rear mecanum roller centers the cube by compressing it against an HDPE wall, causing it to roll sideways into the gap. Our original attempts at using mecanum rollers outside the robot were unsuccessful because the cube had too much friction with the field carpet. This solution allowed us to bring the cube inside the robot first and then slide it on slippery surfaces in a more controlled manner.


Here’s a video of our first test of the intake. Seems to be working pretty well, but we’ll have to wait to see when the whole robot is put together.


The arm is made up of two independent stages. Both stages are driven and supported by a large gearbox at the back of the robot, with chains to transfer power throughout.

The bottom arm is constructed out of two 20x40mm profiles, connected by 2mm plates. The arm pivots around a 1” round aluminum tube attached to the base, using custom lathed brass bushings to provide smooth motion. At the top, a 17mm steel shaft runs through the entire arm both to add strength and as a pivot for the second stage. This shaft is tapped into 5mm plates riveted to the sides of each profile, and secured by two large M16 nylock nuts. (For those of you on the imperial system, that’s about a 5/8" nut).

To drive the bottom arm, two 60t #35 sprockets are attached directly to the arm via custom hubs, one sprocket per profile. These are connected to a shaft spanning the arm base, which is the output to a custom gearbox driven by two Falcon motors. The total ratio for the arm is 64.3:1. For feedback, the arm has a 1:1 belt to a hex shaft with a thru-bore mag encoder.

The top arm is made of a single 40x40mm profile. It is supported by the 17mm shaft on the first arm stage, with ball bearings to allow it to spin freely. A 1:1 belt connects it to a hex shaft on the bottom arm with a mag encoder for position feedback. Custom hubs connect the arm to a 60t #35 sprocket for rotation.

This sprocket is chained to a free-spinning cluster sprocket on the lower tube axle, which transfers power from the gearbox below to the arm above. The cluster sprocket is driven by a custom gearbox powered by two Falcon motors. The final ratio including the gearbox and all sprockets for the second arm is 30.9:1.


The gripper design hasn’t changed much since we last talked about it. It has two linear sliders, based on elevator blocks, which move the side profiles back and forth. Two pneumatic pistons actuate the sliders open and closed to grab the game piece. Flex wheels are attached to 1/2" hex hubs, and their axles sit in bearings in the side profiles, allowing the wheels to spin freely.


Well the robot is assembled, wired, and has been handed off to programming.

Our first order of business was running everything in open-loop and stress testing it to make sure it wouldn’t break. With the intake, it went pretty well until the angle motor burned up. We replaced it and added stronger current limits to prevent that from happening again.

With the arm, it wasn’t as straightforward. The arm itself is plenty sturdy and the motors can move it without issue. Here’s our first test of the elbow joint

Due to the robot’s layout however, we weren’t able to have supporting tubes for the arm extending all the way across the chassis, they had to stop halfway. So the arm was only supported by the back frame member and the bellypan, making it very wobbly under any small load. See the gearbox base wiggle here as the arm is lifted

To remedy this, we added two profiles underneath the bellypan connected to the arm gearbox and spanning the whole length of the robot. This added a lot of stiffness to the entire system, at the expense of lowering the robot’s ground clearance. It wasn’t our first choice, but it was necessary to be able to position the arm repeatably and not worry about it failing under load.

A few weeks ago we held a vote for the robot name and the team chose Pulsar, which is a rotating neutron star and fits with our name theme of celestial objects. Even though this was the option that won, there wasn’t a ton of enthusiasm behind the name. So when someone on the team suggested switching the name to Scorpio, after the robot’s scorpion-like appearance and the zodiac constellation, it was met with overwhelming approval. The name will be added to the robot arm in one of the plates connecting the lower arm profiles.