Team 4099 2020 Build Blog

End of Week 1 Update

Realistically, this will just be a weekly update barring needing to ask for help to fix issues or something very cool happening.

This week was interesting, as we were not able to meet in our normal build shop in school. We expect to get back to our normal build schedule mid-week 2, but this hiccup did slow down our fabrication team’s progress with prototypes a little. Even still, a lot got done this week, starting with design:

CAD Update


Yes, this looks like a snake to us, too. :snake:

The first couple of work days we had were used to work on the full system sketch. This is the first year we’ve done this in great detail, and it’s paid off incredibly well. Now, when the students are doing their detailed mechanism design, they start their part studios with a derived sketch from this master sketch and they have to think about very few dimensions, since they figured them out earlier in this sketch. The only downside is that making this sketch isn’t really effectively parallelizable, as far as I’ve seen, so the first couple of days had 9 kids huddled around one computer and they rotated who was actually drawing things in.

We drew a lot of inspiration from FIRST Capital’s design. Going into Monday, our intention was to build a robot that just shot for the OUTER PORT from the TARGET ZONE. However, based on the accuracy FIRST Capital was able to show shooting from the INITIATION LINE into the INNER PORT, we decided to try for inner port shots by modifying the robot concept to shoot from the INITIATION LINE.

This also simplified our concept greatly – initially, since one of our design constraints was to intake from the opposite side as we shot from, we had a double bend in our feeder which we were not confident in our ability to get working. This was because shooting from the TARGET ZONE required the shooter to be at least one robot length away from the port so the angle was not literally vertical. Therefore, since we had to shoot across our robot, the intake would have ended up on the same side of the bot as the shooter, forcing the double bend.

The downsides we brought up for this switch were that it’s easier to be defended on the INITIATION LINE because it’s not a protected zone, and shots need to be more accurate because it’s a longer range shot. Additionally, we’re not confident that we will hit INNER PORT shots with great consistency, so we may not see great benefit from this shift. However, because the point potential is higher, and it simplifies the design of the robot, we chose to stick with this concept.

The only major thing that should change from this sketch is the positioning of the intake pivot point – we noticed that as is, there is a 5" gap between the intake roller and the top of the feeder when we’re intaking. We are worried that the ball will sometimes shoot out of this gap, so will likely move the pivot point of the intake to be on that feeder roller and add something to stop the ball from flying out of the top.

Subsystem Updates

We’re planning on running chain in tube this year, because our offseason build of that style of drivetrain was successful and we wanted to build a small and narrow robot this year. The chassis will be 24" wide and 30" long with 6" wheels. Currently, our intention is to use corner omnis and center Colsons, but we have a 1/8" center drop and will be testing all traction wheels to see if the resistance to being pushed is worth the loss in maneuverability.

Our hope is the narrow chassis will make it more likely for us to be able to fit on the rung with wider robots while also making it easier to put our CG closer to the center of the rung when we go up. Additionally, for the first time, we will now be able to easily fit our full bellypan on our OMIO X8 router, making it far easier to machine (last year all the holes fit but we had to manually cut out the outside because it was just over the size of the bed).

image

The intake is modeled in many ways after 971 in 2016. We’re using 2" mecanums vs. their 4" ones, and the shape of the intake is different, but the concept is the same. We’re using a 1" OD aluminum tube at the front of the robot to prevent direct hits to the 3D printed Thrifty Bot mecanums when intaking from near walls. The side plates are going to be 1/8" polycarb, also to deflect impacts. While this may change because the intake pivot may change, the current plan is to drive the roller with a NEO 550 on a 4:1 reduction (similar RPM to what Ryan from Thrifty Bot showed in his example intake video). We want both the intake roller and the intake arm motors to be inside the frame perimeter at all times, so the roller is belted (that’s the far side of the image). The intake arm gearbox has some interesting packaging constraints where it is right now – we spent a decent amount of time figuring out how we would fit that in. With our narrow robot, this has to fit into the 3.5" of space between the 8" wide feeder (in the middle of the robot) and the side rail. With this design, the plan is to use a NEO 550 with some gear reduction to a VersaPlanetary 180 degree drive kit and a custom mounting plate, then use a 1-stage VersaPlanetary to drive the hex hub mounted to the intake plate. This would get the intake to move at a semi-reasonable speed (currently we have 6:60 into 1:10 for a stupid quick 614.8 deg/s). This will be a pain to get right for the programming subteam, which is one of the reasons we’re considering moving the intake arm up (more space for more reduction there).

We had most of this design done well in advance of the release of the Greyt elevator, but we modified the hood to be polycarb with standoffs once that came out. It used to have rails, but that was mostly because we had no idea how teams fastened polycarb to the standoffs with these types of designs (for those that don’t know, apparently it’s just zipties).

image

This is our Limelight attachment method. If you haven’t seen it already, check out @AdamHeard’s video on these Keystone 4337 angle brackets: https://www.youtube.com/watch?v=q-VbqeWwro4

They’re super tiny and super cheap, and for teams (like ours) that only have access to routers and no 3D CNC machining techniques, a great way to precisely line up things in 3D.

Our entire feeder assembly seems to have appeared between our last meeting and now, even though today was supposed to be a work-free day :angry:. But the general idea is very similar to FIRST Capital’s: the intake roller centers the ball and pulls it into the drivetrain, where the feeder rollers grab the ball and push it up. There will be 2" wide urethane belt running between the rollers. The reason you don’t see the bottom feeder roller is that one is going to go in the drivetrain, since it only mounts to the drivetrain.

We plan on having beam break or distance sensors along the ball path to detect how many balls we have, so signaling LEDs can show the drivers how many balls they still need to grab.

Initially, around the bend in this feeder, we planned on only having one roller. However, we realized that if we did this, one section of the feeder would have its polybelts off-center, changing the compression. Rather than worrying about what the new off-center compression should be, we decided to just go to two rollers at the bend, so the whole ball path will have the polybelt along the center.

The climber is, in my opinion, the most interesting mechanism on this robot, just because of design decisions we made due to not using pneumatics.

This design was also fairly heavily inspired by FIRST Capital. We’re using 1x1x0.125" tubing for the climber rails. We’re powering it with 2 NEOs geared at 10:72 on 12T #35 sprockets. This gives us ~1s actuation on the climber.

The interesting part of this climb is that the actual climb is heavily assisted by CF springs. The initial intention behind this design was to find a way to hold ourselves up after the buzzer without using a pneumatic brake, since the rest of this robot was done without pneumatics and we didn’t want to add them into this robot. One of our team members suggested that CF springs would work if they were balanced while holding the robot up. We realized that the heaviest CF springs sold by Vulcan (using the KOP voucher) were 40.9lbs, so we decided to use 3 of those per robot. We hope that even if we’re at max weight, the springs plus the gearbox friction and brake mode on the motors will prevent us from falling down.

More interestingly, though, if (as we expect to be) we are below max weight, and the robot is under 120lbs with battery and bumpers, we get an after the buzzer climb. This is a double edged sword, as if we are trying to line up a double/triple climb when the buzzer goes off, we may ruin the level state of the existing climb when the climber slams down. However, in matches where we are the only climbing bot, it would be quite helpful to be able to cycle till the last second and rush over to get the climb. This was not the initial design intention, but may end up being a nice bonus.

