Behind the Design | 2015 Skunkworks

This reflecting off of our mistakes from last year we decided to improve our prototyping process because were not using our time efficiently and were dropping ideas without testing their effectiveness. Over the summer a student and some mentors created our rapid prototyping schedule and program to make our first weeks in the build season use the knowledge base of the whole team to make multiple and various prototypes.

After Kickoff the whole team returned to school and began the meeting by defining what characteristics our robot will need to be competitive. Keeping those values in mind we split into smaller groups to focus on a subsystem that would be a necessary part to play the game. For example, we had a team devoted to coming up with ideas for tote stacking mechanisms, and another team devoted to coming up with ideas for a system that got totes from the human loading station. Each of these teams presented and selected systems that we wanted to prototype. We reorganized our team into different groups to make the actual prototypes in seven to ten days and present their efforts to the whole team to prove that the system worked. The systems were discussed and compared under different parameters. The Design/Build and Programming team met with mentors to further discuss the prototypes and decided which system would be the most reliable and also feasible to put on the robot. The final step was to make a to scale sketch of what the robot would look like in Autodesk Inventor which we reference to as the Master Geometry.

After looking at all the prototypes, we decided that we wanted a stacker that came down over the top of the totes, and had polycarb blades that snapped under the lid of the totes to lift them. We also wanted a human player loader ramp that had wheels to slow the totes down, so that totes slid into position for our stacker to pick up. To pick up cans, we chose to pull in cans with mecanum wheels. Through prototyping, we discovered that the mecanum wheels centered the can as the can is pulled in. This can collector could intake cans that were knocked down, and rotate them to be vertical. Then a claw would grab the can to stabilize it while the polycarbonate blades stacked totes below the can.

All of the prototypes were large and the robot needed to be tall to hold the can while making 6 stacks. It had to have a large wheel base so it would not tip over from holding the totes. In addition we knew we had to leave lots of room for electronics. The transport configuration that the robot had to fit in was 78 inches tall, 42 inches long, and 28 inches wide. After laying out a sketch of what we thought our robot would look like, we decided that these dimensions were too small. We decided to make the robot fold into its transport configuration, like a Transformer. In transport configuration, the main stacker elevator would fold horizontally. In this configuration, the maximum length of the robot is 78 inches, the maximum width is 42 inches. This provided more than enough space for all our mechanisms.

Introduced to the team last year this Geometry was created in AutoDesk Inventor as a place to experiment with mechanism placements and size constraints as well as a reference file for how the mechanisms will fit together.
Introduced to the team last year this Geometry was created in AutoDesk Inventor as a place to experiment with mechanism placements and size constraints as well as a reference file for how the mechanisms will fit together.

In this configuration, electronics can be stored under the human player loader ramp at the back of the robot. This includes the battery, which is stowed as far backwards as possible to counterbalance the weight of the totes being stacked at the front. The drive base’s dimensions have been increased from 41″ by 27″ to 31.5” by 41”. These dimensions give our robot maximum stability, enough room to stow electronics, while being small enough to fit through the average doorway.

Subsystems

2015_1983_CanAcquiringWrists
This assembly required many parts to fit within a very small space. CAD was very useful in that it allowed us to calculate the range of motion that would be allowed.

Can Acquirer

The can collector arms pick up cans that are knocked over on their side. We chose to pick up cans that are lying on their sides, rather than standing upright, because that is the orientation the recycling cans are the most stable in. They fall over the course of the match, and even if all the cans remain upright, our robot can always knock the cans over into collection position.

The original weight budget for the mecanum collector arms was 10 pounds. The arms also needed to fit within transport configuration. They had to quickly attach and detach from the robot so we can transform the robot from transport to field configuration in under a minute. We also had to keep track of the angle of the can collector arms using a potentiometer and the speed of both mecanum wheels using an encoder. The ends of the can collector arms had to be actuated, the arms had to release the can when the can holder grabs the can.

