FTC 17012 and 18638 Open Alliance Build Thread

[Jill_ls101]

FTC 17012 and 18638 Open Alliance Build Thread

FTC Teams 17012 and 18638 are from Lafayette, IN, representing Jefferson High School and Tecumseh Junior High School, respectively. Both teams meet and work out of the high school, working separately but from a shared pool of resources and coaches.

Also within the Broncho Robotics Programs are three FLL teams (Broncho Bits, Bots, Bytes) and one FRC team (1646 Precision Guessworks).

Structure

17012, Precision Guessworks, has students from all grades in the high school. To best fit the needs of our overall robotics programs, all high school FTC students are also participating on FRC 1646 (and choose to also do FTC. We also have FRC students who only do FRC). We anticipate having 4-8 students on the team this year.

18638, Giant Wacky Waving Inflatable Arm Flailing Tube Man, has students from the 7th and 8th grades. We just had our callout and anticipate having 5-8 students on the team.

Meeting Schedule

Both teams follow the same meeting schedule, meeting after school, 2:45 – 5:00pm twice a week following kickoff. This continues through December. In January, we may elect to cut back to only once a week (to avoid overburdening adults/high school students with the overlap in FRC build season).

Meetings pause for the year after we complete our last competition and resume once the FRC season has finished. At that time, all students, 7th-12th, meet at the same time (6-9pm, once a week).

Mentors

One of our struggle points is the lack of available mentors for our FTC teams. In addition to myself, there is one additional teacher who works with these students. Like myself, he is also an FRC coach with over a decade of robotics mentoring experience. Typically, I work more closely with the high school team and he works more with the junior high students.

Keeping to the directly after school schedule works best for our students, but has made it hard to recruit additional mentors to our FTC teams.

How we operate

Approach

18638 focuses on learning basic robot building skills, without putting too much strong focus on specific design skills. Last year, the team had a great time building the Rev Starter bot, and likely will choose to follow a similar path this year.

17012 fluctuates in how they operate, depending on student interests and desires. Last year, the students wanted a lot of freedom from mentor input, so the adults took a very hands-off approach and spent more time with the junior high students, occasionally checking in with the older kids. As a result of that experience, I gather they want a bit more direct guidance this year, but also are quite hungry for more competitive results. Their robots are typically a hybrid between COTS parts and custom laser-cut wooden parts and 3D printed parts.

Resources

Working out of the high school shop (same space that houses our FRC program), both teams have access to a large variety of machines, tools, and supplies. This includes CNC routers, two laser cutters, 3D printers, and traditional shop equipment (band saws, drill presses, lathes, mills, etc).

Most funding piggy-backs off our FRC program and through the acquisitions of grants. The junior high students pay yearly dues (the high school students pay dues as part of being on the FRC team, but don’t pay anything extra for participation in FTC).

Code

We use Android Studio to code our robots at both levels. Basic training in code is done through a classroom curriculum I have developed (and use in my classes).

CAD

… Is a bit of a hot mess. Most of our students and our coaches prefer Inventor because it is what is taught in our schools so it’s the most familiar to everyone. However, the school is typically slow in updating our desktops every fall to get the Inventor license even working. Which it currently isn’t. So for now, OnShape it is.

Season Goals

• Build competitive robots capable of achieving the game tasks
• Have a winning record at at least one of our competitions
• Keep this thread up-to-date at least once a week
• Learn things!
• Have fun!

Team Links

• CAD
• Github
• Flickr

[Jill_ls101]

Because of everyone’s respective schedules, today was the first day the teams met since Into the Deep was revealed, thought most members had elected to view the stream on their own.

Given the delays we had last year getting the field, we never ended up with a fully built field, prototyping against… insufficient mockups or nothing at all.

This year, we were happy to have access to the field kit from day 1 and after rewatching the game animation, all members of the teams (~5 students present) spent the meeting on field assembly.

We’re happy to report that our field in now completely built and we’re ready to start diving into the game on Thursday.

[Jill_ls101]

Limelight Update!

“Oh my god, we’re actually going to have a camera on the robot this year?”

Not quite our normal build time, but our Limelight 3A arrived today and it was far too tempting to play with to put off such a thing until tomorrow’s meeting, so one of our students got the Limelight plugged into a laptop to start learning how to use it during our FRC meeting.

We normally try to keep the meeting times discrete, but, I also wanted to play with the camera. We haven’t used any Limelight in ages and I’d never gotten to be one of the people working with it.

The long and the short of things is it was pretty easy for us to get tracking objects on the laptop, first selecting various objects and tracking by color, which has been discussed as a potential use case (for distinguishing between red/blue samples, particularly in the Submersible, and rejecting the wrong colored ones).

Then, we moved on to April Tags and field localization. Which was pretty easy to click all the right things and see the robot’s position on the field.

For the most part, we were testing out the capabilities of the camera, and the thresholds where things started flaking out a bit. For trying to view things at a distance and at some sharp angles, we found the 960x720 resolution to work well.

We’re still learning what sort of behaviors to expect, and for more distant tags (especially at angles), we found there to be what seemed to be noise, with the robot’s position jumping around a lot between the valid position and somewhere else.

All in all, we’re pretty happy so far. Alongside brainstorming and prototyping, we’ll definitely try to schedule in some time to hook up the camera to a Control Hub in one of our next few meetings.

[Jill_ls101]

Meeting 2: Talking Strategy

The members present from both 17012 and 18638 sat down for a deep dive into the game manual. We covered all the components from the Arena, Game Rules, and Robot Construction rules.

Then, we took a brain break and mocked out a match on the field with one of my favorite activities, human matches!

The students did 1 v 1 matches, trying out different strategies, just to see what the outcome would be.

Everyone was given restrictions to make themselves more robot-y: crawling only, elbow had to stay close to the chest (no full extension unless vertical), and they could only reach into the submersible from under the low rung/chamber, because that’s more like how a robot would operate.

The major benefits of this are:

• The team learns how the field should be setup at the start of each match
• The team learns what areas are utilized during a match and when
• We see who understands the rules/game. (A few students attached clips to yellow samples at first)
• We learned how to attach/remove clips from samples
• It’s fun

