I can also confirm that the sprocket drive does work. Successfully used in 2010 and 2011 by 2145, back when I was in High School.
8 Likes
Sunday 2/5 Update
We made lots of progress this week; our robot is alive in its initial testing state!
Here are some videos of it scoring and driving a bit with our v1 roller claw on. Cube go in cube go out!!!
Apologies for the terrible filming in the end, but trust me we did score a high cube there.
It seems like uprighting tipped cones using the arm is fairly trivial, and is definitely a viable way to do it with a bit of driver practice. Although we didn’t get this on video, stalling the intake at 0.25 speed against the cones held them in very solidly.
Also re-upping this video of just hooning around for fun. Swerve!
On the subject of general testing for fun, we found that we can self right using the arm!
Mechanical update and discussion
A frames
We had difficulties earlier with our turnbuckle A-frame design, so we switched to a static mount at the base and an adjustable tension setup at the top. This seems quite robust so far, and can easily lift the weight of the robot. These also added a lot of rigidity to the arm uprights overall.
Bumpers
We got bumpers on! This is always when it starts to feel like a real robot. Our mounting method uses 2.5” 10-32 bolts with a nut on the inside of the frame tube (maxtube is super helpful here, both with the captive nut slot and the spline holes for hardware access). Our bumper installation setup was quite neat this year: @leeofzebee designed a 3d printed jig to ensure our bumpers mounted at the very top of the legality box, and to keep them uniform all the way around. CAD for that bumper jig can be found here (designed for 4.5” tall bumpers).
End effectors
Our v1 roller claw worked quite well in testing. It’s fairly height sensitive for cubes, in that it’ll pick them up within a ±2” height range or so but they’re best held when it’s centered on the cubes. Cones were able to be lifted across a much wider height range. We’re planning to try this roller claw out with a nitrile weedwacker early this week to see how that performs.
Some impact testing was also done on the v1 claw. @wesley_li and I spent a while kicking it and it mostly just flexed out of the way. The TPU compliant wrist block (in orange) seems like it works quite well to allow the intake to deflect while keeping it rigid enough to function.
Our v2 roller claw features a pneumatic wrist and dead axle setup using 10-32 bolts, which should lead to a bit more functionality and even more robustness. This design also features 6” long nitrile weed whackers, which should agitate the cubes inward and help vector cones into the rear wheels. We also switched to a miniCIM driving the rollers here. The idea is a tradeoff in weight and a bit of controllability for a major simplification in wiring and more overall robustness.
We’re also contemplating stacking more compliant wheels at the rear for a firmer grip on cones, like this:
Our over the top (OTT) everybot-style end effector also made some progress! Like the roller claw, we had to switch from polyurethane infinity belts to timing belts and gears to transfer enough torque. After doing this it seemed to be fairly touch it own it on gamepeices. A v2 OTT intake is being designed now for Wednesday design review, which will incorporate the same wrist design as the v2 roller claw, allowing the two to be swapped out during testing with only 2 bolts (pivot and piston mount).
If testing shows the OTT to be better for driveability and robustness we’ll probably move forward with a v3 that uses dead axle rollers for some weight savings and serviceability benefits.
Counterbalance
We noticed that the counterbalance rope mount protrudes about ½” out of frame at the rear when the arm rotates away from a stowed position. This doesn’t seem to fall under the definition of momentary and inconsequential protrusion like I initially thought, so we’ll have to move the arm uprights ½” forward to avoid dual side frame protrusion penalties.
Bellypans and ballast plates
Our robot this year will be 45lbs without battery and bumpers. Yes, that’s not a typo. To give us a bit more pushing authority we decided to implement a ¼” steel bellypan, weighing 20lbs. Our manufacturing sponsor whom we love deeply, USA Dutch, has the capability to laser cut and bend ¼” steel plate, so our top bellypan will use flanges to mount to the interior of the drivebase rails. To avoid the need to spot drill for any components, We included cable management and component mounting holes for everything we’ll need.
On top of this (or really underneath), we have another 2 18lb ballast plates with clearance holes. These will be modular, allowing us to configure between 70lbs, 90lbs, and 110lbs as we practice to see what we like best. Lighter will be more nimble with faster direction changes, and should be easier on wheel treads, but heavier will allow for more pushing authority. We should be able to add or remove ballast plates between matches depending on our strategy for the next match, if that’s something we or our alliance partners desire.
Heavier configs will also balance the charge station better, but a lighter config will make it easier for alliance partners to balance with us already on the platform.
“Landing Gear”
Finally for comp bot, @wesley_li has been working on a pretty awesome mechanism. The idea here is a deployable omni wheel “landing gear” to allow us to overhang from the platform and still adjust position. These spend most of the match retracted into frame to allow us to traverse the cable protector and platform more easily, and then deploy downwards and over center for a locked in and level endgame overhang.
Having a level overhang buys an extra couple inches on the platform over a simpler “yeet style” overhang, or one with passive omnis 1” off the ground (which would be the necessary height to clear the cable protector and platform).
This robot is very simple and that’s awesome, but we wanted to find cool areas to innovate and add some non-critical complexity. This mechanism won’t make or break our event performances, but should make for a fun development process and a cool talking point in the pits.
Beastbot update:
The telescoping arm is coming together! We were able to jig the inner tube into the router and get a sprocket rack drilled, which seems to run suuuper smoothly.
The rest of the robot is also coming together, with the arm uprights and outer tube machined. We’ve had lots of fun drilling out clearance holes for maxspline. The widest bit we have is 1.125”, so we ran with that and followed up with a few minutes with a deburring knife to take off the remaining ¼” of diameter. Our arms were sore after this.
Software update
Control scheme and testing plan
This week we spent a lot of time with electrical debugging on the arm and drivebase, so we’ve only been able to get our integration tests with manual arm control code so far (where up and down correspond to trigger inputs). This week we plan to implement button bound setpoints, and next week we’ll integrate a state machine for arm control.
The basic idea here is that there are only ever 4 positions for the arm across 2 states. Here’s a graphic visualizing the control logic tree.
Vision updates
The current plan for vision is to integrate a snake eyes and raspi 3b for minimum viable product retro reflective-based cone node alignment, and then move to an odometry based apriltags solution after it’s been developed to a satisfactory level. Retro vision is useful to center, april tags centering doesn’t matter much, so we’ve got the following vision config at the moment. We’ll integrate the snake eyes this week and test that by the end of the week.
Electrical update
At the beginning of the week our drivebase was described as “electrically sad”. We had a number of problems, both with improper wiring and bad hardware, that needed lots of debugging. We might follow up with a more detailed post on that if folks would like more info about debugging sparkmax based swerve. We’ve been having issues with a number of our sparkmaxes, which could be attributed to lots of things. We’re staying vigilant and hopefully have filed away all of our bad units. We may spend some more time analyzing these issues after the integration grind has passed.
Conclusion and ramblings
The robot is coming together, which is very exciting! This week has been busy, but very fulfilling. It’s always fun to see a robot come to life.
Speaking of… deciding on a robot name is now a critical path task for us, because the final arm tube manufacturing relies on it. Our current top candidates are Hydra and Hermes, we’ve got some other ideas kicking around, though. The goal is to reach a consensus by wednesday, but if y’all have more suggestions before then that would be quite sick.
That’s all for now, goodnight!
-Lucien
7 Likes
I want that rack and pinion hole pattern with the sprocket to work so bad! Can’t wait to see this bot in person during our upcoming practice!
2 Likes
Videos or it didn’t happen!
2 Likes
Hopefully we will stream it for everyone on Feb 18th 
1 Like
Wednesday 2/8 Update
Hello everyone! We have arrived in our testing testing testing and iteration phase of the year. Here are some updates from our last two meetings:
Design:
Improved everybot style intake!
- Wristed, designed to be easy to swap into existing arm geometry
- Adjusted belt and pulley sizes to make less janky and avoid using zip tie tensioners
Landing Gear(Onshape)
- Allows us to overhang more to take up even less space on the charge station
- Allows us to have more controllability while overhanging to adjust balance or reposition
- Mounts to side frame rails
- Will incorporate a downward facing distance sensor on the bellypan to rumble the driver controller when we overhang the correct amount
Limelight
- We were able to secure a Limelight 3 thanks to @iicemannie, thanks for getting it shipped out so fast!
- Currently mounted to the top of the arm uprights, but we’ll probably move it down near the bottom of the robot and angled upwards to prevent target flipping.
- We’re going to add a sheet metal cage around it to prevent it from getting hit by other robots
Mechanical:
This was a pretty light week mechanically due to us shifting towards testing and tuning. However, we did get a couple major things integrated onto the robot:
Snakeyes vision module
- Mounts behind the arm uprights and is centered to make retro tape alignment as easy as possible
- Mounted vertically to keep chains outside the FOV and allow us to mount the module between chains
- Uses 2x1 maxtube construction and 3d printed parts to mount
Pneumatics
- We were able to get most of our pneumatic components on the robot, with the exception of the compressor and PH
- We were able to fit just about all of the components on the outside of the polycarb part that houses tanks
- Everything except high pressure gauge and pressure switch which mount directly to the compressor
- This may cause issues if there is a flow restriction going into the air tanks, but time will tell
- We’re going to add caps to retain the tanks horizontally and protect it from side impacts later this week based off @wgorgen’s suggestion
- Additionally, thanks @pchild for pointing out how thin the polycarb walls are in places. As designed they were already pretty thin, but when you add up the error of having improperly placed bends, a bigger than designed radius, and stretching of the material due to bending we ended up with super thin walls. We’re going to solve this by having the printed cap go all the way around the edge so that the printed part takes the load instead of the polycarb.
- (also, the pressure regulator is currently mounted backwards, we’ll fix that before we test it for the first time)
- Everything except high pressure gauge and pressure switch which mount directly to the compressor
Electrical:
I’m going to do a writeup soon of our inverted PDH bellypan design because we really like how much space and flexibility it gives us. We had a pretty quiet week on electrical too, with the exception of the Beastbots robot. Our team is generally unfamiliar with CTRE devices due to us using primarily Spark Maxes in recent years. We don’t have enough Spark Maxes for two full robots, so we had to dig up our old brushed motor controllers. This also necessitated using CAN and Phoenix Tuner which turned out to be a massive headache for some reason. We were finally able to give all of our devices CAN ID’s but were unable to update firmware and kept getting catastrophic errors. We think this is because of an outdated Phoenix Tuner version or wiring quality.
Software:
Our programming team was mostly busy with writing arm code using PID and starting to build the state machine that we’ll eventually use to simplify controls. We forgot to take videos of the testing we did on Tuesday, but I’ll do my best to explain it.
The arm went to the correct setpoint the first time after we enable, but after that it seemingly did whatever it wanted to do. We think this is an issue with the state machine and will do some testing bypassing the state machine to debug.
Auto Balance:
We weren’t able to test our auto balance code on the charge station we built with 4829 because it isn’t properly weighed down yet. We tilted the robot by hand and it moved the wheels in the right direction. We’ll hopefully be testing this on a charge station on Saturday.
We didn’t have a finalized plan for vision until very recently. For the near future, we will be running two vision systems; photonvision for retroreflective tape/cones and a limelight for apriltags/cubes. We found through testing that CV wasn’t really necessary for cubes but was crucial for cones, especially when the node isn’t right in front of the driver. This is the quickest and easiest path we have towards having alignment for cones, and provides us with a pathway to doing everything solely off pose and apriltags.
We were able to test our photonvision/retro tape module off robot on a cone node and were able to get reasonable tracking and yaw values. We installed it on the robot and we were able to connect to it and control LEDs. We’ll be testing auto align code later this week.
We’re running Maxswerve and the issues with wheel delamination meant that we needed to implement slew rate limiters into our code to lower sideloading on wheels. In addition to this, we noticed that the robot thought that the left side of the robot was the front. Rev’s example code has a chassis offset, but changing this value to anything that isn’t zero caused the robot to not drive and wheels to fight eachother. We fixed this issue by subtracting 90 degrees from gyro yaw values
Edit: forgot a gif
Me when we try to score a cone with vision
9 Likes
Yeah… some of those are really really thin so this is a good idea. You’re definitely going to want a bit more heft to hold those in place. Looking good though.
1 Like
With those plates organized like that you could opt to create a flange and rivet or use Tab and Slot T-nut techniques like other teams have shown in the past.
1 Like
Sunday 2/12 Update (except it’s Tuesday)
Apologizes for missing the Sunday Update, but it wouldn’t be a real Sunday update if it were actually on Sunday, right? Some big picture items this week:
-
One less than a week away from our scrimmage with 3506 Yeti and other NC teams! We’re working hard to get our robot to a good state for that.
-
Robot code is progressing and we’re getting some practice and tuning in.
-
We settled on a name! Our 2023 robot is officially…
HYDRA (whooo)
Mechanical
V2 claw+wrist
Claw and wrist were assembled and put on the robot. They should be more sturdy than the last one and will hopefully not fall apart. We tested it off-arm with a drill and it seems like an improvement compared to the V1, especially the flappers.
Weirdly enough we had trouble putting black oxide coated 10-32 screws into 3/16” bore radial bearings. But we had no issues with ones that weren’t coated! We had to sand off the coating for them to fit. This will cause rust long term but that’s well outside lifecycle for these. That was a neat little thing to note for the future, though, and a fairly easy fix.
Everybot intake
Since our V2 roller claw was still under construction and we had to take the V1 roller claw apart for some parts, we put the V1.5 Everybot style intake on the arm for testing (just mounted with two brackets). We noticed that our driver had a little more leeway in lining up with it horizontally since the intake is wider but it was harder to line up vertically or rotationally.
Pneumatics
All pneumatics components are mounted now. We added the end caps for tanks as well, but no plumbing to our wrist cylinder yet though.
New Arm Tube
We machined- and mounted! Our new arm tube with cool LEDs inside. The Eastbots lettering turned out very smooth (currently it’s kind of obscured by the pneumatics mount but we’re getting a new bent sheet metal part that doesn’t do that). While we were at it we replaced some low profile hex bolts that stripped incredibly easily because they would probably be a pain to take off later on.
We had a little bit of trouble putting the RGB strip in the tube and keeping it centered and flat. The adhesive backing kept causing it to cling to random sides at odd angles. Any advice for how to do that better in the future from teams running rgb in tubes?
Design
Sponsor panel
We are making a polycarb cover on the back of the robot to protect the electronics and put sponsor stickers on. We will need to take it off very often so it has to be really easy to take off. It has TPU hinges on the top, mounted to the A-frames, so the whole sponsor panel can flip up. On the bottom, there are two 3d printed parts that clamp around the neos on the swerve modules.
We’re planning to print sponsor stickers on Amazon sticker paper using a standard household printer, and then cut them out by hand. We imported an image of the flat pattern of the sponsor panel and just laid all the logos out in google slides. We then pasted these into a google doc to print so that they stay true to size.
Ratioed virtual four bar concept!
Since the everybot reveal this year, our team has been working on a similar intake design. We realized that a virtual four bar like the REV starter bot this year might be a good idea for making the intake stay at an ideal angle for each arm position.
But the problem is, we have only one arm tube in the center of the robot, so when the arm goes to the stowing position, there will be a point where the intake goes past the arm.
For REV starter bot it is not a problem because it has two arm tubes and the intake can go between the tubes. But for us, the intake will interfere with the arm.
(Onshape is getting really laggy since kickoff lol)
Our solution to this problem is making the two sprockets on the virtual four bar different size, so that the intake gradually changes angle throughout the travel of the arm to prevent the intake from going past the arm.
After doing some calculation, we found that a reduction of 1.055:1 will be an ideal reduction ratio.
Unexpected surprise! Because the everybot intake is so big, and the cone rollers happen to be at the tip of the intake, we can actually reach the high peg! Going for high cones is not a part of our strategy, but if we can do it without adding extra complexity, it seems like something we can give a try.
We are working on a full cad for this concept and looking to build it after our scrimmage with Yeti! We’re planning to build 2-3 more arms off-robot for groups to develop and experiment with. This should make the tail end of the season a little more engaging, and it’s always good to give folks opportunities to be creative and innovate.
Steel bellypan
We have sent the steel belly pan design to our sponsor USA Dutch. Big shoutout to them for making these massive parts for us on such a short turnaround (3 days)! Since it is steel, we will spray paint the whole bellypan so that it does not rust.
Electrical
We’ve been thinking about the best wiring setup to be able to switch out between intakes quickly during yeti testing.
On the pneumatics front - the pneumatics hub was wired and hooked up to the compressor and we’re using an analog pressure sensor, wired up the solenoid also to the pneumatics hub. Sparkmax on arm was moved to the drivebase and hooked up over CAN as opposed to PWM.
Our electrical members were annoyed with feeding wires through the 2x1 because connectors kept getting snagged on random bolts.
RGBs - we essentially moved our motor testboard setup over to the robot and put inside the arm tube to look cool- we haven’t hooked them up to the robot electronics yet.
Testboard setup
We finally got around to putting connectors on all our new batteries this week (and naming them).
We also got one of these retroreflective sensors that plug directly into the rio and we’ll be testing those this/next week to get game piece detection without having to rely on current sensing.
Tomorrow there will be a more detailed post about testing and software but here’s a little clip of a successful auto balancing attempt. We’re using cubic feedback control with top end limiting to get a fast climb time while keeping fine adjustments.
BEASTBOTS UPDATE!
Our junior team: the beastbots, has made outstanding progress on completing their robot ahead of this week’s scrimmage.
The rotary arm
Because of REV shipping delays, the Beastbots team was forced into the incredibly educational experience of janking together a rotary arm from supplies on hand. This turned out amazingly well, and gave a lovely little live axle maxspline setup. The maxspline ends were bored out to 1.125” and ½” hex shaft passes through the whole thing to allow for rotation. The ½” hex is mounted on versablocks at the ends to allow for cam chain tensioning, it all came together rather nicely.
A counterbalance similar to the comp robot’s is also in the works to avoid a need for feedforward control on the arm.
The telescope
The part I know y’all are waiting for… the rack and sprocket telescope is done and on robot! It came together quite nicely, and seems to run great without binding.
More work is definitely needed before software testing or even full electrical completion, but the team is psyched!
Closing notes and musings
As always feel free to leave any comments, and again our software post should be up tomorrow and our upcoming Sunday post should have many useful findings from the scrimmage Thank’s to @Skiddy4795 and @Wesley_Li for helping write the update
Here’s a little poem:
- Snacks are plenty and vibes are swell
our new claw grips things quite well
RGBs make me feel good
please don’t make bumpers out of balsawood
also, funny feature of the everybot intake:
- Andrea
8 Likes
Saturday Morning 2/18 Pre Yeti Mini Update
I’m typing this from the seat of a schoolbus. Today we’re headed to 3506 Yeti’s space for a day long scrimmage. The robot looks like this:
This is the most engineering effort we’ve ever put into a sponsor panel lol. The whole thing rotates upwards on living hinges for bellypan access.
There’s a lot of talk in openalliance right now about spray painting setups, so I’ll share ours.
You should be able to just use any brick wall.
We got the bellypans mounted, it went much smoother than anticipated!
The whole robot is developing this menacing look which I have so say I’m a fan of.
We had a few problems yesterday with belt alignment on the v2 roller claw. The polycarb sheet flexed and caused the belts to ride off the pulleys. Some standoffs fixed this issue for now.
We weren’t able to get the landing gear on the robot for this scrimmage, so we’re pushing that to a bit later this week to test.
In terms of controls we worked yesterday to tune our state machine, so that the arm, intake, and wrist move to the correct states at each set point. I showed a logic tree diagram a few posts ago which describes this in more detail.
We’ll also be integrating swerve heading lock and testing align to goal with retro tape and 2d april tags for today. Finally, we’ll be testing auto event integration for charge station engaging and scoring. Hopefully we can get a basic auto routine tested by the end of the day.
Beastbots update!
It’s like… a whole robot now. Members riveted the bumpers on so we had to fnaegle it through doors but manual control works on the telescope and arm. Setpoint control is being written at the moment between smash bros games.
There have been a few spooky drivetrain electrical issues, so we’ll see how debugging goes on those today. Hopefully we can get driving and score a few times by the end!
We’ll be back with an update after the scrimmage in the next few days. See y’all later!
-Lucien
2 Likes
Which sensor are you using on the intake? Any advice? Thank you.
You’re robot looks great.
1 Like
We’re using this sensor, but haven’t really gotten it properly tuned. We’ll update when we’re able to properly test and tune it.
2 Likes
After practice today the sensor seems to work pretty well. Was about equivalent to the more expensive photoelectric sensors we’ve used and it outputs digital straight to roborio without needing an adapter board.
We’ll definitely update this thread regarding how it works out through the season.
1 Like
Thank you. Curious if you have any trouble with ambient light?
Here’s a recap video for our week 6 testing day. Both robots ran great, and the team is stoked!
Thanks to 3506 Yeti for hosting this awesome scrimmage.
6 Likes
We’re overdue for an update, I know. We had a big testing day today, and are planning to come out swinging this week with a:
- Software and automation post
- Robot reveal video (not that the robot is a big secret, but it should be pretty fun)
for now, here are some pictures of stuff that’s been happening!
As always, send questions if you have em!
-Lucien
7 Likes
Sorry for the continued lack of updates y’all, we’ve been fairly busy. Like with last time, here are some robot pictures to tide you over, this time of the robot all illuminated-like!
Also- here’s what we scored today in a practice match with auto and climb (we did everything except the top left link):
By my count that’s 12 gamepeices (counting duplicates in the low node there).
Stoked for Asheville this weekend.
-Lucien
7 Likes
Here’s a post detailing the fixes we implemented to prevent wheel delamination on our swerve modules
5 Likes
Software Update:
Hello Everyone!
For our robot, we implemented a state machine that manages the state of every mechanism on the robot.
This also simplifies codriving a lot by using the same buttons for intake and outtake positions. More on this in the controls section.
- Arm setpoints
- Wrist setpoints
- LED patterns
- Vision pipeline selection
- Intake/outtake speed
Here, we can see multiple setpoints being switched on the robot. They control arm position, wrist extension, and outtake speed.
For the wrist, it’s important that it is not extended while too close to the ground where it could be damaged. Therefore, instead of changing the wrist state manually, we set the target state instead. Then, inside its default command, it can extend if the arm’s position is inside certain bounds. This lets it automatically retract once it reaches a certain position, and extend once its back outside of it.
For the arm, our method of control is using setpoints. Whenever we press a setpoint button it will set the setpoint variable inside the arm subsystem, and the arm will move to that position. If manual control is used, we increment the setpoint and set the position again. Soft limits are also implemented by clamping the setpoint values.
We are also using a “smoother” for the gamepiece presence sensor, which allows it to only switch state after it has been a full high/low signal for half a second. This helps us wait until the game piece is fully intaked to slow the motors, but also stops it from letting any random flickers from changing anything.
For the exact code, it is located here
State Machine Controls Diagram
Vision Alignment
We’re using PhotonVision with a PWFusion Snakeyes this season. When we press the vision align button it automatically turns the robot to face the goal using the gyro, regardless of whether there is a visible target or not. If there is not a target, the robot takes over control of the angle of the drivebase but feeds in joystick inputs for translation. If there is a target, it takes control of the angle and horizontal speed to align to the goal. It always feeds in the forward/backward joystick value.
Autonomous
We got our baseline auto of scoring a high cube, picking up another cube midfield and balancing working pretty well! We occasionally miss picking up the cube but the auto balance seems to be very reliable.
Controls
Generally we prefer to have driving and outtaking on the driver and everything else on the operator. Here is our controls layout for this season.
Driver:
Codriver:
Overall, we’re feeling pretty good about our robot and are super excited for Asheville! It’ll be a really fun event with a ton of great teams.
8 Likes
Thursday 3/2 Pre-Comp Update and Robot Reveal!
We’ve been hard at work this week putting the robot through its paces and making iterations before our week 1 event at UNC Asheville this weekend.
We began the week with a testing and practice session along with our good friends from Orange high: team 587. We spent a lot of the time testing and tuning autonomous. We figure the minimum viable product for Asheville to be a 1+grab+climb, which we were able to get tuned by the end of yesterday. We verified that this works in the mirrored configuration as well.
Our odometry struggles to maintain accuracy with rapid translation while rotating; there seems to be some second order kinematics related skew that we’ll have to figure out if we want to really optimize our auto routines. This is our first year using a holonomic drive and path planner so we’re currently on the up-slope of the learning curve.
Anyone have tips on improving path planner auto accuracy at speed?
After getting our MVP auto sorted we moved into driver practice. We first tested cycling on the field alone. We scored 12 gamepeices here and managed a level charge station. We didn’t preload here, so 13 would have been possible with that change.
Next we practiced cycling against defense. Hedgehogs probably played better defense on us than we’ll see all season, but we were able to put some points on the board at roughly ¾ the rate of our normal scoring.
We ended the day with end effector problems. During a huge impact with defense, the flexibility of the polycarb on the roller claw allowed the rollers to shift vertically relative to one another, forming a parallelogram. Combined with roller rotation, this kicked the belt off the inboard pulley and jammed it beneath, stalling the intake. This hit also bent the polycarb plate at a long unsupported bit near the wrist.
The intake spun again after we manually re-seated the belt, but a competition robot mechanism should be robust without intervention. After a lot of discussion, we opted to machine some aluminum scab plates that replace the spacers on the dead axle rollers. These seem to work really well in preventing that vertical skew between the rollers, especially in combination with standoffs. We typically don’t like to make big iterations this soon before a comp, but this should solve the issue and doesn’t represent a huge commitment; we can easily revert to the non-scabbed design.
A hefty corner bonk also did this.
With that testing done, we packed up and loaded out! We’re running a service at events this year to donate spare parts to teams to help them pass inspection and get playing. We dubbed this “AssistBots”, and will be running this service at UNC Asheville. Prep for this involved building the “AssistCart’’ and assembly line-ing some corner bumpers to donate to teams missing them. We’ll be working with event staff to bring this service to teams in the most helpful way possible.
And finally…. Our 2023 Robot Reveal!!!
Let us know what you think. Despite our 10-year history, this is our first time doing a proper reveal video. We’re super excited to take HYDRA to its first competition.
I’ll leave y’all to watch.
-Lucien
8 Likes