FRC 3205 The Patriots | 2024 Build Thread | Open Alliance

THEBIGTHREE · December 10, 2023, 3:16pm

Who We Are

Welcome to 3205’s first build thread! We’re The Patriots, a team of around 40 students from Concord-Carlisle High School in Concord, Massachusetts. Our team has been competing in FRC since 2010, but we’ve grown rapidly in participation, mentors, and resources in the last few years. Our team’s philosophy is heavily centered around student leadership and design: our mentors guide us but never write a single line of code, wire an electrical component, touch a drill, or organize a meeting. This is our first year in Open Alliance, and we hope to provide some insight into our approach to designing and building competitive FRC robots while learning from the other great teams here.

This year we have 4 team captains:

Sammy Saak (@ssaak) - Chief Engineer
Colin Balfour (@thebigthree) - Software Lead
Will Wood (@Wheel) - Mechanical Lead
Cecilia Hetling (@chetling) - Electrical Lead

Feel free to ping any of us for any questions on our posts. The captains will run our build thread, but we also have four amazing mentors helping behind the scenes.

Open Alliance Contributions

We plan to split up our regular posts into three categories: one for each subgroup (programming, mechanical, and electrical). We’ll rotate between them each week, so roughly one post per subgroup every three weeks. Programming will likely be an exception, and our current goal is to post a programming update every other week.

In addition to the more extensive updates, we’ll post smaller updates more frequently. This might include information we gathered while prototyping/testing ideas mentioned previously, any minor design changes, or updates on more broad full-team activities.

Posts will be written with contributions from everyone on 3205. Within each subgroup, we have small teams working on different projects; each team will be responsible for a write-up on what they’ve been working on. The subgroup lead will then compile and edit those into an update on this thread.

Team Structure & Goals

During the preseason, we’ve been meeting 2x/week for 1.5 hours, plus occasionally an extra day for programming. Entering the season, we’ll meet 5x/week for 2.5 hours, with increased hours as we approach competition. We’ll post a more detailed preseason update later, but for now, here’s a summary of each subgroup’s structure/goals.

Software

Written by Colin Balfour, Captain

Our software is mainly split into two groups: Computer Vision (CV) and Controls, though there is overlap between the two. Controls refers to the Java code running on the RoboRIO––everything that makes the robot go. Computer Vision refers to the Python code running on our coprocessors, processing camera outputs to send information about the robot and its environment to the Controls code. The separation comes inherently from the differences in code structure of robot vs. coprocessor software but also due to the use of Python vs. Java, as many team members are only comfortable (for now😉) with one or the other.

This year, we have very few upperclassmen in software, and a significant amount of time will go into training our large group of new underclassmen, who are all very talented and motivated! This training will primarily be hands-on projects: writing and testing code on last year’s robot and the (new!) swerve base, with a few “lectures” on essential concepts. In addition, I’ll be maintaining/updating a set of training materials and exercises on a public GitHub repository, found here (largely inspired/modified from team 8033’s training materials).

CV Goals:

Pose estimation/Localization using AprilTags
Object detection with YOLO
Use ZED stereo depth camera for pose estimates and 3d point cloud
Setup processing on Jetson Orin Nano

Controls Goals:

Swerve Drive (new for us this year)!
Pose Estimation – goes along with CV’s pose estimation but focuses on combining data from vision with odometry/IMU using filters
Autonomous OTF (assisted-teleop) and pre-planned (fully-auto) trajectory following
Improved Structure/Simulation
- Switching to a command-based paradigm
- Utilizing AdvantageKit & AdvantageScope for advanced logging and simulation

Again, there will be a more detailed post on all of this coming soon, but please feel free to ask any questions in the meantime!

Mechanical

Written by Will Wood, Captain

Our mechanical subgroup is primarily focused on designing and building the different mechanisms and drive bases needed for each year’s game. Our preseason goals this year have been to train all of the underclassmen on how to use the tools in our woodshop, use CAD, and the basics of the engineering design process. We make sure to train every member of the team on basic woodshop safety, including how to use a bandsaw and drill press, regardless of which subgroup they are in. The mechanical subgroup members will also learn how to use the metal bandsaw and miter saw since they will use these tools frequently during the season. Once they have completed said training, we use a Google sheet to sign out who has been trained on what tool. All of the underclassmen learned to use OnShape by viewing and following a series of tutorial videos. We posed a design and build challenge for groups of 2-3 students to CAD and animate a prebuilt hydraulic arm.

