Team 5996 R. U. R. | 2025 Build Blog | Open Alliance

Introduction
Team 5996, R. U. R. is a small team based in Prague, Czech Republic. Every year we have between 10 and 15 students and 3 mentors. Last year, we ran a prototype OpenAlliance thread on our website, which we shared mainly with team 9585, which is the only other team in the Czech Republic. This year, we feel confident we can run a full build thread on Chief Delphi.

Last year, our team won the Regional Engineering Inspiration Award at 10,000 Lakes Regional. We strive to adhere to best practices of mechanical engineering and hope to inspire future generations of engineers by attending Maker Fairs all over the country. Below is a photo of our robot and a warning about what could happen when you make your hook tolerances too tight:

As for manufacturing capabilities, we own a CNC mill/router that we use on all plates and tubes on our robots. One of our mentors has a rather small lathe, where we can manufacture custom bolts, pins, and hubs. Lastly, we love 3D printing and in the past couple of years, we’ve managed to run various 3D printed mechanical components without a single failure, including rollers on our 2024 shooter.

I’ll be using primarily metric units as it’s easier for me to convey and I’ll try to remember to go back and convert at least the most important ones.

I’ll let this intro end with a fun fact: Did you know that the word “Robot” came from the Czech language? It first appeared in the play “R. U. R.” by Karel Čapek.

Strategy

This year’s game is very interesting, we even brainstormed the usage of cylindrical scoring elements in November, as we haven’t seen those probably since 2015 pool noodles. The one-defender system calls back to 2019 when one defender was able to shut down one of the isles.

First, let’s talk about Algae. From our perspective, Algae isn’t a very viable scoring option for us as scoring into the Processor nets only 2 points and shooting it into the net for 4 points would require packaging a large shooter inside Robot Perimeter, which doesn’t fit our other design requirements for the robot. Furthermore, interacting with Algae doesn’t directly affect RP progress. Therefore we’re completely skipping Algae shooting and Processor scoring will be a nice-to-have.

Corals are a fun new game piece to interact with. Corals feel that they will be easier to handle than cones because they have holes on both sides. Based on points gained, they’re netting at least 2 points on L1 and they directly affect the Coral RP. To achieve the Coral RP, we have to reach all 4 levels of the Reef. The Coral Stations are conveniently close to Reefs and they seem to drop Corals a bit faster than what we saw last year with Notes. Despite that, being able to collect rogue Corals from the ground seems like a should have.

Next up is the Coopertition bonus. We don’t want to rely on having the Coral RP threshold lowered. Furthermore given there are more RPs to earn, Coopertition points will be less likely to affect the overall rankings.

The endgame seems fairly difficult. Being able to climb on the deep Cage to obtain the endgame RP more easily is very tempting and we consider it a should-have. If all fails, climbing the shallow Cage seems very approachable even with last year’s climber.

Mechanisms

Let’s talk about some mechanism ideas that we’re working on right now. Considering the size of our team, there’s no way that we can build too many prototypes simultaneously, therefore we’ve put together a vision that we want to explore in-depth to iterate on in later weeks.

