5119 Open alliance build thread

[Andy-5119]

Team 5119 is excited to get involved with the open alliance for the 2023 season!

Our Team’s Background
We are a low-mid resource team from the Kansas City area. We are still looking for our first regional win, but have been gaining a lot of momentum in recent years. We are really looking forward to this season! The Open Alliance has been a great resource for our team, and we hope to give back to this community in every way we can. Last year, we competed at the Heartland regional, ranked seventh after quals, and were eliminated in quarter finals.

2022 Season
Our robot last year was a fender shooter with a mid climb. We prioritized and achieved simplistic robust design in our mechanisms, but failed to compete at the level of the top teams at our event.

Here is a more comprehensive reflection of our robot last year for anyone who is interested: https://docs.google.com/document/d/1vIuJaEE3qGM4UBHMRHfKzLgo6yXTJaj4fMUfxgOkjYc/edit?usp=sharing

2023 Expectations
This season, we are planning to share a STEP file for our robot each week, as well as layout sketches for important geometry on our robot. We will post weekly updates in this thread with robot progress.

We are looking forward to a great season. Good luck everyone!

[mmongar]

Good luck this season. 5013 looks forward to seeing what you have learned along the way and to compete with you at Heartland.

[ngreen]

Thanks Andy and Team STEAM.

Look very much forward to seeing your progression this year, and think you will get a lot out of open alliance.

I was thinking during Cowtown how far your team has come along, and that you have a lot of pieces in place to be really successful this season. Having the students, mentors, and partners to do that is no small feat, and I think the fundamentals you’ve built into the program are ones that will be more lasting than just a single season.

[Andy-5119]

Thanks!

I am looking forward to seeing what 1108 comes up with every year. You all have always been a great example of a sustainable team in our region, and I really appreciate what 1108 has done for our team and the Kansas robotics community.

[Andy-5119]

With build season fast approaching, I thought I should provide a little more information about our team’s manufacturing resources and processes

Build season Schedule:

We will come up with a more rigid schedule once we know what we are going to do this season, but our build seasons tend to go something like this:

Week1- decide what we want our robot to do, begin prototyping
Week2- continue prototyping, have a complete robot in cad
Week3- Begin manufacturing, get parts sent out to be cut by sponsors
Week4- assembly, have a complete robot by the end of the week
Week5-Competition- drive practice, iterate on subsystems, software

In the past, to organize parts and tasks during build season, we used 1678’s parts tracking sheet. This year, we are going to try to use this spreadsheet. It combines all of the critical resources our operations sub teems need including gantt chart for the schedule, PBS sheet, a sheet to track COTS parts, and a sheet that tracks motor slots, their respective positions in the CAN loop, and CAN IDs. The PBS sheet is based off of 3512’s PBS sheet found here.

Manufacturing resources

Our team is lucky to have a pretty complete shop:

• Basic power tools: horizontal and vertical bandsaw, drill press, mitre saw
• Tormach CNC mill. We don’t use this much because of the upfront cost of training, and the speed that we can make parts in build season
• CNC router: we can only use this for wood and polycarbonate, but it is very useful for prototyping and making intakes
• 30W Laser cutter: literally the only 30W machine I have ever seen, but it gets the job done for plywood prototypes. We don’t do any Delrin because it is so expensive, and would take so long to cut on our machine
• 3D printing in materials like PLA and PETG
• A sponsor with a laser who cuts aluminum for us.

Design style

The most efficient way to make robots for us is to lean pretty heavily on our sheet metal sponsor. This means that we use a lot of tube and gusset construction. By standardizing the patterns we put on tubes, we avoid doing any CNC work on them, and we just use jigs to drill all our holes. Anything that passes outside the frame perimeter (in general) is made of polycarbonate and can be machined on our router. We probably won’t use MAX tube this year because we already have a large stock of regular rectangular tubing.

Some important parts of our structures:

• Crush blocks. These allow us to bolt through tubes, and can be easily and cheaply 3d printed. Most of the time, we like to use rivets and gussets to attach tubes to each other, but in places where modularity is important, bolts and crush blocks can be used.
  You can also embed nuts into the crush blocks:
  
  The result is a structure that is strong and can be assembled and disassembled quickly.