We wanted the left and right can collector to be perfectly parallel when rotating, so we had to have a mechanical connection between the two arms. For our design to work properly totes had to go through the middle of the robot. This prevents any shaft from going through the middle of the robot. The only place where we could run a shaft is underneath the human loader ramp. Therefore we had to rotate the collector arms with a rod and lever. We set up the linkage so the slowest rotational speed of the arms is near horizontal and vertical. This means the lever that rotates the arms can have more error in where it stops rotating, as the arms will be in about the same place even if the lever is off. This makes it easier for the programmers to tune the PID controls of the arms.

On the can acquirer arms, we mounted mecanum wheels that centered the cans when the robot intakes cans. We used a RS550 motor connected with a chain to the mecanum wheel. To keep track of the speed of the motor, we connected a encoder with a 3D printed gear. The encoder records the speed of the motor so the programmers can tell the motor the exact speed to run to intake cans.

For the first iteration of the can collector arms, we planned to run a chain from a motor to a mecanum wheel on one side of the motor, and run an encoder with two gears from the motor to the encoder on the other side of the motor. This meant that the motor had to be precisely positioned between the mecanum wheel and the gear so that the chain run was tight, and the gears meshed properly. When we first tried assembling these arms, the gears to the encoder did not properly mesh, and the chain to the mecanum wheel was too loose. We figured out that we could not build this version of the design in our shop accurately enough. The location of the motor and all four plates were independent of each other, which meant that each plate could drift. We ended up having to redesign the actuating arms. We used the waterjet to design a plate that references the motor with two hard stops. That means that the attachment points for the gears and the chains are determined by the waterjet, which is much more accurate than human hands.

Can Stabilizer

The can stabilizer was designed and created for the means of controlling the can game piece from acquiring to scoring. Keeping control of the cans in a secure manner was very important to us because it would multiply the value of each stack made. The difficulty in designing this mechanism was the size and weight constraints as well as the shape of the can itself. We were given a height constraint of 78” and a max scoring height was around 72” tall so we had a very small margin of error when it came to holding the can. On top of that we had to cut out as much material as we fit the budget of 10 pounds given to us. We first looked at different arm sizes and pivot points to find an optimal leverage and range for the system.

Considering we had a weight budget a team would expect to minimize the number of moving parts as well as the amount of material that is being used for a system, however for this mechanism we decided that it was more important to consistently center the can using two pneumatics instead of opting for the pound shaving one pneumatic to power the clamping action.

We needed enough force to hold the can even when the acceleration of the moving robot or the weight of the can tries to force the can out of the mechanism’s grasp. We used tread that was fit taut to the jaws in three places to have a three point contact system going. This was working great until we realized that when receiving the can the holder would not have a perfect grip on the game piece because the friction of the tread and the crunching force of the pneumatics would force the can to be held a bit more forward than we designed it to. To help with the intake process we implemented wheels to create a gliding action that would accept the game piece while still providing three points of contact to securely hold the item.

Testing out this system proved that our design was still not competition ready because it wasn’t strong enough. We were originally using 1.8 material for the arms of the claw to hold the can but during practice sessions those claws began to bend out of shape and became out of service. We doubled the thickness and cut out as much material as possible without jeopardizing the structural strength of the piece in critical areas.

This design went through many stages and transformed from an idea drawn on paper to a design, but the biggest lesson learned from designing this piece was learning how to CAD well. When creating a design it is easy to become careless and lazy when the design needs to be done quickly to begin fabricating parts to get it onto the robot, yet it is the most painful thing to go back into a part and realize that the process that was used to make it made it a nearly un-editable item. Going back to change a part that should take minutes took us hours and that was precious time wasted so we started from the base up. The geometry was re-done to be simpler and easier to change, cut circles were changed to holes, and parts were derived to make changes faster and precise. This invested time helped us greatly when we made the final touches to make the arms fit the can better while making greater  range of acceptance. We learned from our mistakes and created a system that not only worked well, but was also reliable.

The weight budget for this system was ten pounds. We used AutoDesk’s properties feature to calculate the weight of the system before we built the system.  In addition we downloaded flexible part files from Bimba to experiment with stroke length and pivot points within AutoDesk to find the optimal leverage and force we can get from the pneumatics.
The weight budget for this system was ten pounds. We used AutoDesk’s properties feature to calculate the weight of the system before we built the system. In addition we downloaded flexible part files from Bimba to experiment with stroke length and pivot points within AutoDesk to find the optimal leverage and force we can get from the pneumatics.

