The SuperNURDs are more excited than ever to take part in the FRC 2023 Challenge, Charged Up!
We will be posting weekly recap videos every week during build season to showcase our progress and designs!
Look forward to videos posted on the following dates:
Week 1 (1/14)
Week 2 (1/21)
Week 3 (1/28)
Week 4 (2/4)
Week 5 (2/11)
Week 6 (2/18)
FRC 2023 Robot Reveal (TBD)
To kick off our season! Check out our FRC 2023 Trailer Video!
Our first revision of our cone intake prototype!
We were using 2" Flex wheels on one side, and 1.875" Bane Bot wheels on the other roller as an initial test. After further testing we discovered that for this style of intake, doing two sets of 1.875" Bane Bot wheels provided better grip with the cone’s material. *Note there are many other variables at play here and this is just a rough prototype.
Zip Tie Cube Intake Prototype
For the 2020 Season, our robot featured an intake made of zip ties for the balls, so we decided to give it a test for this year’s cubes. However, it was not as effective as it was in 2020, but still worth a test.
We spend today’s meeting primarily discussing robot strategy and making intake prototypes.
Here is our current concept for a cube intake!
Here is our concept for a cone a intake!
We are still in the rough prototyping phase, but I thought I’d share some insights.
Our 3rd Revision of our 2023 cone intake design! This revision of our cone intake will be mounted on pivoting arm allowing us to pick up fallen cones as well as upright ones!
Fantastic job! That intake/cube shooter is amazing! Is your v3 cone intake backward-facing arms passive? Or some elastic that pulled them in/out? If so, do you mind showing a top-down picture?
After prototyping our cube/cone intake we decided to test out the idea of launching the cubes! It doesn’t seem that consistent with our current setup, but it was definitely worth a shot!
Thank you! We currently have elastic surgical tubing bands keeping them pulled out in the V formation! We found that keeping it in the V formation by default allows for the cone to get trapped behind the wheels like the video, and allows for good compression on the cube.
Heres a top down photo from our weekly recap video!
On kickoff day our one and only goal is to understand the game. We try (with some success) to not discuss robot design. We try and avoid words that indicate a specific mechanism, like “arm” or “elevator”, opting for words like “lift” as to not unintentionally bias ourselves when it does come time to design.
First, we read the game manual carefully and thoroughly. We sought to answer questions like
After that we analyzed various basic aspects of the game, asking questions like
Once everyone had a solid understanding of the game we moved on to basic strategy discussion. Questions we wanted to answer were
We started on a list of abilities a robot could have. Importantly, these were not designs or mechanisms, just the ability to do some action. Examples include
We tried to make this list as exhaustive as possible, and any idea anyone had on anything a robot could do was include, no matter how impractical it may seem.
At the end of the day we were tired of looking at a spreadsheet so we started playing around with intake prototypes for the game pieces, experimenting with how different wheels gripped the pieces and around how much they could compress. Nothing scientific, just trying to gain a basic idea of how these game pieces behaved.
We took the list of abilities a robot and gave them all a rank from 0 to 5. Items like “drive” got a rank 5, while items like “pickup cone from high node” got a 0. This was a long and tiring process, but we now had a priority list of everything our robot needed to do, and everybody had a good idea of what should be prioritized.
We then went through this list again and wrote down which general subsystem would be responsible for each ability. Luckily this didn’t take too long, as we found that the intake subsystem and lifting subsystem were responsible for the vast majority of actions (big surprise, i know).
Since the lifting subsystem design will be so dependent on what’s on the end of it, we moved into intake prototyping. You can find our prototypes in the videos above, and we will continue to upload shorts to our YouTube channel of prototypes and progress.
We ended up with 3 main designs
We started the meeting by presenting all three intake prototype designs and making a few decisions
We continued to develop the compliant design. We
Along with the intake prototyping, we started mounting electronics to our swerve chassis. This chassis was created before kickoff so it will swerve as our practice robot drivetrain. We had another swerve chassis we used to program during the offseason but it was not created to be anything more than a programming test bed.
We also started researching a mechanism we’re calling the Charger. More on this to come…
Fairly happy with the state of our current “compliant” intake prototype design, we created a CAD model for it and began fabrication. This will be a more robust prototype built out of wood that will let us really see how this design performs.
We continued to mount electronics and started to wire our swerve chassis. This is our first time using a brainpan instead of a bellypan, as well as our first time using the PDH and RPM.
We created our software project for the season (link) and populated it with many issues to resolve. We’re going to treat our main branch as sacred this year, and take extra steps to insure we can deploy main to the robot any have it just work, with no glaring bugs or crashing issues.
The CAD model of the compliant intake prototype was finished.
We created a geometry sketch template for every subsystem to use, and began on geometry sketches for the arm.
The swerve chassis wiring was nearly completed.
With the compliant intake prototype CAD and fabrication completed, we began assembly and testing, and immediately found good results with this design. It can pick up a cube and upright cone very well, and it keeps a very tight grip on both.
We decided to assemble a prototype “utility arm” to help grab the cube for the intake. This worked really well and you can see it in our Cube Launcher short.
At this point, we were were ready to make some (preliminary) decisions on what mechanical subsystems will be on the robot.
This intake will have to have some sensor to tell if it’s holding a game piece because we have to stop the motors or else we will probably pop the cube. Originally we thought this should just be a simple limit switch but the idea of a color sensor seems promising, so we started working on software to detect which game piece the robot was holding based on its color. It was mostly complete and just needs tuning.
We finished the swerve wiring and turned it on for the first time (no sparks!). We then needed to put the latest firmware on the 8 Falcons and 4 CANCoders, which was a whole lot more difficult than I remember it being in 2022. Mainly, there was an issue where every single CAN device disappeared in Phoenix Tuner after flashing the firmware on each CANCoder, requiring the robot to be turned off and back on 4 times.
Formatting the roboRIO wasn’t without troubles either. After checking that all the network adapters were disabled, checking the firewall was disabled, restarting the robot several times, putting the rio into safe mode, restarting the laptop several times, and trying several laptops, the issue turned out to be a bad USB-B to USB-A cable (I think). At least the radio programming went smoothly.
After all that we could start debugging the swerve code. We did have functional swerve code from the offseason, but decided against just porting it to 2023 and instead rewrote it. There were several bugs and quirks with the old code and rewriting it would give us a better understanding of how it worked.
Is your guy’s cad public this year?
Our CAD will be made public at the end of the season. You can keep up with our designs and progress in our shorts and recaps
Here is our current code for our 2023 robot, which is just a swerve drivetrain currently. If anyone has any questions please feel free to ask here.
Testing out our arm prototype!
Last week we focused a lot on the intake, under the logic that the design of the intake is going to affect the design of everything else quite a bit. This week we finished the basic intake CAD, and started the CAD for everything else.
The collector is going to be a wide, over the bumper roller to assist in picking up cubes, as well as our climbing mechanism. It’s going to deploy using a motor rather than pneumatics, and we’ve been working on CAD for it throughout the week. We also started assembling a more advanced prototype of it so we can fine tune the gear ratios and make sure it works as intended. Here’s a video of an early collector prototype picking up a cube:
We’ve decided on a double jointed arm mechanism to put the intake on, and started work on the CAD for it. To give us a head start on more advanced programming of it though, we built a 1/4th scale simplified double jointed arm. It’s powered by NEO 550s with 100:1 planetaries and REV through bore encoders. The plan for our full size arm is to use full size NEOs so this will allow for much of the complicated programming to be completed early.
Here is a video of the of the model arm in action (before any advanced programming, the operator here is just commanding the percent output of each joint motor):
You may be asking yourself “what complicated programming? You can just run a PID loop on the motors and have a few preset positions.” Well, that is a valid approach, and we did implement presets before doing anything more advanced to have something to fall back on if the more complicated doesn’t work out, but there is more we can do. By using inverse kinematics, ideally we will be able to set the position of the intake (which is at the end of the arm) using horizontal and vertical coordinates. This will open the door to let the arm be controlled more smartly. Here are a few examples:
The operator can directly move the intake up, down, forwards, or backwards (instead of manually controlling the rotation of the joints). If they need to do something complicated this will make it much easier for them to do so.
Motion profiling, or moving the intake around with deliberate motions. The way I like to think of it is that we can technically run G-code on the arm. This isn’t actually all that useful but it may allow for much more consistent mid or high node cone scoring, since you can deliberately and quickly set the cone down on the node.
Constraints. Although not as important this year due to the generous 48" extension limit, this will also let us more easily stay within the frame extension limit and height limit.
We made it as far is implementing the inverse kinematics based on this educational video, but couldn’t get it to be completely functional. The intake was definitely going to a point in 2d space but not the desired point. Sadly since autonomous routines and general swerve drive tuning will take priority over the advanced arm control this might have to take a back seat, but I will be sure to revisit this if I get the chance.
Last offseason, we worked on AprilTag recognition using PhotonVision running on an old Limelight, but due to a bug in the implementation of the Kalman filter used in the SwerveDrivePoseEstimator WPILib class the robot code would crash when seeing an AprilTag. We did learn a lot in the process though.
We decided to get an N5095 Beelink Mini PC for our coprocessor this year, along with two global shutter cameras (AR0144 and OV9281) and 2.8mm lenses. The Beelink will be running PhotonVision and powered by a boost buck converter that accepts an 8-40V input and outputs 12V 3A, perfect for the Beelink. (I am slightly concerned about it only accepting a minimum of 8V but that shouldn’t be an issue in a match.)
Since we had already completed the swerve drive base for our practice robot, we were itching to see the pose estimator work with AprilTags, but there were many things holding us up.
First, we needed to mount the Beelink on the robot and wire it. Thankfully, mounting holes for the Beelink were included on the brainpan, but when we had previously wired everything else on the robot, we neglected to leave the space open for the Beelink. So, we spent an entire meeting rewiring around where the Beelink needed to go.
The next day we needed to wire the Beelink to be powered by the robot, and we didn’t have our boost buck converter yet (actually we didn’t order it until that day), so we decided to just use the VRM for now and hope for the best.
It was at about this point that we realized that we should probably have the field elements that the AprilTags go on in the correct position before we get too excited about recognizing them, so we got started on taping out the zones and where the field elements should go on our carpet. We had already completed the co-op grid, so now it was just a matter of figuring out the correct location for it, moving it there, and placing an AprilTag on it.
Next, we had to actually put a camera on the robot, and although we had our global shutter cameras we had no good way to mount them. Our plan is to 3D print cases for them later in the season. We also don’t have the lenses for them either, so we decided to just ziptie a good ol’ Microsoft LifeCam on and call it a day.
Finally (after a few minor software fixes) we got the whole thing working. A WPILib SwerveDrivePoseEstimator being updated with drivetrain encoders, a navX2, and AprilTag pose information. You can see us playing with it at 0:58 in our week 2 recap video.
https://youtu.be/JqeocUKpMHE?t=58
Since the camera was loosely ziptied the vision pose wasn’t very accurate, so we couldn’t do much more until we got the real cameras properly mounted. Still, it was really nice to see this all come together after months of work.
