GalacTech 4926 - Build Blog 2023

GalacTech is excited for 2023 and plans to share even more than our 2022 thread. We are setup as a Wiki and will keep the links to our CAD, Code, and other things up-to-date in this first post. Let’s bring on 2023 and Charged Up!

CAD: 2023 - 4926 Robot Assembly
Code: 2023 - 4926 Git Code


January 12th update:

After kickoff, we brainstormed multiple important components to the robot. Firstly we were initially going to use a kit of parts chassis set up as a tank drive. However seeing the field we believe maneuverability outweighs the benefits of a tank chassis. We decided to prototype a mecanum drive. While in past games mecanum could be considered a disadvantage due to a loss of traction but due to there being protected zones, we believe it will perform well. We used a 2022 practice chassis to prototype the chassis on. Our team used a mecanum drive in 1 other season, 2015. Because of this the parts we do have are outdated or down right disassembled.


As a result, the final product was a KOP chassis with 8” vex mecanum wheels paired with 4:1 transmissions. We did this because of a lack of transmission parts. We knew we wanted to use Neo’s as our drivetrain motors and because of this sourcing 4 matching transmissions in under 2 days requires some modification. We are well aware that the current speed of the robot is unusable in its current configuration however the goal of this chassis is to test driving on the charging station and maneuverability with a robot.


This past week we have been brainstorming, prototyping, and troubleshooting ideas for possible intake solutions. We have been attempting to test an intake similar to RI3D Redux’s, but planning to use it as a through the bumper intake/indexer instead. Monday and Tuesday we were able to build one side completely, and begin on the other side as pictured here:


We are using a combination of both team 5254’s HYPE block system as well as some modified versions from Ryan Dognaux, which worked fairly well for prototyping purposes last year.

Wednesday was spent troubleshooting the intake system which has posed some issues. We quickly found that when using the HYPE blocks without actually screwing them into tubing, but rather clamping them around the tubing, they tend to move, causing thrown chains. Since these are 3D printed blocks, they also tend to be fairly fragile when met with high rpms, and we found that out the hard way.

As you can see, the blocks snapped after we screwed them into the material to keep them from moving. After fiddling around with this approach for around an hour, we made the decision to move away from the 3D printed parts, and move towards plywood prototyping for this specific subsystem due to its severe forces at high rpm.

Today we began our plywood prototyping approach due to its rigidity and flexibility. We had the same basic layout as before, and since it didn’t break, we were able to test different wheel’s interaction with the cone (since the cube is much easier to grab). We wanted to be able to pick up cones in any orientation so that the drivers spend less time maneuvering, and more time scoring. We wanted to test out the idea of star wheels since they seemed to work fairly well for RI3D Redux. There was one problem however: we don’t have any star wheels. In order to get the same effect, we decided to chop up some bald high grips and they worked great! We are very happy with how the intake works, we just need some minor tweaks so that we can “touch it and own it”. Here is a video of our current prototype in action:

Intake Prototype Video

Arm Mechanism
Once we had seen how high and far we needed to reach to place game elements, we began brainstorming. From this we came up with a list of loose requirements (listed below) to follow when making our first prototype. Most ideas using linear motion were scrapped because of their high weight and slower deployment speed. At the time of creating the first prototype we had not decided what type of drivetrain we would be using so we also wanted the design to be easy to put on a turret.


  • Low center of mass. We plan on moving as fast as possible across the field, and at high speeds flipping is easier.
  • Reach. In case we were to put this on a turret, we want to be able to reach as far as the rules allow in most directions.
  • Movement. The arm would need to be quick to reduce cycle time and would need to be able to move as freely as possible.

The End Design:

In the end we decided to go with something similar to a four-bar linkage. The lower limb spins freely on the lowest shaft, with a large sprocket attached so it can be driven with a chain. The lower shaft is chained to the upper limb so that a motor can drive the upper limb while still having the motor separate from the two limbs. When the motor is engaged, the upper limb’s angle to the chassis will stay the same, making it easier to place elements. Both limbs are spaced apart so that the upper limb has full 360 degree motion. This is so that anything attached to our arm can be used on both sides of the robot.


  • Low center of mass, all motors required to control the arm are mounted lower to the chassis rather than right on the arm.
  • Quick deploy, because of how long each limb would be when made for competition, each limb only has to move a little bit to reach all the way to the high post
  • Utility, with enough clearance between the limbs, the arm can reach both sides of the robot with no turret.