Elevator

The elevator was the core system of our robot. The mechanism was designed to be simple yet effective at making stacks of totes. From our first week of prototyping we determined that one of the best methods for picking up totes was a passive grabber that only needed to be moved up and down past a tote to pick it up. As the elevator was lowered to the ground, the blades would deflect out of the way until they passed the top lip of the tote. They would then snap into place underneath the lip of the tote allowing the tote to be raised above the ground. This process could then be repeated to pick up another 5 totes.

This assembly was created using Design Accelerator to calculate the parametric values of the Spur Gears and Chains that we would use.
This assembly was created using Design Accelerator to calculate the parametric values of the Spur Gears and Chains that we would use.

Along with picking up totes, the elevator could also make stacks with cans on top. Although the can acquirer was what picked up cans, the elevator was what helped push the can to the top of the stack. Using the can acquirer and the can holder we could transfer the can from the field into our robot in an upright position. Because  the elevator mechanism and can holder both rode in the same track system, the elevator could push the can holder up in effect raising the can as well. This allowed the robot to be fed a tote from the feeder station. Once a tote was in the base of the robot, the elevator could be lowered and as it passed below the tote, it would set the can on top of the collected tote. When the elevator was raised, it would lift both the can and tote supported underneath it. This process could then be repeated to pick up 5 more totes forming a stable 6 stack with a can on the top.

These angled pieces of polycarbonate on both the moving arms on the trolley and the front of the Elevator System to register and stack the totes quickly.
These angled pieces of polycarbonate on both the moving arms on the trolley and the front of the Elevator System to register and stack the totes quickly.

The elevator was the biggest and most visible part of our robot with the exception of the drive base. The system alone was 75” tall, 24” wide, and 26” long including the stacker arms. The entire system was made of aluminum parts and most of it was waterjeted to get accurate mount holes and lighten the parts. The main frame consisted of 3 C-channels that were welded together to form a U-shape. Delrin rollers inside these C-channels attached a pop riveted box frame with two 19” arms to move up and down. The rest of the system was either pop riveted or VHB taped together. Systems that didn’t need to mount directly to the main frame, such as the elevator trolley, were pop riveted together. The components that did attach to the main frame like the back sheer panel and drive train were VHB taped on to the frame. Mechanically, the system was relatively simple, containing only two motors and a single sensor, but getting the system to integrate well with the rest of the robot and fit within the size constraints was very difficult.

This trolley was designed to be very tall because it would carry a great amount of weight that would want to pull the mechanism out of the ladder. Making the piece longer gives more stability but in turn becomes a heavier piece.
This trolley was designed to be very tall because it would carry a great amount of weight that would want to pull the mechanism out of the ladder. Making the piece longer gives more stability but in turn becomes a heavier piece.

Although the elevator could stack totes independently of any other system on the robot, it needed help from the can acquirer and can holder to handle the cans. Since the can holder rode in the same guide rails as the elevator, the elevator had to be recessed into the robot at the right position so that when the can acquirer lifted the can upright, it transferred the can to the can holder. This also meant that the can acquirer had to fit around the elevator so it wouldn’t interfere with it as it raised the can. Another  design complication we had to deal with on the elevator was how to make it fold up in a matter of seconds. Due to the nature of all our robot systems, we weren’t able to fit everything into the transportation configuration of 28” x 42” x 78”.

This is the cumulative assembly of the trolley systems, tote stacker, and can holder. This assembly gave us better insight on how much room these systems take and how much more is available for use.
This is the cumulative assembly of the trolley systems, tote stacker, and can holder. This assembly gave us better insight on how much room these systems take and how much more is available for use.

So we built a drive base that could fit all of our systems, which came out to be 32” x 41” x 77”. In order to make the robot fit into the transportation configuration, we put the entire elevator mechanism on a single pivot point attached 20” above the drive base so that it could be rotated perpendicular to its original position. Then the entire robot could  be rotated up onto its nose so that its new dimensions were 27” x 32” x 77”. This meant that entire elevator had to be a single independent system that had a drive train independent of the drive base. To insure that the elevator stayed in the upright position while in competition mode, we used 2 small quick release clamps that clamped on to the bottom frame of the elevator holding it in place. In the final product it would only take about 5 seconds to unfold the elevator from transportation configuration.

