FRC 5987 Open Alliance Build Thread

[AmirM]

Welcome to team Galaxia 5987’s #openalliance build thread!

Our team is from Haifa, Israel, consisting of 32 team members.

Team Structure
We have two captains, one for the technical side and the other for outreach, and a lead for each of the sub-teams. The technical side is divided to two sub-teams: Mechanical (Doing Both CAD and building) and programing, while the outreach side does both media and outreach.

Our Schedule For The Season
We have a team meeting every day of the week, 16:00-23:00 on weekday and 10:00-18:00 on Friday and 16:00-21:00 On Saturday.
We divide our season to the following structure:
Prototyping: Weeks 1-2
CAD: Week 3
Building, Testing And Adjusting The Robot: Weeks 4-6
Testing Programing: Weeks 7-8

We will be competing in ISR2 & ISR 4

#openalliance
This year we have decided to join the open alliance project in order to force ourselves to lookback on our progress and because of our belief in sharing a way of growing. This thread will be updated 1-3 times a week depending on both our progress and workload each week.

[AmirM]

Its time for the first update! We’re a bit behind on posting updates here, so we’ll start with our game analysis and decisions on priorities.

Kickoff Analysis

After a base analysis of the game, we arrived at a list of requirements for the robot which our prototyping process is built upon (sorted into groups, not ordered):

Required to successfully play the game:

• shooting cargo from at least one location
• intaking cargo from the floor (touch-it-own-it)
• storing cargo (two)
• climbing to the 2nd rung, and either the 1st or 3rd rung (to allow for flexibility in games)

Important for our strategy:

• scoring from multiple locations
• intaking cargo from the terminal
• scoring in the hub regardless of the robot’s orientation
• ejection of unwanted cargo
• automatically counting number of cargo held, and distinguishing between colors
• climbing to the 3rd rung

Nice to have but not required:

• scoring from every position on the field
• rapid shooting (back-to-back shots)
• delivering cargos to the terminal
• climbing to the 4th rung
• intaking cargo while bouncing
• scoring in both goals

We decided to postpone the decision on drivetrain type (WCD vs swerve) and which goal to focus on until we get the results of the prototypes by beginning of next week.

For climbing, our analysis of the game showed four “minimum” combinations of climbs in able to get the RP: 2&3, 4&1, 2&2&1, 3&1&1. Meaning that in order to consistently get the RP you need to at least climb the 2nd rung with 3rd rung almost guaranteeing the RP. For further reading on our analysis, @benjierex 's post is a good start. To achieve this, we ideally want a climber capable of climbing the 2nd and 3rd rung with an option to extend it’s capability to 4th rung if we have the time. If we cannot get to the 3rd rung, we need to add rung 1 functionality in case our partners can only climb to rung 2 to allow for the 2&2&1 option.

In order to test various ideas for the robot, we split the team into five prototyping groups:

1. High goal shooter
2. Over-the-bumper intake (horizontal rollers)
3. Through-the-bumper intake (parallel wheels)
4. Cargo conveyor
5. Climber

We’ll have updates on the progress those prototyping groups have made soon!

[AriMB]

We have been hard at work the past few days prototyping mechanisms, mocking up field components, and beginning coding!

Simulating Shooting Angles

For simplicity’s sake, we want to avoid an adjustable hood shooter if possible. In the programming subteam, we started tackling the shooter options in order to be able to shoot into the upper hub by changing the velocity without changing the angle of the shooter. We used MATLAB in order to check the trajectory of the cargo from different key positions in the field. We found that for shooting from all distances up until the launchpad 2 shooter angle positions are optimal. Further explanation can be found at @adamv 's post.

Climbing

We have two main concepts for climbers:

1. Stick on a wrist: A long pole with hook on both sides swinging the robot pole to pole, much like in SnowProblem’s RI3D build. We just finished our first medium-scale prototype of this climber, and are starting to test its viability. More to come on this front soon.
   
   