• Bearing plates: to avoid having to machine precision bearing holes, we often use plates, cut by our sponsor, to capture bearings. The plates just bolt to the outside of the tubes. The added benefit here is that, since we mostly use thin wall tubing, we can use plates that are thicker than the walls of the tubing, increasing the life of the bearings. Here is an example from an elevator we have been working on:
  

CAD processes

We use solidworks and have found a variety of processes that make it super effective for our team. Here are the important parts of our workflow, and some useful features in solidworks that I thought I would highlight:

• Layout sketches: these are the core of our workflow. We use 3512’s style, outlined here. This consists of a top level layout sketch document, which captures crucial geometries like intake and hopper rollers, positions of mechanisms like elevators, drivetrain dimensions, etc. The subsystem sketches show more specific locations of tubes, motors, gussets, etc. Splitting up the layouts sketches like this makes our CAD more editable. Members can work on subsystems simultaneously without having to worry about conflicts in the layout sketches. All of the geometry in our parts is derived from the layout sketches, so the entire robot can easily be edited. An added benefit of using this method is that most of the parts can be mated into the assembly using their fundamental planes which is super fast and more robust than other methods.
• Part templates: Use them. 3512 (I keep referencing them but they have developed some great resources for SolidWorks) has a collection of them here. We use most of the same ones, but use a few of our own templates.
• Pattern driven component pattern: I am going to start getting into the more specific solidworks features that I use. Hopefully all of these are well known, but I thought it could be useful to talk about them. This saves us a lot of time in assemblies. It allows you to pattern components based on a pattern created at the part level. For example, if you had a pattern of rivet holes, and wanted to have a rivet modeled in each hole, you mate one rivet into the assembly, then select the rivet and the pattern feature, and the rivet will be patterned to all of the holes.
• Designing with symmetry: I like to center all of my parts, and robots, using layout sketches, along the fundamental planes. This allows you to easily mirror parts or features. Since robots are often pretty symmetrical, it can save a lot of time. Honestly, having access to assembly mirrors is the main thing keeping us from switching to onshape
• Derived mirrored parts: When I first started CADing, I did not know about this feature and wasted a lot of time mirroring parts. This feature allows you to select a plane in a part document, then create a new part by mirroring the old part across the selected plane. To save even more time, You can also do this at the assembly level using the advanced assembly mirror functions
• Mate references: when using a parts library with solidworks, these can save a lot of time. Basically when you drag a part into an assembly, it will be automatically mated into the assembly using the mate references. For example, our BHCS document has a mate reference on the edge of the screw between the body and head. When I drag it into an assembly, and position it over a hole, it snaps to the correct position, concentric with the hole, with the bottom face of the head mated to the surface above the hole, then adds the mates
• Custom macros or plugins for solidworks: I have started exploring using these to streamline my workflow. I have a macro, which I use regularly, that generates a spacer based on user entered dimensions, saves it to the same folder that the assembly is in, then inserts the part into the assembly. This can save a lot of time when using custom, 3D printed spacers. I also wrote an addin that we use to generate PBS sheets. It allows you to select parts, enter data like manufacturing process and status, then adds a line to an excel spreadsheet for the part with all its data. From there it is quick to copy and paste the information into our parts tracking sheet. I kind of don’t know what I am doing when it comes to programming, so I do not feel comfortable sharing these right now, but I would encourage teams to look at their design processes and find creative ways to automate them.

Part numbers: Our part numbers follow this format: 5119-00-XXX-00-00 Where the first set of 0s represents the year, XXX is a three letter abbreviation of the subsystem, the second set of 0s represents the subassembly in the subsystem, and the third set of zeros represents the part number. For example, 5119-22-ELV-01-05 is the fifth part in the 5119-22-ELV-01-00 subassembly of the 5119-22-ELV-00-00 assembly, which is the elevator subsystem. The top level, robot assembly is named 5119-22-000-00-00, and layout sketches follow the same format, except they say LAYOUT at the end, so 5119-22-000-00-00-LAYOUT is the top level layout sketch for the 2022 robot, and 5119-22-ELV-00-00-LAYOUT is the layout sketch for the elevator subassembly.

