The Velvolteen Rabbit: A Rabbit-Emulating Mechanical System

Transcription

1 The Velvolteen Rabbit: A Rabbit-Emulating Mechanical System Prepared by Cindy Au, Margaret Koehler, Sean Pacheco, Roberto Vargas Stanford ME 112: Mechanical System Design Winter 2013 Professor Christian Gerdes 1

2 Executive Summary Our objective in this project was to create a battery-driven machine that resembled a rabbit in both appearance and gait that could traverse an inclined ramp and trigger a button. Our design was motivated completely by flexibility and ease of assembly/disassembly. Our mechanical rabbit frame consisted of two panels of basswood (for lower weight than Duron) connected with bolts to 2 Duron cross pieces. The larger side panels gave us the opportunity to test different linkage designs on the same frame. In our final iteration, 4 identical four-bar linkages connected to the main frame drove the rabbit s walking motion. From initial concept, we performed analyses using MATLAB code and Working Model. We modeled several different linkage and mechanism types to assess the viability of different designs in ascending the ramp. This was an iterative process that started with testing mechanism types in Working Model and followed with specific linkage length analysis in MATLAB. Our group also generated a power analysis with MATLAB that allowed us to estimate device parameters and output a projected energy usage for our rabbit. In this way, we were able to ascertain that 4 AA batteries would allow us to traverse the ramp. Our virtual work analysis also convinced us that the gearbox and motor that we were considering (dual gearbox with 2 FA130 motors) provided enough torque to overcome our mechanism weight. While modeling was useful, building an actual prototype was essential to making our design work. First, we could not model the frictional forces between elements correctly in Working Model which resulting in slipping issues in our first prototypes. Next, we did not anticipate fastener tightening/loosening with our modeling tools, which turned out to be one of our largest issues in refining our prototype. Lastly, we were unable to anticipate the weakness of Duron in holding small axle geometry, which was critical to our power transmission in the linkages. Figure 1. The side and top-down views of our final prototype 2

3 Design Development Our team employed a top-down process in designing the gait for our mechanical rabbit. Instead of going from the analysis of one leg mechanism to thinking about the rabbit as a whole, we started our design process with brainstorming a biomimetic walking motion for our rabbit. Analyzing a slow motion video of a running rabbit on Youtube allowed us to note down two key characteristics for our desirable motion curve for each leg: a relatively flat propulsion stroke and a fast return stroke. Tracing the trajectory of the legs in the video couldn t provide us with all the information we needed for pinning down the exact leg trajectory for our mechanical rabbit, however, because the running gait of a real rabbit includes a flight phase that our team knew would be challenging to replicate. Because we were uncertain about what motion curve would work best for our rabbit, we decided that we would use the same four-bar linkage for our back legs and our front legs for ease of simulation and modification. With some preliminary ideas for what motion we would like to obtain for our coupler curve, we proceeded to using a Java applet offered at to obtain the general proportions for our four-bar linkage. Because the program features automatic tracing of the coupler curve as well as visualization of the coupler s velocity, utilizing the Java applet at this stage allowed us to iterate very quickly through different linkage configurations to note down a few promising ones for subsequent simulations in Working Model. After noting down some linkage proportions we would like to test out, we proceeded to Working Model to incorporate the leg mechanism into a full-scale rabbit. Running simulations of the rabbit s gait in this program was particularly helpful in helping us determine the geometry of our legs, brainstorm for stabilizing features for our rabbit s body, and discern potential challenges for walking up an incline. Working Model helped tremendously in finalizing the gait of our rabbit. From our initial observations of the Youtube video, we erroneously thought that the back legs and the front legs of our rabbit should be 180 degree out of phase. With the coupler curve designed such that the rabbit s leg would be on the ground approximately 50% of the time, being completely out of phase would allow the front and back legs to alternate in propelling the rabbit forward. Some preliminary simulations in Working Model proved us wrong. With the legs out of phase, our rabbit could barely walk on flat ground, let alone walking up a ramp, because the body kept vacillating up and down as each pair of legs left the ground. The simulation quickly made us aware that we needed to seriously take into account the motion of the body, as it carried most of the rabbit s weight. Constantly refining the lengths of the legs attached to our coupler link and the phase offset between the front and back legs in Working Model allowed us to come up with a model that could walk up a ramp. In this functional model, there was no phase offset between the front and back legs, and the rabbit rested its body on the surface for one part of the gait cycle. 3