This system was relatively simple to design, however the arm that the grabber claw was attached to was cut down and curved to fit within the design constraints given.
This system was relatively simple to design, however the arm that the grabber claw was attached to was cut down and curved to fit within the design constraints given.

Auto-Can Grabbing System

The system used on the competition robot was a prong with five bolts that slammed onto the top of the can lid. It dragged backwards and had 1 or 2 of the bolts catch on the can. The season begun with a four-bar linkage idea in mind. It was ambitious, but weight was to be allotted to the rest of the robot so only a linkage that grabbed two of the four cans on the step was kept in mind for the early parts of development. There needed to be horizontal stability so that each can grabber had the same chance to reach the lid, however there needed to be vertical stability as well as seen by the situation where one of the cans isn’t present to be acquired from. A sketch was created that showed the possible geometry if a four-bar linkage was made because the length of the linkage is limited by the height maximum for the robot. This sketch helped determine the measurements for the linkage that would reach the front of the can lid hole without breaking the height limit when it folded up. However a hiatus was placed on the auto-can grabber system to focus on the other systems for the majority of the build season from then on.

The greatest challenge in this system came from spatial constraints that required the motors to be put into the back of the robot out of the way of incoming totes. The four bars include the robot drive base, can acquirer arm, rod, and mount that attaches to the spur gear in the back. Design Accelerator was used to make calculations and AutoDesk was used to find the reaches of the arms in their configurations.
The greatest challenge in this system came from spatial constraints that required the motors to be put into the back of the robot out of the way of incoming totes. The four bars include the robot drive base, can acquirer arm, rod, and mount that attaches to the spur gear in the back. Design Accelerator was used to make calculations and AutoDesk was used to find the reaches of the arms in their configurations.

Near the end of build season when the remainder of the robot was near completion, with weight allotted for almost everything else, save a couple of pounds for powder coating, and the auto-can system, designing for this subsystem resumed. However because the auto-can grabber system became an afterthought, a mere couple of pounds of weight were all we had left. The resulting ideas were as follows: a tape measure that stuck horizontally and grabbed the can;  an umbrella handle that reached for the can and pulled it; a claw-like acquisition that was in early development before the hiatus. Most of these ideas became quickly eliminated once the system was most likely to be successful was clear. The tape measure was light, but simply not possible to make the system fast enough to grab the cans. Also, in order to automate the system, there would need to be a system that extended the measuring tape, and there was not enough time to develop an actuator for this system, allocate wiring and programming as well. Then, the umbrella handle had an issue that was an issue for the tape measure too. The cane idea was light, simple, but gave the robot only one shot to grab each can. The cane handle was only one chance, which was too risky. This transitioned well to the development of the claw system. This claw system had many fingers that translated to three chances for the can to be in possession of our robot. Plus, the fingers were curved in the back that made the removal of the can from our possession very easy, in the act of pushing our robot forward with our can angled away from the robot. We continued development of the system as one of our final ideas for the auto-can grabber system. We added a horizontal crossbar to prevent the claws from slipping completely inside the can lid. The fingers of the system were moved closer together to fit two fingers inside the lid at a time, and to provide space for another finger to grab onto the can. This system would’ve faired fairly well in the competition, however the design of the system was finalized too late and the team had used a separate system in the time that we were developing it between competitions. This other system, which ended up becoming part of the system used at PNW district championships then at world championships, was a system that was inspired by a fellow PNW team, Issaquah Robotics Society, whom had created a system that was very successful yet required minimal fabrication.

Drive Base:

The drive base features a U shape design to allow the game totes to enter the front of the chassis before being collected by the can .It was designed to  reduce weight, but maintain enough structure to withstand any impacts that could occur during a match. Designing a chassis of this particular shape proved to be challenging because it needed to maintain sturdiness while having the front of the right and left sides not directly connected. To increase the strength of the design we added multiple pontoons down the sides. This greatly improved the rigidity of the design which is very important because our robot would be carrying a very heavy stack of totes over uneven ground.