File structure: the robot folder contains the top level layout sketches, top level assembly document, and files for each subsystem. The subsystem folders contain the subsystem assembly document, subsystem layout document, and folders for each subassembly, which contain the subassembly, and its parts. Sometimes we have parts that belong to the subsystem, but not a subassembly (PN would be something like this: 5119-22-ELV-00-01). Those go into the subsystem folder.

I know nothing listed above is particularly groundbreaking, but I thought it would be beneficial to share our processes as context for our build blog. Thanks!

[burakdemirelli]

On the crush tube example, assuming the tube on the right is something like a drive rail which is constrained on both ends, do you still use crush blocks? If so, how do you service it?

Or another way to put it: Do you guys use crush tubes on the middle of a tube rather than the ends as well?

Also how does the 3D print hold up? Do you consider in which orientation it is printed so the layers hold up better under any side load maybe?

I think we might implement a similar approach this year, so I would love to hear more! Keep it up.

[Andy-5119]

yeah, we have used the crush blocks in the middle of a tube before. I find that with the right clearances around the block, they are pretty easy to position just by tilting the tube to slide the block to the center, then using a pick to catch it through the holes. We use the KOP drive, so I don’t have any experience using them on drivetrain tubes, but my gut tells me that they would be fine to use without needing to service them. I probably would not use the embedded nut style, and just bolt through both tubes though. One thing you can consider is adding a screw that passes through the wall of the tube, then just taps into the block (strength does not really matter here) to retain it side to side.

TBH, I have never really worried about print orientation with these blocks, and they always seem to be fine. I guess the way I look at it is that if I was printing a spacer, I would just do it vertically on the bed, so I always just print them with the holes extending up perpendicular to the bed. If you have holes going in both directions though, I don’t think I would worry about it. The one thing I always do though is use 5 or 6 perimeters, so there is a little more plastic around the screws.

[Andy-5119]

Kickoff recap for our team

Hi everyone,

Here are some early observations we made about the game:

• This is a very programming heavy game. Lining up cones without good vision will be difficult, and balancing, ideally, should be optimized.
• Picking up tipped cones off the floor will be difficult
• Cubes should be pretty easy to intake
• As a KOP drive team, maneuvering behind the charge station could be difficult
• We might have an easier time balancing on the charge station than swerve teams
• Scoring cones is extremely important since there are more places for them
• A pink arm seems well suited to scoring on all three levels
• We could mabe look towards this year’s FTC game for efficient cone intaking

Some potential strategies:

• Scoring on the lower levels will be easier. A robot optimized to get RPs would be good at scoring quickly on the low levels, getting as many links as possible for the link RP, and be good at balancing for that rp. A robot scoring on the lower levels could have a lower CG and be better at balancing on the charging station
• For getting many points, because of the distance between the HP station and community, scoring in the top levels is better. Cycle time matters less when scoring at L3 and L2

Our current priorities

• Score at all three levels: For our team, this seems feasible (This is definitely subject to change). As a non-swerve team, we won’t be able to keep up in terms of cycle time, so we can try to score more points each cycle, and be a valuable first pick
• Intake cones upright off the floor, and from the HP station: cones are the most important game piece this year, and could be somewhat difficult to intake. Manipulating cones should be emphasized in our early prototyping.
• Versatility: To be a good first pick, we should be able to complement an alliance captain. We want to be able to adapt to their strategies. This probably means intaking cubes as well
• Automation: try to automate as much as possible to help the driver. This will help offset our disadvantage as a non-swerve team
• Balance in auto: we won’t be able to score a lot of points in auto due to our drivetrain, but we could be good at balancing during auto, also important for getting the balancing RP
• Due to the tight space between the charge station and grids, planning will be essential to having good matches (this also plays into the versatility aspect). We should invest resources into understanding the game well, and determining the best strategies for certain situations. Scouting is important

All of the points above are subject to change based on the developments from other OA teams, Ri3D, and our own prototyping. That said, here are some things we want to explore this week

• Cone intaking: this will be challenging and important to our strategy
• Pink arm geometry to see if it would be reasonable for our team
• Getting a test bed set up to test balancing and vision for our controls subteam

Good luck this season!

[Andy-5119]

Pink Arm CAD

we will post a more detailed recap of our week on Sunday, but since we are about to move into manufacturing our pink arm, I thought I would share our design:

Design constraints:

