Sunday, March 15, 2015

Lecture Alternate Assignment

Summary and critique of the article by Professor Wood and his colleagues
Seitz, Benedikt F., et al,  “Bio-inspired mechanisms for inclined locomotion in a legged insect-scale robot.” Harvard Microrobotics Laboratory. 14 December, 2014.

The development of insect-scale robots has made a lot of progress in flat surface movements. However, locomotion of the insect-scale robots on slanted surfaces has not been as successful. This paper explores the use of different adhesion and alignment mechanisms on the Harvard Ambulatory Microrobot (HAMR), the model insect-scale robot for this experiment. The legs of the robot must exert enough peak and normal forces on the surface to prevent slipping. Therefore, the different adhesion methods must be tested for a degree of stability.

The components to of the HAMR were carefully analyzed and tested to ensure the best performance of the robot. The design of the actuator of the HAMR was selected after testing different thicknesses of the various actuators. The 2-ply actuator was determined to have the best mechanical advantage. Also the transmission performance of the legs of the HAMR was tested. The locomotion of the legs was then analyzed; it was found that the motion of the legs as they took steps was not ideal for climbing inclined planes, as the robot rocked back and forth on the legs that were in contact with the ground as the other legs were moving. In order to compensate for this unwanted motion, a passive tail was added to the HAMR so that its motion would be more stable.

There were three types of adhesion methods that were tested: electroadhesion, micro-spine adhesion, and gecko-like dry adhesion. The HAMR’s performance using these adhesion methods was recorded.

In testing the three methods, the HAMR was programmed to simulate walking on a flat surface. The peak shear force (x-direction) and peak normal force (z-direction) were recorded for each adhesion method. The directional gecko adhesive resulted in the highest average shear force, while the electro-adhesive material resulted in the highest average normal force.

Then, the adhesion methods were tested in a climbing test. Each adhesive was tested for the maximum incline and decline angle for which slipping would not occur. The gecko dry adhesive, h = 100um, resulted in the greatest angle for incline and decline – 22 and 45 degrees, respectively.          

The paper presents an exploration of ways to design locomotion on inclined planes for insect-scale robots. By comparing the performances of the three adhesion methods, the experiment clearly showed why one was more effective than the other. The data and conclusions agree with each other – the gecko dry adhesive had the largest maximum angle without slipping. The data and conclusions address the limitations of certain aspects of the experiment, as well. The micro-spine feet have a limited trajectory, and thus the trajectory must be adjusted to create an adhesive force. This acknowledgement is thorough and provides room for improvement in future experiments. Also, the analysis of the original HAMR and corrections to its mechanics, such as adding the tail, was very important to the overall experiment.


Possible future experiments include using a combination of different adhesives to achieve maximum attachment to inclined surfaces. I would also suggest that future experiments include the same peak/normal force test and climbing test, but with slightly different specifics – for example, alter the h value for the gecko dry adhesive. I found it very interesting and helpful to see an example of hybrid adhesion systems in nature – the Oecophylla smaragdina ant’s foot. This shows that the idea of the insect-scale robot’s hybrid adhesion systems is modeled after something found in the natural world.

Sunday, March 8, 2015

Ardunio Day 2

On our second day of programming with the Arduino Uno, we started off by attaching a Servos motor to the Arduino board. The example program used to control the motor was called Sweep. The circular plate on the motor rotates from 0 to 180 degrees at different speeds, depending on the program. 

The program starts off by indicating that the servo is being used, and that it is named "my servo". Its initial position is at 0 degrees, and it is connected to pin 9. 

Then, a loop is created so that the motor rotates from 0 to 180 degrees, and then back. The speed of the rotation can be controlled by specifying by how large of a step should be taken during the rotation. For example, with the code pos +=2, it will rotate at twice the speed with pos +=1.

The delay(15) is needed to give the motor enough time to reach the desired position.




Next, we attached a potentiometer and an LED light to the Arduino board. The LED was defined as ledPin as an output at pin 7, with an initial setting of LOW -- or off. The potentiometer was attached at A0. 

The goal was to have the blink rate of the LED to depend on the position of the potentiometer. In the loop, the integer val was defined as the analog reading of the potentiometer, whose values go from 0 to 1023. The range of values was scales to 0 to 180. 

The light was turned on and off by digitalWrite. We set the delay of the LED to be val, so that as the potentiometer was turned from 0 to 180, the light would blink more quickly. 


In the Knob program, the servos did not do anything -- we only kept it there because it had been used in the previous program.

The next project involves using Arduino with a photocell. Look forward to posting about that!

Arduino Day 1

This week, we started to work with Arduino, a program on which we can write codes to control an Arduino board with various inputs and outputs. 

First, we started with a small light as the output, on pin 13 of the Arduino board. 

The example program "Blink" programs the light to blink on and off at regular intervals. We modified the code so that there is no delay between the light turning on and off. We did this by adjusting the number of milliseconds that the program delays for -- from 1000 to 0.


This caused the light to blink on and off so quickly that to us, it just seemed like it was constantly on -- as our eyes cannot pick up something with that high of a frequency.

The next step was to create a pattern with the blinking light. We did this by adjusting the two delay intervals: we made the delay for 2000ms and the second delay for 500ms, so that the light would turn on for 2 secs and off for 0.5 secs. 

Then, we added an LED light on pin 12. We had to define the second light as an output, using digitalWrite, as shown below. And, we added the code for the pin 12 LED to blink into the loop. This time, the delay for turning off the lights was only 100ms, so the lights stayed on longer than they stayed off.