The drivetrain consists of four mecanum wheels spaced apart in a nearly square shape, this allows the robot to be extra versatile and move sideways as well as forwards. We chose to use mecanum wheels instead of omni-wheels because they provide more versatility without the need for another set of wheels and without sacrificing as much performance. For a mecanum system to work, each of the four wheels needs to be individually powered because the front and back run in opposite directions in order to go sideways.

We also designed the tote intake and repositioning system for obtaining totes from the feeder station. These are clear polycarbonate sheets on top of the drive base and inside the U shape. We made the top intake system out of one bent sheet in order to reduce weight and complexity, although we had to add two aluminum angles to attach it to the robot. The two parts on the inside of the U shape are used to reposition the totes once they move through the back of the robot, these pieces are important because the stacking mechanism needs very consistently placed totes. One of the most challenging parts of the design of the drive base was making sure there were no interferences with other subsystems. The intake polycarbonate sheets were greatly limited by the folding action of the robot’s stacking mechanism. In order to make the static intake system work we had to make very precise cuts out of the polycarbonate keeping the radius of the stacking mechanism movement from hitting into my pieces.

Describe the design, manufacturing, control, assembly and testing processes used by the team to create the robot.

Prototyping:

In previous years, our “rapid prototyping” was neither rapid, nor prototyping. It consisted of the team narrowing down our ideas to one or two systems, then building mock ups of those systems and testing them. When we reflected on last year’s process, we did not consider this prototyping because we did not test a wide breadth of ideas. Instead, we only tested the ideas we thought would work and if they didn’t, then we just modified them until they did. This process was much slower and less effective than we wanted to be, and as a team we decided that in order to improve our designs, we needed to revolutionize our process.

Over the summer some team members created a new process of how we could make the prototyping process more useful and efficient to test out many ideas and better involve everyone on the team. This was patterned after prototyping work done by a number of other teams including Team 254.

Similarly last year we defined what characteristics of a robot would be the most important to be successful. We then split the team up into groups to focus on each characteristic. For example, we had a team devoted to coming up with ideas for tote stacking mechanisms, and another team devoted to coming up with ideas for a system that got totes from the human loading station. Each of these small teams presented to the team and we found systems that we wanted to prototype. Everyone on our team was then put into different groups to make these prototypes in a little over a week. At the end of the week, the different teams presented their prototypes. After presenting the prototypes we finalized which systems worked the best and could be combined into our robot. The final step was to make a to scale sketch of what the robot would look like in inventor.

Designing:

After we prototyped different design ideas and chose the concepts we would develop further, we began to design the robot using CAD. Initially we developed very basic models for everything, just so that we could have a good sense of where everything went and so that it would be easier to change things when needed. Once we had the basic structures completed we started adding more detail and went through multiple iterations of design making sure everything fit together and would work properly. The final step for everyone’s designs was to “cheese” them to reduce weight. The drive base in particular had most of the material taken off for lightening. Before we started constructing anything we had most of the robot design finished and once we started constructing a piece it must be completely finished in CAD and checked over by multiple people to insure perfection.

The narrative (and images) may also include insights relevant to design, manufacturing and control processes based on the robot’s performance in FRC events.

For districts and regionals our robots stacking mechanism was top notch. We were able to do two full stacks of 6 with cans on top with time to spare and very few robots could do that. Once we got to worlds however we were not nearly as fast as we should have been to be Einstein worthy. There was one main problem that was holding it back, the totes would slide too far through the robot when loaded through the back and this would make the robot need to drive forward slightly after every tote was collected. Even though this could be done very fast, each time added up and in the end it greatly limited the amount of stacks we could produce. It was a problem that could have been solved by adding powered wheels or some sort of hard stop to the front but we didn’t have the weight or time to add or change anything in any major way. 

CAD submission specific questions:

Describe how the team used CAD and other software to design the robot. Was CAD used at the earliest stages to “sketch” the robot’s concept, and then refined to finalize the design, or was CAD used primarily as a detailed design tool?

After prototyping, our team used CAD to create a master geometry of the robot. This is a sketch that portrays a 2d representation of what we imagine the robot to be. This geometry can be used to figure out how your piece is sized relative to other parts of the robot and it can be updated if one changes the geometry of their piece. From there, the team could design their individual parts, all in CAD, and reference the original geometry when a view of the whole robot was needed. Before we started construction of anything, it needed to be fully designed in CAD and thoroughly reviewed for errors.

