Gems of Wisdom for Future 210s

Sid: 

I think this project was a super cool learning experience for me. I would advise future students to soak in as much as they can from their teammates, especially since they are likely coming from different areas of expertise. Ask questions as much as you can to each other but also to the TAs. I think one of the biggest things a team can do to increase the likelihood of a successful project is to create an extremely detailed spec of your design from every mechanical part to each instantaneous movement of the robot. Of course things will change along the way, but having a really detailed plan and vision will help extraordinarily. It will also lead to easier debugging, making, and collaboration. Technically speaking, I would advise students to think about power consumption of the robot and how fast movements, hits, and motor stalls might alter function. Also, I would advise students to break their state machine and code into the smallest possible movements of the robot, which will not only make it much easier to debug but will also allow you to have more fine grained control over the robot's complete path. 

Jingyi: 

One thing I think all of us did well was that we spent more time trying things and prototyping than thinking and talking. The project creates a big open space and there are so many options to implement an effective robot. I remember that we had a really long conversation in the beginning about the drivetrain architecture. Afterwards, we were able to make lots of decisions fast and smart. I was very inspired by how quickly my teammates put together prototypes and tested out different options, and it inspired me to create my designs as quickly as possible. 

I also think that we did a good job being flexible while also holding each other accountable. If one person needs more time for a deadline, or comes late to a meeting, we didn’t make a big deal out of it because we all understand that things happen. However, we all did a really good job making our subsystem functional and ready for integration. 

A few specific things for future students to come: 

• Don’t underestimate the strength and reliability of VHB.

• Don’t underestimate how much space cables will take.

• Cables always unplug themselves.

• Work really hard on this project, but also schedule break time and day off from the project

Veronica:

Overall, our team functioned really well! There was a good balance between solo time and team time. At the beginning, we divvied out the subsystems to each member and for a while, most of our time was solo work, dedicated to making sure each of our subsystems was reliable. Integration of the subsystems was gradual: first, it was drivetrain and navigation, then we added orientation and mechanical parts. It all culminated in our “beat the brick day” when we all stayed in the lab for an entire day to get all of our subsystems working together. My advice is to take the time to craft things really well. Shoddy workmanship leaves more room for error and more frustration when you’re trying to integrate everything. I was really impressed with my teammates’ dedication to fabricating clean, well-fitting parts. 

Code testing was a frustrating endeavor. I was often unable to initialize the sensors and the reading printouts were unreliable. After much hair-pulling, I asked Jingyi to upload the code from her computer and…it worked perfectly. Sometimes the problem is your computer.

My teammates were an important source of support. There were many times when I thought that I had run into an unsolvable issue, but after consulting with the team, I realized that it was, in fact, solvable. Everyone came in with different skill sets and experiences, and I had something to learn from everyone. 

Benjamin:

I really agree with everything above, especially Veronica’s last paragraph.

Some other advice for future teams:

• Build a robot that will be fun to spend time working on.

  • We built a flywheel launcher and machined a lot of metal parts - and spent a lot of time on our robot - primarily because it was fun.

• Build a robot that is mechanically solid and reliable 

  • Of course this is easier said than done but using mechanical fasteners, taping plugs, and soldering for the electronics, and building the frame from metal meant we only had to spend time on building it, not fixing it.

• Build a robot that is maintainable

  • Not too many layers of parts. Fryborg was assembled and then fully disassembled and reassembled. Drive modules come off relatively easily and are interchangeable which was helpful when one of our motors broke.

• Utilize (and appreciate!) lab64

  • Lab64 has a lot of electronics and aluminum sheet (and lasercutter) available for free

• Consider components/libraries that aren’t the “default” if proven/calculated to be better

  • ToF sensors were found to be better than ultrasonics at getting accurate readings when aimed at angled walls as well as not requiring as many pins.

  • More powerful motors with encoders were available for the same price as lab-provided motors (though without gearboxes). Consider fabricating more custom parts to get more functionality for less of your budget.

  • The Adafruit ToF sensor library took up a lot of our Arduino’s memory, but there were other libraries available that worked just as well and were much smaller.

• Use encoders and control loops

  • Not essential but we learned a lot from using them and they did work well for us. The drivetrain has three proportional control loops and the launcher has a proportional loop with feedforward. Adding a control loop to the launcher made its spin up and recovery times much faster.

• Don’t assume that microcontroller power is easy

  • We were powering the Arduino from a laptop so we could unplug it as an E-stop and also to get testing earlier, but this slightly delayed beating the brick as the regulated voltage dropped under load when we switched to a 5v regulator right before our attempt. We ended up using a 3A buck converter for powering just our 5v servos and electronics and this worked well.

• Divide work by subsystem not by engineering specialty.

  • I liked getting the full mechatronics experience instead of just doing the CAD/machining work I usually choose to do on group projects.

It’s also helpful to have at least one person who really understands each full subsystem

• Have a team with a good mix of skills and experience that works well together - especially with someone (Jingyi) who’s good at project management.

  • Our team was lucky as we found each other over slack when we all needed a group 

• Spend lots of time early - this way problems can be fixed more fully. 

• When choosing a threshold in code try to find both sides of the range where the function works.

  • It turned out we could widen our orientation and encoder thresholds a lot and keep Fryborg from being too picky about whether to advance to the next state.