2. Elevator and wrist: An elevator with a hook on top, which raises the robot to the 2nd rung. A hook on a wrist then locks on to the 2nd rung. With the robot fully on the 2nd rung, the elevator rises, disconnecting from the 2nd rung and then, using the wrist to change the angle of the robot, the elevator hooks the 3rd rung and pulls the robot to it. The wrist lets go of the 2nd rung and the robot is now hanging from only the 3rd rung. This mechanism is similar to ZouKeeper’s Ri3D climber Theoretically this concept can climb an infinite amount of rungs, making it very alluring.

Over-the-Bumper Intake

For the over the bumper intake we decided to take direct inspiration from 2020 robots and built a general prototype allowing us to easily change the positions of the rollers of the intake. Using the green compliant wheels we managed to get a decent control of the ball, but trying to center it using mecanum hasn’t worked so far.

Videos of the prototype (will be updated over time) are available here.

Through-the-Bumper Intake

For the through the bumper intake we took heavy inspiration from 2016 robots, trying to convert a face of the robot to a wide bumper using wheels arranged in a cone shape. While testing has been successful the problem with this concept is the balls bouncing from the wheels instead of being lead by them. To solve this we implemented an over the top roller to force bouncing balls into the wheels, making this concept a merge of the two types. We’re now working on improving the funnel wheels and investigating the possibility of moving the funnel wheels onto the intake to be deployed outside the bumpers.

More videos of the prototype are available here.

Shooter

We started testing the high-goal shooter using a modifiable prototype with variable compression, wheel type/size, hood angle, # of motors, gear ratio, and flywheel mass. Our goal is to find one or two angles that give us the widest range by only varying flywheel speed. Our initial strategy requirements say that we want to be able to shoot from as close as possible, and up to 5m away.

In testing, we found a good combination of 4" colson wheels, 1x falcon at 1:1 with our 2020 flywheel, and 20mm compression. We first tested the minimum release angle that would allow us to score when touching the HUB; this came out to 69°. We then backed up the target until we got to our max range, which was ~3.5m. This is likely not enough range for our strategy, so in the coming days we’ll test a second hood angle for longer-range shots. Testing a number of hood lengths, we found that the longer hoods keep the ball in contact with the flywheel longer, increasing the max distance. We ended up with a hood arc length of 55° on a 272mm radius.

Videos of the prototype testing are available here.

Cargo Conveyor

We wanted to prototype a conveyor system to check the required compression, belt distances, etc. On the first prototype, we forgot that the belts not being centered on the ball means the ball has a smaller effective diameter, reducing the compression. While it does work, it doesn’t hold the ball securely enough for our satisfaction. We don’t want to completely remake the prototype, so we are working on modifying it to allow for larger compression so those numbers will be available when we go to design the real conveyor system. Meanwhile, we have attached the through-the-bumper intake to the conveyor inlet to begin testing system integration.

More videos of the prototypes can be found here.

Computer Vision

We were able to create a small prototype of this year’s retro-reflective target, and successfully identify it using the PhotonVision grouping mode and a deconstructed PSEye3 camera.

Additionally, we have been working on automatic detection of cargo position and color. Using OpenCV, we were able to both identify cargo within the image based on color and differentiate it from other objects of similar colors (e.g. bumpers)

 

We’ll have more updates on prototyping results and strategy decisions coming soon

[Gregory78]

Thank you for sharing all of this! In your prototyping of the cargo conveyor did you happen to see what happened when you stopped a cargo from moving and let the belts keep spinning? Or stop the first cargo and intake a second cargo? I’m curious how the interaction is and how much it differs from power cells (which notoriously did not like to have belts spinning across them or stack up against each other)

[AriMB]

This year’s cargo are much slipperier than the power cells (in a good way). They had no problem with belts sliding over them or rubbing one on the other. We could run the conveyor with the end blocked off and the cargo lined up one after the other no problem. We are planning on increasing the compression on this prototype in the upcoming days so that may make it a bit grippier, but I still don’t really expect a problem.

[Gregory78]

Awesome thank you!

[AmirM]

We’ve been hard at work and have made a lot of progress in the past few days.