Explain how the use of CAD techniques affected the team’s ability to efficiently and effectively design and create a robot.

By using CAD, we have been given the ability to design the robot in a far more realistic manner than any non computerized design could achieve. We create nearly the entire robot in CAD before building anything. By doing this we can essentially view a finished version of the robot before we start building it. This allows us to spot potential problems in our design. For example, when we were designing the drive base we needed to make sure that every piece on the robot would be properly positioned without interference. If we were to try to do this on paper and pencil, it would be extremely difficult to make sure that none of the pieces interfere with each other. By using CAD, we can look at an assembly that includes all of the pieces and move them how they would move in real life and check whether or not they interfere with one another. By using CAD we can also check the movement of different parts.

How were the CAD efforts coordinated and organized? For example, were individual robot components assigned to specific sub-teams or was a single “CAD group” responsible for the entire robot’s CAD model?

Our team is comprised of multiple sub teams. One of these sub teams is the Design/Build team which is responsible for designing and building the robot. This subteam is broken down into multiple groups during the beginning of build season and each group is assigned a component of the robot to design. The lead of the design team is responsible for the integration between the components as well as the design of their part.

How did the CAD team gather information from other team members to design the robot? Would team members provide sketches that were then refined and modeled in CAD or was the CAD team presented with open-ended design problems that needed a CAD solution?

The Design/Build team, or “CAD team”, is responsible for the design of the entire robot. Some systems, such as electronics, are the responsibility of the Electrical Team, but because the design of the robot and electrical layout are intertwined, the electrical team sends a memeber over to the design team that helps them add the electrical layout to the CAD model. The programing team will sometimes give some input that affects the design, such as how difficult a mechanism will be for them to program, but other than that most of the design process is done by the D/B team.

How were the CAD models ultimately used by the team? Were the CAD models an entry point to the manufacturing process or were these models primarily used as illustrations of what needed to be fabricated and assembled?

The CAD models had two main functions. The first is that they determined how the robot would be built and how the robot is going to work. For example during the design process we used them to check for interferences, structural flaws, weight, and afterwards we use them for a reference while building the robot. We typically project the robot’s design on a screen in our shop and use it for reference whenever we need a dimension or need to remember how something is put together. The second function is to supply shapes to be cut using our water jet. We design our robot primarily out of sheet metal that is cut using our in house waterjet. the files we design are converted into DXFs that we use for computer aided cutting in order to obtain very precisely manufactured pieces.

What feedback processes were used during the modeling process?

Each of piece that is designed goes through a hierarchy of feedback. If a younger student designs a piece for, lets say the can collector, then he will give that piece to the lead designer of the can collector and that student will provide feedback on the part and possibly tell the younger student to redesign the piece or modify it in some way. Once the can collector is perceived to be finished, or to have passed some important level of completion (for example if the general design is finished even though cheesing and similar details needs to be added). Once the design reaches this point a mentor checks it over and points out any potential problems. The students will go back and try to fix these problems and then submit the design to the mentor again and again until none exist, as far as we know.

How were the CAD models shared with the entire team? For example, was a status board used to display the computer renditions of various components or was a team meeting used to show digital images of the design progression?

During the design/build phase, there is no formal presentation of what the robot looks like. During this time only those who actively worked on the robot know how it works. Afterwards, however, the design team creates a powerpoint presentation on how the robot works. This involves pictures and descriptions of all the major parts and capabilities of the robot.

Were the CAD models used as inputs for computer-based analysis, for example to estimate weight, strength and/or performance? How did the design change as a result of this analysis?

We used CAD heavily for analysis. Because we design most of the robot before manufacturing, we can use the analysis to rectify potential problems and fix them before it’s too late. For example, we constantly check the weight of our design to make sure that it is within our parameters. This helped us greatly throughout the year to make sure our parts were not overweight. One example of when this helped us is when we were deciding whether or not to powdercoat the robot. We knew that the weight of the powder coating is roughly 5 pounds. When we looked at what CAD predicted our weight to be (roughly 116lbs) we knew that powdercoating would not be an option this year.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s