Following that, we added 3 more LED lights to pins 8, 7 and 4. The  3 pins were defined as outputs and the code from the previous program was repeated for the 3 new outputs. With this code, the 4 lights blinked one by one. 



Another example program, "BlinkWithoutDelay", allows for the board to control multiple outputs at the same time without having to use the 'delay' command after every action. With fewer lines in the code, the program takes up less memory. 

Our objective was to control the 4 LED lights from the previous code, but this time using "BlinkWithoutDelay" instead of "Blink". 



First, we defined the 4 LEDs as pins 12, 8, 7, and 4, and the starting position for all of them as LOW -- or off. 
Then we set the interval  for the LED blinking at 100ms and set the 4 digital pins as the outputs.



We then programmed the pins into a loop. Each ledPin was defined as its corresponding ledState. The loop consisted of an if statement, followed by a series of else if statements, and ending with an else statement. If the first condition was true, a certain action happened. If not, the program would check to see if the second condition was true and decide whether or not to take that specified action. And, if the second condition was not true, then the program would jump to the third, and so on, until the program reached the last else statement.





Jumping right into Arduino programming was very difficult, but it is the kind of skill that is learned through experience. I noticed two importance technical aspects that we need to be careful on: one, is that the number of brackets matter - if the number of open and closed brackets don't match, the program will not compile; and two, the semi colons after each line of the commands is very important. 




Sunday, March 1, 2015

Lego Racer

This week, our challenge was to build a Lego Car that can carry a 1.0kg weight across a distance of 4.0m. The supplies were a gray Lego motor without internal gearing, and many, many Legos. 

We knew that the motor has high speed and low torque. As a result, we attempted to use gear reduction to reduce the speed of the motor so that the output of the motor would provide the wheels of the Lego Car enough torque to move. 

The above graph shows that speed and torque are inversely related. We wanted to reduce the gears enough so that the output gear reached the midpoint of the graph -- where the speed and torque are both maximized. 

We used two Lego beams as the basic structure of the car. The motor was attached to one end of the beams, and the gear train and main wheels in the middle section of the beams. The last gear of the gear train was put on the same axle as the wheels. A platform was built behind the gears to hold the 1.0kg mass and the Picocricket.



At the back of the platform, we added a small wheel to support the car. We chose to use only one back wheel, a small one, because it was not attached to any gears and we wanted to minimize the mass of the entire car. 

In our first iteration of the car, we attached a 16 tooth gear to the motor, which was meshed with a 40 tooth gear. An 8 tooth gear was put on the same axle as the 40 tooth gear, and was meshed with a 24 tooth gear. Then another 8 tooth gear was put on the same axle as the 24, and meshed with another 40 tooth gear. This last 40 tooth gear was attached to the wheels of car, therefore acting as the output of the system.


The overall gear ratio for this system was 37.5:1, meaning that for every 37.5 rotations that the gear attached to the motor (16T) makes, the output gear (40T) makes one rotation.

The gear ratio is calculated by dividing the number of teeth of the output gear by the number of teeth of the input gear. 

For example, if a 16T gear is the the input gear, and a 40T is the output gear, then the gear ratio is 
40/16 => 2.5 => 2.5:1. 

The gear ratio of each pair of gears is then multiplied together.
So for our gear train, 
(40/16)x(24/8)x(40/8) 
= 2.5x3x5 
= 37.5 
=> 37.5:1

This system of gears was built into the structure of the lego car, as depicted.


The motor is the input and the output gear is attached to two large wheels. We chose to use the wheels with a larger diameter so that with every rotation of the output gear, the car car travels a longer distance.

Many bushings were used to secure the gears and wheels on the axles. We found that at first the car did not go in a straight path. We realized that the two large wheels were different distances from the center of the car, and therefore the car curved to one side. The problem was fixed and the car went straight this time.

The car was fully functional and took 13.6 seconds to travel the 4.0m. We decided to try different gear ratios to try to increase the speed. We tried the following three other gear combinations:




Because we wanted the car to go faster, we did not reduce the gears as much as we originally did. Our three different gear ratios were 15:1, 22.5:1, and 25:1. We tested each of the gear reduction systems. The times taken to travel the 4.0m for each version were 10.8s, 9.03s, and 10.2s, respectively. 

The system of gears that gave a gear ratio of 22.5:1 was chosen in the end, as it gave the car the highest speed. We used one 16T gear, one 40T, two 8T and two 24T gears. Therefore,
(40/16)x(24/8)x(24/8) 
= 22.5 
=> 22.5 : 1

In class, our car took 8.92 seconds to complete the race!


My partner and I were very pleased with our results. (I originally was working with Sophia, but then partnered with Sarah when Sophia and Sarah's original partner left the class.) Working with the Legos was very fun. However, with the small pieces of Lego, like the bushings, attaching and taking apart pieces of the racer would sometimes be difficult. We had to be very careful about firmly attaching the pieces together so that the car would not break. Also, we had to be sure that the pieces were properly aligned and fitted, as any poor fittings could lead to the racer to breaking or to traveling in a curved path or to not going at all. The gears were especially tricky to align, as the space between the two bars that provide the car's structure is very small. 

Given more time, I would test more different gear ratios to maximize the speed and torque of the output gear. The difficult part with the Lego gears is that some gears, like the 16T, don't mesh with other gears when the axle is inserted into the Lego beam, as the Lego beam has evenly spaced holes for the axles. In order to use those gears, the axle would need to be inserted in between two of the holes. Also, we tried to minimize the mass of the car by removing unnecessary pieces. However, with more time, it may have been possible to reduce the mass even more.