Takeaways:

• While humans are not robots and we were only doing 1v1, it’s probably unlikely that game pieces will run out during a match. Even when only scoring in the baskets, the students didn’t exhaust all game pieces over a two minute period.
• Getting the cycle flow right when running Specimens will be crucial. On one playthrough, first the human player got behind, so the “robot” started running baskets, but then they got distracted, and when they returned to grabbing from the human player, they forgot to be dropping off Samples each cycle, which created another interruption in scoring.

After doing the match simulations, the two teams split to discuss their particular approaches.

18638
This is our 7th/8th grade team, who are primarily focusing on their robot building skills (ie. the physical act of using tools to accomplish the desired task, not design).

They watched the reveal video of the Rev Starter Bot, which is what 18638 built last year. The Rev bot is our chosen base because we have mostly Rev supplies.

The team discussed their thoughts on the design/strategy and decided they’d like to tackle making one upgrade to the robot before beginning construction and that is converting it to a mecanum robot.

17012
The HS team began strategy discussion with a conversation of realistic goals and Needs/Wants/Stretches/No-Ways.

• Needs: Things we think we’ll ‘need’ to be successful at Into the Deep and be competitive. Not having these things is not an option.
• Wants: Things we desire to have, and believe are fairly import to success, but can make do without.
• Stretches: Things we desire to have, but recognize they might be beyond our capabilities and could compromise our Needs.
• No-Ways: Things we want to avoid at all costs because they actively detract from success in some way.

Needs:

• Drivetrain (Drivetrain, Drivetrain): The top three most important parts of the robot. We plan to use mecanum. Currently the goal is to go “faster” than last year. The team will discuss specifics of actual numbers soon.
• High Specimen: Being the highest point scoring objective (outside climbing), the team believes Specimens are the right choice for our primary scoring objective.
• Level 3 Ascent: Being worth 30 points, the Level 3 Ascent is hard to turn away from. The team considered cycle counts when making this decision and looked at past number of cycles performed in Indiana last year. Based on our observation, 6-8 cycles were achieved in the state finals. While the field layout is of course different, assuming teleop cycles, climbing will definitely be a better use of the last 30 seconds.
• Score at least 1 game piece during auto: Otherwise, 30 seconds is wasted. However, we’re not the strongest at programming, so acquiring other game pieces during auto is left off the Need list
• Low center of gravity: There’ll be a lot of reaching above the robot in this game, and robot stability will be critical to staying on our wheels.
• Differentiating Color: With the goal of being a Specimen robot, it’ll be important for the robot (not the driver) to quickly distinguish between the different Samples. This could be accomplished by a color sensor or by the Limelight.
• Clean electrical: Bad wire management makes for difficult troubleshooting. Enough team members had a bad experience with this last FRC season, and are eager to never ever do that again.

Wants:

• Low basket: Since the low basket is under the height of the High Chamber, it should be feasible for us to score here (perhaps to reduce congestion at the Chamber), but it is not a primary goal.
• Being able to achieve a Level 2 ascent: There aren’t many ways of climbing to the high rung without being able to hold at Level 2, but there are a few potential ones. This want specifically calls for use to be able to do so, so if time is running short at the end of a match, we can at least get off the ground.
• Look nice: Everyone loves a pretty robot. Googly eyes are a must.

Stretches:

• High Basket: The high basket, is, well… high. Designing to score in the high basket is low on our list of priorities, but it’d be nice to have.
• Score additional game pieces in auto: A decent goal to have and try to accomplish once we have a robot. Our programming skills aren’t the best, so scoring more than the pre-load will take time we’re not ready to invest yet.

No-Ways:

• Push-bot: Last year, the robot struggled to achieve many of the game tasks and only was capable of pushing pixels and eventually climbing. We’re aiming for better this season.

[Robotgobrrrr]

This is super exciting to see FTC teams using april tags! Some advice from a lot of headache solving these problems in the FRC world:
What you’re seeing with the noisy position is called tag ambiguity and is a fundamental problem of april tags being observed by a 2d camera where there is ambiguity in mapping the 4 corners of the tag to a plane in 3d space. You can read more about that here What Are AprilTags? — FIRST Robotics Competition documentation. That is why it flip flops between roughly the same too positions (mirrored about the center of the tag with ambiguity) because it can’t determine which of the two perspectives is correct.

One of the ways the creators of Limelight have attempted to fix this is via the integration of the gyro into the algorithm. The robot code updates the limelight with what its gyro angle is (described in the limelight docs) and that gets used by the megatag2 or MT2 (Green) algorithm, since you don’t currently have the LL connected to anything it isn’t getting that gyro angle and hence the MT2 pose is way off the field. Once it has the gyro angle it will reject poses that don’t agree with the specified gyro angle and hopefully be more robust. The caveat is you need some way to tell the gyro where it starts relative to the field (this can be as simple as always starting the robot facing a certain wall and then applying a constant offset to match the field ).

In FRC there’s a convenient class for using a Kalman filter to mesh wheel odometry data with vision data, that might be too advanced to start with so I’ll give some other examples of criteria one can filter on.

• Reject limelight poses that are outside the dimensions of the field.
• Reject limelight poses that are beyond some threshold from your previous position.
• Reject poses when spinning above some speed.
• Reject poses with high standard deviations ( getStddevMt2() ) or small tag areas.

Lastly I would add that its extremely important that your tags are the exact dimensions they are designed to be, placed in the exact locations they’re designed to be, and that they are as flat as possible. Any of those things will increase issues like you were seeing.

Good luck, excited to see what you accomplish with Limelight!

[Jill_ls101]

Last Week’s Updates

18638
The team started work on assemblying the Rev Starter Bot. As previously mentioned, we’ve decided to do an upgrade to mecanum drive. Rev lists two guides on how to do a mecanum upgrade, but the team has elected to do neither.

The first requires using chain to drive the front wheels (leaving the back ones directly driven). The second places all four wheels on 90 degree gearboxes with the motors/gearboxes inside the drive channel. Since we don’t have 4 spare ultra-90s laying around, we’ve elected to do a hybrid assembly. As seen below in this highly technical drawing…

17012