Our main goal for our upperclassmen is to get the MK4i swerve drive built as quickly as possible to hand off to electrical and software for testing. We assembled our new MK4i swerve modules and designed a basic drivebase to house them. We have been looking into different types of wheels to use for our swerve drive to make it cheaper and increase friction. We have also been making 3D-printed motor covers for the swerve modules and camera mounts that are easily replaceable and cheap.

Goals for Preseason:

Train all students in basic shop safety
Train mechanical group members with all the tools in the woodshop
Familiarize all students with CAD software
Have co-axial swerve drive ready for testing
Test viability of different wheel setups for swerve

Goals for the Season:

Have prototypes built within the first week for software to experiment with
Have final design built within two weeks of the first competition for rigorous testing
CAD entire robot before the first competition

Electrical

Written by Cecilia Hetling, Captain

Our electrical group mainly focuses on three things: motors and drive, sensors and cameras for programming, and mechanisms for tasks. This year, we are emphasizing familiarity with different types of motors to have more options during the season, and knowledge of pneumatics, as 2023 was our first venture with them in 10 years.

For this season, we have some upperclassmen with a few years under their belt, as well as some new freshmen and sophomores who have been eager to learn throughout preseason so far. Training has been strongly focused on getting used to the electrical components on the robot and how they are wired together and introducing how the team uses various motors, sensors, and pneumatic components; our goal is that every electrical person can completely assemble a rudimentary electrical board all by themselves. In training so far, we have also covered pneumatic systems, an overview of sensors, and technical skills such as soldering, cutting, and stripping wires. We won’t know the complete layout of the board until the Crescendo challenge is announced and we have made decisions on drive and mechanisms, so for now, we are covering all of our bases to be ready to take on any challenge that comes during the season.

We have also been slowly adding to and editing our Electrical Information Database, which contains tools, sensors, components, pneumatics, and more, found here.

Electrical Goals for Preseason:

Thorough electrical training for all members to be familiar with primary board wiring and organization, sensors, and motor controllers, as well as a focus on how motors work & their uses
All members have an initial understanding of pneumatic systems and how they work on the robot
Have co-axial swerve drive ready for testing

Electrical Goals for the Season:

Have an easily accessible electrical board, using cable mesh and chain to provide organization.
Increase communication between mechanical and electrical subgroups.
Improve RoboRio and network switch consistency by opening up and cleaning components and soldering when connectors (notably, barrel jacks) are unstable.
Emphasize secure pneumatic wiring to ensure no leaks.

Team Links

THEBIGTHREE · January 2, 2024, 5:05am

Software Update 1 (Preseason Update) - Part 1

Hey everyone! I’m going to provide some updates on what software on 3205 has been up to in terms of training and new features. I will keep this mostly high-level, but in a few circumstances, I’ll dive into the code when I think the implementation details will be relevant/helpful for other teams.

Training (Training is part 1 of the update, rest of it in the coming days)

One of the most important things a team can do to improve its performance is better training! This year, we only have a couple of members comfortable with WPILib and robot code, so it’s been especially emphasized during the preseason. In fact, all of our scheduled team meetings (everyone meets on Tuesdays/Thursdays) have been spent on training, while new code is tested on Fridays: optional days where only a handful of software members meet.

We take a very hands-on approach to training. Students have been writing code from day one. We give assignments to each of our students to complete, leading up to some bigger project. Students work independently or in small groups, depending on interest and skill level. There have been 3 main projects that students are working on:

Mecanum Drive code
AprilTag detection/camera pose estimation
Object Detection
Swerve Drive code

The goal of the projects was to get students comfortable working on robot code and understanding the fundamentals of FRC software engineering.

These projects are meant as a training/understanding exercise and are separate from the development of our main code. However, they’ll build the foundational skills for the underclassmen to begin working on the new robot during the season. I’ll now give a little detail on what each project entails and their desired outcomes:

Mecanum Drive Code

This project was for newer students, writing working code for our old mecanum drive robot: including field-oriented driving and PID control of motors.

Task Progression (Step-by-Step Goals)