Unfortunately, it seems that the CG of this subsystem is quite high (25" off the ground!!) We hope that the other subsystems will drag that number down way lower. To that end, we plan on running belt up to the shooter wheel to move those motors down, in addition to the motor for the final stage of the feeder.

Other Subteams Update (far less detailed)

The mechanical subteam was able to prototype an intake and a feeder. However, due to some oversights in pre-season ordering, we did not have any long hex shafts for them to be able to test a full width intake with. They were therefore able to figure out ball compression for both the intake and feeder (2" seemed optimal for both), but not spacing from the bumper for the mecanum wheels. We will do more testing this week, especially after Tuesday when our new hex shafts will come in.

Programming wrote most of the basic subsystem code for all of the subsystems on the robot, and are currently working on signaling LED code, as well as state machines for multi-subsystem interaction.

One of the tools that made this way faster to do is our new ServoMotorSubsystem class, pretty much copied from 254’s 2019 code. What I think they realized was that almost all the code in subsystems like turrets, elevators, arms, etc is the same, because fundamentally all these subsystems do is move to a target position based on encoder values. The only real differences are the encoder values, units, and PID values. For our purposes, we’re able to use this wherever there is a servoed subsystem (intake arm and climber this year).

Things I’m Proud Of This Week

  • The whole team handled being out of our normal workspace incredibly well. The level of productivity stayed as high as I could reasonably expect given that our meeting location made it physically impossible to precisely cut prototype parts and some of our parts were just not accessible (stuck in the shop room).
  • Our design subteam is almost entirely made up of new members – the only returning members are the two design leads and the design mentor (me). Even still, design is ahead of the ambitious schedule we set at the beginning of the year. Almost all of the mechanisms are being worked on by new members exclusively (climber has both design leads). I’m very proud of the job the design leads have done in teaching CAD over the offseason, and even more proud of the job the whole subteam have done themselves, successfully taking on (and already nearly finishing) full mechanisms.
  • I set this up during our Saturday meeting :smiley:

Hiccups and Mistakes

I think one of the most important things about these build threads is when teams talk about mistakes they’ve made and how they’ve overcome them. We’re not quite far enough yet to have made massive mistakes with the robot yet, but we did make an administrative mistake a couple of days ago.

We try to avoid ordering parts for a mechanism until we have done a full design review of that mechanism. However, on Thursday, when placing one of our Vex orders for prototyping parts, we thought it would save some money to add in our drivetrain gearbox gears for both robots. We were fairly confident this would not result in an issue, because we had checked the gearing and were sure we would stick with it. However, while we had sketched the gearbox, we hadn’t done an assembly of it yet.

It turns out that the gears we ordered made it physically impossible to assemble the gearbox (the first stage output gear clipped the output shaft by a significant margin). It was an easy CAD fix, but it will result in a great deal of effort to now have to return the gears in question to The Robot Space (and a loss of at least $30 in shipping and restocking fees). If you’re reading this, please don’t rush orders this early in build season – it may end up costing you. We learned this lesson the hard way – no matter how confident you are, review before ordering parts.

Still To Do

  • Add climber support beams
  • Figure out feeder motor locations
  • Potentially move shooter motors down
  • Finish drivetrain
13 Likes

This is looking really nice, I hope you keep up this blog!

1 Like

Great updates. Really admire how you’ve laid out the progress and thought process. Showing teams examples like these of what they could aspire to present information in helps their fundamentals and seeing it from others reinforces that its not only our mentors who like to see these detailed updates.

1 Like

End of Week 3 Update

I skipped a week :grimacing:, so a lot has happened since the last update. Overall, we’re just getting into manufacturing, and all the box tubing for the practice bot has been machined, as well as bellypans for both robots. We do the bellypans first because they are the only part on the bot that requires the TubeMagic to be taken off of our Omio X8 (because they take the full bed size to fit). We expect that by the end of this week, the practice bot should be fully assembled and wired up for programming to test and tune. We expect that mid-late week 5, we should be able to start driver practice with that bot while the comp bot is being built.

At this point, we’ve decided to not worry about fixing some things in CAD to try to get a robot built quickly. There are details we could spend a while ironing out to perfect now, but we prefer to have something built so we can test and make potentially larger refinements.

CAD Update

By the way, the Onshape link for the bot is in the first post in the thread.

Drivetrain

We’ve done a similar bumper mounting strategy to what 254 has done for the past couple of years. I’m still concerned that we only have attachment points to the drivetrain right at the top of the bumper, but we’ll see how it turns out. Worst case, we can add some tube spacers or something in between the wheels to support the bottom of the bumpers.


As a result of the small size of this bot, we’ve decided to go with inserting the battery from the bottom of the bot. We are going to use rivnuts and screws to secure the battery holding plate to prevent the battery from falling out.

Intake

image
We added a second roller to the intake to reduce the dead space and hopefully prevent balls from flying out between the intake and feeder. The polybelt you see here connects to the top roller of the feeder. We’re concerned that potentially, balls will fly out of the gap on the right side of that polybelt (we can’t put a second polybelt there because it will interfere with the intake wrist motor when the intake is up). If this proves to be an issue later on, we will likely change the way we mount our wrist motor.

Feeder

We’ve settled on using 2 NEO 550s to power the feeder. This isn’t for any particular reason – we could just as easily have used BAG motors or 775pros, but since we have 4 550s we decided to use them here. If later, some other subsystem really needs the small packaging these allow, we can swap them out for 775pros. We briefly considered doing a gear+belt between the top side and bottom side of the feeder, but we suspected we may need two motors on the subsystem anyway and thought overall it would be simpler to just use two VersaPlanetaries.

The intake wrist motor (moves the intake up and down) is a 775pro on a 50:1 VersaPlanetary and a 18:56 gear reduction after that. We measure the rotation through a Mag Encoder in absolute mode in a hex bore housing. Because the intake is very light, we think we should be able to transfer the torque necessary to rotate it through just that one long hex shaft. If that doesn’t work, we can change that gear out for one with VersaKeys and attach the intake to that through bolts.

If you look at the structure of the feeder, there’s only one bearing/bushing hole that goes directly through the 1x1 box tubing. This was a conscious design decision – later on, if we decide to change the compression in the feeder, or the distance between rollers, or anything else, we now only have to re-mill the plates they’re mounted on rather than the full tubes.

Also, because they were so much cheaper (about 50%, I believe) we decided to use the Space Coast Products 18t pulleys on the feeder rather than the aluminum Vex pulleys. These will see very low load, and we honestly could have printed them from PLA ourselves, but we don’t have super reliable access to a 3D printer right now.

Final feeder interesting point: we decided to, for the first time, use shoulder screws and bearings for dead axle rollers in a lot of places. We’re using the 5/8-16 tapped inserts for the VersaRollers from Vex, then using 3/8" shoulder bolts to screw into those to create a super simple to assemble dead axle.

Shooter

That roller driven by a 775pro in the back used to be a belt stage in the feeder. However, we decided to swap that out for a single roller. The purpose of that roller is basically to stop balls from coming up into the shooter before we’re ready to fire. It also acts as something of an accelerator wheel, since it’s the wheel that will pull balls up from the feeder into the shooter flywheel.

We decided to power the flywheel with 2 NEOs on a 1:1 belt stage. The belt stage is for a couple of reasons – first, we wanted to take load off of the internal bearings on the NEOs – we wanted to avoid the radial forces generated by the ball pressing on the flywheel as the ball passes through from affecting the motor. Additionally, doing the belt stage makes it simpler for us to replace the urethane wheels if we ever need to do that.

There are standoffs around the flywheel – these are primarily for rigidity, but also for safety. Safety wise, they do two things: make it harder for people to accidentally touch the flywheel, and act as something of a barrier if the wheel explodes/delaminates.

Climber

The primary thing we’ve added is the climber supports. These are 1x1x1/16" box tubing and are fairly straightforward. Additionally, we’ve mounted the radio and switch to these supports to make them as high up (and far away from motors) as possible.

We also added plates to mount the chain to the climber carriage. This needs updating, because as of now, when the climber goes up, it clips the bearing blocks (reducing travel by 8in).

Other Subteams Update

We prototyped a feeder with the bend the way we did it – this was successful, and gave us the numbers for how much space we could have between rollers and not have an issue with balls getting stuck.

We also prototyped an intake and used that to iron down how much compression we wanted on the intake, as well as the distance away from the bumpers. We also tested this with multiple balls, and observed the same sticking/jamming effect other teams have noticed. However, we also found that simply doing a short pulse out and then continuing to intake pretty much always resolved this issue. As of now, we don’t think it’s a significant enough problem to fix for our week 1 event, though when we have time we will try to prototype/CAD an alternate intake + singulator and feeder. Most likely, it will look like 95’s or 3847’s.

Also, we have two milled bellypans and all the non-climber tube for the practice bot milled:

In the process, we did a skim cut on our TubeMagic, which since last year has had an issue where the middle of the jig is slightly out of alignment with the front and back sides. This made it so no matter how carefully we tramed it, there would be holes in the center of our tubes that would be off-center. We finally corrected this recently by doing some skim cuts along the aluminum rail the tubes square up against – now, the entire rail is aligned with the Y-axis of our router.
Programming got vision alignment working with our mule chassis. We are now able to (I think) seek the goal as well as line up to it precisely. They are currently working on getting path following working on that chassis using the Ramsete controller in WPILib. They also resolved a super weird bug with the drivetrain not stopping after the end of autonomous (caused by our use of “lazy” motor controllers, which was our attempt to reduce CAN traffic from previous years). This bug took enough time to resolve that we didn’t get to work on path following much, but the drivetrain characterization data has been collected so they should be able to get it working soon :tm:.

Electrical has crimped almost all of our motors and motor controllers with Powerpoles and latching connectors for CAN.

Things I’m Proud Of This Week

  • Mentors finished up most of the field part assembly we had to do. I personally didn’t do too much here, but @amanjaiman, @Siris243, and other (not on CD) mentors got stuff done. Embarrassingly enough, this is the first year since 2017 where we’ve had the field parts usable before the robot was ready to test them :sweat_smile:

  • The build space situation still caused issues for us these past two weeks, with some parts being left in our main shop on days where we didn’t have access to it. The mechanical team was still (for the most part) able to find things to do and worked around most of these issues really well.

  • Our mechanical team has figured out how to use a Boxford CNC lathe at the school. We haven’t used it for anything much since 2016, when it was used to cut a lead screw (don’t ask). Back then, it was operated by a student who graduated that year, and nobody (including mentors) really knew how to use the thing until we found manuals online this year. Now, we plan to use it for simple things like cutting shaft to precise lengths. Unfortunately, it doesn’t have a tailstock, so some potential uses for the machine are not available to us, but even just being able to cut shaft precisely is a big boost for quickly machining gearbox parts and such.

Hiccups and Mistakes

The biggest hiccup I can think of right now is that we’re in week 4 and we still haven’t shot a single ball yet. We had prototypes for a shooter semi-built back in week 2, but there were some issues with it that prevented us from being able to use it. At that point, we decided we were close enough to having actual shooter CAD and it wasn’t worth trying to spend too long figuring out a prototype. Since then, we have had some delays (I would have liked us to have built the aluminum shooter last week, but we had milling issues, unfortunately). Hopefully, we don’t need to make major adjustments to what’s in CAD, but even if we do, we do have a decent amount of time to do so. We’ve tried to learn as much as possible from prototypes built by other teams who are posting on CD, so hopefully things like compression and gearing won’t need changing.

Other hiccups include some major milling errors with our bellypan (unfortunately, a massive waste of aluminum:

We still aren’t sure what the root cause of this was, but somewhere between the contour to cut the bellypan out, and the contour that acts as a finishing pass for the gearbox cutouts and cuts out the battery hole, we had major Y axis errors. We checked the set screws holding the coupler for the ballscrew onto the stepper, which were very tight. In the end, we couldn’t determine precisely what the cause was, but we cleared out all the chips between the pocketing op and the contour op, and the next two bellypans turned out fine. The current theory is there was so much chip buildup near the ballscrew that it jammed the system for a while, causing it to lose a lot of steps.

Also, our new plan to not order parts until CAD was absolutely finalized has kinda come back to bite us – Vex was, as of our last order, out of stock of VersaRoller hubs. Our backup plan is to 3D print some hubs, but as previously mentioned, we don’t have reliable access to a 3D printer this season, so we’ll see how that goes.

Still To Do

  • Assemble practice bot
  • Test practice bot subsystems and code
  • Get autonomous paths to work
5 Likes

Feel free to ask on CD. Many folks will gladly print and send you parts, even in Onyx.

I can only do PLA+ though :slight_smile:

3 Likes

Have you tested how well this works? If you’re using the “run your storage belts continuously to bring up balls with a hard stop at the top to keep them from entering the shooter” method, we found you need a good amount of support at the top. We tried doing something similar, only covering half of the opening, but these balls managed to squeeze by the hard stop and enter the shooter anyway. We also tried something inspired by 118’s 2012 robot, but it managed to squeeze through that too. Those tests we also with pretty slippery belts, whereas it looks like you guys are using grippier polybelts.

1 Like

We haven’t really tested the roller effectiveness, but we also aren’t trying to run the storage belts continuously. Given what other teams have said about the ball compression, I don’t think the roller will be as effective in its current form, but hopefully it doesn’t need to be since right now it’s basically the last resort if we can’t properly space balls with sensors.

1 Like

To add to what Aidan said, we did do one test with a compliant wheel roller at the top, and when we ran the prototype feeder continuously, we did observe that balls were able to squeeze out of all but the smallest gaps between that top roller and the feeder. However, we also noticed that if we only needed to use that wheel for a short pulse (if a ball came in contact, pulse roller + entire feeder downwards) it did serve that purpose effectively.

Also, our tests were with a 30A flex wheel – I suspect we may get better results with a wheel that doesn’t compress as much.

Beginning of Week 5 Update


It drives! This video is from Sunday night — one of our captains and I missed the beginning of the Super Bowl to get it driving before I went back to college.


This year, by contrast to previous years, we’ve decided to build the practice bot before the comp bot as opposed to in parallel. We think this should help us iron out some assembly issues and make the comp bot a better product on the field.

This past week was basically getting the practice bot to the status in that video. In the process, we discovered a few issues:

  • The front bottom feeder roller (the one that attaches directly to the drivetrain) is not possible to install or remove after the braces it connects to are riveted in place. We had to remove one brace to be able to install it. We will most likely end up shortening the roller or something to make it more possible to maintain — it’s the part of the feeder most likely to take damage and the hardest to repair. Incidentally, this difficulty is why currently in CAD there’s 3” wheels on that shaft and not on the bot — we forgot to install them the first time around and didn’t want to disassemble again. We’ll try it this way and if it works, we save a few flex wheels.
  • There was a gusset to attach the H structure on the feeder to the braces which clipped the battery box :confused: Easy fix in CAD, should be fine on comp bot.
  • When using https://www.mcmaster.com/96349a203 to install rivet nuts, the tool is left hand threaded (probably to protect the aluminum threads in the rivet nut if you over-install it).
  • We need a better system to indicate which parts have been milled and which are in progress. Currently, our PBS sheet shows the status of a part, but I think we need a better way to show current (in inventory) quantity for both COTS and milled parts. This issue is why we only have one bumper rail on the bot as of now.
  • The drivetrain configuration currently on the bot happened in a very spur of the moment type of way. We discovered that we didn’t have enough omni wheels in stock to build 2 2+4 drivetrains. Since we had extra pneumatic wheels in stock from last year (thanks @mrnoble), and some teams are using the pneumatic wheels to reduce damage going over boundaries, we thought we’d try this type of configuration as something of a middle ground. As of now, the Colson wheels on this bot are worn down pretty significantly and don’t get much traction on the ground, so it’s really acting as a 4WD as of now — as a result we can’t see how effective the drive would be with even wear just yet.
  • Our team’s manual machining skills need work. Part of the problem is the tools we have access to and what we’ve trained with, but the other problem I think is we have too much reliance on CNCing all the critical parts, so when we have to manually machine things like shafts and spacers, our tolerances are awful (like worse than ±0.125” awful) because nobody has any real practice on this. Also, our current method isn’t ideal (hacksaw + file/sand). We have a CNC lathe that we’re just beginning to learn to use, so we could avoid the problem entirely by this time next year, but for shafts longer than ~10” we’re afraid to run on the lathe because we have no tailstock. Fixing this will likely be one our major offseason training improvements next year, as it made our drive gearboxes something of a pain to get right. Most likely, for the comp bot, we will buy OTS spacers to eliminate this problem.

Plans for this coming week

By the end of this week, we want to have started driver practice with a “fully functional” bot. This means controls and automation should not significantly change so the operator doesn’t have to relearn things. This is a mistake we made last year: the operator got so used to the manual controls we had early in the season that he didn’t ever want to use the (faster and more reliable) elevator presets for scoring.

In the next few days, we hope to get bumper structure done (plus enough of v1 of the fabric) so that we can send fabric and laser cutting SVGs to our sponsor for ironing.

Also by the end of this week, we want to have made significant progress on machining and ordering comp bot parts. By mid next week, we hope to have two full robots ready to drive, so that programming can tune autonomous while drivers are practicing.

8 Likes

End of Week 5 Update

This is with a decently tuned flywheel (it’s almost all feedforward) running at 5000rpm from about 9ft out. We shot 3 balls in an attempt to get an idea of recovery time, but we didn’t really get to test that because our feeder is still running pure open loop and we just couldn’t feed it balls quickly enough to get a good test.

This is from earlier, manually feeding balls into the shooter and running at max power (open loop) I believe from ~15ft out.

We made the decision to switch to using 60A neoprene Fairlane wheels instead of the WCP urethane ones because the WCP wheels were taking too long to ship. I had hubs for the fairlane wheels printed at my university on a Markforged printer, and so far, they seem to be working perfectly.

Still To Do

  • Figure out if our bottom feeder roller’s position is fine as-is. When we were testing the shooter, the intake wasn’t wired up yet, so we were rolling balls into the feeder by hand. It seemed that too frequently, the ball would just roll up against the feeder roller instead of being picked up into the feeder. This could be fixed by just having the intake behind it also spinning the ball forward, or potentially with the flex wheels we haven’t installed on that roller yet, so we will see if changes are required. If they are, the simplest mechanical solution for the comp bot (I think) is to just flip that brace which the roller mounts to upside down, lowering the position of the roller.
  • Figure out optimal flywheel RPMs per distance. We were beginning to test this (that’s what the first video is from) but my laptop died, and the programming members who were there didn’t have working Shuffleboard to adjust RPM values so we stopped after figuring out the one setpoint. Our plan is to input a bunch of RPM to distance data into Excel or Google Sheets and find a line of best fit (linear or quadratic, most likely) and use that line to calculate what RPM to use.
  • Add polybelt to the last feeder stage. We currently don’t have enough to make that possible, unfortunately, so we put surgical tubing over the rollers instead to allow us to run the subsystem. This technically works but isn’t ideal – the knots in the surgical tubing rub up against the wheel, leaving residue on the wheel, and the tubing doesn’t have pulleys to hold it in place so it slides along the roller. We are ordering the remaining parts today, so we should have it fully functional by the end of the week.
  • Add beam break sensors and implement feeder algorithm.
  • Test intake. This depends on finishing bumpers – the wood frames for this were almost assembled by this weekend, so we’ll see when the actual bumpers get done. Once they do, we want to make sure the centering and feeder action parts of the intake work effectively.
  • Assemble + test climber. Parts for the practice bot climber were just finished yesterday, so assembly will begin today. Since the first test of the shooter ran so smoothly, my worry about this robot not working has transferred to the climber. The whole season can’t run this smoothly, can it?
  • All the autonomous stuff. Primarily, this means characterizing the drivetrains and getting path following working on this chassis.
  • Building comp bot (all of the above, except on a powder coated robot this time)

We’re definitely behind schedule at this point, but we did have 2 weeks of lag time built into the schedule. It’s making me uncomfortable how much of that lag time we’re using, but I still feel confident we’ll be very competitive at our week 1 event.

4 Likes

Oh, I forgot to mention:

As we try to catch up on our milling schedule, we need some help to get our Omio X8 running at the speeds it should be at. Long story short, whenever we run at the speeds some have recommended for this router, the machine skips steps around sharp corners. To try to fix this, we’ve significantly cut down the speeds the machine runs at, but this obviously slows down machining times. Does anybody have a good solution to our problem or some diagnosis we may have missed?

1 Like

Pre Week 1 Update


You know, from this angle it really looks more like a 2019 bot than a 2020 bot.

We competed in a Week 0 event this Saturday, and it mostly went well. The climber had just been attached to the bot hours before we competed, but it still worked perfectly on the second try. The first was when we squared the input to the motor to make it more controllable in open loop, not realizing that this prevented the climber from going up because squaring makes the output only positive.


Just after the first climb – we’re on the left here. We probably should have talked to 1418 about us wanting to climb beforehand – instead, we went up in the center, then on their way up, they hit us. We learned two things here: discuss before matches (even practice matches), and the climber is able to support the bot on one hook.

Also, we’re very very excited about the climb because this is the first climb we’ve pulled off ever, I think (unless we hit one in 2017). It’s really incredible to me how much progress we’ve made since then, and I hope any of our students reading this realize how proud they should be of themselves for pulling off this robot.


This is just before our first match. That intake actuation is super satisfying :heart_eyes:. This is what happens when programmers get extensive time with a robot to tune things.


Still shot of climber up (first full actuation). It was super scary because the springs pull it down with a ton of force, so the operator had to be very very careful to not let it slam down when not on the rung. In fact, we bent a bolt and dented our bellypan significantly when it came down the first time without even noticing until inspectors pointed it out. We later realized brake mode made this significantly more manageable, and we were going to do that anyway to help hold the bot up post-climb.


Video of our second match at the Week 0 event. Things to improve include auto (we fixed it after this – the issue was we stored a timestamp in onStop instead of onStart :grimacing:, shooter speed calculations (apparently we somehow lost our quadratic regression calculation on this branch? should be fixed now, too), driver practice, climber automation to avoid the issue at the end of the match (should theoretically be able to hold the rung level until a buddy is properly hooked, then go up close to together), and beam break sensor implementation just under the shooter to prevent balls from getting stuck while intaking.

Unfortunately, we only got two matches at the week zero event, but we got the bot pre-inspected so we know what to look out for before week 1. That inspection process took like 1.5 hours, though.

Also, don’t know if you can tell from the pictures, but we somehow managed to wrap our blue bumpers in different shades of blue fabric. Not sure how it happened, but we apparently had some old fabric on hand and that caused the issue. Luckily we caught it before we sent the fabric to our vinyl cutting/ironing sponsor.

Auto Issues

My biggest worry going into Week 1 is our auto code. We can reliably hit 3 shots (if tuned, all in inner port) and cross the line. However, I’m not confident this will be enough to win the event. Overall, I’m confident that with some practice, our cycling + reliable climb will get us to the level where we can probably partner with a great auto team and it stops being an issue, but really it would be a lot better if we could get our path follow code working. Right now, the issue seems to be either a bad NavX or us missing something stupid:

Hopefully, we can get this worked out soon enough that we can at least attempt a >3 ball auto by the start of week 1, and hopefully tune it enough during competition to get it reliable by elims. Other than gyro issues, we seem to have figured out other issues we had (unit errors and the like).

Limelight issues

Not anything technical, but we were warned by a CHS LRI at Week 0 that there is a possibility they will rule the Limelight LEDs illegal at competition if teams complain about the brightness. I really, really hope this doesn’t become an issue. I’m sure it would cripple far more than just our team if they did this. We were told to bring a ring light to put around the Limelight as a potential backup plan, but the issue is 1) this was one week in advance of the competition, and we would need to do custom regulator wiring and whatever else is necessary for the ring light for the first time ever in that time, not to mention shipping time for the LEDs, and 2) we would have to find a ring light that was less bright than the Limelight, and there is no guarantee such a light would even work for our purposes while also being dim enough to not cause teams to complain.

Week 1 Preparation

We started the season well ahead of schedule for design, then due to CNC machine issues fell way behind schedule with fabrication. I’m probably not as concerned as I should be about the status of the competition bot (not fully assembled yet, but pretty close and mechanically identical to practice bot so hopefully minimal additional tuning?) Also, it’s good to have a backup plan (fully functional practice bot which we can compete with in the worst case).

But it does look very nice, so there’s that:

7 Likes

Got a chance to see your team at the CHS week zero and the bot looks solid! You all put yourself in a pretty good position with week 1 coming up. Please keep posting as the season progresses. I have really enjoyed seeing how your team has tackled issues and moved through this season.

Slightly Closer to Week 1 Update (wrote but didn’t post this yesterday)

Today felt like we made a lot of progress, but ended up being a bit of two steps forward, one step back.

As Parth talked about, we’ve been working on our auto using WPILib Trajectories. Today we figured out that our navX was calibrated incorrectly, since two years ago we had calibrated it for a vertical roboRIO. After fixing that, we had trouble with the bot slowing down in the middle of the trajectory and speeding up again.

We didn’t manage to debug this during the meeting, but after we realized that our kV and kA were in meters/second(/second) per volt, which we fed directly to the Talon arbitrary feed-forward, which expects percent output on [-1, 1]. This meant that the robot was going much faster than it should’ve, causing the Ramesete controller to correct and slow it down. Annoyingly, we actually fixed this bug on Monday, but tested with a different laptop today. The code which fixed it never got pushed to GitHub, so we accidentally reverted our changes.

Our competition robot looks a lot cleaner now, with most of the wires actually being ziptied down. We hit a snag with our shooter wheel - one of the bearings was put in with the flange on the wrong side, throwing off the spacing for the entire thing and pushing the flywheel off center. The only real fix for it would be to disassemble the entire shooter and flip the bearing. We’ll see if we end up needing to do that tomorrow.

The one notable omission on the competition robot is the climber. Most of it has been milled, but it hasn’t been powdercoated yet since it’s too large for our oven. We’re hoping to use the schools ceramics kiln to coat it tomorrow, so hopefully our milling goes smooth tonight.

On the bright side, we finally replaced the LED board on our 2nd Limelight, and it actually worked… but one of the Weidmuller connectors isn’t holding on to the wire well. We’ll have to see if this is an issue with the wire or if we’ll need to relegate this Limelight to the practice robot.

Some Week 1 concerns at the top of our minds are a lack of driver practice and a lack of batteries. Our practice bot is ready, but we haven’t had a lot of time in a gym lately to get cycling practice. We’re hoping to get a couple hours in tomorrow, but our driver isn’t able to be at our meeting on Thursday, when we need to load our trailer. We do have a half day on Friday, meaning we’re able to practice from 12 to 5 that day. As of now, the plan is to practice then with the practice robot and have our drive team come down late in the evening.

2020 Season End and 2021 Plans

A pretty great (though quite sad) recap video for our 2020 season

I wrote up a short update after week 1, and meant to give another update after events were cancelled. This is, of course, very late, but better late than never, I think.

After Haymarket, VA Week 1 Event (written right after event)


Student leadership addressing the team after we were eliminated

A lot of the weekend didn’t go exactly like we’d have liked, but we’re optimistic we’re still on track to reach DCMP, and (assuming we improve significantly for week 3 and beyond), potentially qualify for champs.

Saturday morning


Team dancing during field delay (technically, the picture is the field delay just ending and everybody just about to walk back to the stands)

Post-Cancellation

We were all pretty upset about not being able to compete week 3, especially as we had just gotten our shooter tuned in, a 6 ball autonomous working, and our intake + feeder upgraded. But after we got past the immediate grief of losing a competition season, we quickly moved on to creating plans for doing robotics (and our normal offseason plans) in a socially distant environment.

What Went Wrong in 2020

After event cancellation, we had a meeting to talk about the things that went well and things we could improve for next season. The list was quite long, but I’ll share a little of the “things to improve” list as it relates to doing better competitively:

  1. More driver practice. This one is pretty obvious, and something nearly every team would benefit from (even those at the very top). Historically, our problem has been that our robots are not completed quickly enough to get any meaningful amount of driver practice. This year, though, we finished our robots earlier than usual but still didn’t get that much practice. We learned that it’s important to have scheduled practices in a usable facility for driver practice – we often had the issue where the drivers were not available at the same time that the robot was ready to use, and that the space we had to practice in was not great (if we drove fast, since the carpet was not affixed to the ground in any way, the carpet would slide a ton, etc).

  2. If it’s not tested, don’t compete with it. This year, our practice bot was ready for week 0, and it competed there. We also had quite a lot of testing time with that robot, tuning the shooter and getting it fairly accurate from many distances at home. Unfortunately, we made the mistake of thinking that in the couple of weeks before competition, we could get our all black powder coated robot together quickly enough that we would be able to get it to perform identically. This was a mistake, and in the future, if it’s not ready a week in advance of the competition, it won’t compete. Had we used our practice bot, the shooter likely would have been a lot more accurate, and the drivers would have been able to practice more (some components were stolen off of the practice bot to make the competition bot work, rendering it somewhat inoperable).

  3. My personal favorite: make sure to review match footage carefully before deciding what to change for later events. Going into week 2, when we were making changes to the robot, we heavily prioritized auto, shooter tuning, and intake fixes, putting feeder changes as something of an afterthought. After events were cancelled, though, we looked back at match footage, and it became clear that the feeder was the biggest problem we had outside of driver practice. The initial gut feeling of what we thought the problems were drove our decision making process, but it ended up being incorrect.

FalconCamps

Usually, during the summer, we host RoboCamps, our youth outreach camps based on team 1678’s camps by the same name. These camps use the VEX IQ summer camp curriculum to get young kids (elementary and middle school) interested in STEM and robotics. The kids who have participated in the last couple of years have had an excellent time, and those who have come to our high school since have joined our team.

These camps are really great, because 1) they get young kids involved in STEM, 2) they provide a more consistent pipeline of robotics-interested kids into our team, and 3) they are one of our most important revenue streams for running our team. Unfortunately, they also obviously rely on in person meetings. We knew that with students staying home all of summer, some type of camp would be something many would be interested in, but even in March, we were not confident in being able to have in person gatherings for camps in June or July. We briefly considered stay-at-home VEX IQ camps similar to what some on this forum said they’re doing, but we were not confident in our ability to properly sanitize all the kits and ensure no spread of COVID-19.