The team has continued their process of brainstorming, strategizing, and prototyping.

Now, with limited mentors (1 mentor per team for most meetings), sometimes students do things, have whole conversations, draw a full whiteboard of drawings, and then adults come back to them later, and… no one can really explain what was going on.

So, I’m recording them here for posterity, with what was explained to me for some of the sketches.

White Board Sketches

The rounded hook drawing (second from left) is a climber idea, where there would be multiple deployable hooks around a central mechanism.

I’ve been told the Garfield gets drawn when some team members are trying to think things out and don’t know how to draw what they want to draw.

The far left drawing is another climber idea, being an elevator that reaches up, hooks on, and then reaches up again to climb for the Level 3 ascent.

Intaking Prototyping

On Tuesday, the team did some rough proof on concept intaking with some compliant stars on an axle stuck in a drill.

On Thursday, the team took this approach a bit more rigorously, making a quick laser cut intake mockup, to see how the Sample would react to being corraled into a space.

The team’s plan is to have the intake mechanism house the Sample and then spit it back out in the Observation Zone. So, ideally, the Sample gets held by the intake’s fingers, or a small chamber above them.

For the moment, we’re prototyping with only 2 compliant stars as 17012 is sharing them with 18638. For a final design, we’d likely add 1-2 more, but, really, even 2 stars grabs the game pieces well. (And when stuck in a drill at high speed, definitely can launch those game pieces across the field.)

The original CAD file had an open top, simulating if we wanted to move the game pieces into a separate holder. (Also, that was the gut-design choice to clear the compliant star’s fingers.

When we wanted to close the top, on of the students asked if we could just cut our notches for the stars. The cardboard was the 2 second fix to the design, as we were at wrap up time. Initial results seem to indicate the Sample can be held just by the fingers and against the intake ramp. In the upcoming meetings, we’ll probably laser cut a new top so the roof is more rigid than cardboard.

A CAD file of the pieces can be found in our Onshape link in the first post of this thread.

Next week’s goals:

• Start refining the intake prototype into something that can be packaged onto a robot. Meeting only ~5 hours a week means we can’t afford the time it would take to test many different styles of intake, so we’ll probably categorize this under “good enough” and try to make it the best that this style can be.
• Start studying linear mechanisms (slides/elevators/etc) for the lifting portions of the robot and possibly Specimen retrieval/ deployment.

[Jill_ls101]

Today’s meeting, we broke out the heavy tools to put together a prototype Specimen gripper.

For our Specimen gripper, we want a design that can grab the Specimen off the field wall and is tolerant enough to handle misplaced game pieces, if the human player is not precise in their placing of the Specimen, meaning we wanted a fairly wide opening and linear motion for the closing of the gripper.

The gripper is modelled after the carriage of a 3d printer, with 3d printed fingers sliding along the rails on linear bearings. Tentatively, the idea is the two fingers will be sprung together using surgical tubing, to maintain a tight grip, and then pulled open using the two servos on the end using cord and pulleys.

The linear rails we’re prototyping with came from a dead 3d printer, so this design is really going full circle…

Tentatively, the results are promising, with the Specimen being held firmly in the gripper. One change we’re likely to make if we proceed with this design is tapering the top and bottom of the finger blocks, to aid in alignment if our height is off. At the moment, you’d have to be pretty much dead on to grab the Specimen.

Unfortunately, we ran out of time before we could get it fully assembled, so higher fidelity testing will have to wait until Thursday.

[Jill_ls101]

Another week bites the dust…

18638

The robot is making good progress with the majority of the drivetrain together and elements of the arm system also being assembled in a timely fashion.

Our parts are a mixture of anodized colors as robot parts typically get sent out in raw stock form when we take our FRC robot to get anodized. Students then can choose which colors to use out of what we have available (currently: red, black, purple, and unanodized)

17012

We have been able to properly test our linear specimen gripper. Our goals with the mechanism were to make something mechanically simple with a large margin of error for specimen pickup.

As you can see, the mechanism works as intended. There is surgical tubing drawing the two finger pieces together, with the servos pulling on a cable to draw them apart. We discussed using a belted system to drive the fingers both directions, but prefer the simplicity of this mechanism.

One concern we had once we started testing is whether or not the fingers could wander off-center during a match, defeating some of the purpose of this mechanism (again, limiting the effort needed during alignment).

To test this, we set a timer for two and a half minutes, and ran the intake fingers continuously during this time, which would far exceed their use during a match. At the end of the test, there had been some movement, ~1/2" or so to one side, so we’d consider this potential con of the design largely a non-issue.

To meet our goal of a functioning robot by the start of December (only about ~24 meeting hours from now), we’ve largely been choosing to move forward with design elements that show reasonable levels of success, versus spending a lot of time testing different mechanisms.

Our hope is that we will be able to spend time refining our choices to the best possible versions of themselves and also get as much drive practice as possible before our first competition (late January).

Planned Improvements

We plan to iterate on this design to make it more compact while still maintaining the wide-grip range. One way we plan on doing this is by replacing the grey 3d printed linear rod holders, with 8mm linear rod holders we found on Amazon. In addition to being smaller, these have the benefit of making rod installation simpler (aka, it won’t involve an arbor press…)

We’ve also been redesign the finger grabbers to have a smaller profile. One of the ways we’re doing that is by purchasing shorter linear bearings (17mm long versus the 24mm we used for testing).

The red is the original profile of the finger and the purple the proposed new design. There is some hesitation over the tight spacing around the sample and the part that needs to wrap back up around as well as some thin-ish walls around the bearings, but filament is cheap and the bambu is fast, so we’ll print it, test it, and then see where we go from there.

Color Sensing

We began testing with one of the Rev Color Sensors to start deciding placement in the intake so we can auto-reject the samples we don’t want. We haven’t used the color sensors much (or ever…), so we just loaded the sample code and looked at the values. At the moment, there seems to be clear distinction in the hue values, but, we’ll have to keep testing to determine best placement and usage of the sensor.

[Jill_ls101]

Moving upwards!

Designing the main specimen lift has been a back and forth process.

Our major constraint is funding. There are many COTS lift systems that could solve our problem without us going through a major design process, but most of those systems come with a significant price. Given we are looking at 2 linear systems (intake and specimen lift) and one possibly needing to be multistage (depending on design choices), buying multiple linear motion kits is something we’d like to avoid.

We have a large surplus of Rev extrusion and could use their Linear Motion Kit, however, these seems to have a history of binding, and in my limited use (albeit with 3d printed parts) have some stability challenges we’d like to avoid. (Also experienced bind issues)

So, we first looked into generic drawer slides (therefore low cost) that we could rig into a lift system. McMaster-Carr sells these over-extension drawer slides (~17” travel for 15.75” closed length) which would suit our needs of going between the field wall and to the high chamber.

However, these drawer slides are already like a multi-stage lift and rigging it seemed to get more and more unfeasible the longer we played with the CAD. Now, we could have spent longer researching/contemplating both these and other drawer slides. But, we decided to delve into the back rooms of the shop to see if we had any useful things hiding in storage.

And the answer was yes!

We found 7 610mm pieces of Igus 40mm drylin N Guide Rail and a ton of the carriages. Igus parts used to be a common inclusion in the FRC kit-of-parts and I can’t think of a single time we’ve ever used these before, but they seem perfect for our linear motion needs (and budget).

Rudimentary testing puts little play/wiggle between the carriages and the guide rails and everything is metric based (M4 mounting), which plays well with everything else we’re doing.

For the lift design, there is currently some debate how to make the design, currently split between single- and multi-stage lifts.

Single Stage

• Simple to build. There aren’t a lot of experienced lift builders on the team, and one stage is feasible with creative carriage design.

• Here’s some (incomplete) CAD ideas of what this might look like.
  

  

• To reach from the field wall to the high chamber, we need about 15” of travel, which can be done on a single lift, provided the gripper is at the field wall height when the elevator is all the way at the bottom.

• A challenge is the mounting carriage for igus slides is fairly small and only has 2 mounting locations. There is a concern that the portion of our carriage that goes up might not be rigid enough for our uses.

• Additionally, we’d like to use the specimen lift as part of our climber system (to get to the low rung), and the structure seems a bit dubious for that.

Multistage

In cute CADing stage, with some short channel for funsies:

• The biggest downside here is there is an added complexity with additional moving parts and our general inexperience with lifts.
• An advantage to the multistage lift is the robot can be shorter/more compact, which depending on how the climbing ends up working out (more soon!), could be advantageous.

Moving Onwards
We’re 3d printing some parts for the igus slides to test mounting constant force springs to the carriages to allow for spring extension to simplify some of the movement.

[ElliotS]

@Jill_ls101

We have been able to properly test our linear specimen gripper. Our goals with the mechanism were to make something mechanically simple with a large margin of error for specimen pickup.

LigerBots in 2023 we made a design similar to this, we ended up not going with this on our final design in favor a a design with spinning wheels. I would strongly recommend trying to find a design with rollers so that you follow the motto of “touch it, own it.”

CAD: Onshape
CD Post (images are broken, sorry) LigerBots 2877 FRC OpenAlliance Build Thread 2023! - #6 by Themadcadder

[Jill_ls101]

Thanks for the feedback.

The style gripper shown is planned for use in acquiring Specimens off the field wall (where they should be available in a consistent location/orientation every time) and delivering to the Low/High Chambers for scoring. We’re also looking at testing a more traditional single-servo driven claw style grabber.

For intaking from the Submersible, we’ve been primarily prototyping with AndyMark Compliant Stars, as we received several for free at a local kickoff event.

At the moment, the proposed CAD looks like this with more details to come in a post to follow soon):