Use WPILib’s MecanumDriveKinematics class to take joystick inputs and translate them into wheel outputs → drive the robot
- Use Pheonix Tuner X to set CAN IDs, update firmware
- Actively maintain code on GitHub
- Measure robot specs (wheel radius, track width) and understand why they’re needed
Use WPILib’s ChassisSpeeds class and the NavX to implement field-oriented driving
Use WPILib’s PIDController and SimpleMotorFeedForward classes to tune kV and kP for velocity control of the motors
If time allows:
- Use WPILib’s MecanumDriveOdometry class to track where the robot is moving
- Write a simple autonomous routine, using positional feedback, to move 1 meter forward

Desired Outcomes

Understand how motors are controlled and the steps needed to get them to respond to code
Understand the importance of kinematics and their role in moving the robot how we want
Be comfortable working with vendor libraries/WPILib, being able to reference documentation and write code without strict guidance
Understand basic controls and how feedback and feedforward control are used and their importance in motor control, understanding different types of control modes
Future projects: coding mechanisms, prototypes

Having students write simple drive base code has proved to be a really great project for training! It’s not particularly difficult, but it’s super fun for students to be able to see what they code come to life and be able to drive it around. In addition, it exposes them to some of the key aspects of coding an FRC robot that they might not think of, like using motor configs in Phoenix Tuner/REV Hardware Client, the necessity for measurements like track width, wheel radius, and gear ratios, and how even if your code is “perfect” hardware might not behave the way it should.

AprilTag Code

This project was also for newer students with a bit more experience in Python and OpenCV: writing code to detect AprilTags and estimate the location of the camera based on detections.

Task Progression

Write a simple program in OpenCV to display the camera image, text, lines
Use OpenCV’s Aruco module to detect AprilTags on an uncalibrated camera
Use projective geometry to calculate the distance of the AprilTag based on camera FOV and tag size (after having a mentor/upperclassmen go over the math)
Use a checkerboard with OpenCV to calibrate a camera, getting camera intrinsics and distortion coefficients
Measure accuracy with a tape measure
(If time allows) Use OpenCV’s SolvePnP to estimate the pose of the camera based on AprilTag detections and camera coefficients

Desired Outcomes

Understand the basics of OpenCV and how to work with a library/write code based on online documentation
Understand some of the math that goes into AprilTag pose estimation to get an intuition for why difficulties arise (why depth measurements are more precise than horizontal, why accuracy decreases when tags are smaller on the screen, etc.)
Understand why camera distortion occurs and how it affects an image
Future projects: writing more robust AprilTag code, doing testing with different libraries/settings, working with a coprocessor to deploy code onto the robot

I was pleasantly surprised by how well the pure-math approach on an uncalibrated camera worked for estimating the distance; we were getting estimates within 6” at 15-20ft away. If anyone’s struggling with getting a camera calibrated and using PnP and just wants something simple to get started with, let me know, and I can post an explanation of the math/code we used; it’s very simple/short. (I would recommend taking a look at PhotonVision first, though)

Object Detection Code

This project was for more experienced/returning members and is actually a continuation of work that started during the season last year: writing code to detect cones and cubes on the field and estimate the position of the object. The task progression and desired outcomes, in this case, were much more focused on the end product, as it’s a full project that no one else is working on.

Task Progression

Use YOLO (object detection model) to detect the 91 standard objects in the COCO dataset and display them in an OpenCV window
Write code to work with the ZED camera (stereo depth camera) to estimate the displacement of the objects from the camera
Find/create a dataset for the model to learn how to detect FRC cones/cubes
If time allows:
- Run transfer learning (a process that starts with a “good” pre-trained model and runs additional training steps on a new dataset) using YOLO and above dataset
- Deploy code onto the jetson nano and send data over NT to the robot

Desired Outcomes

Understand how to use Ultralytics (the library that holds YOLO) and be able to work with online documentation/tutorials to write code without guidance
Understand how the ZED camera works, what stereo cameras can do/measure, and how we can use that information on the robot
Understand how transfer learning works and why it’s important for creating new models easily
Ultimately, write working object detection code!

