In the 2019 season, one of the biggest developments was improving our robot’s drivetrain. We built 3 completely different designs, but still wanted a slightly better version for 2020-21, so over the summer Spencer spent a lot of time designing and putting together a new version. For this iteration we spent much more time in CAD, since there was no time pressure, being very careful about every little detail. We made two unique designs that utilized polycarbonate sides again but combined them with other, more rigid, components for structure; however, neither of these made it past the digital design phase because they were either too space inefficient or not robust enough. In this design, we also spent a considerable amount of time attempting to find enough space for “odometers” on each side of the robot (see next section). We also realized that buying new parts was not always necessary, so we reused old parts and only bought a few bearings. Pictured left is a render of the final Version 3 design. To mitigate the flexing problem we experienced with past drivetrains, we decided to use 3.1mm gauge aluminum for the sides, something we recycled from an old game field. Like the previous version, we used standoffs to attach the two sides, but this time stability was not an issue because the aluminum sides were so rigid. To save space, we 3D printed smaller sprockets, which even after considerable use show little wear (apart from one unfortunate break). We took some inspiration from another team’s drivetrain and instead of having extra beams connect the two halves of the drivetrain, we simply used the box-shaped motor housing to connect the left and right sides, saving space. This box is constructed from recycled polycarbonate, but flexing is not an issue since the box shape makes it very rigid (pictured right). Additionally, the inside of each wheel channel is incredibly spacious (pictured left), something which was very important to allow for better odometers in the robot. The problem of the bearings coming loose was fully solved by making the entire structure more rigid; however, in a measure of extra safety, we replaced them with flanged bearings and made sure each end of the axle was capped, keeping the whole system stuck in place. While manufacturing the parts we made sure to double- and triple-check that everything was perfectly aligned, but even then we made some mistakes; however, because every part of the design is so robust it still functions perfectly well. The combination of all of these things, as well as generally making everything as compact as possible, allowed us to make this machine incredibly reliable yet still very space-efficient and fast. It is the first robot system that truly lives up to our team name, the Robust Robots.
Odometers are something we learned about from other teams online and somewhat successfully implemented in our 2019-20 (Skystone) robot. Essentially they are small Omni wheels on dead axles with encoders. Three are placed around the robot and track how far that point of the robot moves over the field in a given amount of time, then the robot does calculations based on those data, and determines how far it has moved on three axes, x, y, and rotation. It adds these up as it goes, creating a position measurement more accurate than measuring the drive wheel rotation because those powered wheels slip often. Over the offseason Spencer also worked on these, improving the reliability and accuracy of the system. Pictured is an odometer on our current robot.
To shoot rings, we use a launcher that sits on a turret that can rotate more than 360 degrees and aim at any target easily. The hardest part about designing the turret was determining how to get rings into the turret to be launched since it needs to be able to rotate freely without any other mechanism getting in the way. What we decided to do is to push the rings up through the middle of the turret, and then have them shot out wherever the turret is pointing. Since we need to have the middle of the turret open for rings, we decided to use a slew bearing as a rotation mechanism, and power it using a motor with another spur gear. We originally tried using v-slot bearings and a circular rail, but that didn’t work very well. Our first version of the bearing was big, and because of its size was flimsy. After that, we compacted the bearing and entire turret and found a much better way of mounting it seamlessly onto the transfer mechanism using 3D-printed plastic parts. The turret mechanism also includes a way to adjust the vertical aim of our launcher. Originally we used one servo to do this, but after compacting our design decided that it would be better if we instead used two servos, one for each side of the turret, to ensure that it is pointed correctly and to eliminate as much flimsiness as possible. A major upside of the turret is being able to aim automatically during the teleOperated period. Since it can rotate in any direction, we do not need to take the time to align our robot with the tower goal before we shoot the rings, and can instead focus on going as fast as possible. To do the aiming, we utilize the positional data we receive from the odometry system. We then use trigonometry to calculate the best angle for the turret to aim so it shoots into the tower goal (diagrammed right). To calculate the optimal vertical launch angle for the turret to use, we again use our odometry positional data, this time using simply the distance to the goal, then approximating the trajectory and finding the angle which will result in the ring ending up at the desired height. We needed to know the launch velocity of the rings to calculate this, so we measured it using slow-motion video, a stopwatch, and a tape measure over several trials, then found the average and used that as our value. We originally tried getting an exact value (some work shown above, left), but this was beyond our math skill set, so we opted instead for a good approximation (work shown right). During our testing, one of the biggest issues we encountered was turret drift, caused by the encoder on the turret motor drifting when the robot has low voltage, such as when it is running the intakes which take a lot of power. We solved this by adding an absolute homing system so that during a match if the turret is drifting, it can reset itself using a touch sensor acting as an end stop to fix the error. This works pretty well and has improved the aim significantly.
To launch rings we use a flywheel mechanism that is powered by a Tetrix motor. As mentioned above, we use the turret mechanism as well as two servos to aim the launcher in any direction we want. We tried several configurations while designing our launcher, first using a compliant wheel and indirect drive through two gears. To increase the speed of the flywheel we removed the stock gearbox from the motor and instead attached our gears directly to the motor output shaft. After testing the compliant flywheel we decided it was too squishy and when it squished would cause problems by running into things, so we switched to a hard plastic wheel with hockey tape on it to improve its grip. Additionally, we tried several different gear ratios between the gear on the motor and the gear on the flywheel but ultimately decided that it would be better to simply drive the flywheel directly 1:1 since that would reduce friction. Our next design did that and was effective. We also found that placing the wall opposite the flywheel closer to the wheel so that the ring is forced to squish more increased the power of the launcher significantly, likely because before the flywheel did not get enough grip to fully accelerate the ring previously. Another part of the launcher that we changed was the way that we pushed rings into the flywheel. Initially, we tried to use a simple pusher servo, but this did not work since it couldn’t push the rings far enough. We then moved to an upside-down conveyor belt system, which worked but was unreliable and had a lot of moving parts. To solve the issue we shortened the launcher track so that the ring doesn’t need to be pushed as far for it to be launched by the flywheel, and this allowed us to go back to a simple pusher servo which is very fast and reliable.
One design challenge we faced was finding a way to bring the rings from the main part of the robot up to the turret above. The way we do that now is using an elevator on a linear bearing that is lifted by a string on a servo. Previously we tried using a 4-bar linkage design to lift the rings using two servos, but we found that this wouldn’t work since it pushed the rings back and forth too much, and we needed to lift them perfectly straight up and down. Since linear bearings do this very well we thought that we should use one, but we didn’t have enough metal rods to use two bearings so we instead chose to use a bearing on only one side. We used a small rail on the elevator platform to ensure that it does not rotate. The entire mechanism is built into two large 3D printed parts that make up the center of the robot under the turret so that it is compact and everything fits together. We had issues with the lifter sticking in places, so we installed a rubber band return system so that it is always pulled back down and does not get stuck. This mechanism is now very reliable, and an integral part of our robot.
The intake of this year's robot drew greatly on experience gained in previous years of competition and intake designs. Last year we needed to bring in larger blocks and thus decided to use rubber wheels on a horizontal axis, but with the low profile of this year's rings, we needed a new design. We opted for an intake that uses multiple rods of varying material which sucks in the rings with multiple 1” diameter rubber bands which both apply traction and power to the rings. The design of our intake uses only one motor connected via a pair of 1:5 gears which efficiently brings the rings into the robot at a minimal cost of motors. The robot uses two intakes located 180° degrees from each other on opposite sides of the robot. For the sake of speed and coding simplicity, we have made it so the robot does not have to rotate as much, meaning faster gameplay. We recognized that in previous years, the intake process has taken a large amount of time which could be used in other ways more efficiently. We decided that to alleviate this potential limiting factor, we needed to make a more reliable, simpler, and better-implemented system dedicated to increasing the speed of the intake process. I believe that we achieved this goal.
We decided that the best way to grasp the wobble goal, which is a fundamental part of the FTC game, is to use a claw-like arm to hold onto the vertical rod which protrudes from the base. The claw motion is controlled by a single servo which connects to two 3d printed pieces sections of the claw. 3d printed components are a large proportion of the hardware on our robot as it offers the capability to create custom parts for specific design solutions. We primarily use Spencer's 3d printer and the educational software fusion 360 to design the parts. To not interfere with other parts of our robot and fit within the 18 x 18 x 18 minimum dimensions, the arm immediately folds from an initial starting position of 180° as to not interfere with the constantly turning turret.
We control the robot using the control hub and expansion hub. The motors, servos, and sensors are plugged into these hubs, and move everything on the robot. We use the app on the phone with the control and expansion hubs to run autonomous, as well as the Xbox controllers in TeleOp. In autonomous, we use the webcam (on the turret) to scan the number of rings, and based on how many rings the robot “sees”, the robot moves to the desired location to score points. The motors on the robot move the drivetrain, turret, and flywheel. The servos move the claw and the transfer elevator. Last, the sensors are plugged into the control hub. They tell us the position of the robot and help control the turret location.