Within the robot, there will be no handoff between the two mechanisms (as Samples need to be delivered to the human player to be turned into Specimens).

[Jill_ls101]

There’s an Assembly Named Robot

Which is less a robot, and more three subassemblies floating in space near each other, but it’s vaguely robot shaped, which is a win. Additionally, it’s allowing us to start to think about overall robot packaging and the relative sizes of different components.

And relative size is currently one of the bigger sticking points. The original tentative plan was to have the Specimen grabber be permanently outside of the drive base to reduce the need/want to have another linear extension and simplifying the acquisition/scoring process.

At the moment, the robot sitting in a sizing cube looks a bit like this:

Which, in addition to being a lot tighter of a fit than we’d like (we normally aim for a 17.5" cube to handle intolerance in sizing mechanisms at inspection, and the purple in the CAD is a true 18" cube). Additionally, while we know mecanum doesn’t have to be a perfect square, it generally works better the more square it is, and to maintain a perfect square with the outer extension, the drivebase is currently squished down to about 12" square. Which is really tight for adding in other mechanisms.

Here’s the layout from the top:

It’s hard to see, but right near the edge of the screenshot is the edge of the sizing box.

Potential Solutions:

Option #1: Do something highly untraditional and in the category of “just feels wrong, but there’s nothing technically wrong with it” and relocate drivetrain motors to the outside of the drivebase itself, freeing up the center space for the lift motor(s) and soon-to-be-added/CADed climbing mechanism.

Option #2: Reconsider outwardly deployable Specimen grabber. But we’re not big on this. Trying to avoid more complexity.

Option #3: Consider other Specimen grabbing mechanisms. Other potential mechanisms include more traditional claw style intakes, including ones that could potentially fold flatter to fit into the cube better.

Option #4: Repackage/Redesign the existing design to protrude from the robot less.

Intake

Related to the above mentioned sizing issues, another side-effect is our intake is currently geometrically constrained in how far it can travel in a single stage. While we haven’t ruled out a multistage slide for the intake, again, we’re trying to keep complexity down. But at the moment, it’s barely getting out of the robot.