A lot of the code the students wrote was first written in Google Colab: this allowed for easy collaboration and running code on Google’s servers rather than their school-provided laptops, which can’t necessarily run complex code; it’s a great tool, and I would recommend all teams using python for anything introduce it to their students. For code that needed a GUI and used a live camera (like the ZED), we used a laptop with an NVIDIA GPU. I would recommend any team trying to get object detection working consider getting a computer with a decent graphics card to run code on first. Coprocessors are great on a robot, but they can be extremely difficult to write/test code on. Having access to a laptop that could run object detection code made it much easier to debug the code first before putting it on a coprocessor and debugging the issues there.

Swerve Drive Code

This project was for more experienced students who still need training: writing working code for our new swerve base (separate from the main code). This was a big project for students, and I was less concerned with them understanding specific details (for example, why we use onboard PID instead of on RIO) than them understanding how each part interacts within the larger system.

Task Progression

(I made a writeup on getting started with custom swerve code for them to reference, here, which has a more detailed task progression and links for resources)

Learn a bit of the math/physics behind swerve and controls (intended for students with a strong maths background)
- Vectors & Basic calculus (3b1b)
- Linear and rotational kinematics (flipping physics review videos)
- Robotics geometry (twists/poses, WPILib docs)
- Controls & Feedforward/PID (WPILib intro to controls)
Configure/setup motors/encoders in code (set current limits, CAN IDs, get PIDF controller & encoder objects)
Write methods to handle getting/updating any relevant info from motors and to set setpoints for control loops
Write a class/methods to send setpoints to every module (same setpoint to each)
Create a command that reads joystick values and sends the proper output to the drive subsystem to set module setpoints
Move the modules! And tune PID/FF
Modify the previous command and drive subsystem to set different states to each module using SwerveDriveKinematics (i.e., robot-oriented driving)
Use the gyro to implement field-oriented driving
If time allows:
- Add AdvantageKit/logging to the project
- Track the robot’s position using odometry
- Add autonomous commands

Desired Outcomes

Be comfortable with how Swerve works under the hood, and understand how the physics affects certain parts of the robot (i.e., be able to convert a motor velocity to a wheel velocity and understand how that’s converted to a chassis velocity)
Understand how to work with vendor libraries/online documentation
Understand how a command-based project is structured, how to structure new classes/code in a large project and add them to RobotContainer
Understand motor control and how to tune controllers
Ultimately, have the skills to be comfortable understanding our current swerve and being able to make contributions to the main code
Future projects: whatever the latest project with drive code is

This process is super helpful if you’re just getting started on Swerve! Particularly, try controlling the modules individually (i.e., joysticks set module setpoints, not chassis setpoints) before attempting anything complicated with kinematics. It’s how I did it while writing our swerve code, and it’s worked great for training as well.

Conclusion

With that as our plan, I think we managed to stick to it very well! On most projects, the underclassmen are about 70% of the way through the tasks we gave them, and I feel that they’ve achieved most of the desired outcomes. For various reasons, it’s moved a little slower than I would have liked, but the 3 biggest reasons I saw were:

Many students, not many teachers – for the most part, it’s just me and the 1-2 software mentors running training, while we have ~10 software students to train on a given day. With many different training projects, I would often be bouncing between groups, and sometimes that caused slowdowns. In these cases, it’s important to have clear goals for your trainees so they don’t finish something and wait around for you to tell them what to do next.
Debugging is hard – One of the biggest tendencies I see in new students is to stop or start doing something else when they hit a roadblock because they don’t know how to get around it. Reinforcing good practices/steps to take when they get stuck is a great way to build better coders.
It can’t all be software (sad, I know) – we had a lot going on in the preseason, and some days there just wasn’t time to do software training. Whether it’s spending time doing outreach, having a guest speaker, or simply training our software members in other tasks (how to use shop tools, electrical info, what CAD is): all of this is critical that we can’t skip out on, so it’s important to organize and plan out all your meetings so you know how long everything will take and what you’ll have time for. You won’t be good at it at first, but the more practice you get, the more accurate estimates will be and the more efficient meetings will be. It’s often helpful to plan a week or two in advance, as well, so you can evaluate where your team is at and where you’d like to be and plan accordingly.

Due to being a little behind schedule, we’re going to continue “training” into the season. For some, this will be continuing/finishing their projects; for others, it may be transitioning to learning other things. One plan I have is to move the students working on mecanum code to working on how to code various mechanisms we’re considering using. For example, if we were considering an elbow or an arm, I’d have them write up code for each of them as a “training” project, though it’d still apply to the season, and we’d likely use the code if we were to choose that mechanism.

