Summary and Analysis for Professor Robert Wood's Article

A Summary and Analysis of Seitz’s Article on Adhesion on an Incline for Microrobots

Seitz, Benedikt F., et al,  “Bio-inspired mechanisms for inclined locomotion in a legged insect-scale robot.” Harvard Microrobotics Laboratory. Published 14 December, 2014.

The HAMR (Harvard Ambulatory Microrobot) is an insect-scale micro robot and a vehicle for further study on adhesion methods on a microscopic scale. Three different types of adhesion methods are proposed: micro-spines, electroadhesion, and dry adhesives (comparable to gecko-foot tissue). To determine which method is most conducive to locomotion on a microscopic scale, the robot must exert shearing forces (a force that pushes one component in one direction while pushing another in a different direction) and apply normal force to detach the foot. The HAMR is tasked with measuring the degree of inclines that each method can produce adequately stable forces upon when applied to the legs of the micro robot. Tests upon the HAMR using the three different foot surface technologies analyzed the ability of the HAMR to move along varying degrees of inclined and declined surfaces, and used the results to formulate an idea for future modifications of the material. The three methods proposed for the foot materials were logical, and the results were interesting because of the ranges of locomotion were so different. The study has yet to conclude the best method for movement on a microscopic scale.

The study used three types of material to cover the foot joints of the microrobot. The first material proposed was similar to a capacitor – a surface of charge that included a dielectric material. Dielectric materials increased the ability of the plate to hold charge, and therefore its addition created a stronger electric attraction between the test surface and the electroadhesive surface. The shearing force was created through the protrusion of charged electrodes. The second method investigated a gecko skin-like surface that induced Van der Waals forces between the test surface and the foot joint. In the foot, a material that had many wedges directed outward created London dispersion forces which attracted the foot to the test material. The authors experimented with three different orientations and widths of these wedges: non-directional, directional, and directional with a larger wedge width. The last method used the concept of microscopic spines to create shearing force when interacting with the test material. The micro spines were oriented at 90 degrees from the foot joint.

Preliminary testing of these methods attracted attention to the instabilities of the HAMR. Before proceeding with the tests, the authors investigated some of these problems and attempted to reduce their effects on the locomotion of the HAMR. Two major modifications were made: a “passive tail” and a five joint foot piece. The foot piece was able to increase the range of movement and self-alignment, while the passive tail reduced the rocking motion of the HAMR.

With these three methods, the means of testing the locomotion capacity of each at varying angles from the horizontal was straightforward. The HAMR was equipped with one of the methods on its foot joint and programmed to climb up and down an incline. The incline was increased (or decreased when testing downward motion) until inadequate shearing forces were produced. The maximum angle of functionality was determined by the microbot’s ability to climb the subsequent incline without slipping or becoming unable to move forward.

The major results of the study showed that the gecko-like adhesion method with wedges of larger width (100 micrometers) had the greatest angle of incline and decline at which the HAMR functioned within parameters. The micro-spine method proved to be more efficient than the electroadhesive method at both inclined and declined angles. Limitations to the both methods were discovered, and the study mentioned the inefficiency of coordination between the electrodes and the movement of the leg (electroadhesive method) and how the restricted range of leg movement reduced the micro-spine functionality.  The study revealed that the best method to test next (surpassing any singular method mentioned and tested above) is a combination of micro-spines and gecko-like surfaces. This is a logical conclusion given the presence of both structures in nature.

This study shows the potential of micro-adhesive surfaces and how they could be useful to technology. By exploring three different micro-adhesive methods, the range of results point scientists toward better methods of adhesion and suggest that a hybrid combination of two or more technologies may be ideal. It was critical that the study first involved a modification of the HAMR to reduce negative influences on the robot’s performance. The introduction of the passive tail and new foot joint decreased the rocking effect and improved the ease of foot alignment, which made implementing the three methods easier and perhaps more accurate.