Obviously, as a single stage slide, it’s very much limited by the size of the robot and in this case the drive base, aka, dinky (~12"). And to accommodate the ramp at the end, the travel distance is further reduced.

(And none of this takes into account the barrier, which the intake needs to traverse past, which the current CAD/prototype is ignoring for the moment.)

There’s definitely room for condensing the intake itself (ramp/stars), but that’s not been the focus of the last few days.

Instead…

Slides!
As previously mentioned, we found a bunch of igus linear slides/carriages in a back room and are proceeding with those for our linear motion needs.

To simplify rigging needs, we’re electing to use a spring up, winch to retract system using constant force springs. At the top of each slide is a 3d-printed holder for the spring.

This was tested with a Vulcan Constant Force spring (specific spring was SH6G25) that has ~2 pounds of force. As expected, the slide travelled well when pulled by the spring. The holder has a low profile and fits in well to the lift structure.

The top of the slides in the multi-stage lift will be tiered for clearance (exact geometry still TBD). The stage-0 and stage-1 spring holders will also featuring mounts for bearings to run along the sides of the next rail to keep things aligned as the lift is extended (bearings not yet CADed).

Next Steps:

• Further CAD refinement
• Climber testing/CAD

[Jill_ls101]

Up, Up, and Away!

Climber Developments

We are planning on achieving a Level 3 climb. The first stage of that ascent will be handled by hooks on our Specimen lift system, getting us off the ground. The second stage will be done by a telescoping hook mechanism.

This style of mechanism (boat hook) has been used by several FRC teams and seems to be the current choice of extension mechanism of FTC 23513.

We’re planning on only using the boat hook for climbing. Inspired by Shrinky Dink and the Chameleon Climber, the main linear mechanism is a rollable boat hook.

The extension of the boat hook is driven by a 3d printed drum heavily inspired by the one found on Shrinky Dink. There are two pieces, driven by a central 1/2" hex shaft, and the two pieces nested together with a large hex pattern. The 1/2" hex shaft will be Rev Ultra Hex (which has a 5mm hex bore), which allows us to drive it from the output of a Ultra 90 degree gearbox.

The hook then passes over a 3" compliant wheel which will aid in the drawing out of the hook. This was added due to the concerns brought up in the two threads about the difficulties in extending the tube due to a “pushing rope” type effect. The last section is a 3d printed element funneling the hook into its round shape.

The entire extension assembly is mounted on a pivot, allowing us to easily reach the top rung regardless of how the robot is hanging.

What’s next for climbing?
Continued CAD refinement - working out mounting geometries and discussing incorporation of the mechanism into the robot.
Remove the foam “handle” section from the boat hook - This process started at the end of last meeting and is ongoing. The adhesive used was pretty darn good.

Intake Updates
The intake is probably the most wishy-washy unknown on the robot right now. To recap, the purpose of the intake is to acquire and store the Sample for deliver to the Observation Zone. As we’ve decided not to pursue any Basket scoring, this game piece never needs a handoff to another robot mechanism.

Our biggest challenge with our current intake is that, well… it’s big.

So far, we had prototyped with uncut AndyMark compliant stars, which are 5" in diameter at their outer points.

In an attempt to down size, we modeled a similar intake using custom intake stars that were then printed out of TPU (flexible) filament.

The results were… not great. (So far)

To start, the stars themselves are not flexible enough to wrap around the edges of the Sample the way we’d like and the surface texture isn’t as grippy. Neither of which are totally surprising, but still a little disappointing.

What’s next for intake?
We’re still tinkering with other intake styles entirely, currently looking at a possible claw mechanism over roller intake. While rollers present a better touch-it-own-it experience, we’re already fighting a big intake hurdle in that, being a Specimen-only robot, only 25% of all game pieces in the Submersible are ones we want. The logic currently being in Teleop, we’re going to have to be targeting fairly specific regions anyway.
The roller intake is still on the table and the current plan involves custom molds and making our own more-rubbery intake wheels…

[Jill_ls101]

I’ve been a bit behind in updating, so I’ll catch things up covering a couple of topics in the next few days. Starting with…

Boaty McBoatface

At today’s meeting, one of the things we did was put together our boat hook mechanism for the first time. The purpose of this was to test some geometries and see how the material handled being unspooled by the mechanism.

As CADed, we have a wheel outside the spool to help draw out the material to avoid the ‘pushing rope’ phenomena. Originally, this was designed to be a 3" compliant wheel, but it became very quickly evident that the wheel was under way too much compression. (Sorry, didn’t get a picture). But the wheel was very egg shaped.

So we downsized to the 2.25" compliant seen above, which remained in contact with the hook, but… didn’t keep the material far enough away from the drive axle for that wheel.

This resulted in some abrasion along the side of the boat hook.

Double unfortunately, the compliant wheel didn’t work as effectively as we’d hoped, with material building up around the spool. Partial cause is likely the too much compression from the 3" wheel, putting resistance between the spool and the wheel, so the spool expanded instead of deploying outward.

Moving forward, we’ll likely go back to the three inch wheel, which will keep the boat hook off the wheel drive axle, but move its position to give less compression.

Secondly, we’re looking into adding a shroud around the spool to keep it from expanding in though areas.

[Jill_ls101]

Oh no, I found a new hobby
One of the other things we’ve worked on this past week is iterating on our roller style intake system. Previously, the intake had 4 TPU stars, 75mm diameter to the outer tips. We found the TPU as printed to be too stiff and lacking in that grippy texture a COTS compliant star had.

So, we decided to try molding our own.

We purchased a two-part silicone rubber kit, and printed molds out of PLA.

The first attempt failed out of hubris. The pamphlet said ‘10 minutes at 150 F’ would cut the cure time down to about 10 minutes (instead of ~6 hours). Being impatient and wanting to play with it as soon as possible, into the toaster oven it went.

Unfortunately, the glass transition temperature of PLA is around 60C (140F). So, when the mold came out it was a bit… squishy. The cast rubber seemed mostly set though, so, out it came. Not. The rubber definitely was not set all the way through and stretched out as it was removed, and became a bit melty, as seen above. Once it fully set though, it definitely felt like a compliant star. Just, a bit malformed.

So, back to the beginning. An additional mold was created, this one with taller posts for the holes so they wouldn’t get covered over and walls to help prevent spills. The walls on the outside proved to be anti-helpful, as it was way harder to scrape excess material off. These stars sat overnight to cure, getting the recommended 6+ hours.

Even without mold release, the stars removed quite easily from the molds and were satisfyingly squishy upon release. This particular rubber has a shore hardness of 30A, making them slightly softer than the green compliant wheels/stars (35A) and way softer than the TPU filament (Bambu 95A).

Intake with Custom Stars 1*

Onto the intake the stars went and testing begun. The wheels performed well picking up the Sample from the wide orientation and onto the ramp largely regardless of the ramp angle.

In the long orientation (short end coming into the intake first), they struggled a bit. Once the initial lip passed by, the tips were too short to continue pulling the Sample in.

Intake with Customs Stars 2*

To combat this, the model and mold have already been updated, increasing the outer tip diameter to 85mm, but we’re into a waiting period on both making the new stars and testing them as we’re headed into our fall break, so meetings will pause until we come back on the 28th.

[*these keep giving me errors when uploading, will try to get them here later]

[Jill_ls101]

Long Time, No Talk

Well it’s been a nice break as we took off for fall break last week and there’s quite a few significant updates to discuss that’ve actually been around for a while, but, time off is nice…

So, without further ado, CAD:

Compared to the last CAD update, this is finally a robot with the potential to exist. The main structure of our robot is going to be sheet material. The jury is still out over sticking to our usual lasered 6mm Baltic Birch chassis structure or routing it out of 1/4" polycarbonate.

The major advantage to the wood chassis is the speed it can be created, as we’ve recently acquired a new laser (130W Thunder laser) which is way faster than our old one (Epilog 40W), which is still faster than trying to rout anything. (Since our new router is still not setup, alas, waiting on the electricians).

Wood, we’ve found is perfectly serviceable as a building structure, especially in FTC. But the aesthetics of the smoked polycarb is also quite satisfying. From a size standpoint the two are essentially interchangeable (6mm is approximately 0.236 inches), with minor tweaks.

Realistically, it’ll probably be wood, as right now, changing router bits mid-job on our existing router is essentially impossible without losing home and the need to have holes as small as 3mm and cutting out larger features such as the profile of the side panels would take… forever with such a small bit.

Intaking (x3)

Intake development continued before fall break and we’ve essentially decided to just not decide on any one particular style until we can put in on a robot.

The design is well suited to adapt to multiple different end-effectors, which has been set up as a configurable in our Onshape.

All intake systems are part of a virtual four bar assembly, mounted at the end of a linear slide system.

The first potential design is not one we can claim as our own. This design was created by the Seattle Solvers. We’ve done some minor tweaks so it would work with Rev/GoBilda servos as opposed to Axon ones (which I didn’t even know existed before this…).

The second design is still a huge work-in-progress. This is the progress of our over the top roller intake system as discussed in previous posts. Currently, there is some challenge in the packaging and getting it to fit in the available space between the intake slides. As of yet, the CAD is very TBD.

The third potential intake design is also not one of ours, but actually the intake of the FTC Everybot. When the Everybot was revealed, we identified the intake as one that likely is more effective than our roller intake, and could be easily adapted into our design.

So, some CAD shenanigans later and tahdah, there it is. Albeit, floating and not actually mounted in any way what-so-ever. But, it’ll fit in the space, barely, but, is definitely something we’re going to be testing.

Climb CAD Updates

Our climber system is a lot more buttoned down than it was before. There are some changes reflected based on the results of our physical testing. The compliant wheel mounting location was lowered to not be under so much compression. Additionally, spacer/standoffs were added to the back to keep the spool from expanding outwards so much when unspooling.

The pivot mechanism is not one of our favorite solutions, but it’s what we’ve got. With the eight motor limit and the way the robot is currently designed, something that we’d prefer to not be a servo was going to have to be a servo anyway. At present, 4 - drivetrain, 1 - climbing, 1 - intake deployment, 2 - lift system.

To (hopefully) handle the loads of the pivot joint on the climber, we plan on using a servo mounted onto a Gobilda worm gearbox. Worm gears are generally very difficult to backdrive, so hopefully this will prevent the servo from painful death the first time that joint is hung free and the chassis on one side of it.

As a side effect, unfortunately, this means the pivot is quite slow, but, ideally, it should never have to pivot more than 90 degrees to be aligned with the high bar.

The hook as shown in CAD is a (poor) representation of the stock hook that came with the boat hook. We’re gonna try using that first, because, well, why reinvent what already exists?

Some Minor/Major Obstacles Ahead
Where would robots be without robot problems?

Winch
Our lift system unfortunately lands right on top of the drivetrain, so routing the winch cable isn’t as simple as having a spool directly underneath the slides. There’s a plan to rout the cable with pulleys (as seen in green), which is okay, but, one of the bolts for said pulley landed in the intake slide system. Whoopsie.

The tentative plan is to incorporate the pulley into the 3d printed bracket at the bottom of the lift, but we also need to work around the limit switch that is also currently in that space…

Electrical (do we reallllllly need the control hub? )
There’s some decent space at the bottom of the robot, but access will be a challenge if we need to troubleshoot anything. Thinking ahead to wiring challenges, having a good system for handling the linear motion of the intake is a must. We’ve got tentative plans to make the specimen grabber passive (so that hopefully eliminates that wiring nightmare).

Climbing, Part 1
The astute observer will notice that we don’t actually have a way of getting the robot initially off the ground before finishing the climb with the boat hook.

Whatever we use has to both be within the sizing box at the start of the match and stay out of the way of both acquiring/scoring specimens.

In other robot news
18638 has continued working on the Rev starter bot, making great progress in each subassembly and will likely be onto putting things together soon.

As a side project (with the potential to become the main project?), one silly mentor [raises hand] decided it would be a good second project for 18638 to go ahead a build another robot…

So over fall break I put my personal print farm to work and, viola:

Some of the parts were modified to work with the Rev Ultraplanetary gearbox, as while the Everybot crew did a great job offering many different configurations, none of those configurations included the Ultraplanetary.

Whether or not 18638 goes with Rev starter bot or Everybot, I figured having more robots around the shop is never really a bad thing…

FUN Things
We did do some work over break, with two of our 17012 students coming in to record an interview with FUN on our progress.

[Jill_ls101]

Everyone is busy, and robots are hard

This image crops up in build threads from time to time and we’re absolutely in the thick of it. Individual schedules, some runs of illness, and general mid-season fatigue have stalled progress for a little bit.

Emotionally, sometimes it’s also hard to feel we’re moving forward when each step forward is a small nitty-gritty detail as we work out a few finer points in the design.

So, at the last meeting, we took a step back and worked on a few robot projects that fall into known categories and some-non-robot robot projects.

To keep moving forward, the team sat down and assembled all the motors we plan to use on the robot, attached the 5mm hex hubs to our mecanum wheels, and assembled the worm gear box.

The (not so) side project is putting together the FTC Everybot.

We’ve currently got two sets of parts printed, one for each team. The goal is to give students the opportunity to explore the design and giving them more opportunities to work on robots. Once the Everybots are assembled, they’ll be a additional drive chassis for the students to practice with and maybe even run a few in-house practice matches with a full field of robots.

Progress stalled on the drive train as we realized we had neither M4 or #6-32 bolts long enough to close off the tops of the clamshells. Once those are acquired, we imagine it shouldn’t take too long to put the rest of the robot together. The friction fit on the bottom portions on the clamshell is satisfyingly tight and snug.

17012 is also still planning on testing out the Everybot intake for use on our competition robot, so having one/two on hand will be helpful as we try to integrate it into our design. The hardest part so far has been finding all the components used, as a lot are Rev COTS parts. We have these parts, but 17012 tends to use a hodge-podge of FTC/FRC/custom stuff, so that plus new members, meant that very few had any idea what they were actually looking for.

Yay learning!

[Jill_ls101]

What’s been going on?
The teams have been making good practice the last two weeks, I’ve just been 100% swamped with non-robot projects that completely absorbed whatever freetime I once thought I had and I had to de-prioritize updating here. Thank goodness that’s over.

The 18638 robot is getting bigger, with the major pieces now constructed together. We ran into some difficulties getting the arm mounted to the gear.

The instructions state to align 4 bolts in the gear as shown on the left, in a line, and slide the extrusion down along them. But, we really couldn’t find the mythical 4 holes in a line the way it’s shown. I believe we ended up with 3 that were mostly in line.

I’m not sure if the gear we have is different (looks different than the one CADed), or what exactly. But the currently product listing/description seems to resemble the one we have, though the assembly as pictured on the Rev page does seem to match our gear and is different than the one shown in the assembly instructions.

Oh well. It’s on, so yay.

---

Closer to Everyness

Our Everybot build continues.

About the only assembly task left is to mount the arm to the superstructure and then we can start wiring/programming.

We’ve made several changes to the base Everybot, outlined below along with the rationale for the change.

---

Changes:

Drivetrain: Driven by HD Hex + Ultraplanetary Gearboxes with GoBilda 96mm mecanum
Why: Resources. We have these motors and wheels.

Clamshells - inset nuts: All clamshells tops were modified so nuts could be pressed into the covers.
Why: Don’t have to deal with both the nut and bolt during assembly. Also, we like the look better. Also, slightly sorter bolts.
Downsides: We didn’t modify the holes were the cross beam comes down, so the pieces are all now unique.

Pivot Motor: Switched to using 2 Core Hex motors instead
Why: Resources. Again, the Everybot doesn’t have UltraPlanetary configs, and while we could have modified the mount (or just used a Rev mount), for as much as I personally am not a fan of the Core Hex, it suits this task quite well. The output speed/torque were similar, and mounting with Rev brackets was pretty simple. (And we have so many of these that we never ever use)

Intake wheels: Switched to TTB 2" Squish with 3d printed insert to adapt 5mm to 1/2" hex
Why: Resources. We have no Rev squish wheels. We have crap-loads of 2" Squish.

Linear Slide Motor: Switch to HD Hex + UltraPlanetary with 1/2" adapter, 2" TTB Squish
Why: Resources.

Pretty much every Everybot change we made boils down to: We have loads of HD Hex and Ultraplanetaries and quite literally nothing else (okay, and some Core Hex motors).

What about our robot?
Production of parts began last week (no pictures, sorry )
All 3d printed parts have been printed and we’re prepping laser files, but cutting will not take long.
Metal parts have also been cut, some drilling still to occur.
All motor and gearbox assemblies have been made.

We’re not competing until January 26th, so while our progress might feel slow, we’re way ahead of where we’ve been in the past, and are taking our time to really fully explore the game, our robot, and other robots in a greater depth than we have before.

[Jill_ls101]

Every1

The physical build on our first Everybot is complete!

As documented in the posts up above, there were some hicups along the way, admittedly some self-inflicted. And as a full disclaimer, the amount of not reading of the build guide was high on our team. I’m pretty sure only the intake folks did any reading what-so-ever. The rest of the assembly was done mostly by referencing the CAD model.

Probably the most annoying part of the build so far was drilling the holes for the u-bolts. All of the other parts for the Everybot fit together really nicely without modification, but the drill guide we printed was incredibly tight on the extrusion and essentially impossible to get off, leading to a lot of hammering and some self-inflicted damage to the extrusion.

We were a bit smarter/gentler when removing the guide the second time, and produced less abrasion on the extrusion. (We were far too impatient to print a new guide for the second post). A modified guide will be printed for the production of Every2.

As can also be seen in the picture above, we don’t currently have PVC tube plugs in, as we definitely printed the wrong ones and they didn’t fit. As a result, team members learned that it’s reallllly easy to overtighten the u-bolts on hollow plastic pipe.

As mentioned in the post above, we elected to go with 2 Core Hex motors for the pivot joint as opposed to one of the configured designs from the Everybot. Using one of the standard mounting brackets from Rev, the Core Hex motors essentially just reach the outer edge of the frame perimeter, perhaps slightly past it.

The smaller herringbone gear as CADed is absurdly tight on the hex shaft. This is a bit of a catch-22, as since it is only the plastic to metal connection for driving the arm, a tight fit is preferred. The downside was a complete inability to move the gear on the shaft at all without the use of a mallet.

And one of the students put a dent in one of my classroom tables doing so.

Once the structure was finished, we began turning to electronics mounting, once again eschewing the as-designed way for our own.

The team elected to move the Control Hub because… reasons…

The original design has the Control Hub on one of the sides of the robot, mounted on the slanted rail. The students decided they did not like the look of the Control Hub being at an angle…

So, onto the back of the robot it went, into the spot the Everybot crew original dedicated for the battery.

Which did have to change.

The Everybot design included a battery mount for the Rev slim battery, but none of the other battery types. We have a whopping 3 of the slim batteries and over a dozen of the Pitsco batteries.

While we could have designed our own mount for the space, the team chose to harvest an existing battery mount from an old robot.

It is currently located on the back of the extrusion that spans behind the intake when the arm is down. As this was a last minute choice, it unfortunately is not mounted nice and securely with bolts, but rather with VHB tape (double sided sticky tape).

I personally have my doubts as to how well it’ll stay on being only mounted from the side and with the battery sticking out of the mount high to almost assuredly get boinked by the arm when it comes down, but really, what do I know…)