Fortunately, two of the strongest areas of our team are design and programming, both topics that can be taught in a socially distant setting more easily than most robotics concepts. That’s why this year, we chose to create FalconCamps (not gonna go into too much detail about what FalconCamps are; there’s more info in the linked thread). Today (6/22) was the first day of the first session, and it went well (or so I’m told by the counselors).

Nearly all of both Design and Programming FalconCamps were planned, written up, and executed by our extremely hardworking and talented students. I could not be more proud of the job these students have done over the past few months putting together an excellent curriculum, doing advertising, making the website, and more. I pretty much only had to do minor reviews and corrections. Anybody who has organized camps like this knows how difficult this stuff is, and these students pulled it off without a hitch :slight_smile:

Offseason Robot Redesign V1

The other project we planned to do after event postponement was a robot redesign. Before we knew how long COVID-19 would impact the world, we were thinking that money we had saved for DCMP registration could be rolled over into next season, while we would maintain most of our fundraising for 2021 as well. This led us to plan an ambitious offseason where we were going to try swerve for the first time. We started to CAD a very ambitious offseason robot (short turreted swerve robot) with the expectation that even if large parts of the robot didn’t work, the primary goal was to implement new-to-us mechanisms for the first time to hopefully be able to use them in future seasons.

When FIRST announced that the 2021 season would reuse the 2020 game, we postponed these plans somewhat, because we felt that whatever we put significant effort into during the offseason should now be something that is going to be competitively viable for us. As a result, after FalconCamps end, we’re going to work on our offseason robot redesign V2.