Overall, I think it’s been a great preseason, and training has gone well! I’m happy with everyone’s progress, and they’ve all done an awesome job. Excited for what 2024 has to bring (water game?) and confident our software members will be able to write great code for whatever it is.

Giant · January 2, 2024, 2:04pm

How did this work out for you? How do you see it potentially being used within a season effectively? You mentioned using an NVIDIA Laptop GPU, what would a co-processor deployment look like?

THEBIGTHREE · January 2, 2024, 4:47pm

We’ve found the ZED very easy to work with and very accurate. They have a fantastic API with solid documentation, and you can get a simple program running in a couple of hours. The main feature we use with object detection is the 3d point cloud: essentially, the API hands you a 3d displacement vector for every pixel on the image. In some initial tests, we found that the value was accurate within .5" in the short range (<2 meters) and stayed within 2.5" of error up to 5 meters. We didn’t do much testing past 5 meters, but the Stereolabs website cites “1% of the distance in the near range to 9% in the far range”.

In tests with detected objects, it was about the same. The main issue we ran into was that with certain objects, it wasn’t always easy to find a pixel value to estimate the depth. We had been using the center of the detected object, but for some (for example, a spoon), that wasn’t always on the object and would instead get the depth of something behind it. With most game pieces, this shouldn’t be a problem, but we’re currently trying a few different ideas to get around this issue.

In my next post, I’ll focus a bit more on what we’ve accomplished in software during the preseason outside of training, and I’ll add some videos and graphs with more details on this.

To me, the biggest problem it solves is autonomous object pickup. The main issue I saw this year with teams’ autonomous routines was that even if they were just slightly off, they could miss the game piece they’re trying to pick up entirely or knock it over. An accurate measurement of the object’s position could help solve this by, at the end of a path, switching to a routine that aligns with the piece before attempting pickup.

If it proves to be especially effective, it could even be used as an assisted-teleop mode, but we’d have to do a bit of testing to see if that would be a useful feature.

This will vary for every team. One strict requirement for the ZED camera is an NVIDIA GPU, which mostly restricts coprocessors to NVIDIA’s Jetson lineup.

We had been using a Jetson Nano 2GB model last year, which was able to run object detection models and the ZED at ~10fps. We used MobileNetv2 instead of YOLO, which has some more lightweight models that worked a bit better on that platform. It’s only ~$50-100, and works well, but I would caution against it unless you have someone on your team experienced with linux and preferably the jetson platform. The original Jetson Nano is pretty old and has reached EOL, and while there’s plenty of resources online for using it, it has outdated kernels and I spent a lot of time last year just getting libraries to work properly.

This year, we’ve purchased a Jetson Orin Nano ($400, with an education discount), NVIDIA’s newer version of the original nano. We’ve just gotten it, so I can’t quote any performance specs, but it should be significantly faster. So far, I’ve found it much easier to work with due to its up-to-date firmware/software.

If you don’t want to use the Jetson platform (which means no ZED) and just want to do object detection, there are still plenty of options. The Orange Pi 5 ($80-120) is a great coprocessor for vision and even has an NPU (Neural Processing Unit), and could probably run lightweight object detection models. In addition, the Coral TPU ($60) is a USB accelerator that can plug into a coprocessor like an Orange Pi or even a Raspberry Pi to run object detection models.

You should be able to find specs and object detection performance for all of those online if you want more details.

ssaak · January 3, 2024, 6:38pm

Team Preseason Update - Training

This preseason, we took a new approach to training with a long-term project for all of our returning and new members. We created a “Hoop Challenge” project inspired by Rapid React, where groups were tasked with designing and building a mechanism that could rotate and launch dodgeballs into an 8ft high hoop. The main goals for this project were:

Inspire collaboration and teamwork between our mechanical, electrical, and software subgroups
Give members a way to apply the skills they learned during training
Have members begin thinking about the design process and manufacturing in a competitive situation

Starting in mid-October, our preseason training was broken into one day of subgroup training and one day of Hoop Challenge work, except for software that focused on subgroup training projects each day after the first few weeks.

Hoop Challenge groups were evenly composed of members from all grades and experience levels, with students who have knowledge in mechanical, electrical, and software in each group. As a team, we also reviewed basic mechanisms commonly used in FRC. Each subgroup used the project to hone different aspects of training:

Mechanical: CAD, use of power tools for prototyping, assembling a gearbox, designing and building mechanisms such as flywheel shooters and catapults
Electrical: building a simple electrical board, working with DC motors
Software: April Tag detection, flywheel control

In the end, we ran into a time crunch, but our two Hoop Challenge groups each finished building flywheel shooters.

What we learned:

Timing is hard: Due to longer subgroup training sessions and special events, we did not have as much time as expected for groups to finish the challenge. This led us to reorganize some of the challenge’s priorities, such as removing the pivoting base and simplifying the goal to be shooting the dodgeball in the air. However, we would reassess our timeline each week and make edits based on the group’s progress, which is great for staying organized.
How to choose a plan: Our groups struggled with finalizing a design and starting physical prototypes. There was a lot of hesitancy in many team members, especially new members, to commit to an idea, but everyone learned how to jump into building once they had an initial plan and tested out their ideas with physical prototypes.

What we would change:

Larger groups: We started out with 4 teams, but as each group struggled, we merged groups into two final teams. Having 2 teams allowed for more collaboration and faster progress with more people working.
Task breakdown: We found that the task of pivoting and shooting was too complicated for the time frame we had. All our groups struggled with getting started and wrapping their heads around the whole design, so we pivoted part way through to simplify the task. We created a Hoop Challenge checklist that broke down the specific steps of the challenge, including attaching two pieces of wood, practicing using the power tools, building the first prototype, and wiring an electrical board. This checklist was really helpful for groups to assess their progress and to stay motivated with short-term goals.

Team members learned a lot about applying their training and rapid prototyping––and definitely had fun!

chetling · January 19, 2024, 12:37am

Mechanical First Week Update
1/7/24 - 1/15/24

Flywheel (“Kitbot”) Shooter:
We made a flywheel shooter with one 4” diameter flywheel on each side, compressing the ring 4” total. When one wheel was spun at full speed (~2500 rpm), the “note” traveled only a few feet. We changed the spinning wheel to a 6” diameter wheel (compressing the note 5” total), and when spun at full speed, the “note” traveled further but not far enough.

So, we drilled a new hole for a bearing so that two wheels (6” diameter) could be on the same side, and removed the bearing on one side to put a 2x4 plank that acts like a wall. The wheels are connected by a belt, and one wheel is spun with a drill. The wheel was spun at ~2000 rpm, and the note flew pretty far with a good speed.

The next day we screwed in the side panel, added bearings to the bottom of the base, and added collars to each side of the hex rods. We also discovered that the flywheel shooter can intake and shoot in the same motion through the gap on the side. When testing the shooter, the friction generated between the wheel and the bearing melted the plastic.

Improvements/Next steps:

Add spacers between the bearing holders and the wheel to prevent melting
Maybe start thinking about how to push a note into the amp
Attach bearings to the bottom side of the base, lined up with the previous two.

Pneumatics:
We built a pneumatic prototype testing using the FRC pneumatic manual and two power supplies. We were planning on using a pneumatic piston to shoot the ring into the speaker. We tested our prototype with one piston at 100 PSI and found that it did not shoot the ring with much power. We are still planning to continue working with pneumatics.

Improvements/Next Steps:

We may alter our design to try to shoot into the amp next week.

Omni Wheel Shooter:
We had an idea for a shooter with Omni-directional wheels that can shoot into both the speaker and the amp. The idea is that it shoots one way for the speaker, and then it shoots 90º the other way to the amp.

We started making a prototype using six 6-inch Omni wheels
We quickly abandoned the idea as it was going to be too bulky, especially on the end of a one-jointed arm

Improvements/Next Steps:

We may try the same idea with pneumatics powering the amp shooting using the Omni wheels solely for stability in that direction rather than powering them with motors.
We also will probably try using smaller Omni wheels; we don’t have any right now, but we’re thinking about 3d printing some for testing

One Jointed Arm:
We made a one-jointed arm for testing aiming at a specific target with a laser pointer while on the swerve drive. We also plan on mounting some of our flywheel shooters on it to see if it’s a viable tactic to use pickup from the ground and then turn and shoot into the speaker/amp.

Used a Falcon 500 motor with a 100:1 gear ratio to decrease the RPM of the arm
Mounted a laser pointer at the end of it for testing