I have nothing to say about this picture of the intake, I just liked it and wanted to include it…

Every2
The plan still is for 18638 to build an Everybot of their own one they finish with the Rev starter bot. Unfortunately, that team lost a day due to some mildly inclement whether (and with many of the those team members walking/riding bikes to/from school, they couldn’t stay after). To help them prep and get building faster, 17012 students precut the extrusion and PVC for their team, and reamed out the holes in the 3d printed parts, to help speed up assembly.

17012’s robot?
CAD has undergone some major/minor overhaul to be documented in a post Tuesday or Wednesday.

We’re behind our hoped for schedule, but on-pace for our needed schedule.

[Jill_ls101]

Gobble Gobble

As alluded to, the 17012 robot CAD has undergone some significant revisions (mostly in the fine details) to prepare it for fabrication.

Drive Base

The base of the robot was finally finished off with the inclusion of a belly pan for the control/expansion hubs and gyro, and mounts in the drive rails for the battery and servo power module. The main structural elements are 2"x1" light MAXTube and 1"x1" peanut extrusion. Both on the larger side of the spectrum for FTC use, but available resources and budget say “yes”.

Both the hubs are mounted on risers on the board. This allows for the clearance of the gyro, placed in its preferential position of ‘smack-dab in the middle of the robot’, and to permit the routing of wires underneath the hubs.

