I think Zeus could be a great name but honestly… is anyone else a little let down by the theming of this game? I feel like they missed a big opportunity for a cool electricity theme.
2 Likes
I agree that the theming could be a better. I understand they are sending a good message by talking sustainability and helping communities but it could be more exciting. Right now I am imagining charging tesla coils. That being said I do like some of the theming elements, sustainability is important after all.
Excited to see pictures/videos of this in action!
1 Like
pics of this should be coming in the next wednesday update!
1 Like
Week 3 Recap - Sunday 1/29 Update
Sorry that this update is lacking in photos, most of our usual updaters were getting K.O.ed by Covid.
Mechanical
This week marks the beginning of our first swerve module surgery. A wobbly baby neo was stopping our software team from steering and we had to partially disassemble the module, retightening and putting loctite on all the appropriate bolts. After this we planned to check all of the modules before integration testing, reading over assembly instructions very carefully.
We routed our polycarb bellypan, the material selected for being the most forgiving towards spot drilling around electronics.
We did a few tests with our v1 roller claw end effector to validate it, and the geometry seems to work pretty well. Having pinch rollers for the cones in the back seems to work for a variety of heights, although the entraption stars don’t do much at the rear.
Our next roller claw iteration has weedwhacker style flappers at the front to draw in cubes and center cones.
We’re building our everybot style “over the top” end effector in parallel, but haven’t tested that at all yet.
We’ll be testing lots of end effectors in the next two weeks to optimize for driveability and durability, and we’ll keep detailing our findings in this thread.
Handoff intake prototype completed today, turned out to be kind of dogwater. Bearings slipping out all over the place, chain tensioned incorrectly. We will probably not revisit this design since we have several other viable prototypes.
Our prototyping process for a pneumatically actuated roller claw went… unexpectedly.
We’re glad to have been saved the disassembly work, and we’ll incorporate ideas from this prototype into another end effector.
Second set of bumpers was completed, we began fashioning a CNC enclosure, and we assembled a few new worktables.
Swerve modules were mostly repaired, but we forgot to check the two button head bolts attached directly to the baby neos. I also forgot to install 3d printed dust covers on the modules when transferring them to the competition robot. Will remedy all of this on Monday before testing.
Competition drivebase half assembled
Speaking of comp robot, our arm is now mechanically complete. We had an issue with using too-long bolts on our maxspline bearing block stackup, which pushed on the shaft collars and kept the blocks from clamping. We fixed this by grinding our bolts down to length, though.
Ethan going to town on the shoulder
We were able to get some testing done running a single motor, and this thing rips!
The claw end effector is also complete and mounted on the arm.
A beautiful assembly with our v1 roller claw
We’ve also collected materials to start building a feeder station.
Electrical
Layout for electronics is finalized, as well as slot arrangements for PDH. Some components were mounted and Giannis was mutilated again, this time getting her main breaker and network switch ripped off.
Very sophisticated electronics map that Lee handed me
Design
Apparently design iterated end effector CAD, I’ve seen one of Lucien’s new designs, there will probably be an update specifically for that soon. I can’t steal his thunder of course.
Software
Finished the end effector code, ready to test. Also started integrating photonvision into the code (so the robot is able to “follow” the apriltags- meaning that it goes to them when it detects them).
-natasha
Auto balance code is written and should work, works logically, reality will be revealed in time.
Giannis’s Rio is in jail for not working on the Triple Helix Drivebase. Still not working as far as I know. We have a couple that have learned from the offender, and are working perfectly fine.
Conclusion and ramblings
Sorry again for the bad photo turnout :,))) Reading the thread I can see that people were looking forward to them. Counterbalance was not finished either. We had a few setbacks this week from both human error and… circumstances. We are a little bit behind but I think a lot of non-seniors got great experience the past few meetings.
Minor setbacks aside, we are still cranking out end effectors, designs are still being developed for Beastbots and Eastbots, and programming is only just starting to get interesting. This week will be eventful for every subteam as our competition robot really comes to life. Beastbots will start assembly, unnamed comp bot will undergo integration testing, and everyone will be cooking with gas.
-Evelyn
P.S.
I was totally unprepared to write this post, I trusted the seniors to not fall ill…
P.P.S.
“Zeus” is so pedestrian! Hydra and Chimera… Bronte and Astrape…
5 Likes
Mini Update - Counterbalance!
A real update is coming Wednesday, but we got the arm counterbalance on today so I wanted to share some pics and videos of that working!
The drum springs go on this big roller and bolt to an aluminum plate. Dyneema rope ties into this plate and runs up to the shoulder, where it ties onto a protruding hole at a specific radius. This allows the spring torque component to always equal the gravitational torque component, cause they’re always proportional to the same sine function.
This balancing allows the arm to be moved around very gently by hand, even with just one finger. Motors are connected to the driving shaft here so there’s some resistance, but moving the arm up and down seems equally difficult. There’s a point at the top of the rotation where it seems to want to stay, and it springs back a little at the very bottom in the front. The latter is likely because the rope hits the shoulder itself instead of the tie down point, and the radius (and balancing torque) momentarily increases.
And @wesley_li discovered the neatest thing. If you tilt the robot the arm will passively maintain its angle.
13 Likes
Do you have a link to the cad for this gripper? We have a similar style but ours wants to bounce the cubes and cones out.
1 Like
Thanks. Looking at the CAD it appears that your outer center distance is 11.5 inches. We had ours at 11 originally. Is the compression at your distance good? Have you tried it while driving around to see if it holds? We don’t have any of the star wheels, so we are just using 4" compliant.
1 Like
We found that the current compression works pretty well, but we haven’t driven around with it yet. We should have videos of testing full cycles this Saturday or early next week. We might end up changing the compression a bit in future iterations based off testing of this intake.
1 Like
We’re also using fairly stiff compliant wheels at the moment, so compression values may be different for Andymark green wheels or similar.
We’ll probably have a post next Wednesday detailing all of our end effector models and what we’ve learned from testing.
Looking super cool. Could you explain a little more how you determined where the mounting points for counterbalancing spring/rope should go?
1 Like
So the springs themselves just need to go roughly underneath the arm pivot: the ropes need to be as close to vertical as possible for the torque components always to be equal. More simply: gravity pulls straight down as well, so the rope should be close to vertical.
From there I just put the spool as low as possible in the robot. The springs are fairly heavy so having that mass low is ideal.
In terms of the mounting point on the shoulder for the rope: the force there times the distance from the pivot has to equal the product of the arm’s weight and the distance of its center of mass from the pivot. This works out to be true for all arm angles as sine components cancel.
(F arm com * R arm com)/(F spring) = R
I determined the com from a quick analysis in cad and then worked with force as a driving constraint to find the lever length needed at the rear below a certain threshold (above ~2.75” does not fit in starting frame perimeter).
I just found the cheapest constant force springs from mcmaster that could reach that force threshold and would ship quickly, and then solved for R.
This isn’t very complex to do at all, and it works fairly well.
10 minutes of cad work and programming team no longer believes in the existence of gravity.
Thanks for that explanation, now it makes a lot more sense. Would the math work out the same way if gas shocks were used instead of constant force springs?
No, because gas shocks have a non constant force as they compress, similar to a coil spring. You could use an cam pulley with a quadratic radius, similar to this video, to achieve constant force from this setup if you wanted to, but because there are springs that already give a constant force there’s very little point to this other than cool factor.
You could use extension by a vacuum tube though and it would work, because that’s a constant force. That would actually be a pretty cool way to do it. Not sure if COTS vaccum springs in this form factor exist, though, and in general vaccums suck.
1 Like
here’s a video that better shows the springs moving up and down on the counterbalance, btw
7 Likes
Update (supposed to be on Wednesday)
https://youtube.com/shorts/oP6Nuu3WYJs?feature=share
Hey y’all! Sorry for the late update, but now you’ll get three whole meeting’s worth of content instead of two!
This week was all about integration, integration, integration. Our goal was to have a robot by week 4, and although we had some slight setbacks we are pretty on schedule! Here are a couple more details divided by subteam:
Design
Last week we designed the second iteration of our non-clamping roller claw based on some preliminary feedback from the V1 we already built on the robot. Here are some updates to the design:
- 3D printed helical gears instead of the infinity belt design in the middle
- Deeper groove for the cones to sit in at the back
- Weedwacker-style additions on the front two wheels (nitrile tread) instead of entrapment stars- we felt they weren’t necessary in the back so those are just wheels
- Mini CIM instead of a neo, with additional support for the motor (still debating this choice)
We also decided to add an extra degree of freedom to our arm since we didn’t think that we would be able to get game pieces from the feeder station with a rigid end effector. The second iteration of our end effector is connected to two parallel C-shaped metal plates with zip ties to allow for some flexing if we get hit (we’ll see how often they will snap). The wrist motion is enabled through a somewhat overkill pneumatic cylinder mounted on top of the arm tube.
We had a design review for these components yesterday and might add another hard stop at the bottom of the clamp so the cylinder hits something when it’s fully extended, and redesign the plates where the cylinder is mounted to the arm.
Our second robot team had a design review for their telescoping arm and here’s the design that they’re currently going with, though there might be a couple more minor changes coming, like moving the encoder gear outside of the shaft collar in pic 2:
We are also in the process of redesigning our clamping roller intake (the one which met its tragic end and snapped violently and gloriously. Mostly our goal is to make it not snap this time. We’ll have pictures by the end of the week.
Other design projects we started this week are a new transparent fancy driver station and a new robot cart. We’re thinking of something that can be folded up, easy to transport and somewhere we can easily access the robot. And of course it has to look snazzy as well.
Finally, we also thought about the placement of various sensors and pneumatics components and designed mounts for those (not final). For example, you might’ve noticed our banner proximity sensor in the V2 of the roller intake. Here’s also where most of our pneumatics components will live (we’re bending polycarbonate, hopefully it turns out nice!)
Bonus We designed a 3D printable jig so we know at what height to mount our bumpers.
Mechanical
We had to take apart our swerve modules this week to fix some issues (not loctited bolts). We were going to put on our new dust covers on but we discovered that they did indeed interfere with some encoder components so we left them off for now. Once they were fixed they were integrated on our main drivebase, however we found that we had some tolerance issues with our router so our bellypan interfered and they were quite finicky to put on and align)
We got the battery box from our sponsor USA Dutch this week and mounted it, they turned out very nice
We’re thinking about getting them to do a cool steel belly pan for us for more weight since our robot is quite light.
Our Everybot style intake was struggling a bit this week because we kept having to change the way our power transmission worked, we had some trouble with getting the right belts and had to add gears later on too, but it should be done in the next couple of meetings. Here’s one test with a drill that did go pretty well though:
We plan to test this on our arm as well.
Our bumpers are wrapped, all that’s left are the brackets.
Lucien already mentioned the counterbalance in the quick update, but that was a big win for us this week. Although I will say, getting those constant force springs around the lip of the spool was quite the pain (as you might imagine they are very hard to unravel… some cuts were sustained).
We discovered a couple issues with our a-frame mounting- the threaded inserts we originally epoxied into our 3D printed carbon fiber rod end caps kept falling out- we tried putting a different one in and melting the PLA with a soldering iron so we could attach it that was without epoxy, but they fell out again so we changed the design a little bit.
Our second robot team made progress this week on machining their telescoping arm.
However, we had a little bit of trouble machining the hole pattern in the 1.5x1.5 tubing where the sprockets are supposed to connect. The holes have to be pretty evenly spaced, and at first we designed a printed jig to see if we could drill it by hand, but then we saw that we had to do it on the CNC router. We designed a 3d printed clamp to hold the tube since we didn’t have a jog for 1.5x1.5 and had some accidents with the router… but we should be getting there! We don’t do tubing very often on the router so it was a little bit of a challenge.
Electrical
Electrical was busy this week, starting with wire management of swerve modules.
Here’s a pic of our bellypan (v proud- srinivas will post a more detailed description of it at some point.) All of the main electrical components came together quickly thanks to initial integration into the bellypan CAD and having updated firmware from the get-go. We do need shorter Ethernet cables though. We thought about making our own but our mentor shut that down pretty quickly.
The triple helix/b bot drivebase was finally able to drive today- hallelujah. It took a lot of manpower to get that going after much struggle with Phoenix Tuner and Rio imaging.
We accidentally connected the motor controller wires to the wrong motors when we thought that we were finally ready to drive. And the wrong encoder wires. We should have tested the modules off the robot more thoroughly (no wonder we couldn’t drive for most of the meeting today). We’ll have to be more careful next time. But good news, once we fixed that and the sparkmaxes were zeroed correctly, we were able to get our robot driving smoothly today (although our joystick doesn’t quite know which way is the front of the robot yet)!
Next up: wiring the end effector- yay for extension cables - and testing our mechanisms!
Software
We made a simple control scheme for testing the arm- 8 states with a button to progress through each and an additional one to return to stowed position. We also started some logic trees for the arm and end effector.
End effector code for the comp bot is readyish for testing!
We’re currently also researching some options for driver cams (two main contenders so far!), we’ll let you know what we settle on. We also had some members looking into LED code for that signature RGB gamer setup.
Our snakeeyes has power and green lights now (!!!) But, we had a lot of connectivity issues this week with the vision module, so we couldn’t test much unfortunately (but preliminary tuning was done today). Not a lot of April Tag progress, although code is under way.
We started looking into taking advantage of AdvatageScope for logging (and thus more effective troubleshooting and match analysis down the line), but ran into issues because romis were being annoying.
We had some issues with the arm motors-for one of the motors, we were able to tune PID, but the other one just wasn’t taking any commands. We thought there might be some issue with the encoder on that side.
Our goal for Saturday is to be able to score game pieces hopefully!
P.S- still have not decided a name. Biggest disagreement of the season.
- Andrea
https://tenor.com/bSZOz.gif
7 Likes
I’m not sure I can see exactly where on the robot that is located. Is that the front side of your base structure of the arm?
If so, it does look like those tanks are going to be reasonably protected from impacts from other robots. I might be a little concerned about something getting in between the uprights of the arm base. If you replaced the 1x1 on the back side of that structure with a polycarb shear plate that covered that gap between a level below the tanks to a level above those tanks, that would be form a nics shield and provide lots of good rigidity for the base structure for parallelogram loads. If that polycarb sheet extended out past the two sides of the structure and then was bent around the sides, I think your tanks would be fully protected from impacts.
After the big pop at IRI last year, we decided that plastic tanks would always be protected with some sort of shield (either located within the bumper zone where they would be shielded by the bumpers or protected by a polycab shield). Since you are bending polycarb for the support structure, it would be relatively easy to incorporate additional shielding for any parts of those tanks that are more exposed than you want them to be. It would also be relatively easy to bend a secondary enclosure that wraps around that whole system.
2 Likes
Yes, they’re mounted at the base of our rotary arm uprights. They’re protected from the front and back by the uprights and polycarb plate, respectively. We also have dyneema rope for our counterbalance near the rear so it would take a lot of bad luck for something to hit our tank from a frontal impact. They’re somewhat protected from impacts from the side by our A frames, but it does leave a bit to be desired. Now that I’m thinking about it, we might add 3d printed or polycarb hats that go over the ends of tanks to make them more protected.
5 Likes
Are you using a sprocket and holes in the profile like a rack and pinion to drive the arm? That’s certainly an interesting idea, I’d be interested to hear how well it works. If that doesn’t work out, I’ve seen teams pin a length of chain along a profile to make a rack that works with a sprocket, might be worth trying.
7 Likes