Offseason Robot Redesign V2

We haven’t really talked about this as a full team yet, so the following are my personal thoughts rather than team decisions.

During most build seasons, for teams to be competitive, they need to make a tradeoff between driver practice/testing and more robot features. The vast majority of the time, teams (including our own, usually) go for more features, resulting in competitive failures. This year, with people practicing social distancing, we’re in the unique position of not having to make these tradeoffs. We can CAD and program a complex robot, and it won’t take away from driver practice time – because we can’t practice now anyway. Of course, there will still be tradeoffs in terms of testing time (more features means more total testing time needed to get to the same quality of output) but this tradeoff is a lot less severe than it is for most seasons.

For this reason, I’m currently of the opinion that we can go a little more ambitious during our offseason redesign than we would during a normal competition season, while still being confident that we’ll be able to produce a competitively viable robot. I don’t think the initial short turreted swerve is viable, but something that looks a lot like 2056’s robot (but less insane software) would be a good option, I think.

If you’ve made it this far down the post and think this mindset will sink us competitively next season, please let me know before we meet to discuss plans, haha.

New Sponsors

Historically, one of the biggest barriers to our team’s success has been a lack of driver practice. This year, even though we had time to practice, we didn’t have a great place to do it, which was one of the biggest reasons we didn’t get as much practice as we would have liked. We’re currently in tentative talks with local businesses who have enough space for at least a half field, but hopefully a full field. This would be great for us, since otherwise the closest practice field to us (that we know of) is an hour away, and transporting tall robots far away is a chore (again results in less practice than would be ideal).


