4795 Eastbots - 2023 Build Thread

[Skiddy4795]

Week 1 - Wednesday 1/11 Update

We started off running this week, and have found some interesting things.

Mechanical

Mechanical so far has tested 2363’s old 2019 intake (thanks triple helix/@Nate_Laverdure, we love your old stuff!) using our new pneumatics test board (try saying that 3 times fast). We found this actually worked really well, at least for gripping both gamepeices.

https://drive.google.com/file/d/1tiPQYg8aaD94ZHV1uvKNCbFtbEsXG-pP/view?usp=sharing

We’re on the way to a full test with active wheeled intaking.

Mechanical also worked on building some of design team’s prototypes, namely the OTT intake (see later in post) and the compression tester. We got the latter working but it literally exploded on first use (@siyeng can vouch lol).

Design

Our design team conceptualized end effector designs and split off separately to begin design considerations for a universal arm platform we can build immediately. We planned out some end effector designs for fabrication into testable prototype mechanisms, and we also designed a more dedicated compression/wheel testing prototype that we could iterate very quickly.

We conceptualized a few end effectors, namely 3 variants of a pneumatic gripper (wheeled and passive) and an intake that grabs cones from above (Over the Top: OTT) and vectors using mecanum wheels. We also designed an intake using HYPE Blocks and 1x1 dowel wood for more rapid testing of wheel compressions.

We also began designing a 1DOF rotary arm. The aim here is for very fast iteration and development, where we can design and build this by the end of next week and integrate end effectors later. Here are a few concepting and design planning sketches made during meetings (used an arc constraint to inform arm and upright lengths):

And here is the v1 design, using a MaxSpline dead axle configuration. We came up with a more clever way to use MaxSpline bearing blocks to constrain the shaft without needing tube passthrough, and several other review points (design review notes in this doc). Those are listed in a doc here. We hope to have a v2 design to review or verify for production on Saturday.

This mechanism should serve as a modular platform moving forward (enabling our aggressive week 4 completion schedule), potentially for both of our robots. Because this mechanism scores and intakes outside of frame perimeter, rapid stowing and deployment will be critical, and the robot will return to a “safe home” position each cycle. Thus, the arm needs to be super light and very fast moving, ideally a motion cycle (280deg) in <0.5sec. We did some ReCalc math and it seems possible to get it that fast without browning out or turning our battery into a black hole. We shall see.

We played around in CAD with configs of this using the Triple Helix intake, and found a few things: notably that:

1. Cube shooting with a 1DOF arm seems hella doable, and potentially faster than scoring top cubes by extending.
   