The data and conclusions are in accordance with each other. The authors found that the gecko-like material (directional) was a more effective micro-adhesive than other methods. The micro-spine method also was significant in its results. The authors suggested that the presence of both materials in nature and insect and reptilian systems is an indicator that the hybridization of the two will be promising for future micro-adhesive surfaces. The data is sufficient in that both locomotion on an incline and decline are considered, and restrictions are noted (i.e. the limited range of leg motion affecting the result of the micro-spine adhesion). Future study could be improved by further experiments of similar natures. For example, these experiments feature the HAMR moving in a line up or down an inclined plane. Study of the HAMR moving in a slight transverse direction along with forward or backward movement may be beneficial in revealing the positive attributes and negative complications of the materials.

Sciborg, Day 2

In class on Tuesday (3/10), we made our sciborgs functional and ran basic programs to explore basic ranges of motion. Day 2 focused upon the sensors built into our sciborgs.

The first challenge was to run Bricktronic's "motor button" sketch and understand it. To do so, we had to attach a NXT touch sensor to our sciborg.
Here is the example sketch:

We noticed two delays. These delays contribute to the "debounce" concept. Debounce here means to double check that the button is depressed before continuing some command. There is a very small delay between checks. Otherwise, the sensor could be counting it as two or more separate presses.

We then created a program that has the sciborg run forward until the touch sensor is pressed, then backs up and turns and continues forward.


We began all components, and set the speed of motor 1 to be slightly slower than the speed of motor 2 (to counteract the tendency of the sciborg to track left). We kept the debounce part of the code.

Next, we told the speed of both motors to be the negative of their previous speeds (by multiplying by -1). This caused the sciborg to move backward for 1 second.

Next, we set the speed of motor 1 to be the same as its previous speed (multiplying by 1), which means it was still moving backward. The speed of motor 2 was set to be the negative of its previous speed (going forward by multiplying by -1). This occurs for half a second.

After, both motors turn forward. This is enabled by multiplying motor 1's speed by -1 and keeping motor 2's previous speed.

The loop then repeats.

Encoder:

We began by running the example code.

This code incorporates encoders, which count how many times the shaft rotates inside the lego motors. Information is relayed in the serial print box. X begins at 0, for no axle rotations.

The sciborg is instructed to move forward at 50 power for x, which is the variable representing the rotations of the axle. The sciborg moves forward for x<200. The encoder "get_pos," or, gets its current position after every 10ms of traveling. It prints "Now I'm at" with the current position, which is equated to the position it recorded before. It then modifies x to equal x+1, which pushes the x count to be greater than 200. This causes the next command to be true.

The next command is a while command which accounts for movement in response to x being greater than 200 but smaller than 400. When this condition is originally true, the motor moves back at the same speed (the negative of the original power). The position is then recorded every 10ms and printed. When x=x+1 is no longer in the second while loop, the motor stops.

The end value isn't zero because of the interval with which the motor checks itself. The motor may reach 0 an extremely small amount of time after a check, and then have to wait the remainder of the 10ms to check again and process to stop. This could be compounded with over rotation in the going forward command.







Touch Switch:
Our next goal was to use the touch switch sample code to light a connected LED when pressed.

Sample code:


Running this program, we noted that the LED stayed on even after the button was released. We then modified the program to turn the LED off when the button was not pressed. (See comments)



Ultrasonic Sensor:
Our final goal was to incorporate the ultrasonic sensor into our sciborg. The sensor emits high pitched sounds and measures distance from objects by recording the amount of time it takes for the emitted sound to bounce back.

Sample code:
Serial data was transmitted at 9600 baud.

A variable integer "value" is recorded by the ultrasonic sensor "kPin_ultra" through an "analogRead" command.

In serial print, the Arduino prints "Analog Reading =" and sets it equal to the value read by the sensor.

We modified the delay to be half a second so we could follow and process the data as it was coming in to the serial print box.




A sample of our readings from the ultrasonic sensor. The value increases because we began by holding a relatively inflexible sheet of plastic before the sensor and gradually moving it away. This makes sense because the value is the time it takes for the sound to bounce back and reach the sensor once more.

We must be aware that objects in the periphery of the sensor can interfere with the readings to some large degree, depending on the distance from the sensor and the angle it's at relative to the projection of the sound.