Strategy Decisions (an overview)

We had a meeting Sunday with the team leaders and mentors to choose the final robot design based on the results of our prototyping:

• We decided to focus on the high goal, as we are very happy with our shooter design. We want two hood angles to be able to shoot from a wide range of distances on the field.

• We decided to go with a swerve drive because we feel confident it will give us speed and maneuverability advantages. The difficulty with this will be the motor limit, since we are using the old control system and swerve takes up 8 motors, but we think we will be able to design the rest of the mechanisms within the remaining limit.

• We decided against using a turret because we didn’t want the added complexity, and since we should be able to align with the target using the swerve. It also helps us save a motor.

• We chose the climber which we referred to above as “stick on a wrist”, based on Snow Problem’s Ri3D climber design. It will now be known on the team as the “Propeller Climb”

• We postponed the decision on the over- vs through-the-bumper intake for a few more days to allow for more prototyping. Just yesterday we made the final decision to go with the over-the-bumper design. Both prototypes performed fantastically, but in the end we had to choose one and the over-the-bumper is slightly simpler and uses one less motor which gives it the edge.

Some more details on each of the mechanisms and their progress:

Drivetrain

We will be using the swerve modules we developed in the offseason last year with minor changes. We finalized the design on those already and will be manufacturing the parts over the next week while the rest of the robot is developed in CAD.

Shooter

We finished the shooter prototype fairly quickly because we were very happy with the results. We were able to consistently hit a target about the size of the bottom of the high goal funnel even shooting from 16ft away, using one Falcon without PID. To be able to shoot from the range of distances we want, our testing revealed we need two hood angles: 69° for close shots (5 to 11ft) and 54° for far shots (10 to 16ft). We are designing the shooter to have a pneumatically deployed flap that can be flipped down to increase the hood angle or flipped up and out of the way for the higher release angle. If we see that we don’t end up using the second angle, the flap can be removed entirely and we will have a static hood. The CAD for the shooter is already close to being done, well ahead of the schedule we set before the season.

Intake

We have the terrible fortune this year of having two intakes that work very well and needing to choose between them. Our through-the-bumper intake has a top roller to grab onto the cargo and four vertical wheels to guide the cargo sideways into the bumper gap.

Longer testing video: https://drive.google.com/file/d/1LFJd_R4TsKYte5R3WJoET_4l2oEZqEbb/view?usp=sharing

Our over-the-bumper intake has two horizontal rollers with compliant and mecanum wheels to pick up and center the cargo. In order to prevent jams when intaking two cargo at once, the intake is purposefully biased to one side and the cargo enters the robot not-centered on the frame.

Both intakes quickly and effectively picked up and indexed the cargo, were able to intake two cargo at once, and weighed about the same. In the end, we ended up choosing the over-the-bumper design because it is slightly simpler and uses one less motor.

Conveyor

We designed a new conveyor prototype to better test the compression needed to securely transport the cargo. Based on the results of our previous prototype, we decided to use timing belts on only one side, with the other side being a flat surface covered in rubber. This has worked well with a compression of 15mm with 95mm between belts. Unlike 2020 where much effort was needed to get the balls aligned in a row without gaps between them, this year we can run the conveyor indefinitely with something blocking the path into the shooter and the cargo will line up on their own. We are now testing a final prototype which includes a 90° bend to ensure that the cargo will transition smoothly.

Climber

We finished the first medium-scale prototype of our windmill climber, which seems to work decently. We are still working on building a team version of the hangar, so for now we are testing the prototype by hand. We are able to grab onto the 2nd rung and lift up to grab onto the 3rd rung. Here is a video of our initial testing of the prototype:

https://drive.google.com/file/d/1SgQik4sPOSLtuTq-227muUDCIvjuOPBp/view?usp=sharing

We designed a custom latch to hold onto the 3rd rung from below instead of using a hook on the 3rd rung so it doesn’t have to line up as exact. We are still in the process of testing to see how much force it can hold.

We’re now working on the physics for a full-scale prototype in order to be confident the idea will work before the final mechanism is modeled in CAD.