Video of the Prototype

Sorry for the lack of images, and the video being a bit too short, but as you can see, the drill can move the upper limb while the lower stays static, and vice versa.

Programming & Electrical

On the programming side of things, our team had a lot to discuss about. From autonomous paths to vision systems, we brainstormed, theorized, and tested a lot. As of week 1, we have begun work in many important areas. They include H-Drive and mecanum drivetrain programming, Limelight and AprilTag programming and autonomous path strategizing.

We decided to test out a mecanum chassis first, so we began programming it! I used the MecanumDriveKinematics class and other relevant classes to code the mecanum drive. Some conversions and methods were a little tricky to understand, but I was able to successfully program the drive. The process to code the drivetrain wasn’t so perfect, though. I had made three iterations of the code, and my latest one proved to be the most efficient and simple. On the other hand, the first I made on my own snowballed into being something a little complicated and ‘extra’. So basically, using the provided WPILib classes will result in a much better experience (and will also be fairly likely to work!). In the end, it’s still your own code with some added support. In addition to the mecanum drive, we also created code for the H-Drive. While we’re testing the mecanum right now, having the code ready was a good choice. Here’s a link to the official WPILib documentation. Below is a demonstration of our first test of the Mecanum drive. Note: the robot is unable to strafe right now (move sideways) due to low torque applied. We’re working to change that.

Mecanum Drivetrain Initial Testing

This year, as you all may know, AprilTags have been introduced to the game. We talked about detecting reflective tape and/or AprilTags, and we found it best to be able to do both! The tape is wrapped around the cone node and the AprilTags are aligned with the cube nodes. We haven’t decided on a method to pick and place game pieces, but we have started testing different vision pipelines and code to be prepared. So far, we’ve tried OpenCV and PhotonVision. We’ve also tried straight-up coding the whole thing (which didn’t work). The team has been able to tune the PhotonVision pipeline to detect cubes and cones pretty well! We’re discussing whether or not we should try to use a Limelight to detect AprilTags and reflective tape, or if we should just split it between a USB camera and a Limelight (to be settled soon!).

Finally, we thoroughly analyzed and discussed some optimal paths for the autonomous phase of the game. We came up with a bunch of paths, but have found about three or four that work really well. Keep in mind that it is still uncertain for some paths to actually work. There are many variables that can affect the robot’s performance during autonomous, such as positioning, the fifteen-second time constraint, robot capabilities, and compatibility with other teams on your alliance. These are probably the most important things to consider when strategizing for autonomous.


I’m really curious to see the results of this testing- we are/were considering going with a mecanum chassis for the maneuverability benefits, but our initial testing on a ramp mock-up was not optimistic. The wheels were slipping unpredictably on the ramp. The chassis in question was using the 6" wheels which had clearance issues getting on the ramp as well, so 8" wheels are definitely a necessity.

If your testing turns out well we may further pursue it though- we really liked the maneuverability it provides with lining up to score, and we don’t think defense will be as big an issue as it would usually be with mecanum, with scoring and loading zones being large and protected.

1 Like

Interesting Ryan. We only had 8” VEX in the shop. They seem to handle the Charge station ‘ok’ but I was planning to get 6”. So now I’ll probably get both when/if available. At the speed we plan to go, the VEX wheels, at least the generation we’ve got, are way too ‘dainty.’ We already broke several rollers just flying around our half field.

1 Like

Here is some short examples of ugly flying around. 2023 Prototype Drivetrain - 2 - YouTube


Jan 14th Update:

We are still playing with methods to pick up a cone laying down and we like the base facing us, so what to do when the cone tip is facing you? Well…. “Flip it, Flip it Good!” This is SLO MO video so skip to the end….

Gross flipping prototype

We’ve built a 8” Mecanum KOP chassis using MaxPlanetaries at 9:1. We think our driver can actually handle much faster so we’ll explore 5:1 too and see how low speed position control suffers. Acceleration and current draw for such low reductions may also prove just too ugly: 8 motor mecanum?

There is an intake prototype for pulling in tipped over cones with the base first. Hopefully the students can post some video of that.

Multi-joint arm CAD is coming this week!

1 Like

January 18th Update:

Mecanum Drivetrain (Mechanical)

After last week’s successful chassis test we decided to commit to Mecanum as our drivetrain. Following that decision we had multiple sub-decisions to make, such as wheel size, frame sizing, and ratios. We concluded from multiple tests from our 2023 practice chassis that to strafe at a comparable speed to the forward drive we would need more torque. We did not want to sacrifice speed by a higher ratio so we decided to use 8 motors for the drivetrain and gear it 8.4:1. This will give us sufficient torque to strafe faster and also have a slightly faster final drive ratio. The transmissions will be sunk in between the frame rails of the KOP chassis and use a slight belt reduction to achieve the final ratio. Another decision we made was to use 8” wheels. This may be unconventional in terms of modern fast FRC chassis however we found it works well and still has incredible maneuverability. It also gets on to the charge station easier with the large wheels. Chassis sizing was a slightly difficult issue to decide on. While we would ideally like to take the extra frame perimeter of the KOP chassis out of the length, we can only take 2” off each side. We can not take more off because it will interfere with the wheels. The reason we would like to shorten the length is because it will make the geometry of the arm easier to achieve and give us a larger margin for error. We currently do not have the final dimensions of the chassis; we know it will have the same wheel base with a shorter frame.

Intake Prototyping

Why the previous prototype did not work:

The 3-D pieces we used to hold our intake together lacked the strength to hold the chains in tension, and the previous mounting did not allow for the cones to cause the “opening” of the intake. The 6’’ Hi-Grip wheels we used were also sub-par at gripping the cones.

How we solved those problems with the new prototype:

Of the two prototypes we made in the past week, one was from .25’’ aluminum and the other was from .5’’ plywood. Both worked well, although we did not test the plywood intake on the chassis. These materials held the bearings in better and allowed for the cone to widen the intake. We also switched to some DIY star wheels for a bit, and finally to 4’’ compliance wheels as the first set.

What we learned:

  • Star wheels require a slower speed to grip and re-orient the cone.
  • Compliance wheels require a much higher speed than anticipated to grab the cones.
  • The spacing on the compliance wheels is absolutely crucial on whether or not you can grab the cones (about 10-12’’ was the goldilocks zone).


This week we decided that we needed to cover a series of criteria for our arm in order to place cones/CUBES. The criteria we came up with are as follows:

•Ability to place on high/middle/hybrid nodes

•Ability to pick up game elements from inside our robot (handoff from intake to arm)

•Place on both sides of the robot? (If space allows)

•Pick up cones laying down in either direction (we are assuming the intake will be able to orient the cones in only 2 directions)

We then went about getting a rough sketch of the arm-to-node geometry to see the longest arm we could make when mounting it directly in the center of the robot (to have the ability to place on either side of the bot). We found that it is possible to get a cone on the node with room for bumpers, but the cone couldn’t be perpendicular to the ground, it had to be at an angle in order to utilize the length of the cone to get on the node. This geometry problem can be seen here:


We found that we would need a mechanism to rotate the cone so that we could

  1. pick it up in 2 different orientations each of which is seen here: (These are top-view images)|242x323.09835889463284|276x366.51075709059853

  2. Reach the high node while staying legal. Our team had the idea to have a gripper similar to that of RI3D Redux’s, but have one side of it powered so that we could manually spin the cones instead of relying on gravity.

Since we are competing in the week one district event, we think we are going to create the same geometry, but offset it from the middle of the robot and only place elements from one side of the bot so that we have a little more room for driver error in our design. We think that since we are going to use a Mecanum chassis that we should have the maneuverability to turn the robot 180 degrees fairly quickly. We also believe that this extra room will allow us to strafe while placing so that we don’t need to have the arm on a turret/rail in order to align with the nodes.


The programming team had made a lot of progress in the past week. The list includes the Mecanum drivetrain, AprilTag and Limelight programming, autonomous paths, game piece detection, and Charge Station balancing.

The Mecanum drivetrain saw a lot of improvements on both the programming and mechanical side. We constructed a new chassis and got some new wheels (they’re awesome!).

I was able to get our robot-centric/robot-oriented drive to fully work. This time, I used the driveCartesian method to do it (I highly recommend this to people who are looking to program a Mecanum drive). However, our field-oriented drive isn’t fully working yet. When we try to drive field-oriented, our strafing is always inverted and everything else works fine (Inverting the strafe doesn’t work either. I’ve traced the code by hand and I’m still figuring this out. Any help is greatly appreciated!).

