WildStang Robotics Program: Team 111 and 112 Build Blog - 2024

WSRP -111-112-Logo-White

WildStang Robotics Program is excited to announce the return of our build blog for the 2024 season! And new for this year, we are an official member of the Open Alliance! We are proud to share our contributions with the community for another season.

Over the next couple of weeks, we’ll be posting a series of updates and summaries of many of our fall projects, team structure improvements, and a purpose built demo robot we built this fall!

Links
111 CAD: OnShape
111 Software: (Coming Soon)

112 CAD: OnShape
112 Software: (Coming Soon)

For an overview of our program, please read the kickoff post from our 2023 blog.

Good luck to all, and we’ll see you on the field! Let’s go!

81 Likes

17 Likes

The 2023 111 code release has been posted in the 2023 blog here

If you want to read about something in that wall of words, I’d recommend the “Control Scheme” section + the driver/operator controls. We had a fairly unique setup, where the driver controlled when all of the robot actions occurred, but the operator controlled what happened for each of those actions. This was a smashing success, and we saw that with how easily other students were able to pick up driving the robot during our driver tryouts in the fall. I think there is a ton of performance the average robot could gain with slightly smarter controller setups. There’s no replacement for driver practice, but smarter control schemes can make drivers better with less practice.

The 2024 version of the Wildstang framework is posted here

We don’t do a ton of development of our software in the fall, as we stay busy training our 112 students and letting 111 students run wild on thesis projects (which you’ll hear about soon). So there will be some updates to the framework repo after the build season starts as we get some robot time to play. The specific changes for 2024 I’ll note now:

  • We’ll be looking at changing to Choreo for path generation. We use our own path follower - a pretty basic framework that takes in the velocity, acceleration, and direction of the path and handles rotation separately
  • We’ve done some basic tests of the limelight plus google coral, and are looking to utilize that for some more advanced control schemes depending on the game next year.
  • We’ve also played around with an orange pi 5 and a global shutter camera. We likely won’t use this for next season, but it seems to be the best path forward for using April Tags while moving, as the motion blur from the limelight while moving seemed too much to overcome and get accurate results.
  • We will be updating our drivetrain to use NEOs Vortex, and hopefully posting some information with the big differences we notice from the NEOs we ran last year

For the 2024 season, we again won’t have a public repository on our github for a myriad of reasons. We don’t like having every branch of our repository public, and there really aren’t any good ways to only restrict part of a repo that doesn’t require a ton of manual overhead. However, we will be going over what we’re doing in software, and sharing code snippets and control schemes through this blog. And, like always, feel free to ask any questions and I’ll respond as much as possible - I definitely sent some files through DMs, and have no issues doing that for this season as well.

9 Likes

112 Robot Code is live here!
Stu covered all of the important info on the framework, and there isn’t too much to write home about in 112’s code for this year, but please don’t hesitate to post here or send me a DM if you have any questions!

2 Likes

TPU Wheels

Over the last few months, a team of four students (including me) have been working on making and testing 3D printable wheels for MAXSwerve. FRC team 88 worked on wheels much like these, releasing a design at the end of the 2023 competition season. We saw their design and wanted to try to adapt it to MAXSwerve.

Why?

Go fast or get passed.

These wheels have a special spike pattern that grips into carpet, allowing wheels to achieve a much higher coefficient of friction (COF) than standard wheels.

What is "COF"?

The Coefficient of Friction, or COF, is the ratio between frictional force and normal force (force pushing down) of an object. Grippier materials have higher COFs. In this instance, what we’re measuring isn’t really the COF, but rather the strength of the mechanical lock between the spikes and the carpet. We’re treating that as the COF.

In numbers, these wheels have a COF of 1.43 while normal treaded wheels have a COF of 0.97. A wheel’s COF directly corresponds to how fast the robot can accelerate. If it’s too low, the wheels will slip instead of putting all of the power into accelerating. This is especially pronounced with light robots and more powerful motors (Vortexes and Krakens). This doesn’t lead to too much added sprint speed, but can help you in handling and being defended. If you have more grip than your opponent, you might be able to push them out of your way, or at least won’t be pushed by them.

Play around with this drivetrain simulator if you want to see for yourself: Drivetrain Simulator - AMB Robotics Calculator
Keep in mind that the sim doesn’t completely reflect real life values.

How to try them out

The design that we’ve been testing is for REV Maxswerve. Many other people have been testing these out for SDS and WCP swerve modules, so if you want to see those, click here.