Programming

We have started programming the subsystems of the robot. For each subsystem we create a pull request so that we can check each other’s work and catch as many errors as possible before we get the robot. For this purpose we have also been using wpilib’s physics simulations, for example in the shooter this year the closed loop control is state space with the moment of inertia of the shooter. From the CAD of the shooter we calculated J, the moment of inertia, and using the wpilib simulation GUI ran our command based code so that the shooter gets to a certain speed as shown by a graph in the GUI. We are currently doing the same for the climber to try to get a rough estimate of the PID constants and make sure that every minute of work on the robot counts.

On the vision side, we wanted to do vision with the Jetson but our J120 carrier board’s USB ports seem to be malfunctioning. This doesn’t seem to be a programming error as one of the USB ports doesn’t receive power, and the correct driver for the board has been downloaded. Therefore, we have pivoted to using RPIs.

[AmirM]

Sorry, we’ve been very busy this week so we’re a few days behind on posting. After finishing up our prototypes the previous week, we spent all of last week working on the CAD of each mechanism on the robot. All of the computers in our lab are connected to a central server that hosts our CAD, which makes it easy for us to work in Solidworks in parallel without needing to manually transfer files between computers or worry about stepping on each other’s toes.

As we started preparing for our CADathon, the team leaders sat together to finalize the robot’s general layout and allocate space for each mechanism. We call this rough model our “blockbot”. We generally model each mechanism independently first and then integrate them together once they’re done. We’ve found that having a clear understanding of the space each mechanism is allotted and how they fit together helps reduce the number of conflicts during the final merge.

In order to make room for the climber arms, our robot will be longer than it is wide (though it doesn’t make a big difference with the swerve drive). The over-the-bumper intake centers the ball and loads it into the conveyor, which has room to store 2 cargo. A deployable hard-stop (not pictured) blocks the balls from entering the shooter before it is up to speed. Though the intake stows in front of the shooter, it doesn’t block the shot path or the camera line-of-sight.

Both climber arms are powered by a single gearbox that sits under the conveyor, with shafts that extend out to either side. A final chain reduction on each side carries the torque to the climber’s arms. We were a bit weary of running a shaft through the whole robot, but we did some calculations and ran some simulations that show it should be strong enough. This placement leaves room for the battery and compressor (not shown) to the sides of the shooter, and the electronics in the back.

Using this “blockbot” as a blueprint, we start CADing each mechanism individually. Each one starts out as a single part containing all of the mechanism’s geometry and dimensions, called the “master sketch” part. Each subsequent part in the mechanism references that master sketch, so all of the dimensions can be changed from one location. We finished the design of the mechanisms individually on Wednesday, when we had a preliminary design review with our mentors. Since then we’ve been working on integrating the mechanisms together into a single robot. Hopefully we’ll be done with that soon, and we can share our final design.

[AmirM]

One of the main lessons we learned the hard way last year was the importance of modularity. Having an irreplaceable unfunctional transport system for the power cells that was connected to more things than even the drivetrain became a real pain when we tried to fix the robot. Following that, we set ourselves the following set of “modularity rules”:

1. All systems must be easily replaced/modified (besides the drivetrain).

2. A system must not have more than one system fully dependent on it besides the drivetrain. (e.g if the shooter is connected to the transport system, then no other systems besides the drivetrain may be connected to it).

To accomplish this, we divided our robot into five distinct mechanisms:

Drivetrain

Our chassis this year is 26.8 x 32.3 inches, made of 20x40mm tube. There is cross-bracing to support the conveyor, which is positioned off-center to match the bias of the intake. There is also bracing to support the climber on each side of the conveyor. Each corner has a swerve module, with the battery and compressor squeezed on the sides.

During the week while we’ve been working on designing the rest of the CAD, our manufacturing team has been machining and assembling our swerve modules. Unfortunately during this time, the SmoothStepper and VFD on our CNC router both gave up the ghost. We’re hoping to get replacements shipped from the US by next week, but in the meanwhile we’re losing precious manufacturing time. So we’ve had to quickly pivot our design strategy from almost entirely manufactured in-house to sending parts to external manufacturers. We’ll survive, but it’s an unfortunate setback.

