Ri3D Redux 2023 - 2 Robot Reveals Posted

Ri3D Redux is a new Robot in 3 Days team for 2023 based out of the Peoria, IL area. We look forward to showcasing a number of potential solutions and useful video content for teams for the 2023 game starting on January 7th. The team includes a number of alumni and mentors from throughout our community, many with past experience from FIRST Capital Ri3D.

We have numerous team members contributing prep time, machining resources, and equipment – their support is much appreciated.

Our Amazing Partners:

FRC Team Support From:

FIRST Updates Now Twitch

FIRST Updates Now YouTube

Ri3D Redux GitHub

Social Media:

Stream Schedule (Eastern Time)

Saturday January 7th:
Stream from ~1PM (sometime after the kickoff stream) - 1AM
Break for FRC Round-Up from 8:45PM - 9:30PM
Team/Robot Update at 9:30PM

Sunday January 8th:
Stream from 10AM - 1AM
Team/Robot Update at 7:30PM

Monday January 9th:
Stream from 10AM - 1AM
Team/Robot Update at 9:30PM

Tuesday January 10th:
Stream from 10AM - ~1:30PM
Robot reveal at 1PM

Wishing all teams an amazing kickoff as we start the new season!


You bet your bottom dollar Ri3D plays in Peoria!

Day 0 Prep - Part 1

So, as you’d hopefully expect, not 100% of the work is done in three days. “Ordering parts and staring longingly at the front door” makes for a pretty boring stream. There’s a lot of prep work that happens first to ensure the three days are as productive as possible.

We fully believe that the steps taken mirror what an FRC team should be aiming to accomplish in their offseason, to make their own build season. For this post, anywhere I know we deviated from the “what could a normal team do” rules, I’ll make a note of.

Parts Stocking & Sponsorship

This work actually started months ago. Ben led the charge on making sure we had sponsored product in the door, and helped to procure parts to fill any gaps.

Recruitment & Teambuilding

An internal discord server was set up to coordinate planning efforts. Team members were recruited, and reached out to their networks to find even more available people. We had a number of planning meetings, including making sure people who were traveling in from out of town had places to stay and cars to get them where they needed to be. Food was planed out, along with a few small social events to make the “mini Peoria vacation” worthwhile. Also, hopefully, build up some relationships with people who share an interest in robots, but otherwise have never met.

Social Media Accounts

One main product of our Robot in 3 Days effort is educational content for teams to consume. Success here means having the channels available to deliver this content. Multiple team members have spent the majority of their prep time making sure these accounts are updated, consistently branded, and prepped for delivering information to teams.

Build Space Setup

A few different options for build area were considered. A basement was selected as the most viable option. As soon as that decision was made, work started on setting up the space. Plans were made for a temporary testing area, along with an organized workshop with multiple build areas. Safety concerns were analyzed to determine minimum acceptable PPE.

Hardware & Electrical Prep

Leveraging a few rules that were tweaked in 2022 and 2023, we went ahead to pre-assemble many different COTS components. This included a full SDS Mk4i swerve drive base.

Not yet pictured: some electrical work to get most of the standard components mounted and connected.

Caveat: This is only legal if used as a practice robot drive base, and isn’t taken to competition. However, the time spent to assemble modules was… not much. Four people got all four done in about 2 hours. The drive base was cut and assembled about an hour later.

Editorial from the Software Guy

These modules were phenomenally easy to put together. It’s honestly easier and more consistent than the kitbots I’ve worked on. Kudo’s to SDS on this one - what impressed me the most was that there was … almost … no way to make a mistake during assembly. If two parts weren’t supposed to go together, they didn’t fit together. If you had parts left over, you knew you did something wrong (guilty, 1x).

Honestly. It blows my mind that the same product that simultaneously won and lost Einstein this year is so accessible to even the teams who wouldn’t consider themselves great at doing mechanical things. My bar of “good mechanical design” has been set to new heights.

We also went ahead and flashed robot controllers up to the latest firmware. However, it’s likely we’ll have to redo that work after kickoff. At least we know we have a laptop that can do it.

Software Prep

Knowing we’d have some swerve drive modules on hand, as well as knowing some of the electrical hardware, we opted to try to write some software in advance. While we’ve had pretty limited time to actually test anything out, we’ve got a large chunk of the “thinking” work done for hardware we are very hopeful will appear in the final product.

Some repos to check out:

Robot2023-Simple represents the WPILib swerve example with pose estimation, updated to support the hardware currently on the drive base. It’s fairly bare-bones still, but represents the simplest, minimum-feature way to get our drive base rolling. Which, for three days, is what will matter the most.