Here’s the video for the testing of our new Mecanum wheels.

Since I’m not satisfied with just one video, here’s another one of our robot climbing the Charge Station. Note that the results will likely differ when there are bumpers attached to the chassis.

We used a Limelight to capture both retro-reflective tape as well as AprilTags (We have a Limelight 2+ and detecting both so far works well). We’re using our 2022 chassis to detect targets and align itself. Once we have the code ready, we’ll integrate it into the Mecanum chassis.

We have started programming our autonomous routines with our Mecanum drive. We have thought long and hard about potential strategies, but for actually programming them, we’re going to start small and build up. I made a quick program for running the chassis for a certain distance using the encoders. One thing I noticed here was that odometry with the Mecanum chassis can be a little inaccurate because of things like wheel drift (or maybe I just need to work on it more. I’ll find more problems as I go and eventually fix them!).

Our team is also focusing on creating software to detect cones and cubes. More specifically, the orientation of these objects. While we haven’t finalized what we will use, it’s a good idea to have a lot of good code ready in case we need it. We’ll be able to come to a decision on this once we have a design ready.

Last but certainly not least, Charge Station balancing. I’ve researched a lot of teams trying to figure out how to balance and I’ve come up with a few ideas of my own. Right now, we’re still in the process of discussing how to balance on the Charge Station, whether or not it should be automated, etc. I’m excited to work on these new concepts this year!


Our Fabulo-so-so CAD has been updated to show our planned approach for an overly aggressive 8 motor mecanum likely to be known as #% on mecanum wheels!. The intake and ‘arm’ CAD are considerably visionary…as in only a vision now!

@sgeckler have you considered just cutting notches into your front and rear frame rails on the kop for slightly more room? With those 8" wheels its obviously not a whole lot, but still a little.
I’ve done this in the past on former teams when using the KOP. If you leave even a bit of the bend/flange and try to filet the corners it should still be decently rigid in those spots, especially with nice rigid bumpers…

1 Like

We actually had a discussion last Friday, and this idea popped up! It’s our current plan on fitting within the frame perimeter while giving us as much wiggle room for our subsystems.

1 Like

January 31st Update:

During week 3 we worked on creating a version of the final chassis. First we needed to cut the KOP frame rails both width wise and length to comply with the frame perimeter rules. Next we created a fixture for our CNC router that allowed us to mill the inner and outer frame rails to mount the REV transmissions. After all the machining was done we started the final assembly of the chassis. Due to all of the mechanical parts being contained within the frame rails assembly was slightly difficult and time consuming. Following assembly wiring was started but not finished at the end of week 3.

Throughout this past week the build team has been working on getting a working arm assembled, in order to test our current geometry, and to see where potential failure points are. We have decided to use a 4-bar linkage in order to power the bicep so that we can have a more compact geometry, and to minimize the slack in the system by avoiding chain. This 4-bar linkage can be seen in action here:

We are very satisfied with how this linkage turned out, and we will be working on completing the competition design of this linkage in the next week. We plan on powering our forearm with a motor mounted to the arm, so we can use the least amount of chain, or possibly even use gears to power it.
In theory, the current geometry of our arm should be able to place cones on either side of the robot, but we think we will focus on a one sided placement for week one due to time constraints.

The programming team had advanced a lot this week. The highlights are field-oriented Mecanum drive, AprilTag and reflective tape detection, arm programming, and auto-balance code.
After lots of work, 4926 now has a field-oriented Mecanum drivetrain! One of the issues that were holding us back for a while was the gyroscope angle. Our gyro (Kauai Labs navX) considers clockwise as positive, and the Mecanum drive code considers counterclockwise as positive. To fix this, we called a unaryMinus method on the gyro angle we used to drive.
We were testing our Limelight on our 2022 robot. We were able to detect both AprilTags and reflective tape. Our code for the Limelight had three pipelines: AprilTag detection, high node reflective tape, and middle node reflective tape. We can switch the pipelines with a button press on our controller. Now, we have moved the Limelight to our Mecanum chassis to continue further programming. Currently, we have a strategy to properly align to the AprilTags and tape to be able to properly place a cone or cube.
The team has built a system to pick up and place the objects. Right now, it is controlled by two motors. We have got it to move, but once the arm is complete, we’ll be able to program it for autonomous use (by setting the motors to rotate to a certain angle and then stop).
Our team hasn’t built a Charge Station yet, but we have some auto-balance code ready. We’re planning on using PID to smoothly balance on the Charge Station. The ‘pitch’ value of the gyroscope will help us with this.
We have also built an eight motor Mecanum chassis and will drive that around soon