Overall, while 2020 did not go at all as we expected, we hope and expect that 2021 will be a historically good season for us – if things go well, we should be able to address nearly every problem we had in 2020.

4 Likes

We’re Back!

ooh, shiny

With the 2021 season effectively being a continuation of the 2020 season, and with most of the design process of this robot being in one post, I think this thread can just be for the combined build log for the two robots.

Also, if you stop reading here but have thoughts on the robot design, we welcome (and actually, are actively asking for) any feedback! Hopefully there are people who are bored over this vacation.

Also also, if you stop reading here, we’d like to thank a ton of teams whose work both inspired us and made our jobs a lot easier. This robot is effectively a Frankensteined bunch of robots we liked various parts of, so we really couldn’t have designed this without those teams.

How did we get here?

As I briefly mentioned in the last post, we planned on doing a redesign of our 2020 robot for (whatever happened with) the 2021 season. We made plans for this for two reasons: this gave us a unique opportunity to be able to look at flaws in our 2020 robot and make massive revisions to them, and we really wanted to at least CAD and program a new robot for 2021 to make sure that students had as much of the FRC experience as possible even during the pandemic. With that in mind, we planned on having our team kickoff in mid September, after the school year started and a couple of weeks of workshops to get new members at least able to participate in the strategic aspects of kickoff.

