Lots of prototyping is underway this first week!
One of our first prototypes for an intake involved squeezing the game piece on either side to maintain control and flipping it into the robot. While we ultimately decided that it would not be efficient as an intake, it evolved into what’s currently our leading prototype for a “carriage” (a mechanism to carry the game piece from the intake to the top of the elevator and eventually to the high node).
The design shown above was able to flip the game piece, but it couldn’t squeeze it since there was too much friction between the wood and the hex rod. The subteam redesigned that part slightly to add a linear slide on top of the hex rod with separate wood attachments for squeezing the game piece.
This squeezing mechanic is nifty because it works for both cones and cubes, as we were able to demonstrate:
This prototype uses a 775pro motor with a 40:1 gear ratio, and it uses 30% power when flipping the game piece.
We’ve also been testing angles for mounting an elevator. We used a wooden chassis that has the same dimensions as Borealis (our previous swerve bot) with a climber we previously used with Aurora (our 2022 Rapid React robot) to mimic what an elevator might look like on this year’s robot.
This elevator is at an angle of approximately 30° and is mounted around 10 inches from the base of the drivetrain. Note that in this picture, we don’t have the second stage attached, but fully extended, and with the additional length we expect from the carriage, this would be able to reach the top node and drop a cone on top.
You may notice that this model rests on the Falcons in the climber - this won’t occur in the final design. Note that the actual elevator would have to be shorter to remain within the frame perimeter and might need a third stage in order to reach the top node, which isn’t ideal for us as it would add complexity. This mock elevator is also a lot thinner than we’d like the actual elevator to be; in reality, we’d like the elevator to be wider than the game piece.
To that end, we’ve started working on an elevator prototype that more closely resembles our vision of a final product; it’s mounted at the same angle and height as we found above. Although it’s skeletal at the moment, we hope to develop it into a working prototype that we can mount our carriage onto in our following meetings.
We’ve also spent a lot of this week designing our drivetrain in CAD. We shifted our plan slightly to using Swerve X modules with a gear ratio of 6.75:1. Originally, we’d planned to use the belted version, but since we don’t have the Falcon V3s that the belted version requires, we’re using the geared version. Our rough dimensions are 27” x 27”, which are the same as Borealis’ dimensions - we wanted to keep it square to make it less complex to program.
One of our more daunting tasks was figuring out how to intake both cones and cubes with the same intake. We went into more detail about this in our last post, but most of it boils down to the irregular shape of the cone - we need to be able to control its orientation to place it on the node, but it’s more difficult to control its orientation on the field. At the same time, we wanted to keep our intake from being too complex. Much of our team worked toward solving this and as of now, we have four main prototypes.
This first design is one of the more fleshed-out prototypes at the moment - you might have spotted it in our previous post. It’s made of lightning-bolt-shaped attachments that each have two sets of two compliant wheels that open and close using a piston. These are able to close around cones but remain open when intaking cubes, letting us launch them. This intake uses Neo550s on both sides that are connected to the inner wheel axles using a pair of 36T GT2 pulleys, which in turn are connected to the outer wheel axles using another pair of the same pulleys.
This intake was designed with upright cones in mind, but we also did some tests at different angles. However, this would require a second mechanism to lift and angle the entire claw which increases the complexity of this design.
This second prototype is similar, but rather than the lightning-bolt shape, it simply extends forward. This design uses two pistons on either side to open and close the intake and has a motor on either side to power compliant wheels. Similar to the previous prototype, it’s also able to close around the cone and launch the cube. Though it isn’t pictured here, this intake is also able to pivot up and down and we expect it to be lighter than the prototype above.
The third intake is similar to our second prototype but has longer arms extending like a funnel and compliant wheels mounted along these arms. Similar to the other intakes, it’s able to intake both cubes and cones, but it cannot launch cubes. Its width would help drivers spend less time lining up to intake the game piece, but it also poses a risk as we think this will be a very high-impact game. This intake is a direct copy of one made in our CADathon during the offseason for 2018’s game Power Up.
The fourth intake uses a different approach from the prior three. Instead of using compliant wheels, it uses a “weedwhacker” approach - it uses rotating wheel treads to pull in the game pieces. It’s unable to launch cubes, but it can intake both game pieces. It can also intake the cone at different orientations without having to alter the direction of the intake. However, it’s more difficult to control the orientation of the game piece within the robot than with our other prototypes.
Not seen on this prototype are compliant wheels on the edge of the frame perimeter, which would help bring the game piece over the frame and into our robot.
While our mechanical subteam’s been busy with these prototypes, our controls subteam has also been hard at work!
Part of the team worked with rookies to import our project into the 2023 WPILib framework, helping them learn more about debugging and our overall controls scheme. Other parts of the team worked on updating Borealis to our 2023 control scheme. They updated the firmware on the motors, speed controllers, encoders, and RoboRio. We have also been looking into creating multibuttons (buttons with different layers of functions).
Outside of updating our code, we’re making changes to the code structure to make it more reliable. We’ve been using the library Dagger for dependency injection. This gives us better access to dependencies in subsystems, especially if we need multiple dependencies, and makes unit testing easier. This works by letting us make a mock motor to test with, rather than having to create the mock motor later in the code. With unit testing, we can test each part of the code individually without needing the robot connected, letting us find issues earlier and easier than if we needed to wait for a robot connection to test code. To create these mock objects, we use the library Mockito and for unit testing we use Junit.
We’re also fleshing out a project that we’ve been working on since the offseason: our Robot Enabled Self Test (REST). This is similar to unit testing, but where unit testing tests the code without the robot connected, REST tests it with the robot connected. It runs the code, then collects data to show that the code worked as intended. We are working on expanding it to return more specific details as well, like how much current a motor is drawing - we’ll be able to test whether a component is running sub-optimally before something more damaging happens.
Our web development team has been diligently updating our website, which we’re proud to say is finally up to date with more information about the past seasons! We invite everyone to take a look here: https://www.yetirobotics.org/
We hope to have completed CAD by the end of this week. We’re excited to share that and any other developments then!
. We are going to add camera support soon. Grouping widgets is more challenging, so that might take a while to be added.
