C.5) Methods and Setup: Dalton Banks, Matthew Hale

Revised Problem Statement and Hypothesis

C.5.1) Restatement of Original Problem and Hypothesis

With robots beginning to see use outside of laboratories and in real-world environments, it is natural to compare the capabilities of robots in such environments to the capabilities of animals indigenous to them. Science has shown that over millions of years, successive generations of animals indigenous to a particular habitat wild have evolved to meet the challenges they face within that habitat. One such challenge faced by animals that is particularly relevant to robotics is locomotion. Evolution has designed animals which excel at tasks related to their survival, such as finding food and water, and which do so while overcoming the often strenuous requirements of navigating and exploring their surroundings. While robots are obviously free from needing food or water, they face the same locomotive challenges faced by animals. Robots, like animals, seek to move as stably as possible so that they can navigate the terrain in their environment without becoming stuck, flipping over, or otherwise being involuntarily stopped. In addition, in both animals and robots there is virtually always a need to be as efficient as possible because both have limited on-board resources and should therefore seek to maximize the utility of these resources. Locomotion, therefore, should ideally be both stable and efficient.

In fact, research into animal locomotion suggests that transitions between the various gaits which may be used on a given terrain are made in order to maintain efficient locomotion as an animal changes speed 1. Energetic efficiency then is not simply a constraint on locomotion, but is in fact the driving force behind changes in biological locomotive patterns. The problem which we wish to address is to transition stably between optimized gaits in a robot as the robot changes speeds. More specifically, as the user commands the robot to change speeds (which the user does by commanding different numbers of strides per second of the legs), we want to change to not only to a new speed, but also change to a completely new gait (in this context, we regard gaits as being different if their gait parameters are different), and we want to attempt to do so stably. To isolate the variable of stability, we will examine gaits over a homogeneous surface so that any instability can certainly be attributed to our method of changing gaits and not to the terrain.

The ability to use different gaits for different speeds is valuable in that it allows the robot to waste minimal energy while locomoting and thus operate for longer off of a given battery charge. This is true because being able to change the robot's entire gait as the speed of the robot is changed enables the robot to conform its gait at each speed to the task of minimizing the energy required to use that gait. In order to take full advantage of such efficiency across a whole family of gaits in a real-world task, there must be stable gait transitions between such gaits so that transitions can be made among them without having to stop the robot's present task to change gaits. Thus, the value of our project is that it enables the user to move efficiently while having a broad range of robot speeds at his or her disposal which can be adjusted without taking time specifically to make such adjustments.

C.5.2) Revisions Resulting from Lab/Course Experience

We have some firsthand experience from the class itself with the potential inefficiencies and problems associated with transitioning gaits. The lectures were generally on topics that were not directly related to gait transitions, though we did have some relevant experiences while working on the laboratory assignments. In trying to tune our own walking gaits and testing different sets of parameters, we saw that when the robot changed from one set of Buehler clock parameters to another (by our definition, this means that the robot changed from one distinct gait to another), it often hit its body on the ground or else was less stable during the transition than it was while walking normally. We found that this occurred frequently as we changed gaits and that the robot hit its body on the ground even when gait parameters were changed only slightly.

The lab exercises have also helped us understand the Junior architecture and the role that the Buehler clock plays in generating locomotion. In tuning our own parameters, we also saw that some Buehler clocks produced much better locomotion than others did. In particular, we saw that increasing the leg frequency paramter, s, did not always result in faster locomotion. In some cases, it only caused the robot to bounce more, meaning that it was much less efficient as energy was wasted moving the robot up and down rather than forward or backward. Our use of Junior so far has shown us that maintaining stability while changing gaits is decidedly not a trivial task and that there exist many gaits for the Junior robot which are extremely inefficient. These laboratory experiences have motivated our desire to change between efficient gaits without sacrificing stability.

C.5.3) Scientific, Mathematical or Statistical Methods

Perhaps the most important thing we have learned about from our literature search is the Nelder-Mead algorithm, a non-linear optimization method. This algorithm starts with a simplex in the space of the inputs to the function being optimized. Then, it calculates the cost associated with the set of inputs at two adjacent vertices on this simplex. The algorithm then determines which of these points has a higher cost and reflects it through the centroid of the simplex and then continues this process, effectively performing a high-dimensional gradient descent.

There are more complex extensions of this algorithm and other variations, though we have a general understanding of the broad goal of the Nelder-Mead algorithm. From the robotics literature, we have learned that this algorithm is very effective at generating efficient gaits on a RHex-like robot. We will attempt to replicate the success had by Weingarten04 when we conduct our experiments. There exist freely-available code implementations of the Nelder-Mead algorithm online, so we need not generate our own. In addition, the Dynamism interface with the robot provides us with the ability to send Buehler clock parameters to the robot. The bulk of our coding work will come in interfacing the Nelder-Mead algorithm with Dynamism commands so that we can try gaits as the Nelder-Mead algorithm outputs them and report the cost back to the algorithm. If we need further information about the Nelder-Mead algorithm, we can read the original paper by J. Nelder and R. Mead, "A simplex method for function minimization." In addition, Professor Koditschek was an author of [2], meaning that he likely has valuable insight into implementing this algorithm on RHex-like robots.