4 Figure 2. Working Model simulation for the front and back legs being in phase. Another important lesson we learned from our simulations in Working Model was that friction played a significant role in allowing our rabbit to walk. With too little friction, the legs would slip on the surface, failing to propel the rabbit forward. Because our rabbit couldn t walk after we changed the surface materials in Working Model to rubber and wood, we realized that it was crucial to add a material of very high friction to the feet of our mechanical rabbit to make it walk. This insight motivated us to purchase anti-slip grit tape for our feet, a move that proved to be very valuable later on during our testing phase. Torque Analysis From Virtual Work After using Working Model to develop a linkage that would allow our rabbit to move up the ramp, we used virtual work to analyze the required torque input and select an appropriate motor. The coupler curve below shows the path of our foot during a rotation of the motor. The region in red is the portion that the foot is in contact with the ground, which is relevant for torque analysis. The rabbit rests on its belly during the other portions of the coupler curve, so the motor requires relatively little torque. Figure 3. The coupler curve. The units are not significant here, since we allowed for various scalings of our linkage lengths. 4

5 Using virtual work analysis, we calculated the required torque for a variety of conditions throughout the linkage motion. We used a frictional constant of 0.7 since Working Model indicated that a high frictional constant would be required to move the rabbit up the ramp. In our torque analysis, we could vary two things: the mass of our bunny and the linkage lengths. Based on approximate motor and battery masses, we estimated that our rabbit s mass would be approximately 0.5 kg, and our first prototype featured legs with a scaling of m/unit. In order to guarantee that our motor would be powerful enough to move our rabbit, we considered a worst case to be 1 kg and 0.03 m/unit, a much bigger rabbit overall. Further, we assumed that the linkage would need to bear the entire weight of the rabbit during the movement. The torque as a function of the input angle is plotted below. Figure 4. The torque vs. the input angle for the largest rabbit that we anticipated. The relevant regions of the torque plot are between approximately 3.5 radians and 6 radians, since this is the region where the foot is in contact with the ground. The maximum torque required for our smaller anticipated rabbit size is smaller by a factor of 4, as seen in Figure 5. 5

6 Figure 5. Torque vs. Input Angle for a smaller rabbit, only the region where the foot is in contact with the ground is plotted. From this maximum torque information, we verified that the motors we had selected would be sufficient for our needs. We chose the twin motor because it would give us more power than a single motor but would still offer easy mounting since it has a through-axle, allowing the rear legs to be attached directly to the gearbox. The speed vs. motor torque plot on the following page is for a single FA 130 motor. Figure 6. The torque vs. speed curve for one of our two motors. 6

7 Since we used twin motors, each motor needed to bear half of the maximum load. In the worst-case scenario, we needed 0.6 Nm applied to the input axle, or 0.3 Nm from each motor. Using a gear ratio of 344:1, we can obtain this load torque with a motor torque of 1.12 mnm. This would give an output angular velocity of 3.55 rad/s or 34 RPM. This would give us 17 cycles to make it up the ramp. While this would require fairly large steps, this step size is not unreasonable, and this is for a rabbit heavier than we are anticipating. Further, since this is the maximum torque, the motor will not be moving this slowly throughout the stroke, just through the peak regions. Also, for smaller rabbits, smaller gear ratios can be used, resulting in even faster leg movement. From our torque analysis, we determined that the motor we selected would be sufficiently powerful to get us up the ramp in the allotted time. Even though our analysis excluded internal friction, since the motor would suffice for a much larger rabbit than we prototyped, it would be able to handle the frictional torques. Results from testing Moving between analysis and physical testing was a very important step in our design process. We understood that not everything we saw from simulations would stand true for our final design and tried to not rely too much on simulation results to get the complete picture of how our rabbit would operate. With that said, there were a few components of our design that did perform as well in physical testing as they did during modeling. These included the motion shown by our coupler curve and the calculated amount of power needed to get up the ramp. In modeling the coupler curve, we used a few tools, including MATLAB and an online four bar linkage tool, to help us understand how our four bar linkage would move. We used both of these tools to systematically alter linkage lengths until we found a coupler curve that moved in the manner we felt would get us up the ramp sufficiently quick. During testing, we learned that our models predicted very well how our four bar linkage would move. This is most likely because modeling linkages is largely a geometric problem that can be solved fairly reliably by a computer. We were very happy with our modeling and analysis; our linkages moved in the air just as they were modeled. We used torque analysis from virtual work to determine the number of batteries and the motor type that we needed to get the rabbit up the ramp. The power calculated exceeded the power our rabbit actually needed; the rabbit had no trouble making it up the ramp. In fact, about three quarters up the ramp on our final demonstration our rabbit lost two of its batteries and was still able to make it to the top, even if a bit slower than we planned. This showed that our design is somewhat robust to power fluctuations. As we expected, not all of our models provided an accurate view of how our rabbit would operate. Specifically, while looking at our Working Model simulation of motion, we saw that neither the legs nor body moved in testing exactly how they did in our model. Our initial leg design had a small kick back in the coupler curve that in the model would move the rabbit backward slightly in the air before moving forward. In the Working Model simulation, this was not a big deal 7

