Hi all! This past week we have been focused on refining our CAD,
ordering parts, and generally preparing to move forward towards more
hands-on manufacturing and assembly.
CAD Polishing and Design Review
Our team’s CAD experts have been hard at work polishing up our robot
CAD and finalizing the last elements of our design. On Tuesday we held a
design review with both the programming and mechanical teams to review
the CAD and ensure everyone is on the same page. This consisted of the
Solidworks CAD being presented with a few mech members going through the
design choices of each subsystem. Speaking of design choices, let’s
highlight a few interesting ones.
Flywheel motors
We’re using Vortexes for our flywheels, and, to keep everything
within the launcher frame, we decided to put the motor itself inside a
few of the wheels. We’ll see how well the Vortexes handles the
temperature dissipation constraint of being wrapped in a rubber wheel
once our robot is up and working.
Tensioned Rollerbar Belts
We’re using RoboBitz’ RoboRollerz for our indexing up until the
launcher flywheels. All the rollers are driven together via belts and
gears. The belt path is shown by the thin gray lines along the rollers
in this CAD screenshot. The two wheels next to the middle roller aren’t
completely fixed along the vertical axis. If you look closely, the slots
they move along are visible. All this should help keep our belts
tensioned.
Pivot
Our pivot geometry ended up a pretty interesting this year due to
space constraints caused by the location of our swerve modules. We also
employ a tensioner here for the chain. This pivot design is pretty
similar to the one used in the arm of our 2023 robot, Crane.
Programming Updates
We’ve also been progressing along on the programming team.
LEDS
We’re now looking to add an LED strip to the robot. We’ve realized
that with our under-the-bumper intake and with field elements heavily
restricting driver vision, we need some way to signal to drivers that
the robot has successfully picked up a game piece. We’d also like to be
able to signal to human players which amp buttons we’d like them to
press.
Logging
We’ve also been focused on adding additional logging and
configuration to all our subsystems. We’re trying to reduce the time we
spend tweaking values during tuning. The last few years, we’ve had to
redeploy code over and over to adjust things like PIDF values. This
year, we should be able to do all that tuning through Shuffleboard. To help with this goal, I wrote a sendable wrapper class for the Spark Max PID controller.
That’s about all the updates I have for now. See you in the next post!
We’ve dived deep into the development process. We’ve made good progress with our CAD, our code, and our physical prototypes.
More prototype progress
For quite a while, we were stuck with our launcher prototype. It
wasn’t shooting consistently, with the notes occasionally flipping in
the air and with irregular trajectories. Eventually, however, we did
discover a few issues. First, we added another set of rollers before the
flywheel. These additional rollers improved the consistency of the
note’s angle as it entered the flywheel. They ensure the note is level
relative to the flywheel. Next, we actually tuned PID
for the flywheel. This helped us ensure consistent testing as the
flywheel’s speed was more predictable. Finally, we reduced the
horizontal compression of the note. It’s now only compresses the note
1/16th of an inch on either side of the launcher. With less compression,
the note maintains a more circular shape as it proceeds through the
launcher.
Our launcher is now much more consistent
We also tested out our launcher’s amp scoring capabilities. Inspired
by Team 4481 Team Rembrandts, we decided to try out scoring into the amp
by reversing some rollers. This method worked pretty well with our
design.
With these tests, we found our flywheels would push the note up
towards the top of the amp and keep it from scoring down. However, once
we moved away, the note did fall right in.
CAD Progress
After inspecting a bit more climb geometry, we realized that our
selected climb design would have difficulties lifting our robot high
enough to allow our launcher to score into the trap. We’ve also been
paying close attention to threads here on Chief Delphi discussing
shooting into the trap from the ground. With these developments, we
decided to pivot on our climb decision. Rather than employ a separate
climb subsystem, we’re attaching two hook systems to our launcher. We’ll
use two pivots off our launcher with hooks attached at a distance.
We expect to be able to reach at least 3 feet from the ground with
this design, allowing us to climb along most of the chain. We also
expect this design to allow at least one other robot to climb along with
us on the same chain, although having all three robots on the same
chain seems unlikely. We plan to shoot into the trap throughout the
duration of the match. Once we have our stage built, we’ll do some more
launcher testing with it, and we hope to achieve decent accuracy.
Code Progress
Our programming team is progressing along well. Our programmers are
split between subsystems right now. I’ll include details on some of the
interesting developments
Drivebase
We’ve continued our experiments with Choreo and PathPlanner for
autonomous. We created a few diagnostic paths for us to tune our
odometry and PID
on. These paths consist of a marked starting location (we use a tape
square on our field), a difficult trajectory (mostly spinning or
capricious translation), and then a return to the start location. Using
these paths, we can identify what kinds of movements mess up our
odometry the most. Then, we plan to identify methods to reduce odometry
error.
This xsin(x)-like path really did a number of our odometry.
This path featured lots of rotating which messed up our odometry a lot.
Vision
This year we’re not only continuing our AprilTag vision exploration,
we’re also branching into object detection with Limelight’s neural
network interface. We plan to include AprilTag cameras on the front of
the robot (the same side as where the notes are launched from) and our
Limelight for object detection on the back of the robot.
Since we’ll generally be facing our targets when lining up to launch,
we decided on only placing AprilTag cameras on the front of the robot.
This might come back to bite us if this isn’t enough data for accurate
odometry correction, but we’ll see.
We also decided on really only using object detection for our
autonomous pathing. We plan on using object detection to both improve
our pathing toward game objects, and to see if game objects are really
there before we path towards them. Since this game has a set of game
pieces that are accessible by either alliance, we want to make sure the
game pieces are really still there before we spend time moving towards
them. If game pieces have already been taken, we’ll instead switch to a
different autonomous trajectory. Since we expect to always be facing
towards the speaker during auto and therefore the center line game
pieces will always be facing the back of our bot, we decided to only put
game object detection cameras on the back of the robot.
Climb
Previously to our decision to nix the separated climb subsystem, we
had a climb programming group. Now that climb is integrated with the
launcher, we’ve moved those programmers into our intake group. They’re
helping integrate sensors into the design.
Okay, that’s about all the updates I have to share. More to come soon!
Our second week into the season saw lots of discussion from our robot
design team in selecting our robot design as well as the completion of a
new launcher prototype.
New Launcher Prototype
After our first robot design team meeting, it became apparent we were
really leaning towards selecting a horizontal roller launcher design.
However, we realized that we hadn’t quite prototyped that kind of design
yet. So, before we locked in on it, we decided to create another
prototype to confirm the idea.
This prototype features another set of wheels before the flywheels to
stabilize the note as it is launched. We also played around with using
uneven wheel sizes to add some spin to the note, although this prototype
does not implement that idea.
Altogether, this prototype worked quite well with it being able to shoot consistently at a good distance.
Our robot design
Our robot design team met several times this week and spent a lot of
time discussing our robot’s design. Due to illness and our uncertainties
regarding a climb design, we were slightly delayed, with the final
robot design only having been decided this past Saturday.
Let’s start with the intake.
We decided to go with an under-the-bumper design based on one of our
earlier prototypes. Our swerve modules are lifted, allowing notes to
pass under our bumpers and be picked up from our rollers. We use four
driving rollers on each side of the robot, allowing our robot to pick up
notes from all sides. We also plan on using these driving rollers to
reject notes once we have one stowed.
Next, our launcher.
Our launcher design is very similar to the prototype we created
earlier in the week. We’re going to attach our launcher to a pivot so
that we can both aim our speaker shots and make our amp shot. To make
the amp shot, we’re planning on using a hood or some other retractable
system to redirect the note into the amp.
Scoring into the amp will look a bit like this, with the launcher pivoted up 90 degrees towards the amp.
Pivoting the launcher to aim into the speaker
Finally, our climb
Our climb design is inspired by FRC 95’s 2022 climber.
Although not pictured in this mockup, the climb will use torsion
sprung arms regularly held down by a string attaching the hook of the
arms to the drivebase. When we want to climb, we will extend the string,
allowing the arms to extend up towards the chain. Pulling the arm back
down with the string will complete our climb.
We’re hoping to ensure that our climb will bring the chain at the
same level as our launcher pivot. Doing so should allow us to launch a
note into the trap by first opening the trapdoor using our hood and then
using the same hood to redirect the note similar to how we expect to
score in the amp.
There’s our robot design! We’ve started CAD and programming work for
each of the subsystems. One of our goals this year is try and reduce the
time between concept and physical, working subsystem, so hopefully in
future OA updates you’ll see these subsystems come to life soon! See you then!
We just finished our prototyping over here at the Robototes. This
post will cover all our insights, troubles, tribulations, and more that
came with prototyping! Hopefully teams that have not yet decided their
final designs can learn a thing or two from us.
Prototyping Philosophy
We try to prototype only for problems that we haven’t dealt with
before - like how to interface with a game piece or element. We don’t
prototype things like a telescoping arm or other systems that we already
have experience developing.
At the start of the week, we split into 5 mechanical prototyping
groups plus one programming prototyping group. I’m going to go over each
group one by one.
Shooter
This prototyping group focused on creating a feasible shooter design
for our robot. After some discussion, they settled on starting with a
design similar to the shooter featured on the kitbot.
The shooter group’s first prototype
After this initial prototype, they iterated by replacing the wall
with more wheels. Then, they drove each side with NEO Vortexes. They
experimented with using solid rubber wheels, but accidentally found that
the wheels simply couldn’t handle the RPM.
Unplanned rapid disassembly of the solid rubber wheels
Ultimately, using compliant wheels with 5 inches of compression
proved very effective with this prototype. One side was driven at a
slightly lower RPM
so that the note would have some spin as it exited the shooter.
According to their testing, roughly 5-10% difference in power between
each side was ideal for stability. The distance traveled by the note was
consistent although sometimes the note would drift sideways in the air.
Shooter + Amp
The next prototyping group was directed to create a design that could
score in both the speaker and amp. However, pretty soon the group found
that its concepts could also be applied to work as an intake as well as
a shooter. Their first concept involved an under-the-bumper
intake-shooter combo attached to an arm that could raise to score in the
amp.
One of this group’s initial prototypes, with a reminder to always
wear safety glasses. This video was posted as one of our Instagram
reels and as of now has 12.4 million views!
However, the group found that the rollers would accelerate too slowly
when the note was loaded to function as a shooter. Their next designs
continued their concepts of an intake-shooter combo, but these designs
allowed for a note to be held away from the wheels to allow them to spin
up before the note is sent through. These designs also did away with
the arm.
This design intakes from all sides of the robot. Before the notes
are shot, they are held against the ground in the center of the robot.
Lift kits are used on the swerve modules to gain a few extra inches of
clearance. While the group did test scoring in the speaker with a
similar design, scoring in the amp was never tested.
This prototype is similar to the final CAD model’s shooter and worked well
Intake + Amp
This group’s assignment was to prototype a design that could function
both as an intake and as an amp scorer. Their first idea was to use two
sets of rollers with tread between them to intake and hold the notes
until they could be scored in the amp. This design would be attached to a
pivoting arm to allow the height required.
This group was tasked with coming up with an optimal intake design.
They choose to go the under-the-bumper router, using rollers and
compression to lift the note off the ground.
In testing, their design proved effective in picking up notes
In this render, you can see where the top of the bumpers are
relative to the intake. In a best-case scenario, there is 2.5 inches of
clearance between the bottom of the bumpers and the ground.
This group also experimented with how their intake design could integrate into a larger robot.
With or without an index, the design feeds notes into a shooter
similar to the one prototyped by the Shooter group. The shooter is
attached to a telescoping arm with a pivot to allow scoring into both
the amp and the speaker.
Climb + Trap
Since we didn’t have a chain to reference yet, this group had trouble
actually coming up with things to prototype. In the end, most of this
group was dissolved into other groups with few members sticking behind
to come up with insights and concepts that could later be applied to the
real robot. In the end, they recommended using two climb-in-a-box kits
with high-grip hooks to lift the robot up on the chain. For trap
scoring, they recommended the arms be off-center, so the robot leans
into the core of the stage. To open the trap, they suggested some kind
of linear actuator that interfaces with whatever scoring system is
chosen. They also found a Ri3D team that had a similar climb design as they had brainstormed. 2
Programming Prototyping
While most of our programmers join mechanical prototyping groups to
advise their work, a few programmers stayed behind to research new
programming concepts.
This year, our programming prototype group focused on researching Yet Another Generic Swerve Library (YAGSL) 1, pose adjustment with AprilTags, and game piece detection using Limelight’s new neural network features.
Since coming across YAGSL, our programming group has wanted to try it
out. The first year we used swerve, we used Swerve Drive Specialties’
swervelib to drive our modules. Last year, we switched to WPILib’s
swerve implementation. In both those cases, our drivebase code ended up
moderately messy. We were really hoping that by switching to YAGSL we
could cleanup our side of drivebase code and leave the nitty-gritty
details to YAGSL.
Game piece detection was quite quick to setup. We used our v1 limelight with Coral’s AI accelerator 3
to speed up the game piece detection. At the end of the week, we were
working on generating paths to drive the robot directly to the game
pieces, but we weren’t quite able to finish in time. We’ll continue
exploring this further into the season.
That just about wraps up this massive update! See you soon as we continue into build season!
We started our kickoff bright and early Saturday morning, tuning in
to the game reveal livestream. After the livestream, we split into
groups to analyze the game manual. There were five groups; Two groups
for game rules and a group each for robot rules, scoring, and endgame.
Each group read through and discussed the game manual, then created a
PowerPoint presentation on it. Once all the groups were done, we
presented our presentations to each other.
Reading through the game manual
A game rules presentation
After our presentations, we took a break for lunch. Of course, the
game analysis doesn’t stop during a break. Most of our conversations as
we ate were still focused on the game.
After lunch, we moved on to an activity that’s become somewhat of a
kickoff tradition on the team. In order to better understand the game,
we play a match of that year’s game using our bodies as robots. We get 6
team members to volunteer and act as robots while the rest of the team
makes observations on their dynamics. This year, since we held the
activity after lunch, our “robots” had a lot of energy and maybe got a
bit too into the competitive side of the activity, so, while lots of
fun, we didn’t glean a ton of useful observations.
Next up, we separated into new strategy brainstorming groups. Similar
to our game analysis groups, these groups discussed potential game
strategies, then created a PowerPoint presentation on their findings.
One group’s thoughts on teleop strategy
Another group’s thoughts on the game
For most our team members, after we finished up our strategy
presentations, the day was over. However, for those on this year’s Robot
Design Team, there was still plenty of work to do. The 2024 Robot
Design Team is comprised of 6 veteran technical students and 6 mentors
and is tasked with choosing the final robot design. As soon as strategy
presentations had concluded, the design team started discussing our
plans for the coming week. We first determined our robot priorities. We
identified a floor, touch-it-own-it intake as a high priority alongside
reliable speaker scoring. Next, we decided what we planned on
prototyping in the coming week. We decided on five prototyping groups,
consisting mainly of intake and shooter variations alongside one group
prototyping solutions for the stage and trap. Finally, we ended the
meeting making some decisions on what needed to be purchased
immediately.
Overall, Saturday’s kickoff was a great start to the season and we here at the Robototes can’t wait for the meetings to come!
We’ve been super busy these past few weeks. So busy in fact that I
wasn’t able to post last week! Therefore, this post will contain two
weeks in one.
Bordie Charged
The weekend of the 14th we had an absolute blast hosting our 3rd
annual Bordie Blast offseason event! We were ecstatic to host 27 FRC
teams with 32 robots in all. We hope all FRC teams who participated in
the event had a great time, and we’re looking forward to hosting our 4th
Bordie Blast in 2024!
We were so proud of our media team which managed to produce the
event’s recap video in less than 48 hours. Check it out here if you
haven’t already seen it!
Bordie Charged was the first offseason event we have participated in
this year. We were super happy with both the performance of our
competition robot Crane (Captain of the Finalist Alliance) and our
practice robot Hummingbonk. We’re also planning to attend Girls Gen
hosted by Team 2046 Bear Metal this weekend 10/21-10/22 and Block Party
10/28-10/29 hosted by Team 2910 Jack in the Bot.
If you attended or watched Bordie Charged this year, we would really appreciate if you would take the time to complete this survey! All the questions are optional. The feedback will help us plan an excellent Boride Blast 2024!
Wrist Woes
Unfortunately, our wrist was damaged during Bordie Charged. Several
of the polycarbonate plates connecting the wrist to the arm were cracked
and had to be replaced. We used our OMIO CNC machine to cut the
replacement plates.
Fortunately, this meant we had the pleasure of experiencing that
sweet sweet sound of peeling polycarbonate protective plastic. We even
recorded the sound for this OA post.
New Motor Purchasing
The Kraken X60 and Neo Vortex drops spurred our team to excitement
the last two weeks. We’ve spent a long time discussing new motor
purchases and have just come to a decision recently. We ended up
deciding to purchase only 10 Kraken X60 motors. We poured over the motor
data for the Kraken, Vortex, Falcon 500, and original Neo brushless
motors, and found that the Kraken’s performance was pretty much
unmatched.
While our interest has been piqued by the Vortex’s interchangeable shaft
system, we believe it’s best to wait a year to see how this feature is
really used in competition and how useful it ends up being. As such,
we’re only purchasing the Kraken motors at this point. Our plan is to
use the Kraken motors as propulsion motors for our swerve drive, and use
Neo motors as the steering motors. We purchased 10 Neo motors prior to
the new motor releases, so we believe it’s a good idea to use those
rather than purchase additional motors.
The final analysis slide of a FRC motor comparison PowerPoint presented to our leadership team
That’s all the highlights from the past two weeks! See you next week for another OA post!
We, the Robototes, are outraged by institutional racism against the black community in our country. We feel it is our obligation to fight to end racism and the injustices it brings. We will not stay silent. We are fighting for human rights and the unity of humanity. We must use our voice to help educate and spread awareness of the inhumane acts of violence being committed towards black people within this country. Black Lives Matter.
Let’s say their names: George Floyd, Breonna Taylor, Ahmaud Arbery, Tamir Rice, Trayvon Martin, Eric Garner, Sandra Bland, Oscar Grant, Althea Bernstein, Walter Scott, Mya Hall, Devid Felix, Tony Robinson, Samuel Dubase, Dante Parker, Amir Brooks, Devin Howell, Kendrick Brown, Lavon King, Kalief Browder, Dante Parker, Tyre King and many, many more...
When we say black lives matter, we aren’t saying all other lives don’t matter; rather, we have to help those who really need it. All lives can’t matter until black lives matter. For hundreds of years, our black brothers and sisters have been oppressed and silenced from slavery to segregation to systematic racism, and it needs to end now.
“If one house is on fire, doesn’t mean we should spray water on all of them.”
We recognize that our team hasn't spoken up about these issues. However, we are working to remedy this by working both in our team and our community to increase equity, especially in terms of STEM learning. Please check our website for more information.
On Saturday and Sunday, we competed in our first competition of the year at Glacier Peak High School, hosted by the Sonic Squirrels (team 2930). We were very excited to compete with Harry for the first time, despite a few programming errors. We loaded in our pit and robot on Friday and got through inspection on Saturday morning.
We played the first match of the competition on Saturday, which unfortunately ended with our robot getting disabled. However, the day improved from there as we worked out some code problems and made a few mechanical tweaks. Other team members focused on our Chairman's presentation and scouting as well as watching our matches (and cheering, of course!), and we were able to finish out Saturday with a record of 5-4.
Hanging out with our #Bellevue Alliance friends
On Sunday we continued improving our robot, finally getting our climb system working! This was exciting for everyone on the climb subteam as well as drive team, as we were finally able to climb during one of our matches. However, we still faced several difficulties (our Ethernet port broke!), as well as a difficult match schedule, and went into alliance selection with a record of 6-6, ranked 22nd. A few team members also spent Sunday morning giving the "sales pitch" to teams in picking positions, hoping to ensure that we would be invited to join an alliance.
During alliance selection, we enthusiastically joined the 3rd seed alliance, led by Team Pronto (3070) and Murphy's Law (4681). Unfortunately, we were defeated during quarterfinals by the 6th seed alliance, which included event finalists Spartabots (2976), Sonic Squirrels (2930), and The Roboctopi (4918). However, we were happy with our performance, given the issues we were having at the beginning of the competition.
We enjoyed the rest of the elimination matches (interspersed with the occasional dance break) and got a welcome surprise: during the awards ceremony, our team was presented with the Entrepreneurship Award due to the hard work of our Business team! After the competition ended, we helped the volunteers tear down and pack up the field, and then retired to Red Robin for a well-earned meal.
Our Business team with their well-earned award
We're looking forward to competing at Auburn Mountainview next week, hopefully with an improved robot and some drive practice.
We've been working on finalizing our robot, from connecting electronics to mounting our final subsystems. We've had to work through several mechanical and programming setbacks, but so far, have managed to find solutions to all of them. Everyone on our team's getting a little tired and stressed since competition is so soon (it doesn't help that we've been staying in the shop until 9, 10, or even 11), but we're excited about everything we've done so far.
