The video you linked is a little older.
This one is from an hour ago or so and seems to be more dialed in:
They’re working on a sketch that outlines all the important dimensions. Once that ready they’ll post it.
The wheels in the last video are all 4" wheels. Combination of fairlanes, stealth wheels and compliant wheels.
We’re waiting on an AndyMark order with extra compliant wheels.
Did your second-order swerve code ever get published?
Pre Season Software Release
It took a while because we had to iron out some bugs while merging code between WPILib 2022 and the 2023 beta, but I’m happy to announce that the 4481 Stock Robot code for the 2023 season is now live on our Github page!
This release includes changes to our Path Planning system and our custom Swerve implementation.
Update #2 - More Prototyping, Yes More
If you’ve been following along, you know we’ve spent all of week one working on prototyping while our 3DM (Data Driven Decision Making) team has focused on analysis. To close out the week, here is a recap/spotlight on some of our prototypes.
YouTube Playlist of Prototypes
Remember we post all of our videos directly to our YouTube playlist for the Build Season 2023 - Robot Development. We hope you continue to enjoy, and in the world of YouTube… we hope you Like, Comment, and Subscribe!
Notable Prototypes
Here are some more notable prototypes so far:
Cube - Ri3D Redux Intake
Cone - Ri3D Redux Intake
Cone - Pinch Rollers
Cone - “Verticalizer”
Cone - Pneumatic Pinch With Gravity Rotation
Fun Prototypes
Here are some of the more fun prototypes so far:
Cone - Double Weed Wacker
Cone - Launcher?!
Lessons Learned
Cubes = Balls, enough said on that one.
Cones = One of the most interesting and challenging game pieces we have had.
Next Steps
It’s approaching the time where we start to move from prototyping to living in front of the computer screens. That’s right, it’s time to go from plywood and left over parts to CAD and custom sheet metal and polycarbonate. We will be looking to combine some of our favorite prototypes into a mockup of subsystems on a chassis to get an idea of how it all works together.
This post was written / compiled by: @Justin_Foss
Week 1 | Team rembrandts Buildseason 2023 Recap video
Week 1 | Team rembrandts Buildseason 2023
Fail fast, learn faster is our motto which is especially true for week 1!
We’ve gained a lot of insight in what concepts work, what isn’t succseful and what the important parameters are for our overall design.
Let’s look back to a very productive but most importantly a very fun week through our week 1 recap video!
This post was written / compiled by: @Sandwich21
Game Analysis
Having a successful season requires building a strong robot. Building a strong robot requires a strong strategy. Having a strong strategy requires a high level understanding of the game. This year’s game, FIRST Charge up presented by Haas poses a new challenge to teams once again.
This analysis is a follow up to the game analysis we already started in our Kickoff / Reaction Post. We’ve started analysis on several different things, chief among them: Where do we want to score? and how quickly could we score? Both are going to be invaluable in not only deciding what we should build but also how to test them, when are they performing to the level we need them to perform?
Location Scoring
To start by stating the obvious: scoring links is going to be very beneficial. An easy calculation shows that even when scored on the highest level it gives you a 33% scoring bonus over three unlinked cones or cubes. This does mean that it seems necessary to either score on the low level a lot, or to be able to score both cubes and cones.
We’ve narrowed the options down to three ways that we think we could do and are worth looking into. These are: scoring everywhere with both cubes and cones, scoring on the middle and low levels with both cubes and cones, and scoring on the high level and lower with cubes, but on the middle and lower level with cones.
As a short reminder this is how that would look points wise, with on the y-axis how much cargo was scored in autonomous and on the x-axis how much cargo was scored in tele-op. For these charts we assume that you always make as many links as possible.
Scoring everywhere with both cubes and cones:
Scoring on the middle and lower levels with both cubes and cones:
Scoring on the high level and lower with cubes but on the middle and lower with cones:
As expected, scoring high and lower is obviously scoring a lot more points, but the third option is a lot closer in certain scenarios when you’re not scoring as much. The reason this third option was chosen is because we believe that we could potentially shoot cubes out of our intake, this would make it an easier mechanism for the cones and would also be slightly faster when scoring them, which would decrease our cycle time.
When you compare the high and lower scoring option with only scoring cubes high you do see that after a couple of cycles you need to start scoring way more cycles to keep up. In the chart below you can see how many tele-op cycles extra you would need to outscore it this way.
After you score 2 or more cycles in an entire match it becomes very tough to outscore high everything, because you can’t link the cubes on the highest rungs so they become basically bad decisions to score unless you can’t reach the 3 more pieces of cargo to get a link anyways. Not only would this be very hard to predict with how chaotic matches can be, but even if you could, with 3 or more cycles certainly being realistic it becomes very unlikely that we could score 2 cycles more just because shooting cubes would be slightly faster (especially with full court cycles this year) or because a less development time to just score middle would give us more practice time.
Cycle time analysis
Field layout
How are we going to make a strong cycle time analysis without understanding the field FIRST? Get it, FIRST. . . uhm yeah Right, Back to the topic. The field for Charge Up has quite some interesting aspects to share.
First, we’ll look at the layout of the field and check which zones are the most relevant places on the field to be. You can see it as some sort of “health map”. The zones indicated by a number are the “places to be”. Not only does this give an indication of driving distances but it also allows for a very first strategic discussion.
For example, where on the field would you want to play defense and is it worth it? Quite a big question to ask yourself.
Of course each zone on the field has its own specific function to the game. In the table below we share what these functions are and how they affect gameplay. In the comments we’ll note important limits or factors to keep in mind.
| Nr. | Name | Gameplay task | Function | Comment |
|---|---|---|---|---|
| 1. | Grids | Scoring Cube/Cone | Scoring | 27 scoring positions (12 cones) (6 cubes) (9 combo positions) |
| 2. | Charge station | Docking/Engaging | Scoring | Docking/Engaging during autonomous/ Tele-operated. Angle changes depending on weight balance on the charge station. |
| 3. | Loading zone | Grabbing Cube/Cone | Pickup | Cones and Cubes are grabbed from single substation and double substation. (Double has a placing pad and a dropping gate. Single substation has a dropping gate. Cones will not always stand upright. |
| 4. | community | Scoring Cube/Cone | Scoring | 3 ways to enter the community: cross charge station, pass in between charge station and barrier, in between charge station and field border. Robots can start the game from anywhere in the community. |
| 5. | Staging marks | Grabbing Cube/Cone | Pickup | 8 game pieces located (4 cones and 4 cubes) alliances can choose the line-up on their side. |
At this point we have not yet looked into scoring data or game rules. These follow as we understand how the field works.
Scoring table and time assumptions
Let’s look at the scoring table. FIRST has made it a good tradition to add this to the game manual! We’ll only have to look it up and use it for our analysis.
In this game one of the first aspects to notice is that scoring on different levels actually does give different point valuations. You might remember 2019 where the scoring position didn’t mean anything to the amount of points an alliance would gain. Only the scored game piece mattered. In this game it’s the other way around. Another aspect that immediately caught our eyes is the importance of strategic scoring. The scoring location in this game can impact your score and your ranking due to the link and co-opertition system.
It really boils down to this: It doesn’t matter what you score, as long as you place your game piece in the right spot. Now, this isn’t completely true as you can’t score cones or cubes on every scoring location. Some are only for one type of game piece but in essence this is how we look at it.
| Award | Awarded for… | AUTO | TELEOP | Qual. | Playoff |
|---|---|---|---|---|---|
| MOBILITY | each ROBOT whose BUMPERS have completely left its COMMUNITY at any point during AUTO. | 3 | |||
| GAME PIECES | scored on a bottom ROW | 3 | 2 | ||
| scored on a middle ROW | 4 | 3 | |||
| scored on a top ROW | 6 | 5 | |||
| LINK | 3 adjacent NODES in a ROW contain scored GAME PIECES. | 5 | |||
| DOCKED and not ENGAGED | Each ROBOT (1 ROBOT max in AUTO) | 8 | 6 | ||
| DOCKED and ENGAGED | Each ROBOT (1 ROBOT max in AUTO) | 12 | 10 | ||
| PARK | Each ROBOT whose BUMPERS are completely contained within its COMMUNITY but does not meet the criteria for DOCKED. | 2 | |||
| SUSTAINABILITY BONUS | At least 5 LINKS scored. | 1 RP | |||
| COOPERTITION BONUS | At least 3 GAME PIECES scored on each ALLIANCE’S CO-OP GRID. | The SUSTAINABILITY BONUS threshold is reduced to 4 LINKS for both ALLIANCES. | |||
| ACTIVATION BONUS | At least 26 total CHARGE STATION points earned in AUTO and/or ENDGAME. | 1 RP | |||
| Tie | Completing a MATCH with the same number of MATCH points as your opponent. | 1 RP | |||
| Win | Completing a MATCH with more MATCH points than your opponent. | 2 RP |
In order to estimate times we’ll need to do some assumptions based on previous years. We’ll go through these one by one. As you might expect, changing these assumptions will have an impact on your cycle time which in turn impacts a robots overall performance.
| Variable | value | Unit | |
|---|---|---|---|
| Collecting Cone / Cube | 1,00 | s | Amount of time it takes to collect a game piece. |
| Scoring Cone / Cube | 1,00 | s | Amount of time it takes to score a game piece. |
| Average drive speed | 3,50 | m/s | Speed at which the robot travels. (11.5 ft/s) |
| Drive over charging station factor | 1,50 | n/a | A slow down factor for driving over the charge station. |
| Docking + Engaging | 2,00 | s | Time it takes to dock and engage a robot. |
| Inch → Meters | 0,0254 | m | Yeah we’re European, we kind of need to use a different system. |
| Total time Auto: | 15 | s | Time available in autonomous. |
| Field width | 8,0035 | m | Width of the field. |
Autonomous cycles
The pieces for our analysis are set in place. Let’s be honest, this is the part you’re reading this blog for, aren’t you? Before we do, we’ll have to keep in mind our starting position. This can be any spot within the community. We’ll assume 3 starting positions, but to keep this post slightly brief we are only focusing on one start position, the other two will look very similar anyways. Now the analysis. We’ll use the scoring table and assumption table to give ourselves an indication for each cycle.
The main question here is simple: What do we think is possible within 15 seconds?
2 game pieces high → Docking + Engaging (Position 1)
| Action | Time | |
|---|---|---|
| Score Cone | 1,00 | s |
| Move to Cube position | 1,18 | s |
| Pick up Cube | 1,00 | s |
| Move to scoring position | 1,63 | s |
| Score Cube | 1,00 | s |
| Move to Charge station | 0,85 | s |
| Dock + Engage | 2,00 | s |
| Total time | 8,65 | s |
| Points | 27,00 | p |
3 Game piece and no Docking + Engaging is 5,80 sec.
Without engaging the score becomes: 15.
Drive time*1,5 because driving over the charging station takes more time.
3 game pieces high → Docking + Engaging (Position 1)
| Action | Time | |
|---|---|---|
| Score Cone | 1,00 | s |
| Move to Cube position | 1,63 | s |
| Pick up Cube | 1,00 | s |
| Move to scoring position | 1,63 | s |
| Score Cube | 1,00 | s |
| Move to Cone position | 1,70 | s |
| Pick up Cone | 1,00 | s |
| Move to scoring position | 1,70 | s |
| Score Cone | 1,00 | s |
| Move to Charge station | 0,85 | s |
| Docking + engaging | 2,00 | s |
| Total time | 14,50 | s |
| Points | 33,00 | p |
3 Game piece and no Docking + Engaging is 11,65 sec.
Without engaging the score becomes: 15.
Drive time*1,5 because driving over the charging station takes more time.
Tele-operated cycles
For tele-op cycles we pretty much want to find out how quickly we can drive back and forth on the field. This game has a full field cycle. We haven’t calculated cycle times for the staging mark game pieces. The reason for this is because these aren’t consistent pick-ups as many things can happen during the game that influence their position. Besides this, some of these might be placed already once tele- op starts.
We can find a cycle time by understanding pick and place times and calculate how long the robot travels from point A to point B and back to point A. Now the pick up and places times depend on your sub systems. These estimates might change depending on proto type results. The travel time can be found if we know the distance and robot travel speed in m/s.
The first figure is a rough straight path for the robot to travel. We purposefully went for these points as their coordinates can be found in the official field drawings. In order to keep the calculations simple we’ve not determined individual times for each scoring position. At this point that would be overdoing things due to the amount of assumptions in our variables.
As you can see, the distance can be calculated by using geometry. The right top corner of the field in the image is taken as reference, you can see the yellow dot. Now you might say, well, but what about the bottom scoring position? You do have to drive quite a bit further right? Wouldn’t that take longer?
The answer is: yes it does. The difference is about 1 meter of drive distance. You can pretty much fill in the blanks. The result is about 1 to 1,5 seconds extra per cycle.
| Cargo collect | Time | |
|---|---|---|
| Drive to collecting location | 3,62 | s |
| Collect game piece | 1,00 | s |
| Move to scoring position | 3,62 | s |
| Score game piece | 1,00 | s |
| Totaal | 9,23 | s |
| Points | 6,00 | p |
| Points per second | 0,65 | p/s |
Assuming a scoring position as starting point. Then moving to collect position, then moving back to scoring position.
So: 3->2->1->2->3
| Approximate cycle time: | 9,5 / 10,5 | s |
|---|---|---|
| Total time (tele-op) | 135,00 | s |
| Total time (auto) | 15,00 | s |
| Cycles completed | 12,86 | cycles |
| * Assumed as a theoretical “max” with the assumptions in our tables. |
Lessons Learned
With our analysis we can conclude several things. First let’s look at our autonomous cycle times.
This post was written by: Gijs de Veer and @tijnn
At 3 game pieces per link and 5 links (4 with coopertition) for the RP that would be 15 cycles (12 with coopertition) to get the RP, no?
You may want to consider driving to the middle of the field as a potential auto as well. Remember, only one robot gets credit for docking/engaging in Auto. Could be worth going to the middle to prepare for tele/cut down on first cycle.
I was thinking about this part, and this is where our prototypes are.
Flipping a cone
Lifting a cone
I’d probably have a redux intake front (funnel) in the channel, and then a pincher grabber at top of slope.
Is there any update on this? Thanks!
Here’s a link to our v2 sideplate solidworks files: 2023 CAD - Team Rembrandts - Google Drive
Don’t have the sketch on hand. The hole pattern matches that of the REV tubes and we used it to test different heights relative to the ground.
I asked within the team again and they said they’d post the sketch tonight! Sorry for the delay.
Very interesting concept and thanks for sharing! Curious to see where you’ll take it.
I could potentially see the same roadblock that we’re hitting with the verticalizer and that’s the huge space claim in mainly the height. We’re trying to go as small and compact as possible. But for such a system the cone needs to drop in from quite high-up.
Only intaking over the bumper and still being able to drive over the charging station isn’t as easy if your verticalizer goes through your bellypan.
You’re totally right, thats a typo.
Totally true and something our programmers are planning on. The reason I don’t mention it in this post is because here we’re kind of reasoning from a position of playing alone: as in what can we do to maximize points, this is so we can consider what we need to design. Of course in actual matches we will have to be adaptable and try and maximize the points of our alliance, or more specific maximize the difference in points between our alliance and our opponents (defence is a totally valid way of winning matches).
Roughly something like this, but it does take a significant footprint.
Here’s the current sketch we’re working with, in millimeters 
The bottom roller in this design is based on 4" wheels. The distance from the carpet to the 4" wheel is 60mm. This plate was mounted on our REV MAX swerve tube frame and we wanted to adjust the height. But narrowed it down to 60 based on this design.
Interesting concept for sure! I assume the diagonal element is fixed and can’t rotate? So it’s a carrier with a linear actuation moving on an slider/fixed angled elevator?
And any thoughts so far on powering the wrist? As far as I can tell from the sketch you’d only need 2 positions? Pneumatics for it could be interesting.
Or look look into having a rotation joint that is done passively at the bottom of the elevator stage which would be very slick, this was talked about in 2 of the Opa Foss posts…
1538 2011 and 1625 2011 IRI redesign!
We talked about these options as well. Where we wouldn’t do the belt/cable system, but rather with a sprung joint (gas springs, surgical tubing, etc) and a wedge/cam follower design.
Here you can see 1538 robot in action with its passive wrist motion: The Holy Cows 2011 - Daisy Maize - YouTube
There are some nice thoughts, so thanks for that. I hadn’t seen the holy cow wrist, but I do like the gas spring idea, although it definitely is a little more tricky if I have a slider also.
The elevator/slider combo is fixed and the wrist rotates up, and my thoughts would be more towards passive, possibly incorporating some spring action in the wrist joint itself so that it was rotated up when out and reacting against the lower slider section when fully slid back in to rotate it down.
It would be a cascade-style slider, I expect. And adding the structure at the end without interfering with the slider itself or pulleys for cascade, is the most tricky part. And as far as pneumatics/gas springs, the trouble is just not having a fixed arm to mount to with the slider and also keeping the wrist and upper part not too long, though a pretty short cylinder could work in a wrist action.
edit: Crudely something like this with a spring-loaded hinge.
You spin me right 'round, baby. Right 'round like a record, baby
Spindexer
As the team was working over the past week, we discussed many times how a robot from last year could play this year’s game scoring low and likely mid with a shooter for cubes. This discussion led to rewatching reveal videos from 2020-2022, which lead to the idea…
What if we could use a spindexer… for CONES? So the team set to work, and here are the results:
First concept
Fixed Latch
Flexible Latch
Next Steps
The next steps are to move our concepts into CAD and see if we can make it all fit together. This is an age old problem in FIRST robotics, it’s systems engineering time! For 4481 this challenge takes a whole new level. If you followed along with us last season you know that we try to follow a “unit build philosophy” that allows us to build modular subsystems that can be disassembled into check-on bag size sections so that we can fly with our robot and reassemble it when we arrive for competition.
This post was written by: @Justin_Foss
We were looking at doing a similar spinner mechanism. Have you done any tests with how cubes interact?