Intake

Our intake features two horizontal rollers: one with compliant wheels to grab the ball and the second with mecanum wheels to index the balls before pushing them through a gap in the bumpers. It is driven by a single redline motor at a 1:3 reduction. Each side is made of two 8mm polycarbonate plates connected by spacers for strength, with inset aluminum plates for bearing support. The profile at the front of the intake has multiple purposes: connecting the two sides to each other, protection for the front roller from hits, and to block the green wheels from the view of our target-tracking camera (which looks for green targets). When deployed, the intake extends 15” beyond the frame perimeter; when retracted, it sits 0.4” inside the perimeter.

Conveyor

Our conveyor system uses two sets of timing belts to take the cargo from the intake and raise it to the shooter. The belts compress the cargo against a polycarbonate backing. The distance between the belts must remain constant to keep the compression constant, so in order to put multiple sets of belts on one axle, the ball has to slide a bit to the side in the middle of its travel. Both sets of belts are powered by a Falcon motor on a 16:24 reduction.

At the top of the conveyor, a plate on each side supports the shooter. The bottom of the shooter hood extends into the gap in the polycarbonate back plate so the ball transitions smoothly. As the cargo enters the conveyor, a color sensor under the polycarbonate identifies it and reports the color to the driver. When the cargo exits the conveyor, a beam-break senses it. This way, the drivers always know how many cargo of what color the robot is holding. The driver’s camera (not pictured) will sit on an aluminum plate spanning the top of the conveyor (transparent in this view).

Shooter

Our shooter uses two 4x2” colson wheels powered 1:1 from one Falcon motor. On the wheel shaft sits a stainless steel flywheel with a MoI of 2.54 lb*in^2 to maintain wheel speed between shots. The hood backing is made of several sheets of CNC’ed 20mm HDPE stacked together. At the top of the hood, a small pneumatic cylinder extends or retracts an extension to change the release angle. Above that, a camera and LED ring is aimed at the vision targets on the high goal. At the entrance to the shooter, another piston extends a mechanical stop to block balls from entering the shooter before the wheel is up to speed.

Climber

Our climber has a rotating arm on each side of the robot. Each arm has a hook on one side (to grab and release rung 2) and a latch on the other (to securely grab rung 3). Both arms are powered by a central gearbox with two Falcons. A 1/2" hex shaft spanning the center of the robot connects the two sides (we did calculations and simulations to show it should withstand the torque). A #35 chain reduction on each side connects this long shaft to each arm. The overall gear reduction is 292:1. In addition to being supported at the bottom, each vertical tube is strengthened with steel cable runs to the frame.

One concern of ours with this subsystem is its possibility for accidental injury. With the power of two Falcons and such a large gear reduction with a long arm spinning between vertical profiles, an accidental activation of the system could cause some serious injury. Because of this, we will leave the brake on whenever the robot is running except when attempting to climb. We also have a safety pin installed to lock the system while testing other parts of the robot.

[AriMB]

I’ll be honest here, we’ve been burning the candle at both ends trying to get the robot built and we haven’t had a chance to post here as often as I’d like. While the students are busy with that, I’ll try to give some updates here to keep the thread up to date.

We finished integration and locked the robot CAD last Wednesday. Here are some pictures of the full robot CAD. We had to make a number of changes for integration, but most of the design is still the same. If you’re interested, you can download the robot model here.

https://drive.google.com/file/d/1BsQ1Vd37wlT7mooA0rGOOAUMIQIktvNU/view?usp=sharing

One important change that we were forced to make was on the climber. When doing design review and preparations for manufacturing, we weren’t satisfied that the climber could be produced as modeled. So we took the same idea but started on a ground up redesign. Because of this delay, the climber parts were pushed off to be manufactured until after the rest of the robot. This means the robot won’t be mechanically finished until later, but gives the programmers and drivers more time to work on the rest of the robot. We are also planning a simpler rung 2 climber in case we can’t get the rung 3 climber to work.

