Sunday, February 10, 2019

Day 33, 34, 35

Snow outside the lab

It snowed again. It's apparently the new cool thing for Seattle to do. That being said, since it already rains a lot here, most parents and kids have AWD or 4WD vehicles, so after some settling, we have a core group of folks working once again. Our deadline has been set for Saturday. Parts that must be manufactured. Parts that must be assembled. Parts that must be mounted on the robot. These are the days in the season where, if it isn't done, we will be here until it is done. Days like these can catch us up a day, or lag us behind yet again.



When to Say No


I personally have a hard time saying 'no' to friends and family. "Hey want to go get some lunch?" - "Sure". "Hey, want to invite literally every family member over for Thanksgiving?" - "Well, yeah sure, I guess so". "Hey, want to go jump off a bridge? I think I have a bungee cord or parachute somewhere." - "Oh yeah, let's do this!". (Alternatively, there are some things that are very easy to say 'no' to. "Would you like mushrooms on your salad?" - "No. Heck No. Awwww no. No thanks. No way. Nope. Wait, are they grilled mushrooms?") Generally, I want to please everybody, make them feel good when I see them, and show that I can handle anything. (FIRST really exploits this character trait of mine.) Many students and many mentors here are the same way. We all just want to make each other happy, and get stuff done, and generally that means saying yes a lot. Yes, we will stay until 1am tonight. (This morning?) Yes, we will come in on a Friday evening. Yes, I can be on the robotics team, pass my AP classes, star in the spring play, and hold a part time job. (Actually, we had one student who successfully managed all of that, and still had an active social life. I'm convinced they had one of those time turner things from Harry Potter...)

FIRST puts a lot of stress on students (and mentors), and often we are asked to go a little bit further. Our team has seen great success, and we obviously want to continue as best we can. We've had a larger team in past years. We've had different mentors in past years. Outside of a robot, we have our outreach programs, our website, our marketing including pit banners and social media, we host events during build season, and meet with sponsors. Saying yes to all of it can, and has, put a lot of strain on several students over in previous years. We always want to keep moving things forward, growing, improving, and continuing on, but some years, it is best to take a step back and make sure the resources exist. In the past, we've had almost a 50/50 business and engineering split (with overlap). Other years (read: this year) we have a smaller business team. But, we still have outreach, website, marketing, yada yada yada... And because we did it all last year, and most of that 2 years ago, we want to do it all again. Some years (read: this year) it just isn't feasible to manage and handle everything that had been done previously. And yet, we have kids that always want to say yes and want prove to themselves. I don't think there is anything wrong with pushing ones self, but there will be limits, lest you will burn yourself out, learn less, and enjoy the program less. This is also not to suggest that you say 'no' to everything that is difficult and challenging. The point of this program is to get dug into problems that you've never seen before. What I am trying to say, is really take a look at the items you can manage, and the items you can't. If you as an individual are being asked to be engineering lead, safety captain, chairmans writer, and train all the new recruits... you may want to drop some of those tasks, and ask for someone else to manage them. As a team, its important to know and understand everything your team does. If it can't all be done, either figure out what you would need to get it done (more resources), or know the priority and the value of each item. Other items can be much more simple, know when to prioritize homework or family events over your robotics team. (Unless your robotics team is your family, then spend all your time with them!) If you're affected by the polar vortex, or a pack of polar bears has taken up residence in your lab, know to keep yourself and your teammates safe.

We went through this process last year with our Unified Robotics program. We are extremely proud to partner with, and now officially hand off this program to Special Olympics Washington, but we had to go through many meetings and discussions of 'can we do this', 'how do we hand this off', and 'what does this look like as a non-CyberKnight owned program'. This past fall, the Unified Robotics Championship event ran successfully and smoothly under its new ownership (with CyberKnight volunteers, of course). On another level, this past week, we also sadly had to say another 'no', for safety reasons. Our annual Unveiling event was cancelled for the first time in 6 years. We are definitely sad that we had to, and hope our local, national, and international invitees understand. Many props to our team that had already put in the effort to make this event happen, but having 5" of snow dropped on Seattle made this call a purely safety call. We miss you all already, and wish you well for the rest of your builds!

Sensors and Feedback


This past week, I poked another famous FRC mentor/blogger, sending him a mailbag question about how his team feels about sensors and feedback. Seeing as I asked it of him, I figured I can share the same information about our team. In the past, we have really enjoyed thinking and prototyping and testing sensors. And then when the final robot was manufactured and assembled, we... left all the sensors and feedback devices in a box on the shelf. In 2017, we had to re-manufacture a bag motor mounting plate that also contained a mount for an idler pulley on which to run a potentiometer. Last year, 2018, our wrist had to "home", and our "ingenious" solution was to use the 3M dual lock tape to mount a snap action limit switch. As you may have surmised, this solution didn't work out so well. Over the summer and fall, several lead students and mentors took time to learn how other teams handle sensors and feedback.
Motors and encoders

Perhaps our best resources were online workshops. We watched videos from 971 specifically. They have great workshops and robot system breakdown videos. We took the lessons they showed, and thought about how to incorporate them into our robot designs. One set of sensors we have generally used ever since our FTC days are drive encoders. We use encoders, one on each side of the robot drivetrain, to determine relative position, and calculate movement distance. Once a match starts, we can follow and calculate how far the robot has traveled, and deltas between the right and left side can tell us when and how we are rotating. On top of the robot however, is where we usually can do more to improve. Of course, each system is different, so the feedback and sensor requirements will be different. Probably the easiest system to make, are passive, unpowered systems. Most of the time, however, these systems violate other robot rules, so lets move on.

One focus this year is improving our control of rotational movement. Part of it is mechanically sound design and perfect assembly, but if we manage that, we still need software to be able to control it. Two options for measuring rotation are potentiometers and encoders. Potentiometers measure in absolute position across a defined spectrum (90* turn, single-turn, ten-turn, etc). Encoders measure relative distance from an arbitrary starting position. In our history, we've found it easier to mount and read encoder values. The problem is, what is the starting position of the mechanism? With an encoder, we don't know. Some of our finicky issues last year came from using snap-action limit switches. A lesson we took from 971 is the use of hall effect magnetic limit switches. On our hypothetical system, we can place these limit switches at the known... eh, limits? of travel, then we can get a software read before we slam the mechanism into a hardstop, or worse. So, for each rotational system, we plan to have an encoder, and 2 hall effect sensors. There's still an improvement to make though. If the mechanism starting position is in the middle of travel, we would need to run it all the way to one end or the other before getting an actual known position. So, here is the action item we have taken on this year: better mounting and reading of potentiometers for better control of a rotational mechanism. But, given that it's almost week 6 and the robot still isn't "done"... I guess we'll all see what happens in the future!

Snow Might Actually Be A Problem

Parts are flowin'!

So, it's the end of week 5, the robot ins't done, (where have I heard that before?) and yet more snow is coming for us. Challenges are fun. Here's a fun piece of insider news. We saw the schedule and saw where the robot was. Our head coach and lead mechanical mentor thought it might be time to swap a few seats with the students, and let the mentors finish clicking through SolidWorks and re-up the tempo to the finish. We brought this idea to our student engineering lead and his response was a simple 'nope'. So, it appears our job is to keep striking matches and attempt to light some fires under chairs in the CAD room. It is working, and, slow as it may seem to us, we are making progress to the finish.

Also happening in week 5 are... more prototypes! And more parts are hitting machines. I spent my Wednesday night with our Chairman's crew, finishing up our submission. We have finished assembling and putting together our second robot chassis. As it stands, we can play defense! What a year I've chosen to be the first year I blog about. Things are going... roughly smooth....

Mentor Conversation of the Day:


No comments:

Post a Comment