Of course, nothing ever really happens on schedule, but in this environment, that was totally fine. We took a relaxed approach here, allowing for more workshops to be fit in before kickoff, and especially before CAD work really started. Our initial plan was for kickoff in mid September, but we pushed it to the end of September for more workshop time, and then only started CAD in late October.

Kickoff and Strategy

One of the new things we tried this year was in response to a discussion on how to avoid overreaching in the future. In the 2020 season we did a pretty decent job of this (our issues this season were not, I think, primarily due to kickoff strategy) but in the past we’ve definitely had trouble with this. The conclusion we came to was to think about if we can concieve of any robots at all at the highest level of play we’re realistically trying to reach that will skip a given feature. If it’s something that any robots at that level of play could realistically get away without, we would have to have some really strong justification to consider that feature ourselves.

With that in mind, we also decided to immediately discard that philosophy for the 2021 season :slightly_smiling_face:. Just kidding, but we did decide that with this effectively being an offseason robot, we could pick a couple of areas to try something fancy, with the hopes that we could learn how to do those mechanisms effectively in case we needed something similar in a future year. Also, if we had decided to stick to the zero overreaches strategic approach for this robot, we would probably have built something very similar to our 2020 robot, and that would not have been nearly enough of a challenge.

One of the “fancy” things we decided to try, before we even talked about strategy during kickoff, was swerve. We had been thinking about doing swerve for a couple of years at this point, and with the low cost of the Thrifty Swerve and the pretty good WPILib support for swerve at this point, we decided this offseason was probably the best time we would ever get to try swerve for the first time.

Other than swerve, we didn’t have any features we considered to be “fancy” until way later in the build process.

So using our new “no overreaches” plan, we realized that in 2021, we could actually have data on what robots at the highest level of play did, rather than just having to guess. We categorized a bunch of teams into “tiers” (Einstein bound, DCMP first pick, etc) and tried to analyze what strategic actions those teams took. We emphasized that what we cared about was not what those teams had the capability to do, but rather what they actually did in matches. Of course this was not perfect, since we didn’t get to see gameplay beyond week 2, but it helped us catch things like low robots that preferred to cross the generator switch area rather than go under the trench (the idea being that if they didn’t actually go under the trench there’s no advantage to being shorter).

https://docs.google.com/spreadsheets/d/1G0P4CUBFCePQ3ktBITnnOWEw00GQtA3zMPmn2Tz6hsE/edit#gid=0

Based on this analysis, and goals we came up with beforehand, we decided on the following needs, wants, and wishes: (everything below wishes are things we didn’t consider)

As for the 2020 season, the needs are things we design the robot around, wants are things we try to fit in if it doesn’t add significant complexity, and the wishes are things that we don’t actively try to fit in at all, but if it’s a trivial change to make them happen, we will do it. An example of treating “shoot beyond control panel” as a wish would be to pick hood angles and everything without considering the long shot, but then if it turned out the angle we picked could be used for the long shot, we would consider adding a flywheel setpoint for it.

The Process

One of the other new things we tried this year was to take a scrum-based approach to building the robot. We had been looking at this since midway through the 2020 season, after we heard about other teams using a similar structure. Basically, our implementation of this was to split the team into robot subsystems, rather than just subteams like mechanical or design or controls, to allow for each group of students to take a broader approach to the robot. This way, even students focused on software would get a little bit of mechanical experience, and vice versa. We hoped that this would both broaden students’ horizons and allow for more continuity in work (so people work on the same project every meeting, so they can see progress etc). On that note, we also decided that each student would have to sign up for both a technical and a non-technical subteam, even if they decided they primarily wanted to focus on one side of that. This was for two primary reasons: first, to get more students to take part in our business and strategy subteams, which we needed, and second, more importantly, to better achieve a part of our team mission, which is to show more people that STEM can be fun. This way, students who join primarily for a non-technical subteam would still do at least a little of the robot work, so they might potentially realize they enjoyed it more than they initially expected.

With everything being online for now, we also decided we would significantly scale back on meetings. Our student leaders brought up (and I agreed based on this semester of university being online) that when being in a Zoom call for a long time, it’s significantly more difficult to stay productive than at an in-person meeting for the same length. That, in addition to having no hard restrictions on time for designing this robot, led to us scaling back meetings to two 1-hour meetings per week, rather than the normal in-season schedule of 2-hour meetings every weekday and a 6-hour meeting on Saturday.

So, how did all of that go? After writing all of this out, I realize we stuck to this a lot better than I thought we did. On the note of widening students’ horizons: we did a pretty good job of that with the technical/non-technical stuff, resulting in us having more activity in our non-technical subteams than I can ever remember. For the “give mechanical people controls experience” side, though, I definitely hope we do better in future years. Most of the issue here was, I think, because of the nature of online calls rather than working in person. If we had both design and controls in the same call, people would just be talking over each other as they worked on different things, so we ended up splitting the calls, resulting in very little of students doing work on both. I think with in-person meetings in the future, though, this may get better.