• 2x2 tubing for the outside and 1.5x1.5 tubing for the inner tube- these tube sizes are light, relatively cheap, and easy to order from WCP.
• Maintain at least 8" of overlap in the extended position- this is pretty self explanatory. This should help keep the arm from braking as easily.
• No bearings smaller than .625" OD- same thing as above. I don’t trust .5" OD bearings on this kind of stuff
• Easily manufacturable with our resources- this means only 3d printed parts and aluminum sheet, no billet parts.

Bearing blocks

Front:

here, we are using .25x.75 bearings around the tube. Since the shortest distance between the inner face and outside face of these bearings is .25", and the gap between our tubes is the same, we can mount the side bearings on dowel pins and sandwich them between the tube and a plate. There is a 3d printed spacer that retains the dowel pin front-back. the top and bottom bearings are mounted on a bolt that passes through the two side plates. 3d printed part on the top of the tube retains the bearings axially on the bolt. they are not load bearing.

Rear

Due to the size constraints inside the tube, we were unable to have bearings on the left and right side of this bearing block. The top and bottom bearings are .25 ID x .625 OD bearings that ride on 8-32 threaded standoffs, which are supported by the aluminum side plates. The 3d printed part serves a few purposes. First, it retains the bearings axially. Second, It also acts as the mounting point for the belt, which I will talk about later. Finally, it also constrains the motion of the inner tube side to side. It has a protrusion that overlaps with the side plates (so it is only loaded in compression) that rides on the left and right sides of the inner tube. We added clearance for some PTFE tape on that surface to help it slide easily. The 3D printed block is held into place by the two standoffs.

Powering the Extension and Retraction

the pink arm is internally rigged using a 15mm HTD 5 belt. this fits well between the tubes, something we could not get with chain, and is a lot simpler than using dynema and spools. A pulley in the top right of the picture is rotated by a neo on a 3:1 ratio. It passes outside, over the top of the tube, around an idler pulley mounted on the front bearing block, in between the tubes, contacting the surface of the inner tube. When it hits the rear bearing block, it jogs down through the block, where it is clamped to the inner stage. This was necessary because there is not enough room in between the tubes to clamp the belt and have a straight run through the outer tube. Finally, it circles around a pair of idler pulleys at the rear, and hits the pulley again.

Tensioning

to tension the belt, we are using a WCP turnbuckle made for chain. This is less bulky than other solutions, and we already have these stocked at our shop. a 3D printed tooth profile is clamped between two aluminum plates that connect everything to the turnbuckle.

Wire Management

the wires are held in a .75" wire loom. This is lighter, simpler, and cheaper than a cable chain. It is zip tied to the bracket in the left of the picture that extends down, and it is zip tied to a tab on the intake (not yet modeled). The black block to the right of the picture is 3d printed and slides along the length of the tube. on it is a pulley that the wire loom is wrapped around. It is tensioned back with a constant force spring mounted to the far right of the picture. When the arm extends, it pulls the top face of the wire loom towards the left. The 3D printed block and pulley are allowed to move to the left, but a force is kept on them tensioning the wire loom as it travels.

Rotational Motion

The arm pivots on a pair of acetal 1" ID x 1.125" OD bushings from WCP. these are retained in the aluminum gearbox plates, and pass through a 1.25" clearance hole hole sawn into the tube. a REV 64T #25 sprocket is bolted through a 3d printed spacer and through the wall of the tube. The gearbox is located on the supper structure.

We are trying to push the arm through pretty quickly because we don’t have experience making these types of mechanisms, and we wanted to give ourselves the chance to make as many iterations on it as possible. Nevertheless, we thought our design could be helpful to other teams brainstorming solutions, so it would be beneficial to share this early in the season. Let me know if you have any feedback or questions!

here is the link to our graced partner space
I saved a Parasolid of the pink arm with the name 5119-23-ARM-00-00. The native solidworks file is named the same

[Connor_McBride]

grabcad link appears to be broken

[Andy-5119]

I think it should be fixed. Thanks for the heads up.

[Andy-5119]

Week One Recap

Prototyping for our cone intake went very well, and we were able to finish V1 CAD this week, one week ahead of schedule. Here is an overview of the robot:

Arcitecture
we chose to do a single stage pink arm with a belt powered extension. The geometry for this arm worked out while leaving a reasonable amount of overlap between stages. We can score at all three levels and intake with a single manipulator on the pink arm. Although the arm itself is relatively complex, it is really the only subsystem on the robot, so it is approachable for our team. The arm is supported by a tube superstructure that bolts to the chassis. through 6 bolts, good for modularity. We are still using the KOP chassis due to budget constraints.

Intake

prototyping the intake was the biggest challenge for us this week. We settled on this design. It picks up upright cones between the top rollers and cubes between the bottom roller and the standoff at the bottom of the intake. This means that it can intake both cones and cubes with the same arm position, lightening a bit of load on the drivers and our controls sub teams. The geometry of this intake did force us to add a pneumatically actuated wrist that tilts the intake down before scoring on the high level, lining the cone up better. The pivot is a 1" aluminum tube rotating on a Delrin bushing from WCP. We also prototyped the intake with a bar that dropped down in front of the wheels to catch the brim of cones facing towards the robot, flipping them up. This idea worked great, but we chose not to include it in the first iteration due to packaging constraints. Here is a video of our prototype picking up a cone: https://photos.google.com/photo/AF1QipMvh2J8Fz0rwauKvQm9dzgIiK2-FLMuKeTYDjzg

and here is a picture of all of the important dimetions:

Arm

The arm has not changed much since the previous post. As suggested by @howlongismyname, I changed the sprocket to a 58T #35 sprocket from AndyMark that should be a lot stronger than the previous one. I also added a REV through bore encoder 1:1 with the arm for absolute position feedback. It is connected to the arm through a timing belt. I took extra care to mount the encoder so it would have as close to the exact c-c distance as possible, reducing backlash in the connection. The arm is powered on a ~100:1 ratio through two max planetaries and a sprocket reduction to the arm. We are using a WCP #35 chain turnbuckle to tension the chain.

Superstructure

I don’t have much to point out here. The main uprights connect to the base tube through a pair of gussets. Diagonal 2x1 supports help brace the tubes left to right and 1x1 supports brace the structure front-back. Due to the unique geometry constraints for the forward braces, we are using 3d printed blocks to mount the tube. both tubes bolt through crush blocks to the flanges of the KOP chassis

What will next week look like?

we are probably going to have a slower week two. We are waiting on parts to come in from suppliers and sponsors. We will start marching the intake plates and the superstructure tubes since we already have the materials for those stocked. We are hoping to have the full robot done by the end of week 3, hopefully with the intake done a bit sooner.

Good luck with everything you are working on!

[Andy-5119]

Week 2 Recap

As predicted, this week was a little slower. Most of the week was spent making 3D printed parts, waiting on COTS parts, and waiting for our sponsor to cut parts for us. That said, all of these came in before Saturday, and we were able to have a productive meeting then. As we stand, almost all of our parts have been manufactured, the superstructure, chassis, Prototype intake, and inner stage of the pink arm have been assembled. In addition, we have started on the electronics layout.

Here is a picture of the assembled supper structure:

what will become the arm extension gearbox:

and our prototype intake, made out of laser cut acrylic before we take it to Polycarbonate. We are still waiting on some gears to come in to complete this:

What’s Next
We are hoping to get this robot working mid-late week 3. The intake will be the prototype one pictured above, but it probably has a few iterations before we have anything final. Rushing the arm and superstructure manufacturing like this will allow us to get something to controls earlier and have a test bed for further intake iterations.

[Andy-5119]

Week 3 Recap

This week, we made some pretty good progress on our robot! We completed every subsystem mechanically, leaving us only with wiring to finish before we get it off to controls. Here is a update on each subsystem

Intake

The prototype intake is all together. We decided to make the first iteration out of laser cut acrylic before we take it to polycarbonate. This allowed us to get it done quickly and cheaply for testing. Hopefully we will be able to do some testing with it mid-late week4

Overall, this came together really well and we are happy with how it is going so far.

Arm

As you can tell from the picture, we are not quite done wiring, but the tubes and bearing blocks are all in place and the pivot is done. I am pretty happy with how the telescoping motion came out. It feels rigid and smooth (though maybe a little tight) . The arm pivot itself went together quickly and feels smooth

We did have a few issues with it though:

The stack up of the superstructure not coming out perfectly square and the arm pivot tube floating around in the bolt holes results in the arm coming out slightly off center when extended over the frame perimeter. We don’t think it is enough to effect performance but is still noticeable.

We might decide to live with this or redesign the superstructure with the following changes:

• use max tube to try to get a more accurate structure
• include a plate on the inside of the main uprights where the pivot tube connects that locates the outside of the tube in a counterbore. Just having a bolt that passes through the uprights into the tube nuts (what we have now) is not really enough to properly hold the tube in place.
• save the arm gearboxes’ bearings by adding another chain reduction that would take some of the radial load off the MaxPlanetaries. This was something I chose to ignore on the first iteration in the interest of getting the robot off to controls, but that does not matter much if they already have something to work with

Additionally, the pulley that the wires wrap around was too small. The pneumatic tubing could not make the bend. I am thinking about fixing this by moving the cable pulley to the side of the arm so we can make it much bigger and maybe moving down to 5/32 tubing.

Overall, I am happy with the progress on the arm. We should have something functioning off to controls before the end of the week and we are planning on making a second arm to swap out if something breaks at competition, so we have plenty of time to clean up the above issues.

As you can tell from the pictures, we have a lot of wiring and cable management yet to do. Right now, I am hoping to get a functioning robot off to controls very soon, definitely before the end of the week. We don’t have any experience making arms, so, all things considered, I think we are doing pretty well. Hopefully, we can iterate on the arm and superstructure to iron out the issues described above.

We hope everything your team is doing is going well!

[Andy-5119]

Week 4 Recap

We finally got the robot ready for controls!

It is not entirely complete, but it is safe for the programmers to start working. That said, we have decided to build a second iteration of the superstructure and arm for a number of reasons: we wanted to have a spare arm at competition to swap out during competition in case of catastrophic mechanical failure, we did not have time to get the wiring to a place we would feel comfortable with it at competition, and because we wanted to iron out the issues outlined below. Building a second superstructure and arm will allow us to refine the robot without cutting into the time controls needs to make our robot competitive.

REV 2

Here are the problems we saw with our original design and their accompanied solutions in the next revision:

Wire management on the arm

The first issue we ran into with this is that the original pulley we planned on wrapping the excess wire going to the intake around was too small. If the wire loom was actually held to it, it would have crushed the pneumatic tubing.

We are solving this problem by moving the cable pulley to the side of the arm, allowing us to increase the diameter of the pulley. In addition, to combat some binding we saw in the block that slides along the arm tube and constrains the cable pulley, we switched to bearings contacting the tube. Here is are the new blocks:

Another problem we ran into was that there was no way to run the wires back up the arm (and to the PDP) from the front. Since the wire pulley guide surrounds the tube, we can’t just zip ties the wires to the tube.

To fix this, we added a piece of aluminum angle running the length of the arm:

The wires will just zip tie to the angle and be protected.

Arm Alignment

Probably the most notable issue we have seen with the robot so far has been with the alignment of the arm. Here is an picture that kind of shows the problem:

note that part of the problem in this picture was that the inner telescoping tube was not made correctly, so the intake was not mounted strait. The more annoying issue was that the arm itself was slanted to the right (relative to looking at the front of the robot, as in the picture). There is not one part causing this. It seems to be a combination of a few things:

• The tube that the arm pivots around is not held to the superstructure well enough. It is just held on by a pair of 1/4-20 bolts that pass through the uprights, into tube nuts in the tube, so it is not constrained very well parallel to the inner face of the uprights. We also saw that when the arm moves, the chain pulls the pivot down, loosening the chain and making the arm alignment worse
• The whole rear of the superstructure leans to the right. It is very close, but this issue is amplified by the long arm.
• one of the diagonal braces is slightly longer than the other, twisting the uprights a bit. Again, very slightly but little differences matter here.

To solve the alignment issues with the actual superstructure, we are just going to build the next iteration out of max tube. I was actually pretty happy with how well the hand drilled tubing came out, but, here, we need to hold better tolerances than we can by hand so it just makes sense to do this.

We will hold the arm pivot better, we have added plates, riveted to the inside of the uprights, that surround the pivot:

They also have a slot facing toward the front that will allow us to slide the tube in. Note that because of the way the slot is facing and the way the slot is oriented, the tube will be pushed to the rear of the slot and held in very well.