February 9th Programming Update:

The past few days have been significant for the programming team. The highlight of last week was autonomous programming and auto-balancing on the Charge Station. To stay even more updated with our build season, check out the YouTube channel. I’ll be regularly posting videos of our progress.

The team had a lot to decide regarding the autonomous paths. A few key questions that needed to be addressed were:

  • What exactly do we want to do in autonomous?
  • How versatile should our robot be?
  • How do we make the paths?
  • How should we decide to execute a specific function? (ex: placing a game element)

Having this discussion helped our team a lot in ruling out extraneous functionalities and sticking to the task. We had a lot of iterations for the ways we wanted to do things. We tried automating our drive alone in four different ways! To go forward and backward, We tested out PID and odometry. Since odometry is a little unreliable when strafing on a Mecanum chassis, we thought of controlling our strafe using time. Our final autonomous routines were far from this though. Here’s a little demo of an auton path we created. As of right now, we don’t have an arm or intake ready so we can’t demonstrate a full autonomous routine, but this covers most of the important drive functionalities.

Click the dropdown below for the details on our autonomous.

Our Auton Specifics

We found that tracking encoder distance to go forward and backwards was very accurate for us (Even though we’re on a Mecanum, which might be unreliable for others). For our strafe, we planned our path in such a way that we’d use strafe only for placing elements. In a nutshell, The robot would strafe until it sees the target (AprilTag or reflective tape) and use PID to stop itself directly in front of it (and move forward/close to it). To make this even more accurate, we always had the robot aligning to zero degrees. We’re using a navX gyro with the AHRS library (provided by WPILib). The gyro is good enough for us to track our yaw and pitch measurements but it’s far from perfect. I think it’s because it’s just worn out (we’ve used it for a few years in the past before). The good news is that the navX2 will be making an entrance into our shop! We’ll see how that works for us. A little note to the programmers out there: I’m using a command framework for all of this code. I recommend making a command for each functionality. Example: StrafeTillYouSeeTheAprilTagCommand (I don’t have this kind of naming convention but you get the idea). As you’re going through your journey of programming your amazing robot, start simple by understanding the basics and making small commands that accomplish a specific task. If you would like to learn about the command framework, here’s a useful link that can help you get started.

Let’s move on to a different kind of autonomous: auto-balancing! In our technical profile, we decided on balancing on the Charge Station using programming. We thought of using our arm to adjust our center of gravity to balance. Eventually, we landed on using the pitch value of our gyroscope + PID to move and stop in the middle of the charge station. Right now, it’s integrated along with our drive command. We use our align-to-zero concept here too. A video for this is shown right here. Important note: The library that we’re using for our gyroscope (AHRS) does not provide a way to reset the gyro pitch (or gyro roll). The reset() method only applies to the gyro yaw. I’ve accounted for this by having a pitch offset. In my drive subsystem, I have a method that gets the gyro pitch. Say our gyro pitch reads 88.7 degrees. Now, I just simply return 88.7 - 88.7 (to make it zero). The appropriate line for this be: return gyro.getPitch() - 88.7;. Your gyroscope needs to be mounted parallel to the ground for this to work properly.

As of February the 9th, we have an autonomous that integrates drive using distance as well as auto-balance code. Right now, it’s easier to get on and balance on the Charge Station because our robot is incomplete and very underweight. We’ll be tuning and updating code as we add other components. It’s going to be interesting to see how the results change!


@pranav You should post the video of the robot tipping backwards off the Charget Station! That’s a good one; very interesting failure mode!

I thought I would throw out imagery of Robot CAD and our prototype build status; this CAD is live in the link at the top! The robot could be fun if we can ever finish building it! We have several weak joints, a frame twisting problem, and a wiring ‘situation’ yet to solve. FIRST is hard AND fun!

Current CAD Image

Prototype Picture


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.