Our leading design right now is called “TPU Wheel Main” in the Onshape document.


CAD link
The hub is meant to be printed out of Markforged’s Onyx, and I wouldn’t recommend using anything less strong than any Nylon materials.
The tread is meant to be printed out of TPU 95A with 100% infill. Using a relatively low layer height helps keep definition in the spikes. I’ve been using a 0.8mm layer height. You also need to use supports for the part that goes into the hub, but not the spikes, which can be annoying.
As it stands, it uses 67g of TPU per wheel, which costs ~$2, or $8 for a set.

Recently, team 2847 ran our design at an off-season competition. The wheels lasted the length of the competition (11 matches!), and this is what the wheels looked like afterwards:



Very big thanks to them for running these!

If you want to see most of the possible wheels you can try, check out this doc which has almost every published design for MAXSwerve, and a few for SDS.

A word of caution:
These wheels still haven’t been tested enough to be 100% sure that they won’t break very quickly, midmatch. Please validate for yourself that these have a long enough lifespan for you.

Static COF Testing

TPU Wheel Treaded Wheel REV Molded Wheel
≥1.43 0.97 0.87

Our testing rig is very simple, all we did was staple an extra piece of carpet onto a plywood board and lifted it up until the robot slipped. We measured this angle and took the tangent of that angle, and that gave us our static COF.
≥1.43 means that the robot fell over before the robot slipped, so we can’t know how much it was exactly above the 1.43. 88’s original wheels had a COF of ~1.6, so it’s probably under that.

Proof

Video of some of the tests

Challenges and Design

During the development of these wheels, we had very many challenges. 88 gave us a good starting point, but they had designed their wheels for SDS modules, which have a 4" diameter by 1.5" width wheel. MAXSwerve, on the other hand, has a 3" diameter by 1" wide wheel. Additionally, 88 designed theirs for SLS printers, which are suuuuuper expensive.

We widened the width to 1.22" from 1" because there was extra space, then we also added a notch to allow the wheel to be hotswapped. The notch goes to the top, and then the wheel clears the pinion driving the bevel gear.

We had a lot of unexpected durability issues with this wheel, leading to many, many redesigns. I don’t know how useful going into detail is here, but here’s an overview of what we’ve changed.

  • The tab that goes into the hub got stronger (more like 88’s)
  • Replaced the metal part of the hub with a bigger 3dp part to support the wheel on the side better
  • Moved away from using gyroid infill for suspention due to my speculation that it breaks when it bends too much

There’s a lot of changes since the original design, but those are the most important ones.

I wish we could have tested these for accuracy in auto, but we ran out of time :frowning:

Presentation

We gave a presentation about these wheels for our parents, mentors, and peers at our last meeting of the year (2023). Here’s the poster that we presented:


Overall it went really well! The the text was a bit hard to read but it seemed like everyone understood what we worked on.

There were four other thesis groups and the demo bot group that also presented, and I’m sure you’ll hear about the others soon!

58 Likes

As with the vex wheel, I feel like this is flying pretty close to the sun.

Good call in your COF drop-down stating that you are not really measuring COF, but rather the interlocking nature.

If you have to use terms such as :

That is getting pretty close to the manual definition

No digging into carpet.

I might frame this different if it has a snowball’s shot for official season play. Optics and wording probably matter here.

2 Likes

By that Logic, wouldn’t nitrile tread be illegal also? The spikes on it also dig into the carpet.

5 Likes

We often frame roughtop in this way, increasing surface contact patch, etc.

I suspect, given a proper QandA avoiding “we can not speculate on hypothetically robot designs” , the difference would come down to design intent or something hilariously vauge.

Given there has been noise in the past of tiremarks meeting a violation of G301 I think it is best to tread lightly here and be careful about phrasing.

3 Likes

While I’m sure they could ban these wheels, it would be in their best interest not to.

In a pushing test that we stupidly ran on our practice carpet, 111 with black nitrile lost traction and burned holes through the carpet. 3 out of 4 of 112’s TPU wheels kept traction and didn’t damage the carpet. The fourth wheel lost traction only damaged the carpet a moderate amount.

3 Likes

Which is still damage from a R201 possibly. With a G301 in the potential mix as what you would get called on.

Just because “my robot doesn’t damage the field as bad” doesn’t absolve you from the rule infraction.

All I am saying is be careful with describing these wheels for R201 sake, and cross your fingers on the G301

This is an excellent experiment, I am glad you looked into it over the off-season and provided such a detailed writeup for the community.