For the meeting times: for most of the design process, we did stick to two one-hour meetings per week. The initial goal was for a lot of the work to be done outside meetings. Historically, we haven’t really been able to do this because our team is relatively new to doing CAD (going into 2020 we only had two CAD students with even a year of CAD experience). This year, that was a lot better, so some subsystems were able to get a lot of work done outside meetings. However, there were still a couple of subsystems that had primarily new CAD students who needed more help to do work, so those subsystems did have to expand to three meetings a week in the last couple of weeks as we came up on our self-imposed deadline.

The Software

As with the 2020 season, I was not very involved with the software side, so I have little insight into how the software developed over the past couple of months. If you look at our code and have questions, though, I’m sure someone on the controls team can jump in and answer anything.

The Design

Yeah, this is the section with the pictures.

Drivetrain


We chose the Thrifty Swerve modules primarily for their cost-effectiveness. After kickoff, we did the math, and based on the hardware we already had in stock (some motors + motor controllers), using Thrifty Swerve compared to other modules like the WCP modules was nearly half the price. With the aluminum saddle and after looking at the stress test videos Ryan put out, we were confident that there would be no downsides for our purposes to the Thrifty modules.

The other interesting design decision here was how heavy this subsystem is. Without bumpers and the battery, the drivetrain weighs 43lbs on its own. This is because the bellypan is unpocketed 1/8" aluminum, and the side rails are unpocketed 1/8" 2x1. We made this decision largely based on looking closely at 2056’s 2020 robot, when compared to our own 2020 robot. One of our goals this year was to make the robot more controllable, and part of that was to make the robot less tippy. Our 2020 robot, in response to 2019 being nearly overweight, was super light – we weighed in at our competition at 90lbs. But a lot of this weight was fairly high up, resulting in a robot that was apparently pretty difficult to drive. At competition, we tried to address this by adding ballast mass to the drivetrain, but finding a good attachment point to make things secure was pretty difficult.

This year, we realized that teams like 2056 used 1/8" sheet metal for their entire drivetrain, likely making it fairly heavy. We realized that there’s no point in lightening everything, only to later come back and add weight back to the drivetrain. Instead, we decided to start with a super heavy drivetrain and remove weight later if the CAD was looking like the robot was too heavy. The first place to cut weight from this robot is everything other than the drivetrain, then reducing the side rails to 1/16" wall, then reducing the bellypan to 0.09" thick, then pocketing the bellypan.

Teams Who Inspired This Mechanism

  • 2056 - large and apparently heavy drivetrain, makes design easier and lets you push through defense if necessary
  • 2910 - the bumper mounting is directly taken from their 2019 robot
  • 1678 - the compressor mounting is directly taken from their 2019 robot
  • 1323 (?) - the plates on the outside of the side rails to widen the frame perimeter to allow for attachments to the side there

Climber


Since we tilted back the feeder to allow the shooter to be far back on the robot, we couldn’t just use a single stage elevator like last year to climb. If we had done this, the top of the elevator would have blocked either our own shots or at least the field of view of the camera to see the vision targets. Based on this, we decided to use a telescoping tube design. The best examples of this that came to mind were 1114 and 2056, and 1114 graciously shared screenshots of the CAD of their 2020 telescoping tube climber. Based on this design, we have the inner tube extending with constant force springs, and being winched back down to elevate the robot.

To keep the climber up at the end of the match, we have a pneumatic cylinder, which when extended, goes through the inner tube and prevents it from extending. This is on a single solenoid so at the end of the match it will automatically brake, so a last second climb will hold.

The shaft across the tubes is meant to prevent the tubes from flexing towards each other. In 1923’s reveal for this year, we could see that before they added a similar beam, when climbing on a non-level rung, one of the tubes would flex towards the center. We may end up changing this shaft to something more substantial like a tube spacer.

Teams Who Inspired This Mechanism

  • 1114 - released screenshots of their climber CAD, which we took inspiration from (especially the bearing attachment and the pneumatic lock)
  • 2056 - for the original design of the 1114 climber
  • 1923 - the strut across the climber tubes to prevent flex

Intake


This is the first pneumatically deployed intake we’ve ever done. For the last couple of years I’ve taught the design students how to do pneumatics in a sketch, based on that one 973 RAMP video, but we haven’t used it (2019 and 2020 both had motorized wrists for us). This year, we had to use pneumatics because swerve eats our motor slots, so we finally got to make the controls students’ lives easier.

We have three rollers, all powered by one Falcon 500. We chose this motor so we wouldn’t have to package a motor controller nearby on the moving subsystem (compared to a NEO or NEO 550). The bottom roller has 3" compliant wheels on it, so the linear speed on it is higher than the other rollers (which are just bare polycarbonate). I think the advantage of the faster bottom roller is that the balls come off of the ground faster, so we don’t drive over them, though to be honest we picked this architecture entirely based on 3847’s success with it. Usually we would prototype, but without in person meetings, that’s way more difficult. We chose this over our 2020 robot’s mecanum wheel intake because we realized that with mecanum intakes when compared to full-width roller intakes it’s just not possible to intake multiple balls as quickly from a wide area.

an aside on mecanum intakes

I think the lesson we learned here is to avoid mecanum intakes, and anything that centers the game piece outside the robot before lifting it off the ground, in games where you have to hold multiple game pieces. Even if a mecanum intake centers the ball in 0.1s and then pulls it in, that means you can’t just drive through that ball and into the next one you want to grab. Instead, you have to stop at the first ball, wait for it to come off of the ground, and then continue, unless you want to risk driving over the ball. In a game like 2019 where you only want to grab one cargo ball, this waiting time is fine, since driving through that one game piece doesn’t give you as much of an advantage. But in games like Infinite Recharge it significantly slows teams down, which you can see in a lot of teams’ match video when they try to grab balls from the open field.

In addition to the rollers, to add rigidity to the intake, we have a couple of tube spacers that just bolt directly to our intake plates.

This is the cross section of each of the rollers we’re using. To make swapping out the rollers easier, we decided to use dead axles here. From left to right: we have a shoulder screw, a bearing, a spacer, a hub for the roller with an integrated pulley, and a heat set insert for the shoulder screw.

This will be the first time we’re trying this, and the first time we’re printing parts that need the heat-set inserts. There’s a couple of issues I can foresee with this, that we would appreciate feedback on.

First, I’m not sure how well a roller like this would take even light impacts. Theoretically it shouldn’t need to take any real impacts because of our tube spacers, but you never know how things may play out, so I would like to make this stronger if necessary. Currently, the shoulder screw goes all the way through the pulley to try to get that steel part to prevent the pulley hub from delaminating, but I’m not sure if that will work. We also plan on printing the hub out of a strong nylon to try to make the roller as strong as possible.

Second, I’m concerned that the installation of the heat set insert will deform the plastic around the shoulder screw enough that it won’t fit in the hole anymore. It’s currently a pretty tight fit so that the shoulder screw properly adds strength to the part so a little deformation would cause a big problem.

Teams Who Inspired This Mechanism

  • 3847 - the spacing of the bottom roller from the bumper and from the ground, along with the overall 3-roller architecture, is directly taken from them. Also, the idea of using dead axle rollers to make roller replacement easier is, I think, from them too.
  • 973 - the positioning of the tube spacers (overall this intake looks a lot like the 973 2020 intake)
  • 2056 - the polycarbonate plate we’re using to guide the balls in the right path over the bumper
  • 319 - nothing directly copied as far as I remember but we looked a lot at pictures and CAD of this intake for inspiration
  • 1678 - the pneumatic cylinder mounting is copied from their 2019 offseason bot, and the mounting for the intake pivot is not copied from that same bot based on their recommendation

Hopper and Feeder