The cost function used here will be the same one used in [2], which is a quantity called specific resistance. We have learned from the research literature that specific resistance was formulated as a means of determining the cost of locomotion independent of the style of locomotion (i.e., legged, wheeled, or otherwise) and independent of the weight of the moving body. Specific resistance is defined as S.R. = P/(m*g*v), where P is the power required to locomote, m is the mass of the robot, g is the acceleration of gravity, and v is the velocity of the moving body. If we feel that we need to know more about specific resistance, we can consult the original paper on the subject, "What cost speed?" by Gabrielli et al. Again, Professor Koditschek likely has valuable insight into optimizing robot locomotion for specific resistance as he is an author of the paper whose work we are trying to replicate for this portion of our project.

While specific resistance is easily calculated, we will need to measure the different values needed to calculate it. There exists a Dynamism interface for making voltage and current measurements, meaning that finding the total power used by the robot will be very simple as it can be found just from these current and voltage values. We must also measure the mass of the robot we are using, though this will be a one-time measurement which is easily accomplished with any reliable scale. The only other measurement we need is, as stated above, the robot's velocity. In the [2] paper, a series of markers was used so that the robot could visually identify its location and thus verify that it had traveled the appropriate fixed distance. Now, the KodLab uses a Vicon motion capture system when preforming Nelder-Mead gait optimizations. The GRASP laboratory owns two such systems, meaning that the same equipment currently used in Professor Koditschek's lab is available to us as well. If we cannot access either Vicon system due to time constraints, we can also use GPS tracking. The KodLab has a GPS interface for the various robots its members use, meaning that we have an alternative method to track changes in robot position and, by timing such position changes, to track robot velocities. We prefer to use the Vicon system as it is indoors and will afford us the most homogeneous surface on which to conduct this experiment, though time using the Vicon systems is valuable and very sought-after, meaning that we may not have enough time to conduct this experiment on either Vicon system and may end up using the GPS interface.

Experimental Methods

C.5.4) Details of Setup

For this experiment, we will need a RHex-like machine that supports the Dynamism software package so that we can easily send commands to the robot in the form of frequently-changing Buehler clock parameters. We will also need an OCU configured to operate robots using Dynamism; each of us has a laptop configured for this purpose because we have needed it in the class laboratory assignments so far, so this requirement is essentially fulfilled. We will also need some external means of measuring the robot's velocity. We cannot directly command the robot's velocity using a Buehler clock, meaning that we must measure it as we have know way of knowing based on the commands we send to the robot. As mentioned above, in [2], this was done using a motion capture system. Again, the GRASP lab has two Vicon motion capture systems, but Because these systems are in high demand, we may not be able to use them for this project. If this is the case, we can alternatively use the GPS interface already used by the KodLab. This will just as accurately enable us to track changes in the robot's position and thus measure the velocity. With the robot's velocity and with voltage and current readings available through the Dynamism interface, we can calculate Specific Resistance (SR), which is our cost function for the optimizations we will be running. The means for optimization will be the Nelder-Mead descent algorithm. We will need a code implementation of the Nelder-Mead algorithm for this assignment; as this algorithm is very complicated, we will likely use an existing, open-source implementation from the internet. Our primary coding task will be to adapt the Nelder-Mead algorithm we find to use the Buehler clock parameters of the robot as its inputs and to use specific resistance as the function it will be minimizing. It is difficult to divide this coding task because we will be editing the same pieces of code. Therefore, we will work on the coding portion of this assignment together.

C.5.5) Sources of Means

The experimental setup required for our project is fairly simple and does not require very much beyond what we use in class laboratory assignments. The KodLab presently has available enough RHex robots that using one for the duration of our final project should not be a problem, though this robot will likely be used by other when we are not using it. There are a few different types of RHex-like robots used in the KodLab, though they all rely on the same electrical architecture and software, meaning that our code should run equally well on all of them, though some small modifications may need to be made to accommodate the differences between platforms. The Nelder-Mead implementation we will use will be taken from the Internet. We will not simply treat this as a black box, but rather will attempt understand it as well as possible (to the extent possible within the allotted time), though we will use an existing implementation rather than attempt to generate our own. For velocity measurements, we will either use the existing Vicon setup in the GRASP Lab, or else use the KodLab's existing GPS interface. We would prefer to use the Vicon setup as that is very similar to what was used in [2], though naturally any velocity measurement will work. We will command the robot by using our own laptops as OCUs. Thus there should not be any monetary cost associated with our project because every element of our experimental setup is freely available.

C.5.6) Operational Plan