superstructure stiffness

I expected the pivot tube to do a better job holding the uprights parallel to each other. When you push on the end of the arm, the uprights twist. The top of the superstructure needs more torsional strength to combat this.

This issue was the easiest to solve. we just added a tube to the top and increased the thickness of all of the superstructure gussets:

Really, the robot came together pretty well this year. This is the earliest we have had a robot operational by at least a week. We are going to take advantage of the extra time by fixing the issues we did see.

The V2 cad is in our grabcad partner space There are native solid works files as well as Parasolids of the robot in its starting and intaking configurations, labeled 5119-23-000-00-00-INTAKING and 5119-23-000-00-00-STARTING respectively. All robot cad is in the 5119-23-000-00-00 folder.

Thanks!

[Andy-5119]

Week 5 Recap

For design and mechanical, it was a pretty quiet week. We did a minor intake iteration, solving some design issues we overlooked in cad, and waited for parts for the v2 robot to come in.

We did have to fix the arm as the tube nuts, as predicted, could not take the loads on the arm, and folded up inside the tube. To fix this, we 3d printed some spacers to sit in the tube, between the tube nuts and the uprights. The spacers take the radial loads while the tube nut only holds the shaft axially. I got this solution from this post.

Controls has been busy with the robot:
(the recap below was written by Andrew, our controls lead)

This week, after controls got the robot, we worked on testing code for the arm. Since we added an absolute encoder onto the shoulder of the arm, some time was taken to measure out its offset difference from position 0, and convert the rotational measurement into radians (which we used to read the setpoint in our PID commands).

To make sure that the robot was mechanically functioning well, we used manually defined controls to move the arm. Early on, we came across the issue of the motor controllers for the shoulder not functioning properly. This ended up being simply due to the motors working against each other, and we had to manually set one of the motors to be inverse of the other.

Our plan for this season is to have 4 different positions at which the robot arm is rotated and extended, based on the scoring heights. The function of each are as follows:

1. reset position (inside of robot, from game manual rules)

2. low goal/ground intake

3. middle goal/human player intake

4. high goal

   To get these positions accurately, each position has a set angle, which we use in a PID command. We might decide to use 2 or 4 buttons to cycle through the different positions, to make it easier for the driver.

   As we continued testing later in the week, we realized that it would be better to split up our robot into more subsystems within the code, so that we could run two PID commands at the same time. Since we already had all of the code written down, it was not hard to make the single arm subsystem that we had into 3 separate subsystems (intake, extension, rotation).

   Looking forward to next week, we will test the arm extension PID commands more, allowing us to hold our arm up at the goal angle while the extension reaches it. We will also map our button bindings to make it driver-ready by Thursday.

Looking towards week 6, we will hopefully get the new superstructure and arm finished as well as doing more rigorous testing on the intake, and possibly creating a competition ready version.

[ngreen]

Hey, you are in 3rd place. Predictions for the future definitely!!

2023 Audience Displays

[ajax]

I saw you guys have a ~100:1 gear box lifting your arm, how much does the arm weigh to need that much? only curious, I have a ~10lb arm working with a 1:28 ratio that’s struggling a little bit.

[Andy-5119]

To be honest, I did not think very hard about the gearing. We had the three 3:1 max planetary stages sitting around, so I just chose to use those. It might be geared a little conservatively, but it is still scary fast, and I have not felt the motors get warmer than room temperature yet. The COM of the arm (in its retracted position)n is 18 inches away from the pivot point, and it weighs 14lbs. That makes about 28.5 nm at the pivot point, which translates to just over a quarter nm at the motors. According to the neo torque curve, this should draw 20-30 AMPS stalled, with the arm in the horizontal position, which is safe for more than the length of a match. Here is the graph from recalc

which shows the arm reaching 90 degrees from the starting configuration in less than 0.25 seconds.

It is worth mentioning that this guide, writen by someone who is probably more knowlagable than me, recommends a ratio of 160-200:1 for an arm if you don’t want to think about the math.

also, if you have not already seen it, here is a pretty good video about motor sizing for frc: https://www.youtube.com/watch?v=U4pgviiEwLg

[ajax]

very helpful, thank you!