Because it is relevant:

3 Likes

Oh I am not worried about 111/112’s ability to follow rules. After all this was testing.

I am just focusing around the language used as that matters a ton for anyone using a similar design.

A few teams out of a thousand will fly under the radar, a hundred teams out of a thousand? Maybe not. Depends how widely used the general design is and what it may (or may not) violate.

At the end of the day I was far more concerned about VEX’s offering in this space as it appeared to be marketed as a drive wheel. It is easy to equate COTS = legal. Those wheels cost money and wheels are an easy upgrade, a lot of teams could have hypothetically wasted a lot of money there if they were planning on using them as drive wheels and where banned.

2 Likes

From Section 1.7 of the 2023 manual: (bold added for emphasis)

Rules include colloquial language, also called headlines, in an effort to convey an abbreviated version of the rule or rule set. … Any disagreement between the specific language used in the rules and the colloquial language is an error, and the specific rule language is the ultimate authority.

So citing “No digging into the carpet.” isn’t quite the right way to use the rule (at least IMO). The actual specific language states:

Traction devices must not have surface features that could damage the Arena (e.g. metal, sandpaper, hard plastic studs, cleats, hook-loop fasteners or similar attachments). …

As it is this is already a poorly worded rule since all of the different treads that are commonly used on FRC robots could damage the Arena, especially if the bot is traction limited and slips its wheels when pushing, e.g. against a fixed field element. This is definitely something we will attempt to clarify in the new season, but personally I think the only way this rule is even feasible to enforce in a consistent matter is if you interpret it to mean “could damage the Arena in normal use”. That would effectively retain the restriction against metal files and the like that initially spawned this rule, but would prevent making any kind of wheel at all technically a rule violation.

5 Likes

You are 100% correct that everyone digs into the carpet to some extent. All those screw heads holding on tread… etc. nobody is getting called for that under normal use (nor should they).

The issue I see is there was a meaningful intention to interlock with the carpet nap. The primary focus of the plastic tread is to engage in this manner. When looking at the definition of R201 all the examples are focused around limiting this intentional 3 dimensional engagement with the carpet. As far as damage is concerned… I guess all wheels can damage carpet nowadays, so that portion of the rule may need to be looked at.

Fundamentally this is the overarching action item. Absolutely agree.

I would still consider it TBD if the wheels will be judged to be compliant with the intent and/or the letter of the existing rules. This would likely fall under the umbrella of the robot inspectors, but I also think it is possible that not all LRI’s will make the same judgement on legality if there is not a clear judgement made.

My recommendation: PROCEED WITH CAUTION. Keep in the back of your mind that, whether you think it is correct or not, you may be asked to change your wheels at competition either at inspection, or because of a hypothetical carpet damaging event. There’s a rules controversy of some sort every year and this smells like it could be one to me.

The good news is that wheels can be a quick swap, so I would not expect a team’s competition to be ruined if this situation happened. Off the top of my head as far as impact to the robot, you would probably have to re-tune your auto drive paths at minimum.

I hope that teams that choose to run wheel designs like these will have great experiences - just wanted to toss in that disclaimer.

9 Likes

On The Fly Path Generation

Over the past year, I have developed an OTF path generation algorithm which avoids obstacles.
The end product can handle most scenarios it encounters, and those it can’t can easily be overridden by manual control.

OTF Path Clip

How It Works

Setting Up The Algorithm

In the algorithm, paths are defined parametrically by two n dimensional polynomial vectors. Since optimizing two vectors at once is challenging, they are combined into a single 2n dimensional vector. Next, since many of the paths possibly defined by the vector do not go through two desired points, it is necessary to constrain the vector space. Further constraints are then added to allow for control over the initial and final velocities as well as locations. The resulting vector space is 2n-8 dimensional and is where the algorithm will operate.

Running The Algorithm

Now that a space containing all possible paths has been identified, the next step is to find the best possible vector within that space. To do that a function which evaluates the quality of the path corresponding to the vector is used. The quality function is defined as the sum of the length of the path and its line integral over the predefined obstacle function. This quantity is then minimized using momentum gradient descent with an initial guess of the straight path from the start point to the end point. The output of this algorithm will be the shortest path between the two desired points which avoids all obstacles.

A write up containing the exact math behind the algorithm can be found here:
Updated Path Generation Algorithm Write Up.pdf (308.5 KB)

The controller used to manipulate the simulated robot in the visualization is detailed here:
Swerve Path Following Controller.pdf (92.3 KB)