2. Intaking from ground is a pretty favorable angle (45deg, for optimal cone drive forward scoring angle), and… potentially allows for picking up of tipped cones from the rear (using some sort of end stop that rotates the cone into the desired angle?
   

CAD (this will likely become our robot CAD) can be found here. The arm and uprights are configurable in length for maximum playing around with different configs potential.

Design team also came up with this interesting handoff intake concept for a full width dual gamepeice intake. Here’s a video showing how it works. We might prototype this if it jives with our timeline and concept.

https://drive.google.com/file/d/1SRK741lfUujQFS2ik4BCiE9Q80x1q3DA/view?usp=share_link

Software

Additionally, our software team began writing auto-balancing platform code, as well as researching motion profiling schemes for rapid rotary arm control. We also began researching coprocessors for AprilTags.

We were able to get a running test with AprilTags tonight, here’s a video:

https://drive.google.com/file/d/1ZYPO01W-Sxtp9P2tvUqW-pnm_BieskpS/view?usp=sharing

Let’s talk about our drivebases. We’re currently working on the following chassis:

1. 2363 Drivebase as vision based path following testbed
   • 2363 cone intake is being integrated onto this for testing
2. Swerve drivebase using Rev MaxSwerve
   • For programming to develop teleop drive code while mechanical works on the…
3. Dummy drivebase using casters as stand-ins for MaxSwerve
   • Allows for the robot to be built and semi-tested and modules to be integrated later, maybe week 3 (since we’re expecting modules to arrive by Saturday).
4. Our old robot: Giannis
   • For data logging testing atm
5. The Beastbot
   • West coast drive chassis based on our pre-season posted design, for our new members, with some returning member leadership roles, to develop a robot on.

Electrical

…is working on wiring all these freaking drivebases.

Wrap-up

We’re also collaborating with 4829 Titanium Tigers on a field build, progress is good! A few of our members go over there each meeting day. Pics will be posted in the Sunday update.

That all said, happy week 1!!

-Lucien

[Twinbrotherofjosha]

Wow that’s some amazing progress, keep it up! Would you mind sharing the CAD of the ‘handoff intake concept’? It’s a very interesting concept and we would love to take a more detailed look.

[Skiddy4795]

Yeah totally, here you go!

And the gripper used in the concept is a lightweight pneumatic-only gripper with a shooter piston.

[andreab]

Week 2 - Sunday 1/15 Update

Howdy y’all, it’s the Eastbots again with another video (err, chief post). Here’s some end of week 1 updates:

Design

We held another design review for our rotary arm. We made a couple key changes after our first review, including:

• Switching to 3D printed pulleys instead of rev’s (doing printed polycarb for the first time!)
• Making our encoder gears smaller (and also 3D printed)
• Adding an A-frame like support from carbon fiber rods
• Decided to go with 2 in-line neos with normal max planetary gearboxes to turn the arm instead of the 90 degree ones
• Adding a couple hardstops
• At today’s design review, we confirmed the viability of these changes and also decided on a couple other minor changes, like adding standoffs between the motor mounting plates. Here’s the design review doc (link).

We designed a prototype of a clamping end effector that operates like scissors. It is similar to the Triple Helix intake we have been testing on, except the geometry is a little different and there’s potential for more wheels.

We also designed a similar end effector which does not clamp, it uses only wheels to retain the game pieces. It uses entraption stars and REV compliant wheels, driven by one NEO motor. We wanted to get this machined as if it was a real mechanism and test its effectiveness as soon as possible, though we plan to keep prototyping and iterating this concept as well as our other end effector concepts. (Can be seen in the first picture)

Our second robot team (also dubbed ‘beastbots’) has also done some CAD for a telescoping arm concept, a two-joint arm, and also tested the feasibility of a cone shooter (no pics of that sadly).

Mechanical
Our mechanical team has mostly been working on machining prototypes this week, as well as machining some parts for our drivebase(s), and improving organization. We continued testing Triple Helix’s intake and added 2 motors to it, as well as started preparing to mount it on a stick to the triple helix drivebase. The OTT intake has been assembled, and the pneumatic gripper is partially done. The handoff intake and the claw intake are ready to be machined.

Our REV Swerve modules finally arrived (with about a week’s worth of delay) and we assembled them all on saturday. So far we’re pretty pleased with them, though we’re monitoring chief for any updates from other teams since we already saw some things that weren’t mentioned in the instruction manual (here’s a notes doc). We haven’t been able to actually make our drivebase drive yet, though. We will have a separate Maxswerve post next week detailing our findings!

On another note, we are continuing our quest to increase our organization: we just got a nice new rolling tool chest.

Software
Our software team has been experimenting with apriltags through photonvision, running temporarily on a Raspberry Pi 3 and a Lifecam. We bought an Orange pi 4 LTS for the future (here’s a comparison sheet of coprocessors). We’re also looking into snakeyes and the new limelight 3. We also plan on having the ability to recognize reflective tape, but we have more experience with that.

We wrote swerve code for the first time- we diagnosed some issues with it after running it in simulations. We used the REV library as reference. In parallel, we’ve also been working on writing drivebase code for the tank drive triple helix drivebase.
Our new members have continued working on their Romi courses and also learning about PID control. We’ve also started exploring autonomous routines for swerve- we decided that we would most likely use path planner or Helix Navigator.

Electrical
Our electrical team has been very busy flashing electronics, configuring motor controllers and crimping our new motors. We have has trouble crimping our NEO 550 motors, we’re gonna use wago connectors instead. We also wired the triple helix drivebase and the Swerve modules.

That’s all for today Wildcats (that’s an easy chapel hill high school joke, don’t mind me. And to quote Lucien: geez is it already 3 am? - it’s not but it feels like it)

• Andrea

[BruhBigChungus]

These designs are amazing! I can’t for the competition!

[Skiddy4795]

Week 2 - Wednesday 1/18 Update

Design Process Update

So we’ve been hard at work designing, reviewing, and making mistakes this week. First, we got our shoulder mechanism all design reviewed, and like @andreab said, we’ve designed an “alpha” end effector of sorts so we can learn from on robot data.

After the design review, one of our mentors @akiyengar brought up a point none of us had been considering… load ratings. Calcs were done for gear reduction and moment of inertia but ironically none of us thought to check the skip ratings for rt25 belts at the loads we’ll be running. Turns out that if we call an rt25 roughly equivalent to a 15mm wide HTD (5mm pitch), we’re about 2x over the small pulley (24t) skip rating. In this case, our max load at motor current limit torque is close to 500inlbs, where the load rating for our use case was closer to 160inlbs.

Doing the math is important.

That said, it didn’t take us long to correct the issue with a chain based design branch. This added a little weight and backlash but the tradeoff was well worth it.

Our “alpha” end effector design is intended to be a functional prototype that we can use to practice cycles with and gather data from an actual mechanism structure. Some notable features include a TPU semi-compliant wrist mounting block (will test this idea for feasibility, it might give a big improvement to impact resistance) and a neato (if I do say so myself) infinity belt setup to reverse drive between the two roller sides at a low weight.

Our Beastbots junior team has settled on development of a 2dof pink arm, and has begun work on an alpha mechanism design. The intent here is to bring experience with this type of mechanism to the team as a whole along with involved Beastbots. Our current design features a #35 spaced slot pattern on the moving tube for a rack and pinion-style sprocket drive, along with 3D printed bearing blocks. We’ll have our first design review for this mechanism in a few days.

Finally, I’ve been working on something I consider pretty neat: a spring counterbalancing system for our arm. I worked through a bunch of math to try developing an eccentric pulley with a sinusoidal radius… until I realized the trig cancels and you can just apply a constant force to a fixed lever. The idea here is a constant force spring pair (57.42lbs total force) connected to dyneema cable that runs up to the shoulder.

In theory, the torque exerted by the CF springs should perfectly oppose the gravitational torque of the end effector moment arm. The math says it will, Murphy’s law says it probably won’t.

Mechanical - Prototyping and Such

A big part of our design process hinges on research and development. Here are a few videos of prototypes that are in either progress or testing.

4795 ProtoVid1 Week 2

4795 ProtoVid2 Week 2

4795 ProtoVid3 Week 2

Also… bumper update!

Mechanical - Field Build

Team 4829: Titanium Tigers and we have been hard at work building field elements. Progress is starting to show…

and we were able to use the platform to test our… wait… that’s the next paragraph.

Swerving!!

For the (sort of) first time in our team’s history, we have full holonomic motion on a drivebase (using our Maxswerve modules). We went through an initial debugging process where we couldn’t get field-oriented control working, thought the NavX was bad, thought the Rio was bad, turned out we forgot to delete a negative sign and it was constantly resetting heading…. another argument for “doing the math”, I guess, although in this case “the math” was a single negative sign. @siyeng will follow up with a more detailed swerve control post, but we’re all very excited!

4795 Santa's Workshop Swerving!

Closing Notes and Musings

The everybot this year is super interesting, as are all the starter bot style concepts. Super stoked at the continued lowering of the skill floor (and accompanying elevation of the competitive floor). We think the everybot’s design actually benefits our strategy (small bot mid+low cubone and high cubes) a whole lot; we feel it’ll be reasonable to ask everybot-wielding alliance partners to score a high cone or two for those sweet sweet links.

Thanks y’all for reading, questions and comments welcome, as always!

^How swerve feels

-Lucien

[philso]

@Wesley_Li

Thumb nuts for bumper mounting. Last season we used wing nuts for this. It was hard to get it on and sometimes they got cross-threaded because the metal was too soft.

You may want to consider using coupling nuts. They are meant to be used to join pieces of all-thread. They can be installed and removed using a nut driver, a socket on a ratchet or a battery drill. This is especially useful if there is a large structure installed close to the stud, hindering hand access.

https://www.homedepot.com/p/Everbilt-1-4-in-20-TPI-Zinc-Rod-Coupling-Nuts-822251/204337387

[Skiddy4795]

Ooh those look nice, and maybe a little cheaper than the thumb nuts! We already purchased stuff though, but this seems like a great alternative.

[Skiddy4795]

also credit to @pchild for reading our thread and telling Amal that belt math needed doing. I love that open alliance is:

1 - Helping others
2 - Helping us

it’s awesome

[siyeng]

Week 2 - Swerve update!

Background

Our team has never attempted swerve, and our only experience with holonomic motion was a H-drive in 2015 that didn’t really work. Up until the release of Maxswerve we were planning on sticking with WCD for this season due to budgetary constraints, inexperience, module availability, and knowing that we could still be highly competitive in NC with a WCD.

When we saw Maxswerve release with its tiny form factor, low cost, and design for neos/spark maxes we knew that we should reevaluate our prior decision. We felt that we could trust Rev to release a mechanically solid module with the software to back it up, and an examination of the design didn’t reveal any big red flags.

Timeline

Originally, we were expecting to have our modules in hand the week before kickoff and were going to take that week to get it running. However, the modules were delayed by a couple weeks and we didn’t have modules until last Friday. We started and finished mechanical and electrical assembly/integration during our 5 hour Saturday meeting, got it kinda running on Tuesday, and got it running well on Wednesday.

Assembly Tips

Here is a doc with assembly, electrical, and programming tips. This combines tips from both us and 111. SWERVE NOTES - Google Docs

Code

GitHub - Team-4795/2023-Charged-Up

Controls/Driving

I’ve been the primary driver for the team since the 2021 season, so I have a lot of experience driving WCDs. Before Tuesday, I had a grand total of about 5 minutes of driving swerve robots from trying out other teams’ robots. We’re using this 8bitdo controller and using traditional left stick for translation and right stick for rotation.

Initial thoughts on driving swerve robots

• Feels way faster than any tank drive robot I’ve driven, even though it’s only geared 1FPS faster than our previous robot
• Rotating while translating is really fun
• Makes precise lateral alignment a cakewalk(really important for this year)
• They make a lot of noises I’m not used to
• Setting the modules into an X configuration brings the robot to a stop way faster than you can with a tank drive robot
• I have to concentrate really hard to make sure I don’t slip back into driving it like a tank drive/robot oriented
• It’s hard to remember which way forward on the joystick will make the robot move when the robot is close to you because the angle between what is forward and your line of sight to the robot gets large
• Easily went up the Charge Station when level and tipped towards the robot, could not climb when tipped away from the robot

Positives Other Than Moving Sideways

Assembly was really fast

• Everything was machined and put together in less than 5 hours
  • WCD last year took us about 12 hours to complete

Mechanism Mounting

• We have the option to mount mechanisms on the side of the robot which gave us a lot of flexibility in our design
  • Probably not going to use it this year unless we add an endgame mechanism, but it’s a nice option to have

Calibration tool is super nice

• Was able to do module offsets without the robot wired or even having swerve modules mounted

Outstanding Potential Issues

Turn motors don’t have a “deadband”

• The turn motors don’t seem to have a tolerance for how close they need to be to the setpoint.
  • Causes motors to stall at a low voltage when idle
  • Causes modules to make creaking/cracking noises
  • Probably not an actual problem

Ultraplanetary bolts backing out

Potential Solutions:

• 3d printed shield that only allows bolts to back out by a little bit so that they can’t fall into gears
• Don’t use those two bolts and rely on the other four bolts to hold it together
  • Likely won’t do this because uneven torquing is suboptimal
• Use red loctite so the bolts will never come out
  • The downside is that the bolts will probably never come out and we’ll need to replace the entire motor/gearbox assembly if one fails
• Do nothing and assume that we applied loctite correctly
  • We will be doing this for the immediate future with regular checks to make sure the bolts aren’t backing out

Pics/Videos

Garage Testing

Charge Station Test

Other Charge Station Test

[Wesley_Li]

Week 3 - Sunday 1/22 Update

Design

Comp bot

The everybot design this year was released this week, and we really like their intake design. The intake on our comp bot is something we want to iterate on a lot and try out a bunch of different concepts. The everybot intake design is definitely something we want to try, so we designed a similar concept.

We also realized that in order to be able to do double substation intake, we need a wrist joint, otherwise the intake will be perpendicular to the ground at the height of the portal. We are currently planning to do a pneumatic-driven wrist joint.

Beastbots

The Beastbots design team has finished their first version of their rotary arm with a telescope. We had the first Beastbots design review on Sunday. Here is the design review doc. We will have a second design review some time in the future.

Mechanical

The arm has been assembled and integrated!

During assembly, we had some tolerance issues with the maxspline bearing block interfacing with the maxtube. The slots for lining up with the tube are too narrow and we had to use the belt sander to make it wider. Pinging @greg_needel to keep an eye out for any more issues. We believe the issue was with the maxtube being slightly too big and the bearing block slightly too small, seems like it could be a case of stacking tolerances.

At the end of our Saturday meeting we tested our arm motors and all we need to do to test out the arm is integrate chains and mount the encoder.

We are also almost done assembling our pneumatically actuated gripper prototype, as well as the new wheels-only gripper mentioned in the last post (they’re missing some motors and belts).

We machined the polycarbonate parts needed for the Over-the-top intake.

When we were machining the polycarbonate parts on the router, we had some issues with the polycarbonate sheet being too floppy. It makes really bad noises and the sheet gradually shifts away from its original position, causing inaccurate dimensions. Hopefully this problem can be fixed by adding more bolts to hold the part down onto the bed. We’re also probably going to start using masking tape with CA glue to hold down thin polycarb.

Additionally, we made a lot of progress on the assembly of the handoff intake, which was pictured in the animation Lucien posted a while back.

We did a test fit to see how the end effector fits onto the arm. It can fit inside the frame perimeter while holding the game pieces.

We also mounted one of my favorite parts of the robot: the carbon fiber A-frame! The mounting plan is to use universal ball joints mounted on 3d printed end caps and use epoxy to secure them inside the tubes. We want to use threads of different orientations on the two ends of the tube, so that we can adjust the tension of the A-frame by turning the carbon fiber tube.

Electrical

There hasn’t been a ton to do on the comp robot for electrical this week. The beastbot was a whole other story. Originally we had our new Rio 2.0 on the swerve robot, but took it off because it was giving us no code errors even though code compiled and deployed fine. The Beastbot team ended up using this Rio and have been having a lot of issues with it. More on this in the programming section. Additionally, we wired and plumbed pneumatics on the Beastbot chassis so we can test end effectors on it.

Also, we made our annual CAN ID and other motor data tracking spreadsheets. Here’s the link, in case anybody wants to… build this exact same robot and use our code, I guess.

Software

Our software team has been working on the swerve drivebase characterization and got the field oriented control working. We were also working on the auto path planning with pathplanner, it can work but there are still some accuracy issues. We also got the 3d April tags working, the camera used to read the tag’s orientation incorrectly but now it reads it correctly. We fixed it by calibrating/using a different resolution (800x448 instead of 160x120), changing the decision margin cutoff (30 → 35), and changing the pose estimation iterations (200 → 150). Currently it can only read the tag from a couple feet away from the tag.

Conclusion

We are in a good spot entering week 3 and hopefully we can give enough time to software tuning and drive practice before comps.

(potential gamepiece shooting mechanism concept)

We are trying to come up with a good name for this robot! Please share your ideas in the comments! (Sidenote: our robot names have a tradition of being related to Greek mythology) (Sidesidenote: Our robot last year, Giannis, is named after the Greek god of basketball and also player for the Milwaukee bucks) (Sidesidesidenote: Since we have our junior team Beastbots this year, we hope that the names of the two robot can be somehow related)

Thanks for reading and please leave a comment if you have any questions!

-Wesley

[Skiddy4795]

Mini-update

I’ve been out with covid for the past few days, so our Wednesday update will be crammed all into Sunday’s post… but I still wanted to share this.

In bed I did some cad and modified WildStang’s SpectrumCorners into a new version that prevents MaxSwerve from annihilating itself if the ultraplanetary mounting bolts loosen. The added ledge should keep these bolts from tumbling into the steering gears and causing mayhem. This issue should be solved by loctite, but we’d rather not find out the hard way. This cover will allow the bolts to loosen enough to be noticeable but not destructive.

@HDrake are these dust covers meant to expand a bit and snap on from the outside, or should modules be disassembled to slide them in? Wondering if I should add a slot to my little bridge so the cover can spread open.

Also! Re-upping @Wesley_Li‘s robot name suggestion request!! If the wise sages of Chief have any ideas (greek mythology theme)… shout em out!

-Lucien

[HDrake]

Ours just slide into the assembly before you drop the 3 main spacers in on the final top/bottom marriage step. No bending necessary.

I did think about doing this, but with just my quick glance, it looked like the encoder fork could potentially hit this bridge when the module spins so I didn’t add it. If yours works though, awesome!

[Inposabi]

Zeus is a good name because god of electricity and all that. Fits with the game.

[Skiddy4795]

Gotcha, that makes sense, thanks for the reply! The encoder fork is definitely a close fit, and I haven’t tried this on an actual module, which is why I didn’t link any CAD yet.

[Skiddy4795]

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.

[Inposabi]

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.

[wolly_efendi]

@Skiddy4795

spring counterbalancing system for our arm

Excited to see pictures/videos of this in action!

[Skiddy4795]

pics of this should be coming in the next wednesday update!

[shroomonfire]

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.

Roller Claw v1 Cube Test

Roller Claw v1 Cone Test

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.

rapid unplanned disassembly

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!

Arm Motion Test

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…