We will largely automate the experimental procedure for this lab, with the Nelder-Mead algorithm running the robot based upon its inputs and outputs and running until it converges to a particular value. This means that while out experimental procedure will certainly be time-consuming, it will not necessarily effort-intensive. However, we want to optimize gaits for leg frequency values from 0.7 Hz to 4.0 Hz (with 0.3 Hz steps in between, i.e., 0.7 Hz, 1.0 Hz, 1.3 Hz, etc.), meaning that there will be a lot of experimentation. Our timetable for the experimental portion of this assignment is thus:
3/23 - 4/4: During this time, we will find a suitable Nelder-Mead algorithm implementation (and verify the reliability of its source). We will also finish the coding portion of our project during this time, meaning that we will prepare the interface between our selected Nelder-Mead implementation and the Dynamism commands being sent to the robot. During this time period, we will correspond over e-mail to discuss Nelder-Mead implementations that we find independently. In addition, we will use class time to work together to code the interface between the Nelder-Mead implementation of our choice and Dynamism. Ideally, we could finish this coding task during class time, though because writing this code will likely take more than the time allotted in the lab sessions, we will set up meetings outside of class during this time as they are needed. On 4/4, we will have a self-imposed deadline of having everything ready to begin conducting experiments. We will meet on this date to discuss our preparedness, though because we will have been working together up until that point, we should have a good sense of our own progress prior to that date. Matthew Hale will be in London during a large part of this time, though because the tasks we have assigned ourselves during this period are robot-independent and do not require meeting in person, we should still be able to accomplish them.
4/4 - 4/12:
4/4: Optimize gaits for leg frequencies of 0.7 Hz and 1.0 Hz.
4/5: Optimize gaits for leg frequencies of 1.3 Hz and 1.6 Hz.
4/6: Optimize gaits for leg frequencies of 1.9 Hz and 2.2 Hz.
4/7: Optimize gaits for leg frequencies of 2.5 Hz and 2.8 Hz.
4/8: Optimize gaits for leg frequencies of 3.1 Hz and 3.4 Hz.
4/9: Optimize gaits for leg frequencies of 3.7 Hz and 4.0 Hz.
4/10 - 4/12: Review our data. Conduct repeat trials if necessary.

During this time we will actually conduct our experiments. The details of these experiments have been clearly laid out above. We will start with the robot's legs moving at 0.7 Hz and optimize gaits with 0.3 Hz increases in leg frequencies until we reach 4.0 Hz. At this point, we should have 12 different optimized gaits, with one at each speed. We will attempt to do at least two optimizations each day during this period meaning that, in the worst case, we will have 3 days to redo any trials if we feel our first data set is somehow anomalous or if we feel that doing so is otherwise valuable.

Data Analysis

C.5.7) Resulting Data Base

The resulting data base we compile will be a set of text files. Each text file will represent one experiment in which we fixed a number of strides per second of the robot's legs and then ran the Nelder-Mead optimization. Each text file will contain not only the energy-efficient gait that the optimizer converged to, but also each gait that was used during the optimization process. This is valuable in that it will show us the path that was traversed by the optimizer, meaning that we can track the path of convergence for successive trials and, time permitting, examine the effects of starting simplices upon the final result of each trial. These text files will be stored in a folder in Dropbox to which we will both have access. This means that any file that is added to or changes to any file in this folder will be updated in real-time on all of the hard drives of both partners, meaning that every working copy of all of these text files will be in sync. This will allow us to keep up with each other's progress on any particular part of our project without having to constantly work together in person.

C.5.8) Data Processing

Our data processing will be carried out in two steps. First, we will perform an interpolation on the gaits that the optimizer converged to for each speed; this is necessary because we will be optimizing gaits only for a particular set of speeds. These optimizations effectively form a discrete sampling of the robot's gaitspace, meaning that an interpolation can give us a continuous path through gaitspace along these discrete samples. This will give us a family of gaits that is optimal with regard to specific resistance and will enable us to have an optimal gait for any speed that we want. These data, like the data from individual trials we run, will be stored on Dropbox.

After performing the aforementioned interpolation, we will make transitions between these gaits while running the robot on the same homogeneous terrain that these gaits were tuned on. The data we gather will be very simple; we are defining "stable" to mean that the robot's body does not hit the ground. Thus, we will transition between the interpolated gaits and record whether (and when) the robot hit its body on the ground to identify the points of failure of our method and potentially locate a discontinuity in gaitspace as we discussed in C.3 and C.4.

C.5.9) Operational Plan

4/12: We will perform the interpolation of our data today. This will realistically only take a single day, as the interpolation will be done in MATLAB and will require us only to run a built-in MATLAB function.
4/13 - 4/15: On these days we will test transitions between our interpolated gaits for stability. We will require only three days to do this because transitioning between our gaits is very simple, and gathering our data requires only that we check to see if the robot hits its body on the ground. We will allot three days for this as we would like to conduct many trials to extensively verify the efficacy of the gaits and gait transitions we formulate. After these dates, we will begin preparing our final presentation and are leaving ourselves 6 days to do so.

Bibliography
1. Wickler SJ, Hoyt DF, Cogger EA, Myers G., "The energetics of the trot-gallop transition", Journal of Experimental Biology, May 2003
2. Joel D. Weingarten, Gabriel A. D. Lopes, Martin Buehler, Richard E. Groff, Daniel E. Koditschek,
"Automated Gait Adaptation for Legged Robots", IEEE International Conference on Robotics Automation (ICRA), April 2004