Running wiring underneath the hubs is beneficial as it leaves the top of the hubs easier to access without sorting through wires running across them.

Access to the hubs will be challenging with the hubs buried deep in the robot, however, with 6/8 motors already being down in this space, wiring cleanliness won out.

Up!

In “things we should have figured out ages ago”, we finally have a way to get the robot initially of the ground for our climbs.

Mounted on the back of our specimen mechanism are two servo blocks with small hooks that can be deployed/retracted as needed. When in the deployed state, the hooks rest against the bottom of the specimen mechanism plate, so when climbing, some of the force will go into the plate, and not right back into the servo’s output.

This climb is only intended to be used for about a 1" lift, just getting the robot off the tiles, then the boat hook climbing mechanism will take over.

Speaking of Climbing

The climbing mechanism is now capable of being mounted to the robot (yay). The climber sits on top of the frame peanut, with the climber being mounted with bolts running through 2"x1" and 1"x1" MAXTubing.

Inside the tubing are 3d printed anti-crush spacers, reducing the likelihood of damaging the tubing during assembly (a problem we ran into with MAXTubing on our 2023 FRC robot). We’re using the light tubing, which should be sufficient for our FTC needs, and is readily available to us as we no longer desire to use it in FRC applications (and have quite a bunch).

Configurations are cool