When manufacturing began in full-force last Wednesday our CNC router was still busted, which was a big problem because our plan was to make most of the robot in-house using that machine. While we were waiting for the replacement electronics to arrive from the US, we started making the lathe and printed parts. We also decided to send some bigger plates to outside manufacturing to make up for the lost time, meaning we had to make engineering drawings for them, a skill we hadn’t covered much in the preseason.

Since we started manufacturing parts for the swerve as soon as we decided that would be our drivetrain, we had most everything already made before the CNC broke. The last parts were finished by Sunday, and they were all assembled a few days later. Before mounting them on the frame, we ran them continuously for about an hour to wear-in the gear mesh.

By the beginning of last week we got the router fixed and could go back to our original plan of making everything in-house. While half the team was busy manufacturing, the other half was assembling the parts fresh off the press. After a few long days, we had all of the parts made by Thursday and the body of the robot assembled by yesterday.

Here are some nice shots of the robot during assembly:

As of today, the robot needs some wiring work and then gets handed off to the programming team for code testing and tuning. Stay tuned for more info on that front.

[AriMB]

The robot is all wired up and ready!

Programming got started with it tonight tuning swerve PIDs and adjusting code. Here’s a video of the robot’s first steps, it should be toddling by tomorrow.

[AriMB]

We finished assembling and installing our climber (now nicknamed “the helicopter”) on the robot today.

And we got to begin testing it today. You can see we were a bit surprised at how quickly it climbed the first time

FRC 5987 2022 First Climb 18/02

FRC 5987 2022 Second Climb 18/02

We realized that the distance between the rungs on our practice field elements is off by about an inch. If the rung were in the right location, the second hook should latch properly. We’ll have to fix that spacing so we can test the mechanism properly.

---

 

In addition to building the climber, we’ve spent the past few days testing each mechanism individually:

• The robot is now driving well, and the field-centric swerve code that the programming team developed in the offseason copied over to this robot with little issue.
• The intake worked well, but was somewhat underpowered when intaking two balls at once. We were worried about burning out the 775pro is we accidentally stalled it for too long. We switched the 775pro for a NEO550 and we’re much happier now.
• We thought there was a problem with the handoff between the intake and conveyor, with a small dead-zone between the two. But when both are running and the bumpers are attached, it’s seems to work fine.
• The conveyor works well to hold two balls and detect the position and color of each. We’re hoping this software will help the drivers keep track of the number of balls in the robot and reject cargo of the wrong color.
• We weren’t able to get the proper size pneumatic cylinder for the hard stop that keeps the balls from prematurely entering the shooter, so it was a bit too short and allowed the cargo to touch the flywheel. We remade those pieces with a different geometry, hopefully this will fix the issue.
• The shooter is plenty powerful with our current setup. We were hitting a pretty high ceiling with open-loop testing. We still have to work on image processing and closed-loop tuning for the flywheel.
• As you saw, we’re happy with the climber in initial testing. The biggest problem with it now is that the bolts attaching the sprockets to the arms bent under the torque. We’re working on ideas to strengthen that connection.

[Alex_Y]

How does this climb separate from the second bar. After grabbing the third bar, the other end of the bar is stuck above the second bar and has no way of reaching under and grabbing traversal

[AriMB]

Right now our plan is only to reach the 3rd rung, not to go for traversal. Once we latch onto the rung 3, we’ll drive the arm in the other direction to lift up off of rung 2 and then engage a brake to hold ourselves in place there.

In theory it would be possible to get to the traversal rung with this design, but it would need a different way of releasing from rung 2 in order to swing under rung 3 instead of over, and it would need the ability to unlatch itself from rung 3 once it’s hooked into rung 4. If everything works well that might be something we work on after the first comp, but we decided early in the season that climbing to traversal wasn’t a high priority for us.

[Alex_Y]