A link to the visualization is here to look at the current implementation and experiment with the algorithm.

Applications

The primary application of this algorithm would be to partially automate tele-op. While it can’t account for the five other robots on the field, the ability to pathfind to a consistent location on the field along an optimized path at the click of a button has value depending on the nature of the game. It is also possibly applicable during autonomous, but it is unlikely to have the repeatability of more optimized programs like Choreo. This is potentially mitigated by adding more components to the quality function to optimize more values, but that would come at the cost of longer processing times. It may also be possible to utilize the algorithm for the entire duration of the match by treating the driver’s controls as a method of creating end points during tele-op and using it in the aforementioned way for auto and autonomous tele-op, but that is yet to be seen.

Next Steps

While the algorithm works great in the visualization, a proper robot-ready java implementation is yet to be created, so it is unproven on an actual robot. Hopefully it will continue working as intended, but that is definitely the major next step. Given that the first step goes well, other next steps will be to see how many of the previously listed applications are actually viable and hopefully make use of it at competition!

Feel free to ask any questions!

28 Likes

The Fall Olympics

This Fall, like last, the students on both 111 and 112 started each Monday evening class with a team building activity. At the beginning of the year, the Program was split into 8 random groups consisting of students from both teams, with the goal of more experienced students helping make the newer students feel more comfortable.

The challenges that students participated in ranged from transporting uncooked spaghetti across a gymnasium suspended between partners’ index fingers, trying to build the tallest towers out of mentor-unapproved construction materials, and various Kahoots. One week, the students had to identify robots from early 2000s TV cartoons, while the mentors got the opportunity to play against them (Spoiler alert, @DohertyBilly won). We also saw how many students use our names when registering for Kahoot. :eyes:

In addition to the challenges, we’ve done different costume-based contests every Monday class. Below is the full list in case anyone wants to borrow it:

Costume Contests
  • Awesome Hat Day
  • Formal Attire Day
  • 80’s Day
  • Disney Day
  • PJ Day
  • Zoom Day (business on top, casual on the bottom)
  • Stuffed Animal Day
  • 90’s Day
  • Best Costume (Halloween Costumes)
  • Fav Sports Team Day
  • Super Hero Day
  • Wacky Sock Day
  • Tie-Dye Day

Team Culture & Vibes

One of our major goals this season is to build on the work we’ve already done to establish a positive team culture across all of our students. While wanting to build a competitive robot and be successful at competitions is a fantastic goal, none of us want to do it at the expense of the students’ or mentors’ mental, physical, or emotional health.

If students are sacrificing any one of those, their capacity for learning is diminished, they’re not having an optimal experience, and we’re contributing to an environment where on-field success becomes the priority over education. Many of us have seen first-hand the effects that this mentality can have on students across a wide variety of sports and activities and we have no interest in bringing that attitude to the WildStang Robotics Program.

Similarly, we believe a vital element of a successful, healthy program is a balanced cadre of mentors who actively enjoy both the experience of teaching students and the relationships they build amongst each other as peers. We are lucky to have a strong group of mentors and coaches representing over 150 combined years of FRC experience. None of us want to be fighting against undue competitive stress, exhaustion, or emotional turbulence either. Turns out being friends off the field makes us more effective as mentors in the shop as well.

This Program would much rather spend our time sharing technical updates on Chief or weird cat memes on our social accounts than stressing ourselves out over things we may not be able to control (also, follow us, it’ll make @JPalmer and the communications team happy).

IG: @frcwildstang111 & @frcplusone112
TikTok: wsrp.111.112
#TeamREV

The New Hotness: Wellbeing Initiatives

This season we’re trying something new. Drawing on our previous experiences, both within FRC and beyond, we are trying to promote a healthier, happier, and therefore more successful student population.

Unbeknownst to them (surprise y’all!), this is going to come in the form of a couple of new challenges for the students and mentors.

The first is going to be to set aside 90 minutes a week for an activity which is completely unrelated to robotics, and ideally not screen dependent. Examples include going on a walk, reading an unassigned book, crafting, cooking, or talking on the phone with a friend. Essentially, we want our team members to experience all the wonders of nature and society outside of FRC (you know, “touch some grass”).

The second challenge is for them each to set a goal to start one healthier habit during build season. A SMART goal. Specific, Measurable, Achievable, Relevant, and Timely. Setting a consistent bedtime. Eating a specific amount of fruits or vegetables a day. Cutting out pop (soda, for all you non-Midwesterners). Limiting screen time.