This mechanism was one of the more challenging ones to package. We decided at kickoff to use a passive funneling mechanism similar to 973 and 2056 to center balls into a linear feeder. The panels for this funnel needed to 1) continue funneling even with the weight of a few balls on top, 2) fit on top of the swerve modules, and 3) connect somewhere that wasn’t being used by swerve modules, the intake, or the climber. Fitting on top of the swerve module ended up being easier than we initially expected, but the other two resulted in our changing the funnel material from polycarb to aluminum.

We needed two motors on this subsystem: one for the bottom sliding floor, and another for the vertical feeder section. This arrangement, along with a couple of beam break sensors, is intended to allow indexing balls in the vertical feeder section.


The really large plates here are acting as both gearboxes and supports for the 2x1s that go up to the shooter. In this picture, the left side motor powers the sliding floor, and the right side motor powers the vertical portion of the feeder (directly belted for one side, and using a gear to flip the direction for the other side).

These plates still need a little work – we need to add beam break sensors to allow for indexing balls, and the plate pocketing needs fixing (mostly because it could definitely look nicer). We also want to add some passive mechanism for balls to be centered inside the vertical funnel part. Most likely, we’ll end up doing what 2056 did with unpowered polycord rollers on the sides forcing the balls to the center.

The vertical part of the feeder is tilted back to allow the shooter to be as far back on the robot as possible, to allow us to take the target zone shot.

One other interesting part here is the crossbeams that the hopper and feeder are mounted to. For the 2020 season, we had similar crossbeams, but we put them in the profile of the drivetrain, as opposed to now, where we have the crossbeams on top of the drivetrain. We did this to increase modularity – now, theoretically, we can assemble the full drivetrain and the feeder separately, and then just assemble them together. We can also then easily replace the feeder if it somehow breaks.

Teams Who Inspired This Mechanism

  • 973 and 2056 - the general architecture of the hopper + feeder with the passive funneling
  • 2220 - tilting the feeder back to get a better angle for the shooter (and actually a lot of the robot architecture – if you look at 2220’s robot it’s very similar to this)

Shooter

Initially, the plan for this mechanism was just to do a single position hood for a robot designed to shoot from the trench. We mostly finished the CAD for this super early on, though, so to give students more to do, we decided to also CAD an infinitely variable hood (with linear servos) and a pneumatic two-position hood. Primarily, the goal was to be able to hit the target zone shot, after teams like 1690 demonstrated incredible 3-point accuracy from a couple of feet back from the wall.

The two position hood was designed to take these two shots – the trench run shot and the target zone shot. To maximize the chances at the 3 point shot, we picked a 65 degree angle from the vertical to release the balls, allowing us to hit the inner port if we were a couple of feet back from the wall. For the trench run shot, we used a 24 degree angle from the vertical, which is the same as we had last year, because we had some success for the medium to long shot with that angle last year.

One issue we’ve had with the two position hood so far is that it seems that we can’t use a single Limelight to see the goal both from 2ft away and from ~30ft away. Currently, we’re planning on trying the beta Gloworms and using two of them, one for the close shot and one for the long shot. The nice thing is that the close shot camera also may be able to help drivers line up the climb, if that’s necessary. If we have any major issues with the Gloworms, we can relatively easily change to using the Limelight we already have.

Compared to our 2020 robot, we also changed our inertia wheels (from large aluminum disks we made in house to the SDS COTS flywheel), motors (from NEOs to Falcon 500s), and the gearing (from 1:1 to 1.5:1). The motor and gearing changes will also help us with taking shots from the trench run. I’m thinking, though, that whenever possible, we want to play the front court game (just grab balls from the opposing loading station area) and take the target zone shot) since we should be able to swerve around defense more easily than most bots.

Missing from the CAD currently are the polycarb plates that act as the hood backing, the ziptie holes in the 3D printed curved pieces for that, standoffs in the back for stiffness, and the Gloworm mounting.

Teams Who Inspired This Mechanism

  • 3940 - varying the compression along the hood to better deal with damaged balls
  • 3476 - the adjustable hood design, which we almost directly copied (we changed the actuation to pneumatic rather than motorized)
  • 1690 - their accuracy at the inner port from the target zone inspired us to try the two position hood

Things I’m Proud Of

Honestly, the fact that anything at all got done in a timely fashion given the nature of this season is really impressive, and it’s even more impressive that the students were able to design something of the quality that they did.

I’m also really happy with how our process changes worked out. There’s probably a lot that we did this year by necessity that we will do in future years because it just works better. For example, we may have CAD members not come in every day but instead do a lot of work over video call.

On an individual level, I’m very proud of the new design members, in particular in the shooter group, who took charge of the design of a pretty complicated subsystem and took initative to learn to keep their group on schedule.

And finally, I’m proud of myself for finding the time in my least favorite semester at university to be able to help these students design the best robot we have done yet.

Next Steps

We currently have plans for a contact-free build process. We recently got a machining sponsor, who will likely make a lot of our sheet parts, and the remaining parts and tube can be run by some combination of our experienced students + a parent and myself in our shop. We’re planning on doing the machining like this, limiting contact down to zero (nobody is interacting with new people directly in this process), then kitting parts together into totes alongside some tools to allow volunteer students and their families to do assembly by themselves. In theory, there shouldn’t be any need for tools beyond a rivet gun, allen keys, a screwdriver, and a drill to do most of the assembly. This way, we plan on building the robot without having any in person meetings. We plan on starting this next week.

After the robot is built (hopefully by mid-February), we need to start doing some type of driver practice. Most likely, for now, this will just be giving the robot to the driver and having them do drills by themselves in a basement or on carpet on the pavement outside or something.

We’re really happy to get back to doing robots, even with the process as different as it is this year. Hopefully, future blog posts will be more regular (and therefore, not quite as long :slight_smile:)

14 Likes

Your team may find it beneficial to have your (lead) designer(s), builder(s), programmer(s) and pit crew monitor how the robot performs during matches from as close to the field as possible. It gives them insights that would be difficult to get from just speaking with the drive team after the matches. We also had instances where we could see/hear something indicating particular components had failed and the pit crew went back to the pit to get the replacement parts and the necessary tools ready for when the robot returned.

2 Likes

Per your recommendation request on the intake pulley-
based on our experience doing something similar last year I don’t believe you will have a problem with that basic design. I like how you are using the shoulder bolt to give some more strength to the pulley. We tested something similar out of pla and then carbon fiber abs versions made it onto our robot. As far as the heat set insert goes, you definitely could end up with a build up of melted plastic beyond the insert that would mess up the bolt. One trick we have done is to make that hole have a taper so that there is less plastic being pushed to the bottom as you are setting it. Just my .02.

1 Like

Yeah, this definitely is valuable, and I think we’ve actually done a good job at this part over the years. Of all of the issues we’ve had at competitions, being slow to identify a failed component has not been one of them (I remember a time in 2018 where we had a wrist chain snap in QF2 and before the match ended, the pit crew prepared a replacement chain length and installed it in time for QF3).

What I was referring to more there is using data (even qualitative data) to identify what needs upgrades on the robot for a later event, rather than just going off of the feeling we have of what needs fixing during competition. In the 2020 example I was talking about, coming out of our week 1 event, we really thought the intake was the weakest link on the robot, based on watching matches at the event. What I’m saying is it’s helpful to do a post-mortem a couple of days after the event, where you watch matches with a cool head, to actually identify if that feeling during competition was accurate.

Thanks for the advice! One other thing I was considering was to have a channel or something right past the depth of the heat set insert so that all of the built up plastic could sit there rather than clogging the shoulder screw bore. I was also considering doing the installation of the heat set insert with a shoulder screw partially threaded into the heat set insert, so that the shoulder screw would be guaranteed to fit in the bore, if that makes sense. Do you think these would be helpful?

1 Like

I’m wondering if you even need to heat set it, or if torquing the shoulder screw is enough to pull it into place. It’s not like you’re putting torque through the connection?
Of course heat set would be stronger. But I’ve been avoiding distributing solder kits to my students for take-home assembly, so maybe there would be value in skipping the step this year. Moot if you do it at the lab.

3 Likes