Arduino and Bricktronics, Day 3

     

Last week, we began to connect various sensors to our Arduino and learned how to modify the programs associated with them to perform certain tasks. I previewed the LED-photocell task in my last blog post. As you can see, the photocell detects the brightness of the light it is exposed to, translates it into a number, and uses the number to vary the degree of turn in the servo and the speed with which the LED light flashes. Ours processed each reading and associated 3 flashes of light per reading, the time variance between each flash being high when the reading was dim. Below is our program for this task.
   

 We began by telling the Arduino that the Servo is involved with the program by the command "include." We named four integer variables. The setup incorporated 9600 baud as the serial data relaying rate, and attached the servo to terminal 9 of the Arduino and also designated terminal 12 the output.

Our loop began by focusing on the readings by the photocell. The reading (recorded by the command "analogRead(A0)" was temporarily set at the variable "value." The serial mode prints the text "analog reading =" and then next to it the value recorded by the photocell. We then used an "if / else if" command to designate certain number readings to a type of brightness, which were then listed next to the value recorded in serial mode. For example, a value of less than 200 reads as "dark" and a value of 800 (but greater than 600) reads as "light."


Next, the loop stores variable val1, which takes the value recorded by the photocell and converts it into a 0 to 180 degree scale. "Servo.write(val1)" then uses this converted value to rotate the servo motor by that amount.

The loop then stores val2, which takes 50 seconds divided by the value measured by the photocell. We chose 50 seconds because the photocell value has a range of 0 to 1000. Therefore by division, the longest period would be at a maximum of 5 seconds. We then said "for" x=0, x<=2, and x+=1 (setting the times the LED would flash at 3 specified intervals) that the LED connected to pin 12 would go on (high) for a time period of val2 and then off (low) for a time period of val2. If "value" was low, then val2 is high, increasing the delay between flashes and causing the LED to blink slower. There was a delay of 0.5 seconds and a command to set x to zero again before repeating the loop.

The next task was to type a SOS-LED code. Instead of directly writing the code with multiple "digitalWrite" commands and "delays," we learned how functions worked.

     
We first wrote the loop, featuring three dot functions, three dash functions, and three dot functions with a 3 second delay before repeating.

We then defined the dot function by the familiar "digitalWrite" and "delay" commands, and similarly defined the dash function.

We ran the program, which used our dot and dash functions to implement the SOS code in LED light flashes.










After these final exercises with the Arduino, we were introduced to sciborgs and the Bricktronics technology.

Our first steps included the construction of our sciborg. We learned how to solder, and used the technique to complete our battery pack apparatus. We fixed our Arduino and breadboard to the wooden platform with the battery pack underneath, and installed the Bricktronics shield directly above the Arduino. We then connected the two motors underneath to the shield via NXT cables.

Our first task was to use the Single Motor Bricktronics program to see what it did.



Here, we saw the Arduino program use the NXT wire and the Bricktronics shield via the "include" command. We also saw that "Motor m" was defined through a Bricktronics port. The motor and Bricktronics shield begin, and the serial recorder shows an introductory message. The loop uses a "while" command, stating that if everything inside is "true" then the loop will continue to run. True is always true, so the loop runs continuously. As the motor rotates forward at a scaled power output of 75, "going forward" is printed in the serial box. This occurs for 1 second, then the motor increases power output to 255, the maximum, for half a second. "Going in Reverse" is printed, and the motor turns in reverse, at 75 power for a second, and increases to -255 for half a second.

Many of these commands were unnecessary in the actual function of the motor. We simplified the program:

We then used this as the basis for our Double Motor program. 

Our comments show how we added another motor and allowed them both to run in the same speeds and directions at the same time. We then attempted to determine the minimum value for speed. We tried 0, and 1, but the sciborg would not move. We found that the minimum on the wooden tabletop was 49 speed. This is due to friction, which disables movement until a threshold is reached. 

Next, we made the sciborg execute hard turns. One wheel went full in reverse while the other went fully forward. 

Next up was to make the sciborg drive as close to 10' as possible. We worked on this while also trying to make the sciborg drive straight. 

We found that the vehicle tracked to the left before making any modifications. We decided to decrease the power of the left motor so that it turned more slowly and therefore kept pace with the right motor. We set the delay at 10 seconds and then told both motors to stop. 

Arduino, Day 2

   

Our second day with our Arduino was more complex.

To begin with, we had to demo a program that functioned similarly to "Blink" but without the delay command.

Our demoed pattern:

This Arduino program featured 4 LED lights that alternated being on/off in pairs for a duration of 250 ms. The loop featured an if/else command: for a specific LED, IF it was on HIGH it would turn off, ELSE if it was on LOW it would turn on. This exercise introduced how specified periods of time can affect which subloop is run. 

Ours was a simple pattern. Other groups had more complex patterns that were fascinating to watch. We were curious to learn how they wrote their programs, as we had tried and failed to write a more interesting program ourselves. Professor Banzaert helpfully asked them to reveal what types of commands they used. We learned that commands such as && "and" and else if() were helpful tools to the other groups. We later tried to use these commands while attempting to better this Blink Without Delay program.

Sweep:

The next component of the Arduino challenge was to use Servo (a lego motor with a rotating disk included and controlled by the Sweep program. 

The baseline program:

The servo is included with the command #include <Servo.h>. We then name the Servo "myservo." We list, as an integer variable, the position, with the current position stored as a reference of 0. We attach the servo to the output terminal 9. In the loop, the first command limits the range of motion (degrees turned) by the servo's attached disk. The original was pos = 0, pos <=180; and the range was 180degrees of rotation. Here, we limited it to 90 by writing: pos = 0, pos <=90. The pos += 1; this tells the servo to increase the number of degrees turned by 1 until it gets to 90. This is all in the forward direction, clockwise. The delay affects the rate at which the servo changes. By increasing the delay to 30 from 15, we doubled the time it takes to get from 0 to 90 degrees of rotation. The next part of the loop reverses the direction, bringing the disk from 90 degrees of rotation back to 0, this time half as slow as that in the clockwise direction.

Knob:

The Knob program utilized an intermediate "knob" - a potentiometer - that controlled the rate of blinking of the LED light based on the amount of turn the knob was given. 

The Knob program:

We kept the servo active in this program. We first listed integer variables potpin = 0, val, val1, and val2. These are variables which are the results of specific functions.

The first step in the loop was to have the Arduino read the degree of rotation in the potentiometer (analotRead(potpin)) and store it as "val." As the potentiometer has a range of motion of 0 and 1023, we needed to convert the range to a smaller one, 0 and 180 by the means of scaling. The map function takes the value just stored in the 0-1023 range and converts it to a variable "val1" in the range 0-180. We then wrote another map command to link the LED to the turn of the potentiometer. We used map to convert the 0-1023 scale to a 0-2000 ms scale, and plugged in "val" to result in "val2." Now that both val1 and val2 were on the same scale, the reading from the potentiometer could regulate both the servo and the LED light at corresponding activities. The next steps with the servo takes the scaled val1 and tells the servo to turn to that position, with a delay of the standard baseline of 15 ms to get there. The LED pin in terminal 12 turns on, and delays for the scaled val2, then turns off with the scaled val2. A greater degree of turn in the potentiometer (greater val) corresponds to a greater val1 and val 2. Therefore the delay is greater. The LED light blinks slower with a greater turn in the potentiometer.

   

Looking Forward:

The challenge for our next class was to use a Lego Photocell's brightness readings to modulate the degree of turn in the servo and the frequency of the LED light. Our attempt at the program and our first test are below. 

The program worked! Our LED light blinked faster and the servo turned faster when the light was dim, and slower when the light was bright. This worked throughout a range of brightness readings consistently. There was a 2 second delay in between Photocell readings and the LED/Servo blinked/moved three times each reading as well. 

More will be said along with program analysis about this part in my next post!

Arduino, Day 1

Day 1 of our interactions with our Arduino package.

This day focused on our understanding of a breadboard and circuits in relation to the Arduino, and instructed us on two basic Arduino template programs.

The first step before connecting a circuit to the Arduino was to understand how the Arduino functioned. We first completed an assignment that would make the LED embedded in the board to blink at a specific rate.

The comments (gray text following the double backslashes "//") were key to our understanding of the commands we needed to accomplish our task.

"pinMode(13, OUTPUT);" designates the output of electricity at an outlet, specifically outlet 13.
In our loop, the "digitalWrite(13, HIGH);" causes the LED light at outlet 13 to be fully on, level "high." The next step causes the light to turn off, thus being at a "low" state.

The result was a steady blinking of the LED light with the smallest of pauses, but these pauses of "low" levels were so small that our eyes couldn't detect the LED going off.

--

After we learned about the connections of breadboards and the proper way to hook up the Arduino to the resistors (through intermediate cables), we began to look at a very basic program called "Blink."

Blink:

Here, the template is shown. Basically, the Blink program designates terminal 13 as the output and turns on the LED high for 1 second (the program is written for milliseconds, so 1s = 1000ms). Then it turns the LED off (low) for 1s. This template showed us what the command "delay" does. Delay holds the preceding command for the specified amount of time listed.

Here is our first modification of the Blink program template. We had the LED go on for 2 seconds, off for half a second, on for half a second, and off for two seconds. To do so, we modified the loop to turn the LED on twice and off twice, alternately. We varied the delay value to adjust the intermittence.








The video of our modified Blink program

We were then assigned to create a Blink program for two LED indicator lights.

We built a circuit using terminal 12 as the other output. The connected LED light responded to the commands pertaining to "12." We utilized the delay command to alter the period between the LEDS turning on and off. This modification had the 13 LED turn on for 2 seconds then off, while the 12 LED came on for half a second. Then they were both off for half a second. They both turned on together for one second, then off for one second.








Our next challenge was to create a "cool pattern" using the Blink program and 4 red LED lights. We designated terminals 12, 8, 7, and 4 as outputs, then used the delay command to stagger the switching on/off of each individual/pair of lights. Ours is shown below.

Lego Racer, Post #2

            Our final design featured a 13.9:1 gear ratio, using a slanted car bed to hold the 1 kilogram weight. Given the wheels that were available, we picked two of medium diameters and another that raised the car bed to angle it down towards the front. We believed that the angle would help the acceleration of the car – instead of the weight being positioned flat and parallel to the ground, the weight was raised and slanted. This created parallel and perpendicular components of the weight which reduced the force on the car bed and contributed to the net force pointing forward. This increase in force in the forward direction would allow the car to accelerate faster. We attempted to balance the gears to balance the entire car – three on the right, some in the middle, and a few on the right. We positioned the wheels as close to the car bed as possible, to reduce the bend in the axle which contributes to friction.

           

            The gear ratio was integral to producing a car that was able to move and the speed at which it moved at. Ours featured a 13.9:1 final gear ratio, with the use of 3 8-tooth, 2 24-tooth, and 3 40-tooth gears. We calculated our gear ratio by comparing the number of times a gear turned to however many times the following gear turned as a result.

(3/1)(5/3)(5/1)(1/3)(5/3) = 125:9

The first two ratios were intended to translate a fast speed to a torque for the 40-tooth gear through an intermediate 24-tooth gear for a better performance (the 5:1 ratio alone had been skipping some of the 40-tooth gear’s teeth). We then aimed to increase the torque by increasing the ratio, but not as much as in our third iteration (41.6:1) and not below our second (8.33:1). This resulted in our 13.9:1 gear ratio and a car that traveled 4 m in 18 seconds.

IMPROVEMENTS

            If we had more time, we would have improved our gear ratio. We began with a low ratio, which didn’t work, then jumped to a higher ratio, which worked at a slow speed. We then attempted a ratio between the two points, which worked, and at a greater speed. Had we more time, we would have tried to increase the ratio a little more to explore the effects the change causes. By observing others’ cars and results, we would aim to create our own version of a car with a gear ratio of approximately 20:1 (averaging 9 seconds). We would have liked to create a gear box with individual ratios of:

(3/1)(5/3)(5/2)(3/2) = 18.8

We would have configured the gear train to look like the following:

We would also try to address the balance of the car and the friction, both of which would have sped the car up by a slight amount. We would liked to have decreased the length of our car and used the bigger tires many other groups had taken.

Lego Racer, Post #1

For our lego car, we began by experimenting with how gear ratios functioned and influenced the relationship of speed and torque.

We started by connecting gears and seeing how they worked – or didn’t work. We became aware of the direction of spin and the impact of friction created by the gears. We also calculated gear ratios and discovered when one or more gears were nullifying the effect of others and thus just taking up space and creating more friction.

Once we began to understand how gear ratios worked and the tradeoff between speed and torque, we created our first model.

We started off with a box configuration – two stacks of legos through which gears could be suspended by axles. Driving our gear train was an old lego motor – one with low torque but high speed. This influenced us to choose an 8-tooth gear as the input gear. Knowing that we had to move upwards along the torque/speed curve, we then attempted to increase torque. To increase torque, we needed a higher gear ratio. We then connected a 40-tooth gear (ratio 5:1) to increase torque, reducing speed. We then began to add gears, increasing torque. However, the final gears decreased torque and increased speed in the hopes that the wheels might turn faster with the already increased torque. Our gear ratio was as follows:

(5/1)(5/1)(3/1)(1/3) = 25:1. This means that for every 25 turns of the input gear, the output shaft – where we attached the wheels – turned once.

We then attached two wheels in the front to the output shaft, and a third at the opposite end of the car for stabilization purposes. We placed the motor at the back and created a flat platform across the gear box to support the 1 kilogram weight. At the front of the platform was a vertical support to keep the weight from falling forward off the vehicle.

The car moved well enough without the weight, but ultimately did not create enough torque to move the vehicle. We also had overlooked the effect of the 8-16-8 gear combination, which effectively nullified any advancements and only increased friction.

We then experimented with many different gear ratios to find one that produced the fastest car.

Our second iteration involved a 25/3 gear ratio. We had concluded from our first prototype that putting the input 8-tooth gear before the 40-tooth gear was not desirable. From our test, we found that the 8-tooth gear would occasionally skip over some of the 40-tooth gear’s teeth and decrease the whole gear train’s performance. We then decided to place an intermediate gear between the 8 and 40 teeth gears. We put a 24-tooth gear in between with the intention of slowly translating the large speed of the motor and 8-tooth gear to torque of the 40-tooth gear. Our gear ratio was as such:

(3/1)(5/3)(5/3)(3/1)(5/3)(1/5) = 8.33:1

    

With the weight on it, this iteration did not move, and you could hear the motor stalling. We then concluded that this model did not have enough torque to move forward.

Our third iteration was the first one that worked. The gear ratio was very high, 41.6:1. As a result, this model moved forward at a slow rate with little acceleration. The average time it took to complete the 4-meter course was approximately 30 seconds.  The breakdown of our gear ratio shows:

(3/1)(5/3)(5/3)(1/1)(3/1)(5/3) = 125:3

We added a 1/1 gear ratio between two 8-tooth gears to reverse direction of the axle rotation.

Our fourth prototype featured a gear ratio of 13.9. As 8.3 was too low and 41.6 was high enough for it to work, we decided to find a ratio in between the two,  especially underneath 25:1 (from our first model). We got this model to work, and it crossed the finish line in 18 seconds. Our gear ratio:

(3/1)(5/3)(5/1)(1/3)(5/3) = 125:9

Pictures of #4:

We tested this Lego car on the floor:

When we decided to test our car, we needed to make some adjustments which delayed our performance time. We ran our lego car at the end of class, which performed its job in under 20 seconds. However, we forgot to record the racer on the 4m course. I went back on Saturday to recreate our lego car. I rebuilt the car so that everything was the same – except for the gear-driven wheels. The wheels we had used during the race were not available, so I thought it would be a good opportunity to see how wheels of bigger diameter would affect the car. We had hoped to use wheels of a bigger diameter in our actual car, but they all had been in use by other teams.

The rebuilt lego car in action on the course (with the bigger wheels)

The lego car moved noticeably faster with larger wheels, as we had predicted.