The third is that we always want the students to ask for help when they need it. Whether it’s a box that seems a bit too heavy; feeling overwhelmed with balancing school and robotics; or being stuck on a design problem, none of us can do everything alone. Being able to recognize where we individually need assistance makes us stronger as a whole.

I’m sure some of our students already do these things on a regular basis and that’s fantastic. But the point of these challenges is to encourage them to be more aware of, and active participants in, their own mental, physical, and emotional health. Being proactive is always better than being reactive when it comes to any aspect of our health, and it’s far easier to learn these habits as students than as adults.

We’ve created a dedicated slack channel (111 and 112 students can check out #wellbeing-challenges for a sneak peak) to encourage students and mentors to share their successes in each of these challenges throughout the season.

Here’s to a great season and tie-dye vibes. Fun is a core value.

17 Likes

CADmas

Over the past week, we competed in a cadathon hosted by @howlongismyname .
Our bot got second, and I wanted to share some of the cool things that I thought were interesting.
|657px;x508px;

First, the game.
This was a rerun of the 2019 F4 Cadathon, Powerplay.
Essentially, you pick up 8" diameter by 2.75" tall hockey pucks, and shoot them into targets. You also had to pass hockey pucks between robots.

Game manual, reveal video, and field cad

Rule manual:
CADathon 8 Rule Manual - Google Docs
Reveal video:
https://www.youtube.com/watch?v=CCCsOhfmCh4&feature=youtu.be
Field Link:
Onshape

Intake

|723px;x559px;
This intake was super interesting to think about. It’s under the bumper (UTB), which is pretty rare.

We had to exploit the bumper rule’s tolerance for bumper height to allow a 2.75" game piece to pass under it, resulting in a tiny bumper. Having this intake fixed also allowed for two less motors (goodbye intake pivot and feed!)

We also utilized the through bore nature of the NEO Vortex in order to have easier mounting, putting a pulley on the back of the Vortex and forgoing any standoffs. IRL, we would probably secure the shaft with a bearing on the main plate as well, instead of putting a washer inside of the motor.
A polycarb protector and funnel runs along the outside to keep pucks from getting under the drivetrain.

Shooter Pivot

|666px;x515px;
This was driven by a 20:1 MAX Planetary and a 10:100 10DP sector gear. This packaging worked out super well, and I wonder how feasible it would be to manufacture this in real life.
We added a 3d printed tube clamp for the maxspline pivot in order to be able to actually assemble this bot, without it sliding the tube out would result in hitting the roboRio!

Shooter

|540px;x417px;
This isn’t unique so I’ll make it quick. Feed is on a 3:1 Vortex, belted. Shooter wheels are foam direct driven by vortexes. Probably don’t want foam shooter wheels for a 3 lb hockey puck, though.
The shooter is held together by nut strips, and consists mostly out of four 1/4" aluminum plates.

Electronics

|699px;x540px;
This isn’t the best electronics layout ever, but it’s all that could fit unfortunately. I doubt that we’d use this electronic layout if we actually built this bot.

CAD Model and extra documentation

Tech Binder
Main Assembly
More links are in the Tech Binder.

Simplified models and document performance

This cadathon was a lot about having an efficient CAD workflow and also keeping document lag to a minimum. Skip if you don’t care about Onshape CAD.

Part of that was using simplified models. parts.frccad.com (run by @AndrewCard) has simplified swerve modules and motors that we used in order to keep primitive counts down, as well as using MKCAD simplified electronics.

The other part was keeping regen times low. The big things that ate up our regen times were tube converter, lightening, and the 100T spur gear.

The best way to make sure tube converter takes as little load time as possible is to only use it once for every length of tube you need. For your drivetrain, you can do a circular pattern to only do one side tube, and also mirror your support tubes.

For lightening, you need to do it. Just make sure that it’s last in the feature tree so you can move the bar up to work on other things.

Lastly, for giant spur gears (mostly seen on hoods), the best thing to do is to make the spur gear in a different part studio and then import it in to your part studio. That way Onshape doesn’t have to spend time regenerating the spur gear every single time you make it. Also cut the spur gear to the right section before you import it if you can.

Extra random stuff

If you want to see the winner’s bot, look here. It’s really cool!

12 motor swerve maxswerve cad

I worked on this over the summer, and before we built it it got outlawed :cry:
Anyway, I thought it was a cool design and this is a cad post so I’d share it here again

CAD

34 Likes

Overall first impressions of the game are extremely positive around here. Game has an extremely good balance of the familiar, the challenging, and the new to put it in contention to be one of the best FRC games of all time.

The immediate comparison is to 2013, Ultimate Ascent, which in my opinion is one of the most exciting strategically diverse games in FRC. There’s a reason we use it for our fall robot design training classes!

Kickoff Notes
I want to open our Crescendo blog with some of our observations of the various game phases and how we see this game being played at an extremely high level.

Auto

  • This game will be beginning the move away from pre-determined paths to dynamically on the fly generated autonomous programs. The 5 Notes starting in the middle of the field will be highly contested by alliances aiming to score >3 notes in auto. This is 2015 can race on steroids. We anticipate autonomous programs that dynamically choose the second note pickup location using vision systems to determine which ones are still available at various times in auto. This is a perfect use case for the Google Coral capability on the LL3.

Note Interactions

  • Multiple (2+) scoring cycles in a 13 second amplified time window should be possible.
  • This game is all about maximizing amplified scoring time. Any note into the speaker that isn’t amplified time is a sub-optimal cycle.
  • There’s a scoring sequence on top of the normal game piece → goal cycle. If an alliance aims to maximize scoring cycles into a amplified goal they need to carefully coordinate the timings of who scores where.

Source -> Amp -> Source -> Amp -> Source -> Speaker (as many as possible)-> Repeat

scores more points than:

Source -> Speaker -> Source -> Speaker -> Source -> Speaker -> Repeat

Stage Interactions

  • Trap is a very difficult scoring objective that can win you a regional. Many teams will try, few will succeed reliably.
    its_a_trap

  • Climb RP requires a trap capable bot with a buddy climb, a trap capable bot with a partner that can climb, or a buddy climb bot with a mechanism or human that can guarantee the spotlight every time.

2_Bot_Climbs

  • Max stage points score (31 points) requires un-climbing the chain after trapping, repositioning the robot, and then climbing again near two other bots. This seems unlikely to happen.
43 Likes

111 Priorities and Prototyping Planning

After a night to let the game sink in, we got right into day two with a list of as many robot actions as we could think of. As long as it was legal, no idea was too silly to make the list: if the robot really wanted to jump up and dunk into the trap, then it could.

Needs, Wants, and Nice-to-Haves

After determining everything that a robot could possibly do, we worked on deciding what priority each action should have relative to our goal of qualifying for champs. We first separated all of the actions into categories based on which subsystem would be responsible for it, then further into varying priority levels. The three priority levels we had were needs, wants, and nice-to-haves. Needs are actions that we determined were absolutely necessary to win a regional. Wants are actions that we want the robot to be able to do, and think should be designed around to at least some extent. Nice-to-haves are actions that would be beneficial, but aren’t worth actively designing our robot around. There is also a NO category for ideas we decided were truly unreasonable (Dunking into the trap basketball-style, for example).

Prototyping Plans

Once we had a priority list, we generated lists of ideas of what we needed to prototype to accomplish our needs, and hopefully our wants. We broke prototyping into two lists which we thought would need the most testing: intaking/feeding, and shooting.

Intake/Feed:

  • Minimum note bend radius
  • Maximum note compression
  • Functionality during quick driving
  • Minimum roller height to knock note upwards
  • Functionality while approaching at an angle
  • What causes jamming?
  • How easy is it to eject broken and not broken notes?
  • How difficult is it to pick up a warped note?
  • How much damage does intaking do to a note?
  • How do varying intake types deal with notes which are leaning against something?

Shooter:

  • How can various distances and angles to the speaker be handled?
  • Consistency of note aerodynamics
  • Effects of varying flywheel RPM
  • Effects of compression
  • Effects of spin
  • How does a warped note affect shooting?
  • How harmful is shooting a note?

We also created a list of characteristics that an ideal climber would have for us; climbing is difficult to prototype at a small scale, but we decided to create a list to guide our climber conceptualization and geometry verifying process.

  • 100% reliable
  • Post-climb position allows shared amp/trap mechanism
  • Predictable robot motion
  • 3 continuous points of contact
  • Stows to under 27’’
  • Climbs and scores in 10-15 seconds after the stage is entered
  • Has an alternative motion which climbs quickly but doesn’t score in trap
  • Leaves space for an alliance member
  • Minimal DOF
  • Lightweight
33 Likes

No jumping and dunking into the trap? What a shame.

5 Likes