It looks like it can fairly easily be modified to go to traveral. Instead of running 2 hook, run 3 with the two hooks on opposite ends facing up and one on the end facing down. Grab onto bar 2 with the side with 2 hooks facing up, then you can spin it 3 times to get traversal.

Excuse the bad ms paint drawing

[AriMB]

Yeah, that’s the basic idea I was trying to describe before (sorry if it wasn’t clear). It would require switching the hook for rung 2 to a latch, and developing a way of opening the latches automatically. Should be possible to do, but not a priority for us at the moment.

[mrnoble]

Since y’all are Open Alliance and so are we, I will tell you that I think with very little tweaking (just figuring out how to open and close the grabbers) you have probably got among the fastest level 4 climb types in the game. Probably possible to get it below 5 seconds. I wouldn’t give up on that as a priority

[AriMB]

We started checking speed vs distance yesterday, and found that with the hood angle we had we wouldn’t be able to shoot from as close as we’d like. We remade the hood plates for a slightly steeper angle, and we are now able to make shots from up against the hub (with the intake down). In doing so however, our adjustable hood now interferes with the shot trajectory when retracted and will have to be remade. Two steps forward one step backwards.

We are having some problems with backspin causing the balls to bounce out, but a combination of playing with the speeds of the flywheel and feeding conveyor, aiming for the side of the hub rather than the center, and changing flywheel speeds between balls has helped mitigate that. Our job for the next few days will be to find the right combination of speeds and angles to be able to shoot accurately from our entire range.

---

At the end of the meeting today, we also tested our climber again after fixing our model hangar. We weren’t lined up quite right at first and this happened

FRC 5987 2022 Climb Fail 20/02

After we recovered from that mishap and put the hangar back together, we got another shot

FRC 5987 2022 Climb Test 20/02

You can see that, although they are connected by an axle running through the robot, the arms had some angle difference causing only one to latch onto rung 3. After that latch was attached manually, it failed under the weight of the robot. We’ll be looking into what we can do to improve the rigidity between the arms, the strength of the latches, and the required alignment accuracy of the hooks.

[AriMB]

In the past few days we finished the (preliminary) tuning of flywheel speeds for our range of distances, and we’re shooting pretty accurately.

Somewhat unintuitively, we are most accurate shooting from the outer edge of the tarmac; closer shots tend to bounce out more often and further shots are necessarily less accurate. We are attempting to compensate for the bounce-out by purposefully aiming close shots off-center of the hub so the ball hits the side slope and bounces sideways rather than directly upwards. This is showing some promise when done manually, the next step will be to automate it.

We also made some mechanical improvements to the intake and conveyor systems to better control the cargo. We accidentally had an intake belt that wasn’t properly spaced, causing it to skip when under tension. We extended the front belts of the conveyor and added flex wheels to help the balls transfer from the intake. We also increased the ratio of the conveyor to slow it and avoid marring the cargo.

At the end of the day today, we got to do some good driver practice. We had wanted to practice intaking and shooting, but unfortunately our targeting LEDs died right before we started, so we just practiced intaking. Now that the belt on the intake no longer skips, we see that we can increase the intake motor power to be able to intake two cargo at once. Here’s a short clip of our practice.

FRC 5987 2022 Driver Practice 23/02

[AriMB]

I don’t usually post two days in a row, but I want to share that we had our first successful climb today without human intervention

FRC 5987 2022 Successful Climb 24/02

We were able to climb a number of times in a row without issue. We still haven’t gotten around to widening the rung 2 hooks, so it takes a long time to line up before the climb begins. That will happen in the next few days. Once the robot was up and locked on rung 3, we saw that the polycarbonate latch was bending and slipping under the robot’s weight. We made those parts out of PC for ease of manufacturing, but we’ll be switching them with aluminum for better strength. Overall though, we’re very happy that the climb is looking promising.

---

As an aside, we’ve had a problem in the past week or so having accidentally ordered endmills from the wrong company on Alibaba. The two products look identical and have the same description, but perform vastly differently. These need a much slower feed rate, DOC, etc and still have problems with chip welding.

Who needs chip clearance when you can make aluminum puddles?