The drivetrain decision was very straightforward for us, especially considering that we finally replaced our old MK2s with shiny new MK4is. The question remains if we want to go for a L3 or L3+ gearing. Considering the short travel distances, acceleration is going to be key as we aren’t very likely to hit top speed this year. The chassis width doesn’t seem to be a huge issue this year, therefore a square 650x650 mm (25.6")
seems a good fit for us unless electronics + pneumatics packaging forces us to go wider.

For our ground intake mechanism, we’re testing a full-robot wide roller intake, which will treat the Corals just as regular balls. From our early testing, it turns out that the more misaligned the axis of the Coral and the axis of the intake rollers are, the easier it is to get hold of the Coral. We tested using 3D printed Mecanum wheels with close to no result as there is no grip. Furthermore, we tested misaligning the intake from the bumpers, so that the gap gets smaller towards the front of the robot. This helps to funnel the Corals towards the front of the robot. We’ll need to make a more precise version of this to see the results more clearly. If we want to be able to streamline the process of intaking Corals even more, we can fit two intakes on the robot.



Here is a link to a video that we took when testing the intake.

For the Coral manipulator, we want to build something that doesn’t require realigning Corals once we intake them into the robot. From this, we landed on the same idea as one of the Ri3D teams. We can create simple V-shaped basins which can tilt using pneumatics and the Corals will be deployed by gravity.

To be able to get to L4 on the Reef while maintaining a fairly low profile (700mm (27,5") of height maximum), we’ll need a 2-stage elevator with a movable carriage, which will carry the Coral manipulator. With the reef pipes being only about 330mm apart, we want to explore the possibility of having 2 basins for the Corals, which would make lining up much easier. In this case, each intake would feed one basin. The downside to this is that if we fill the right basin and want to score on the left side, we would need to realign the robot.



To climb on the deep Cage, we want to use a lifting mechanism that would push on the bottom plate of the Cage, thus lifting the robot. Given that the Cage is only about 90mm off the ground, we don’t want to lift the robot much higher than that, because then the robot would become an inverted pendulum. We would like to use pneumatics to achieve this climb. We found a large pneumatic cylinder that has double the lifting force we need and it still fits into the cage. Therefore we need to create a guiding mechanism for the cage, which will guarantee that the cylinder goes in every time. Furthermore, to achieve a perfect line-up with the Cage, we want to put a conical nut on the end of the cylinder that will fit inside the hole of the bottom plate. There are two things that we need to take into consideration. The center of mass must be placed perfectly in the center of the robot as any tilt would likely discount the climb and we need to calculate the stress applied to the parts holding our climber. Unfortunately, our Cage is made out of PVC at the moment, so we’ll be able to test it once the real one arrives.


Right now, we can’t share any precise dimensions as all is a rough sketch that overlaps on every corner. I believe that we had a 5 mm (0,2") compression on the Coral using 2,25" compliant wheels with various durometers. I will confirm the intake dimensions once I get my hands on the measurements we did on Saturday night.

There will also be a write-up on pneumatics soon as we really need to get it sorted out. We used pneumatics back in 2022 and had leaks all over the shop. I can confirm that that was caused by mixing 6mm fittings and 1/4 in tubes together, which seemed to fit well together, but the sealing wasn’t great.

Feel free to ask any questions, I’ll try to share as much as I’m able to. Or if you find a fatal flaw in any of this, please let me know! :slight_smile:

11 Likes

It’s been a while since the last post, so here are some updates:

We’ve ordered a Cage (yay!). For anyone, who would be interested in using our metric re-design, I’ve uploaded the CAD files and drawings here. (A quick sidenote, all of our drawings are using the ISO-E standard, so that’s why they might seem weird to you at first)

It’s made out of 3mm sheet metal and 33.7x3.2mm pipe, all made out of S235 steel. Powder coating is not mentioned in the documentation, however, we’re getting it powder coated too to have (hopefully) the exact same surface finish as the original ones. Getting this made elsewhere not only shortened the wait time we would have had with shipping from the US, but it saved us a good amount of money, so I think that it’s a win-win. If the climber goes to plan, it doesn’t matter that the pipes aren’t the perfect size as we won’t have to rely on them being precise.


Speaking of which, here are more Climber details:


This is a prototype that uses a DSNU-type cylinder from FESTO with 63mm piston diameter (~4.8 in2) and 160mm travel (~6.3 in). Both of these parameters are on the larger side and the cylinder mounting is a bit weird using only the top thread.

Therefore, if we get this to work, we’ll use a DSBC-type cylinder, which allows for mounting with M8 bolts from the top side. The cylinder in this design is also modified to have 50mm piston diameter (~3in2) and 100mm travel (~4").
zvedak_dsbc

On the end of the piston rod, there is a self-centering cone, which is designed to fit inside the hole in the bottom plate of the CAGE. We’ve 3D printed a testing version of this and found out that this angle (132°) is way too large and doesn’t serve its purpose. So we’ll test some more with different angles and see, what works best. To prevent the robot from tilting off the cage, there will have to be some guards around the mechanism that prevents movement of the robot relative to the Cage. However considering that we’ll likely need a guiding mechanism for the Cage, it can serve 2 purposes.

Considering the awkward shape of the whole thing, we were getting worried about the structural integrity of the design, so we ran some basic stress analysis in Autodesk Inventor to see how the mechanism would behave under extreme load (650 N). So here is the prototype:


A maximum deflection of 1.5 mm (~0.06 in) isn’t great but it should do. All the non-piston material is 6061 T6 Aluminum with the cone being S235 steel.
And here is the real deal:

Thanks to the narrower cylinder, we were able to package the whole mechanism tighter together, which decreased the leverage arm and now it deflects only about 0.6 mm (~0.025"). It’s too early to say how will these impact the mechanism as a whole. In case of elastic deformation, there is nothing to worry about. In case of plastic deformation, we can skew the climber and nobody wants that to happen, right?


Let's move on. I've managed to get my hands on more detailed measurements of the intake mechanism.

Please note that the whole sketch is not to scale as on the top-down view, the rollers should overlap. Right now, the angle between the rollers and the bumper is about 3.1°, which (with the help of Coral Guide) funneled the Corals towards the front of the robot. Unfortunately, I don’t have any photographic evidence of this as we took off the intake to go test some auto paths (or so we thought).


Just as every year, migrating old code to new libraries brings up new issues that need addressing ASAP. We've spent about two hours trying to figure out, why the Studica library for NAVx was throwing errors. I don't have the exact stack trace to share here, however, it wasn't your everyday syntax error, we were getting a full-on java breakdown. I've found a similar trace on CD from 2019 when PathFinder paths were not deploying to the robot.

Long story short, yesterday we found out that if you don’t specify the AHRS connection type in definition and pass a none, you’ll receive a major error that is very different from all others.


No meeting today, we hope to make a Coral manipulator prototype tomorrow along with some milling on the Climber prototype.

4 Likes

It’s been a while, so here’s another post. We’ve been so busy working on the robot that we have probably only 1 video from the autonomous testing and that’s it.

Climber

Even though planned, there hasn't been any work done on the climber prototype, mostly because we don't actually have 20mm thick 6061 Aluminum, so we are cutting the material from a 50mm thick block, which I don't wish on anyone. So let's move onto something else:

Intake

No significant progress has been done either, we milled some test parts that will be tested once the chassis is not being worked on.

Elevator

Oh, I have some great news, the Elevator is coming together real nice. In another thread, I've mentioned that we tend to make our bearing blocks from 3mm duralloy, so now I officially take that back. We're 3D printing the blocks this year due to packaging constraints. Below is an image of what the Elevator looks like without a middle carriage.


The maximum height when unfolded is 1851 mm (~72.8") and the folded height is about 766 mm (~30.2") measured from carpet. The total width of the elevator is (only) 152 mm (~6"). This design stems from our aforementioned dual deploying system. Between the tubing, there is only 2mm (~0.08") to minimize the strain on the bearing blocks and the Elevator footprint.


Here’s a cross-section through the tubing. The bottom bearings guide the PE strap that lifts the whole thing up. The top bearings keep the whole assembly aligned.

The whole drawing package can be accessed on our drive. We’re not sharing the CAD just yet as the whole assembly is still a WIP. If you are interested in the design, let us know and we’ll happily show you in greater depth :slight_smile: .

Coral Manipulator

We've built a very basic Coral Manipulator that closely resembles the one in the initial concept and the initial tests with the Reef built seem promising. (again, no pictures :( ) We love the simplicity of the design and we want to incorporate it into the first version of the robot. Once the robot is done, we'll (hopefully) have a lot of time to assess the reliability and speed of this design and iterate on it. However, due to the nature of the robot, we need to keep the manipulator mass as low as possible, so lifting gearboxes is likely out of the picture.

Programming

The goal for us this year is to be able to automate more of the tasks that the robot performs. Last year was very kind to us and we were able to consistently score 4 Notes in auto without figuring out, how to turn.

This year, we took advantage of having a chassis built from pre-season that we can work on. After spending the last two days migrating 2024 code to 2025 and bugfixing from the past 2 seasons, we’re finally able to drive in auto precisely and rotate the robot! Here is a video of our testing path from middle of the field to the close side of the Reef.

Up next, we want to be able to identify the position of the robot on the field at the beginning of autonomous, so that we don’t have to rely on precise alignment on the field. This should be achievable by tracking one (or rather more) AprilTags by Limelight and thus determining our position.

Coral Tracking

As a longer-term project, we want to be able to determine, which Reef positions are filled and which are empty so that we can fully automate our Elevator. There are essentially three ways to do this:

  • Have the second driver manually address every Coral Scored by other robots through SmartDashboard and have our robot track the Corals it’s deployed. We deemed this to be too harsh on 2nd driver considering that they should be communicating with 1st driver and doing other tasks.
  • Agree with alliance partners to score on one side of the Reef so that we can score on the other one and then our robot can track the Corals it has placed. This is very easy to do, however, if (due to defense etc.) our partners score on “our” side of the Reef, the robot has no idea that this has happened and it will try to deploy on an occupied slot
  • Build a vision-recognition system that will be able to scan the Reef just before deploying to determine which positions are empty. We can do this at the start of the deployment cycle or we can continuously the Reef to get the full picture at all times.

The idea behind this is that if we know, which parts of the Reef are empty, we can take the Elevator Height selection control from 2nd driver and have it fully automated to save time. We also assume that tracking Corals on the far side of the Reef will be very hard from the Driver Station itself.

Furthermore, we can have 2 deployment strategies. One that focuses on getting the RP and determines whether either level is “full enough” - 5+ pieces and disables scoring to that level. The other one focuses on the maximum points gained and scores to the highest level possible.

Nevertheless, having a manual override to this is extremely important!

Conclusion

Based on our experience, we're basically speedrunning this season in terms of actual progress. In past years, we've taken a bit of a break after initial prototyping. This year, we are able to build parts of the robot while iterating on other parts (intake).

I promise to take some (a lot of) pictures once I get back to the workshop to update this thread. If you have any questions to what has (not) been shown here, let us know and we will at least post pictures from our various CAD files.

1 Like

FYI: Updated info can be found here from the WPILib beta page now live page: GitHub - Studica-Robotics/NavX: Repo for finding binaries and issue tracking

1 Like

Thanks! We eventually found this, we wanted to test other things first but this prevented us from deploying altogether with minimum stack trace to the root issue:).

1 Like