Robot2023-Advanced was also tossed together, as reference for an integrated set of swerve simulation, path-planned autonomous, web dashboard, and a host of other bells and whistles. As we see what our build capacity is, it may get used either directly or as reference for demoing more advanced features.

Again keep in mind - neither has actually been tested on real hardware, yet. However, by about a week from now, there will hopefully be more working code there. We’ll be sure to update documentation to clearly lay out


With the AprilTag fiducial targets on the field this year, we’re not yet certain what the “best way” to process or use them will be. However, we are doing some work in conjunction with the PhotonVision team to trail a few solutions. Most will be raspberry-pi based, and involve a few different cameras and mounting solutions.

Latest CAD for that case.

Caveat: doing the 3d printing before kickoff isn’t acceptable per the 2022 rules. However, “watching a 3d printer for 3 days” makes for a boring livestream.

Again, we really don’t know what this will be used for, if anything. But the goal is to have prep work and tools at our fingertips, so that if it’s useful and we can demo it for teams, we’ll be able to do it effectively.


I’m curious to learn about the goals for Ri3D Redux, and how those goals are reflected in your design decisions. Depending on the answer to this question, my comment below might not be valid.

I have little doubt that you’ll be able to pull off the swerve in 3 days. Swerve is unquestionably easier to implement today than it ever has been before. That said…

I have serious concerns about what using a swerve drive during Ri3D says to the types of teams that would primarily benefit from Ri3D. Will there be any caveats during the media content that you put out stating that the swerve drive isn’t something that teams should take on lightly; or is Swerve drive being promoted as an entry level drivetrain at this point in FRC history and I’m just overly cautious?

I would love to learn more about the thought process for this decision.


Build the best robot(s)/subsystems/code we can in 3 days and explain through video form how to implement them. We’ve tried to maximize the resources available and partner with some great suppliers so we can make as much useful/quality content for teams as possible. I personally disagree that Ri3D primarily benefits low resource teams, rather every team regardless of resource level benefits can benefit from Ri3D (I was on a team that showed up on the FRC top 25 several times in 2013 that had no idea how to shoot a frisbee until Ri3D 1.0 showed me how, saving our team weeks of work). Swerve is pretty easy at this point (to the point that many teams are buying modules now without even seeing the game) and a well-built swerve provides a competitive advantage in most games under the current robot ruleset, so helping teams that choose to implement swerve implement it faster is in my opinion a good challenge for at least one Ri3D team to undertake, as this is something some teams will want help with.


I agree with this statement. While more experienced teams / higher resourced teams * are perhaps not going to just copy an Ri3D design, the design ideas that are shared by the Ri3D teams often factor into our discussions and elements of some of those ideas often find their way into the final design.

Also, swerve opens up lots of design options that are simply not viable if there is defined “front” and “back” to the robot. A lot of teams adopted swerve in 2022 or in the 2022 off season that may still be stuck in the mode of thinking about the robot in terms of having 1 or perhaps 2 sides that can be used for manipulator mechanisms. I think a lot of these teams that have already made the jump to swerve could benefit from Ri3D designs that allow them to see how any side of the robot can be the “front” at any time.

Note: * experience and resources are not the same. Many teams with lots of experience are low resource teams and many well resourced teams may be low on experience.


It’s wild how quickly we’ve gone from “Swerve is the most complicated drivetrain and is only ever attempted by the most ambitious teams” to “Swerve is so easy, even an Ri3D team doing one”.

With more and more teams making the switch to swerve, I think Ri3D Redux will be providing an invaluable resource to this subset of teams.


You did all this work creating a swerve drivetrain before the game comes out then you discover that it is 2016 2.0…


A lot of teams are sitting at home with a bunch of sds modules hoping its not (guilty with 10)


Do I spot the unmerged pr for state space swerve in there??


A request:
When talking about your swerve code on stream or in videos, make sure you show everything in the debugging/setup process. Showing up on the first video with a fully working swerve chassis wouldn’t be a fair representation (unless it really did work first try). This includes is setting the zeros in the modules, describing what doesn’t work in detail, how you fixed it, how long it took, etc. Teams need to be shown a realistic view of the debugging maturity you need to do swerve in an effective time frame. Students shouldn’t be running home to their teams saying, “Oh, look how easy it is, they could do it in 3 days, why can’t we do it?” when their programmers may not have the experience necessary to get a template code working. Swerve is a solved problem mechanically at this point, but I still see teams every day struggling to get their template code actually working.

This is already reflected in the mechanical side of most Ri3D, where they show what works and doesn’t work (and that’s what ends up helping teams) and I hope that’s reflected on the software side as well (even though it’s kind of boring and may not get as much screen time as the rest).