One of the biggest CAD overhauls really had nothing to do with the design, and a lot more to do with using Onshape better than we had been.

We’re all mostly Inventor people around here, as that’s what in taught in classes and what I have 10+ years in, so switching to Onshape was a learning experience. (We switched because the IT folks took a long time getting the labs setup with this year’s Inventor license, so it was unusable for a long while).

From learning how to manage Inventor-style constraints vs. Onshape mates for assembly work (now better optimized! yay, it was bad at first…) to creating configurable parts, this build project has been a totally different challenge than just designing a robot.

In this latest CAD update, a lot of configurations have been added from the totally unimportant (robot sign color) to helpful tools (sizing boxes) and modelling various robot features (lift/intake deployment).

A quick rundown of our robot assembly configs:

• Quick transparency [On/Off]: Targeted changing of the opacity/color of certain parts for ease of assembly viewing. Suppresses the robot signs completely.
• Sizing Box [None/Starting Config/Max]: Drops in a surface showing the size of the robot relative to the sizing boxes of the starting configuration (shown as a 17.75" cube to maintain a buffer) and the max extension limit
• Lift position [Down/Low Chamber/High Chamber/Low Rung/Max/Free]: Down is retracted, the named positions go to their respective locations (currently dummy numbers), max is the maximum possible extension. Free allows the viewer to drag the lift anywhere they want
• Climb hooks [Retracted/Deployed]: Changes the position of the climbing hooks on the servo blocks
• Linear Claw [Closed/Open]: Shows the two main positions of the Specimen grabber
• Intake Type [Claw/Everybot]: Changes the two main intake mechanisms we are testing.
• Intake Deployment [Retracted/Partial/Full/Free]: Retracted is all the way stowed in the robot. Partial is an arbitrary spot in the middle of extension. Full is all the way extended. Free allows the viewer to drag the intake where they want it.
• Intake v4Bar Position [Retracted/Partial/Full/Free]: Same concept as the intake deployment, but with the virtual 4 bar mechanism instead.
• Intake Claw Position [Left to Right/Front to Back/Free]: Changes the orientation of the claw style intake
• Intake Claw Jaws [Open/Closed/Free]: Changes the positioning of the claw’s jaws

Have AMS, Will Print

There’s absolutely no reason we needed to make our robot signs as a multi-color 3d print. Besides the part where it’s fun and cool. The signs are reversible and will slot into their respective locations on the robot.

There was debate as to exactly where to mount the robot signs on the robot, running through a lot of different shapes of the side panels to see what would look the best.

But we ended up going back to the original shape of the side panel, and creating a bump-out section for the part where the sign sticks up over the edge, so the opposite color isn’t visible during a match.

There are lots of ways this could have been addressed and this is certainly one of them.

What’s Next?
Manufacturing. Lots and lots of Manufacturing.
And another FUN interview soon.