2023 Offseason Part 1!
2023 Season Overview
After dissecting our 2023 season, which we were not satisfied with (and thanks to the record over time thread, can be pinpointed as our teamâs lowpoint 
),
we concluded our key failure points to be:
- Poor organization and time managment. E.g, failing to adapt to unforseen obstacles.
- Naivety\unjustified confidence.
- Overcomplication.
- Poor integration of robot-subsystems.
A warning by example of some of what went wrong is the case of our pretty good intake
Starting off the season, one of the main objectives we wanted the robot to achive is being able to pickup from the floor both cubes and cones at any orientation. This proved to be much harder than initialy thought. Fairly early-on we had an intake prototype that could pickup both game pieces, however the cones had to be in certain orientations - thus not meeting our criteria.
The critical error made was our failure to adapt and compromise our initial robot startagy!
We fully commited to improving our intake, and the time and effort put into it led to neglect in development of other systems and their integration.
In the middle of week 5 we had an intake we were satisfied with, but the robot as a whole didnât make much sense, an overcomplicated and impractical machine, way too many operations and steps a gamepiece had to go through before being scored.
Even when fully functional (which most of the time it wasnât), the robot still wasnât efficient.
Going forwards, we knew we had to make major changes. We decided that the best way for us to test our new work methodology (which Iâll get into soon) would be making a completely new robot for the Israeli offseason competition in October.
Offseason Progress | Trust the Process
The New Workflow
We set out to find a professional project management system that we could alter to fit the workflow and enviroment of the FRC season.
We ended up applying an altered version of the popular software development framework SCRUM
some key points of our new methodology:
- A daily updated task backlog up on display for the team through a stylish kanban board. All team tasks are displayed in the entrance of our workshop, color coded by subteam. (Weâre also working on maintaining a digital version of the board)
The goal is providing full visibility and transparency, maintaining organization, and
helping us grasp the big picture while following the little details. (Each subteam still maintains itâs own workflow process, now itâs just further organized and open for the entire team)
-
Stand-up meetings - at the middle of every workday, the entire team conducts a stand-up meeting. Everyone stands up as each subteam head goes over that dayâs progress, what got done, what problems they were having, and whatâs the rest of the dayâs work plan in going to look like.
The goal is keeping the whole team updated with whatâs going on, and allowing quick,
thought-out, orderly adjusments throughout the day. The reason everybody is
required to stand up is to get into a similar mentality, maintain high energy, and
prevent the meeting from taking too long - the idea is to get back to work quickly.
-
We are also looking to add retrospective weekly meetings - going over what went on over the work week, things that went well, things that held us back, and planning the steps forward. We have yet to implement this step but see us doing so in the near future.
It was very important for us to develop a culture of open, constant communication. We see it as the cornerstone of a successful, healthy team.
Onto the Robot
We put emphesis on taking advantage of the plethora of great robots from the season, âcopy the best - invent the restâ. Aiming for a competitive yet simple robot, which after strategizing was filtered down to two potential robot types:
- A small fast and efficient cube only shooter - throughout the season this archtype seemed to overperform relative to itâs simplicity.
- A robust all-around scorer, with minimal yet exisiting floor pickup. A âlightâ, compromised version of some of the more dominating teams this year.
We decided to go with option B for two main reasons. FIRST, we had many references for this kind of bot - we knew we could rely on the great works released by teams.
Secondly, we wanted to take advantage of this not being a real season and take on the new engineering challange and learning opportunity which was more apparent in the second bot.
We went ahead with the task of joining the angled elevator gang, heavily inspired by 1678âs great machine which they admirably shared with the community.
For the sake of simplicity and realism we opted for a few changes:
- No rotating\moving segments on the elevator.
- No climbing mechanism.
- Reducing intake width, and fully containing it in the frame perimiter.
And on we go toâŚ
Prototyping
Just because weâre mimicking others doesnât mean we can skip straight to final design 
We prototyped two somewhat similar rollergriper concepts we knew should work, the challange in both was finding the right measurments.
3 Rollergripper intake:
We knew this could work - and work well. However, since our intake doesnât rotate, we had to make sure the geometry was just right.
Prototype was already promising! However, when attepmting to intake a cone while moving fast, it just wouldnât get picked up.
We noticed that when ramming into the cone, the difference between successfully picking it up and failing came down to how the cone contacts with the lower rollergripper - the gap was just barely too tight.
Our solution - switch the center wheel of the lower rollergripper to a smaller one.
Rationale:
- Increasing the gap could lead to a weaker grip on the game cube, we didnât want that.
- We couldnât move the lower rollergripper backwards without changing the position of rear rollergripper because the âdepthâ distance between the two is minimal - moving just the lower rollergripper back would make the cone not contact it entirely!
- Since our intake is narrow the cone always enters in a similar fashion, the cone always contacts the same area of the lower rollergripper.
Resulting in Version 2.0!
Notice the smaller grey wheel in the center. So how did it perform?
We were satisfied. A small issue came up with how our cube indicator sensor was placed, after some testing we opted to use motor current as our possession indicator.
2 roller intake:
Why do with 3 what you can do with 2? With the right geometry this could be simple and efficient.
After some fine tuning and another iteration this prototype also performed well at high speeds (video not found ): )
We ended up fully developing both intake designs for the experience and just in case one has a fault we missed.
Drivetrain
Probably the only thing carrying over from last season is our Mki4 swerve drive.
In hindsight we shouldâve used an unpocketed steel bellypan, but weâll get to that later.
Elevator
Okay so thereâs a lot to get into here where do I startâŚ
Iâll open by saying many thanks to @Michael_Corsetto and all of the Citrus Circuits family, thank you for your marvelous engineering skills and the willingness to share your knowledge with the community, it was a great pillar of information and inspiration.
And now onto our design:
The goal and challange in our elevator geometry was finding the right measurments that would allow the rest of the robot to remain simple.
with the gripper having to:
- pickup gamepieces from the floor
- pickup gamepieces from the shelf
- score at all levels
- stay within extension limits
All without rotating or altering itâs position relative to the elevator!
The next step was bringing the concept to fruition (many photos ahead):
(We CAD using SolidWorks and have yet to use onshape, weâre currently working on uploading and setting up an account to share our work with all who would want it 
)
Some assembly photos
Our biggest hurdle (so far) was in the rigging process, so letâs get into that:
Powering our continuous elevator are two neos with a 7.77:1 reduction.
We are using a single spool to winch both elevator ropes (one for opening, one for closing), following similar rigging to the Tangerine Tumbler (however lacking a spring).
Multiple small problems arose during the rigging process. For example, insufficient tolerences led to friction between a gear and a support plate - leading us to add a small spacer.
However, there was one more major issue with the rigging, Iâll break it down (TLDR ar the bottom):
Long Version
There are two ropes sharing the same winch, operating in opposite directions (when one unwinds the other rewinds), weâll call them rope A and rope B.
Let X and Y be the lengths ropes A and B unwind/rewind in a single rotation of the winch, respectively.
When everything is operating smoothly, a single rotation of the winch leads to both ropes unwinding and rewinding the same length - meaning X = Y.
However, if one of the ropes were to start wrapping over itself, then suddanly X \neq Y
The relationship between the lengths of the ropes is critical for proper elevator function, so when this ratio becomes unstable and unpredictable it leads to jams.
And thatâs what happened to us.
TLDR:
One of the ropes started wrapping over itself leading to jams. Bummer.
This happened because the rope reached the edge of the winch, due to the large angle in which it was connected from the elevator to the winch itself.
The solution - add a pulley to redirect the rope and reduce the angle when connecting to the winch.
A nice before and after picture:
On the right is the adjusted rope with the additional pulley, on the left is the entanglment we wished to avoid.
âYadda Yadda Yaddaâ -Elaine Benes
Itâs Alive!
oh look, a penny!
Iâm guessing most of you reading this post probably thought at some point (mabe even in first glance) âWow, this robot is gonna tip over a lot!â
And well⌠Weâre working on it.
We wanted to see how bad the situation is and be able to approach the problem analytically, leading us to write this short document on calculating the relationship between robot acceleration, elevator acceleration, and tipping over.
Robot Tipping Point Accelerations.pdf (295.3 KB)
(We hope the calculations are correct, feel free to correct us if mistakes are found)
We substituted our initial robot weight (36 kg!!) and center of mass measurments into this nice interactive desmos graph and soon realized the 'weight â of our problem.
A backwards acceleration of just 6 [m/s^2] would lead to flipping over even without moving the elevator.
To help grasp the severity - for a robot driving forwards at an average speed of 3 [m/s], if we were to limit the robot acceleration to 6 [m/s^2] the robot would continue forwards 2.25 [m] before fully stopping!
Leading us to start operation weightgain!
As of now we are not doing any driving with the elevator open until after this problem is mediated.
Our current approach is to add body mass and shift the center of mass to a better position, along with implementing a velocity/acceleration limit on the swerve while the elevator is fully open.
Where are we now?
A month and a week left until the Israeli Offseason Competition, and we have a properly functional robot! (compared to the regular season where we only had two days of the programming subteam with the robot prior to the first competition)
The robot is currently going back and forth between the programming and mechanical subteams, basic automations are done and the robot has gained around 14 kg (~30 lbs.)
The added weight comes from a bulk of small diver weights and increasing the thickness of some plates.
Going forwards we have several big tasks ahead of us:
- Finishing operation weightgain.
- Picking an intake - both intakes were fully developed for competition use, so now we need to test them both in real game scenarios and compare. If both operate similarly weâll probably continue with the lighter intake.
- Autonamous and code fine-tuning.
- Bumpers!
- Practice Practice Practice
- Fixing any obstacles which may arise
- Writing the next open alliance post
Thanks for reading! Feel free to ask questions or give advice, any feedback is appreciated