Improvements/Next Steps:

Mount the mechanisms on top of the arm and see how they perform together
Adjust the location on the robot
Build a handoff that works with the arm

Field Elements:
We disassembled last year’s field elements, constructed the amp, and started on the speaker. A few days when we didn’t have as many people we prioritized field elements as it was something that took us a lot longer than it should have last year.

Monday, January 8th

Disassembled last year’s field elements
Started measuring pieces for the amp

Tuesday, January 9th

Measured and cut pieces for the amp

Wednesday, January 10th

Finished cutting pieces for the amp
Started assembling the amp

Thursday, January 11th

Finished assembling the amp

Friday, January 12th

Started measuring and cutting pieces for the speaker

Finished Amp:

Wheel · January 24, 2024, 3:14am

Mechanical Second Week Update
1/16/24 - 1/19/24

This week was odd since it overlapped with our school’s midterms, so we didn’t have as many students as usual. Because of this, we built fewer prototypes and spent more time on design discussions.

Over the bumper One bar intake:
We began to prototype some intake systems for our robot since we wanted to find a way to pick up notes from the floor and the station. Our first idea was to make an intake similar to the one we made for our robot back in 2022. Just have one bar that will flop over the bumper and pull notes into our flywheel shooter.

2022’s intake:

We quickly ran into some issues when we began to test with one bar and the note. The note wouldn’t be pushed into the intake but was being pushed down and getting stuck. The notes wouldn’t go into the intake unless we pushed them into the flywheels. The material we tested on the bar also had very little friction with the notes, so we will swap them out for one with more grip.

Improvements/next steps:

Build a second bar that will guide the note better
Use compliance stars on the bar to intake the note like a combine harvester
Test different angles to intake the notes from the floor

Over the bumper Two bar intake:
This second version was an iteration of the One-bar intake. We added a second axle running across with each having compliant wheels all along them. This version did a much better job of intaking the notes quickly as soon as they touched the wheels. However, our current design is very bulky, so the next steps would be to cut down the wood around the axles or make a different version with less excess material that could be mounted to a one-jointed arm on the robot.

Improvements/next steps:

Test intaking at different angles
Edit this version or create a smaller version that can be mounted onto an arm on a drive base for testing

Under the Bumper intake:
We played around with the idea of an under-the-bumper intake to take in notes. We made it with two wheels slightly above the floor and would pull the notes onto a ramp. Then, the note would go into some flywheels at an angle to bring it into the shooter. We finished building this prototype on Friday, so we still need to test it for effectiveness.

Improvements/next steps:

Test at different angles
Mount on the drive base to see if it can intake easily after driving over a note

Field Elements:
We are almost finished building the speaker. We assembled the main box part of the speaker, but we still need to put the hood on the front of it.

ssaak · February 13, 2024, 7:39pm

Hardware: Mechanical and Electrical Update

We are moving forward with our refined prototype designs and working on getting them mounted on drive bases for testing!

Shooter and One-Jointed Arm

We have continued working on our one-jointed arm and shooter mechanism this week, and have begun building a prototype out of aluminum and acrylic. Right now, we are building the shooter with colson wheels, but plan on testing different roller/wheel options in the future. Still waiting on some parts in the mail but it is almost ready to be assembled.

This shooter will also have an over the bumper intake on the end to pick up notes, but we will also be experimenting with the length of the arm and possibly using a hand off from an under the bumper intake instead.

Under-the-Bumper Intake

Our prototyping with the under the bumper intake has also continued this week. Right now we are finishing up mounting and testing a two roller intake on an old tank drive base, and then will be moving towards a two roller under the bumper intake that is in front of our swerve modules.

Hanger

We also began working on our hanger this week, and started collecting and cutting parts to make a stage two Andy Mark Climber in a Box. We also laser cut various hook prototypes and tested what worked best hanging on the chain.

Field Elements & Other Mechanical Work

With the rest of the hardware group, our field elements team has been working on completing the Station and Stage this week, adding to our completed Speaker and Amp, and we are excited to start testing these prototypes out!

We also 3D printed some covers to protect the swerve modules while we’re testing and for during matches.

Electrical

This week in electrical, we made an electrical board that we can move between the tank base and the mecanum base to test prototypes with both while continuously doing testing on our competition swerve base. The board has simple wiring as it is just for testing.