If this happens, I then REALLY hope that a ri3D team tries to run the mk4i’s over the terrain and determine if it’s worth trying. 16 pulled a swerve off in 2016, along with many others.

I’d rather see 1 team try it out for everyone before we try to abuse our MK4is like that.


It’s not like I don’t agree but this is a robot being made in 3 days. That level of detail and subsequent explanation will be very difficult. I think that level of information should be left to CD or a less rushed video. A lot of time programming takes place off camera and is a bit difficult to document in an easy to consume video. Also, I am going to assume most of their programming for the drivetrain is already done.

1 Like

I agree that the timeline is limited and giving that level of explanation will be difficult. It probably won’t be possible to show all the issues and whatnot, but even just mentioning them in the software section, like “hey, we had these issues, we fixed them using X, Y, and Z” would work for me. They should at least be talked about if possible, somewhere, whether thats in a CD post or after the fact of the 3 days.

@mdurrani834 I will be at the RI3D Redux, and I’ll see what we can do. I joined RI3D for some of the reasons you mentioned, they show cool designs, but barely get into the software construction/development. You never get to see a cool SW feature, like how to track a goal, or shoot from any distance, or how to do autonomous sequences. Some of that is the time constraints we have.

I am making notes and will try to present something (I believe there is a video or 2 planned for this exactly). That was part of my push also with the Simple repo at least. A lot of RI3D teams use libraries and other features they are used to, but I find libraries confusing for teams learning. The Simple repo should use just WpiLib features to implement the robot, so it should be easier for teams to follow. (I think there will still be lots of hacks to make the robot work, so it won’t be the cleanest)


Yup Steven will be leading the charge on the live things. I suspect the sweat, tears, and “darn you Chris why did you write software like that” will be observable some time fairly early on Saturday.

I prepped about an hour of myself live coding the wpilib example into what the team is using, and am gonna prep another basic overview soon. I’ll make sure these get posed somewhere as a resource.


Here’s the practice chassis wired and with bumpers. Could be cleaner, but most of us were pretty occupied over the holiday break with both prepping other parts of the Ri3D project and other projects, so we opted for functional but quick to put together.

As noted above, we have no idea what the game is, but as a lot of games have mostly flat floors, having a chassis ready to go is great for parallel pathing the programming tasks and having a base to attach intakes for testing. We may need to take it apart if the game requires it.

We left two sides with full bumpers and two sides with cutouts so we can test a number of different intake styles quickly.


I trust Ben and company to do a great job of adding whatever disclaimers and caveats necessary to tell viewers what is happening and why, and the thought processes behind their decision making. Ben is by far one of the few people who does Ri3D that I trust enough to share their videos with my own students. There are a handful of Ri3D teams that already cater to an audience that is looking for a MVP/MCC, so I think as long as Redux establishes their goals in their video, teams should be able to judge for themselves what ideas to lift from Redux vs what they may not be able to accomplish. I also trust Ben and co to release comprehensive resources to help as many teams as possible with their ideas.

Looking forward to seeing how this turns out!


To be fair, it wasn’t done in 3 days. It was (is being) done before kickoff. If anything, I think the Ri3D Redux team is showing that this is not something that is so easy it can be done in 3 days and they have already shared with us that it was something that they needed to do ahead of time. They have not talked in any detail about the code that they are using for the swerve, but I suspect they will be using existing code that they previously developed or that is publicly available as a starting point with few, if any fundamental changes to how the code calculates the angle and speed of each module. Time is running low, but I suspect that they will attempt to get the drive base code fully operational before kickoff as well.

If a team wanted to emulate Ri3D Redux, they too would be working or have already worked on getting a swerve drive base working before kickoff.

1 Like

Not sure where the team will be at code wise but we do intend to release a video soon(ish) providing an overview on the drive/drivebase

When FIRST Capital was around they utilized the drive base of a prior robot to build off of instead of taking the time to assemble it from scratch, mostly for time savings. With the team choosing to go with swerve we coordinated with SDS and other suppliers to get needed resources so this could be assembled ahead of time to be that platform. With most areas of Ri3D we intend to document it so Ben put together a bit about the process that I will be editing soon.


In the image you can see also a 2nd set of modules – if we have time, we’ll put together a second drive base after the game is released. This gives an opportunity to go through some of those lessons on stream that we learned from the first one, as well as also make changes based on the game parameters. A second drive base also gives us room to showcase more than one set of mechanisms, if time and resources permit.

We probably will be debugging swerve code on Saturday due to time constraints, but I’m not worried about it because we have team members with swerve code / SDS module experience.