Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; WPAlchemy_MetaBox has a deprecated constructor in /var/www/vhosts/epic2017.gatech.edu/httpdocs/wp-content/plugins/wp-tiles/vafpress-framework/includes/wpalchemy/MetaBox.php on line 61
Swing Optimization – EPIC Lab +

# Swing Optimization

This is the first big test for optimization. Using a virtual model that represents the prosthesis attached to a frame, I am running a stochastic search for these impedance parameters:

– a1: Knee equilibrium angle during swing flexion (normalized)

– a2: Knee equilibrium angle during swing extension (normalized)

The goal is to replicate intact swinging knee motion so that the device makes a movement that is close to the one found in typical human gait.
Hence, I made a cost function that penalizes when the trajectory is not similar to a goal trajectory.

Simulations are running in Gazebo and there is an extra cool fact: the results are sent to this website, so basically you can observe in real time how the optimization is doing. Probably when you read this, the optimization is going to be finished already so you will only observe the final results.

These are the current optimization results:

These plot shows how the cost function relates to different parameter values:

We can see that the process found that the best set of values are: a1~0.85 a2~0.21, that is angles of 68.9° and 20.9° respectively.

Without any constraints, except for the possible range of motion of the device, the simulation learned how to do a human-like swing flexion and swing extension.

#### What’s next?

This was a test to verify that the framework works, particularly if I was able to launch multiple simulations with different parameters, retrieve the results and compare them against some trajectory. These are basic steps in the optimization process.

In this case, the flexion result was coherent with our current controllers in the real device (we are using a 65° for this parameter), for the case of swing extension the result was not so similar, in our controllers we are extending the knee to 0°. The difference can be because I am fixing the final time of the simulation instead of finding the final time of extension for each simulation. That affects the time normalization of the results, penalizing solutions with smaller knee extentension angle because those take less time to reach 0.

The data extraction for this simulation could be improved to account for this. We could find the time in extension when the angle does not change anymore and define that as the final time per each simulation.

The next step is to define a walking goal function and learn how to walk!