8 and still allowed the rabbit to move up the ramp fairly efficiently. However, when we began to physically test this motion, we saw that the little kick back that was not a problem in our model pushed the rabbit back far enough to make it slide down the ramp. Although we were able to fix the problem by adding anti-slip grit tape to our feet and body, the model we based our initial analysis on did not stand true when it came to physical testing. Another problem we had with our Working Model simulation had to do with how quickly the rabbit moved up the ramp. We modeled both front and back legs both in phase and out of phase to see which would move us up the ramp the fastest. The model showed us that out of phase leg motions would work best because the rabbit was moving forward for longer and therefore made it up the ramp quicker. When we began to run physical tests we continued to play around with phase and found that our model did not match what we had seeing in physical testing. The out of phase motion did not give the rabbit enough leg contact with the ramp and allowed the rabbit to slide back a very small amount with each step. This made the time up the ramp slower despite the fact that our model showed it would make the rabbit move faster. Through physical testing we were able to decide that having both legs in phase would help the rabbit make it to the top in the shortest amount of time despite the fact that our model told us otherwise. There were also some challenges that we encountered during physical testing that did not appear in our analysis. These things included the effects on the rabbit from the sidewalls and the fact that our linkages were not truly as rigid as they were in our models. Running into a sidewall was never really something that showed up in our Working Model models because it was difficult to account for; we were unsure how our rabbit would interact with the wall. After physical testing, we saw that the rabbit had the tendency of running into the wall and riding along it for some portion of the ramp. This extra power needed to make it to the top was never accounted for nor was the fact that the wall could interfere with the motion of the linkages. Luckily we had designed our rabbit to have a little extra power so the wall friction was not a huge issue. Keeping freshly cut linkages on hand also seemed to get rid of any problem we had with linkages becoming worn out from running into the wall. Our linkages moved just as they were modeled in air but once on the track many factors worked to tear them apart. We didn t expect our binding posts to unscrew or tighten from our simulation results alone. This fastener problem that often caused our machine to get stuck or fall apart was largely solved with the addition of Loctite to the end of our binding post. Issues with fasteners were something that never came up in the simulations and had to be dealt with purely through physical testing. Comparing and Reconciling Results Through the usage of many analysis techniques during our design process, we were able to come to some conclusions as to what worked well and what we would leave out if we were to do this project again. First, as mentioned earlier, we used MATLAB and an online four bar linkage tool to analyze which four bar linkage that would give us the curve we felt would serve us best. These simulation tools worked very well, and would definitely be used again. 8

9 Second, we used Working Model to analyze how the legs would interact with the ramp and how far away from the ground we needed to mount our four bar linkage. Working Model was satisfactory in producing an initial design but did give us a few problems in moving between modeling and physical testing. We would definitely still use it again because it was very a useful tool to help us get a feel for what it takes to make our rabbit go up the ramp. It was a quick way to weed out bad ideas and helped to give a look into how something would move. On top of that, it helped team morale in that once we all saw something move up the ramp on the computer, we were much more convinced that we could get something to work in real life. Third, we spent a few days working with Legos. To be frank, in retrospect, this step felt like a bit of a waste of time. It was helpful in quickly showing three-dimensional motion of four bar linkages and the motors and shafts worked well for initial physical testing. But other than that, the Legos were very hard to work with and were quickly passed over after a few nights working just to get something that would fit together. Moreover, the Legos were a bit small to fit two sets of linkages on them and were not ideal for physical testing. They were a good starting point because we already had them on hand but if we were to do it again we would most likely stay away from them and move directly to Duron prototyping. Finally, this leads to the physical testing done with Duron pieces. It took some time to model and cut these pieces but once they were complete, they helped us move much more rapidly towards our final design than anything else we had worked with up to that point. Duron prototyping helped us see how all the final components such as the batteries, wiring, and drivetrain fit together. If we were to do this again we would try to move as quickly as we could to a working physical model made from Duron. In summary we would plan to keep MATLAB, the online four bar linkage tool, the Lego motors and shafts, and our Duron model while we would mostly likely stay away from trying to build a physical prototype out of Legos. 9