SERA Actuator

From DellinWiki
Jump to: navigation, search

This page is under construction. Please excuse unprofessional language, incomplete content, and the occasional animated GIF.

Things To Do:

  • Beef up the Project Management section
  • Work on Chris's OSS page (Chris)
  • Team Bios?
  • Improve formatting in the biped spec, actuator spec, interface spec, etc.
  • Get Gill's feedback
  • Remove this "Under Construction" header

Contents

Project Rationale

An overview draft of the actuator design
An overview draft of the actuator design

Why a Force-Controlled Actuator?

» For more, see Series Elastic Actuators.

We began designing a Series Differentially Compliant Actuator based on the hope of entering in the RoboCup humanoid robotic soccer competition. The state of the art in the smaller category of humanoid robots, 30 to 60 cm tall, is walking robots using pre-planned gaits and hobby servos. These robots are fairly functional and manage to move about fairly gracefully. In contrast, the 65 to 130 cm tall robots in the teen size competition have a hard time moving around at all and often fall over. We knew from our understanding of robotics that dynamic balancing algorithms using force-control could do substantially better than the current teen size robots, so we began looking at what it would take to build a dynamically-balanced teen size robot. We found that the missing piece was a high-powered series elastic actuator accessible to the hobby market, and so we made it our goal to create such an actuator.

What's In a Name

This semeseter-long project, undertaken by six students at Olin College and advised by Joe Bondaryk and Gill Pratt, has undergone several name changes as the goal was conceived and refined. Formally assiciated with the names "Gui's Baby", Robocup, Dancing Santa, and SERA (the Series Elastic Robotic Actuator), the project is currently known as the "force-controlled actuator".

The Team

The project was tackled by a team of six students at Olin College, advised by Professor Gill Pratt and mentored by Joe Bondaryk. The team met twice a week at the Olin Biomimetic Robotics Lab to do project planning, discuss the actuator's design, and develop specifications and documentation.

  • Gill Pratt, Ph.D. - Faculty Advisor
  • Joseph Bondaryk, Ph. D. - Angel Advisor
  • Matthew Aasted, ECE - Class of 2008
  • Guilherme Cavalcanti, E:Robotics - Class of 2009
  • Jeffrey DeCew, E:Robotics - Class of 2008
  • Christopher Dellin, ECE - Class of 2008
  • Kevin Sihlanick, ECE - Class of 2009
  • Jonathan Tse, ECE - Class of 2008


The OSS Connection

The premise of the project coincided well with the Olin Self-Study topics of two of the team members. What is OSS?

Christopher Dellin chose to study Impedance Control and Series Elastic Actuators. Throughout the semester, he has read several academic papers on the subject, and has also created a model of a series-elastic actuator in Simulink. For more about this OSS, see its page here.

Matthew Aasted chose to study control algorithms implemented in software and firmware. He spent the semester reading a digital control textbook Digital Control of Dynamic Systems by Gene Franklin et. al. and working on implementing control systems for the actuator using Labview.

Project Overview

During early October, the team worked to define a Project Charter that would specify the goals and parameters for the semester. While the prospect of designing and building a full biped was appealing to many members, the team decided to focus its efforts on designing and building a force-controlled actuator, with the biped driving its specifications. While a demo of the actuator was deemed important, it would not necessarily be as complex as a full biped; perhaps an arm or single joint would be sufficient to demonstrate the advantages of the actuator.

Project Management

An overview of the project's year-long schedule.
An overview of the project's year-long schedule.

» For more, see Project Management.

Early in the process, the team recogized that good project management techniques would be essential to efficiently using each member's capabilities in reaching the common goal. With the help of Joe Bondaryk, the team appointed a dedicated project manager and began the task of designing a schedule for the year ahead. The ensuing gantt chart defined deadlines for specifications and interface documents to allow the team to work on tasks in parallel. It also designated design review and fabrication deadlines to keep the team on-schedule.

Biped Spec

» For more, see Biped Spec.

Next, the team discussed the target use-case, a 3-foot-tall robotic soccer player, in order to drive the actuator specification. After much debate and a few calculations, the Biped Spec was born. The robot must be able to dynamically balance, walk at speeds of 0.25 - 0.5 m/s, and (of course) play soccer. The spec also defines several external constraints, such as cost, robustness, and self-containment.

Actuator Spec

» For more, see Actuator Spec.

The team next formulated a specification for the actuator. This document enumerated the necessary size, weight, and performance characteristics of the actuator, in order to satisfy the requirements detailed in the Biped Spec. Each actuator would be less than 0.35 kg in weight and less than 7.5 cm in length, and would generate at least 5.1 Nm of torque.

Actuator Design

After the specifications were completed, the team set out to design the mechanical, electrical, and firmware aspects of the actuator. To allow the teams to work in parallel, an Interface Specification was drafted.

Mechanical Design

The project had its roots in a set of initial ideas in the spring of 2007, and those designs were further refined during the Fall 2007 semester. What follows is a description of each of the design iterations that were developed, along with a summary of decisions made in discussion.

Spring Revision 2007

» For more, see Spring Revision 2007.

The first revision of the actuator, this design was built by Gui Cavalcanti without the aid of the rest of the team because he wanted an actuator to use on his biped. The design consisted of a spur gear coupling from the motor to a worm which was free to slide axially on a hex shaft between sets of Belleville washers. We left this design because the torque coupling between the worm and the hex shaft would quickly wear out the shaft and there were lots of stiction and backlash issues with the particular spur gears used.


Summer Revision 2007

» For more, see Summer Revision 2007.

This was a revision that Gui made over the summer on his own. Realizing the problems with his previous design, Gui decided to look at frameless motors and mismatched pairings of stators and rotors. Rather than having them the same size, he considered a design where the rotor is a size larger than the stator and therefore the motor shaft can be linearly displaced without affecting the performance of the motor. The elastic component still comes from the shaft of the motor moving around between gears but there is no need for spur gears.


Magnetic Coupling

Annotated side view of the magnetic coupling design

» For more, see Magnetic Coupling.

The magnetic coupling actuator was an iteration considered but not built by Gui in which a large magnet wrapped around the worm shaft would provide the axial spring force along the shaft instead of Belleville washers. This provided a way to remove another point of contact with the shaft and also would have allowed for sensing of magnetic field strength to determine the output torque. The idea was ultimately discarded in favor of more conventional technology because of anticipated problems with sensing and cost.


Dancing Santa

Isometric view of the Dancing Santa design

» For more, see Dancing Santa.

Due to the cost issues inherent in the Summer Revision design, the team decided to pursue an alternative approach, and designed a belt-driven actuator that uses tensioners to acheive a desired series-elastic effect. In a symetric belt system, the drive and driven pulleys are separated by two rotationally-mounted tensioners sprung by wrapped steel cable and linear tension springs. The team investigated several sensing options for this design, including potentiometers and rotary encoders.

However, prior work in this field discovered through the team's research indicated that the tensioning system was difficult to implement to both sufficiently tension the belt and act as a series-compliant device. Therefore, the team discarded the idea and looked at alternative timing-belt based designs.


Sprung Motor

Isometric view of the sprung motor design

» For more, see Sprung Motor.

Because of the difficulty with tensioning systems, the team looked at other places to put the elastic element, and so they placed it between the motor and the case. The design consists of a motor which is free to rotate about its shaft axis. The case of the motor is connected by a cable to two springs which provide the elastic element to the case in the system, while the output shaft of the motor is connected by a belt to the output shaft of the actuator. Sensing of torque and angular position would be accomplished by measuring both the angle of the output shaft and the angle of the motor via rotary encoders; after correcting for the gear ratio, the differential mode would determine how far the motor has twisted against the springs and therefore the torque on the output while the common mode would determine the angle of the output shaft.

The primary difficulty with this system is that it has the case of the motor moving with the output shaft. The motor adds inertia to the output shaft and therefore the reduces the mechanical bandwidth of the system when the elastic element is moving. Therefore, the team returned to the Belleville washer design to further explore that space.


Belleville Worm, First Iteration

Isometric view of the actuator design as fabricated

» For more, see Belleville Worm, First Iteration.

Returning to the idea developed in Gui's early prototypes, the team considered and built a design very similar to the design from Spring 2007. The motor shaft is connected to a spur gear train which in turn connects to the worm gear shaft. Rather than having the worm free to move between the washers, however, the shaft itself moves. This motion is very small, on the order of .05", due to the higher spring constant of the washers than the previous design. Sensing was designed to be done using a magnetic rotary encoder which can also sense field strength; therefore it is able to sense both the axial displacement and rotational position of the worm shaft. From these, the microcontroller is able to calculate both output torque and output shaft angle.


Belleville Worm, Second Iteration

» For more, see Belleville Worm, Second Iteration.

After sending the Belleville worm's first iteration out to fabrication, the team set about creating different variations on the design to reduce cost and improve efficiency. The team decided that it would be best to not involve a spur gear train at all, but this presented problems with the coupling between the motor and the worm shaft as it it needed to allow linear freedom of the worm shaft while conveying torque. During this design phase, the team also realized there were problems with choosing the proper bearings; bushings would be unable to handle the speed of the shaft and bearings are not designed for axial motion. Eventually, all these problems were solved by moving to a flexure design, documented in the next section, and by limiting the range of the motion to being within the axial play of the motor.


Strain Flexures

Isometric view of the flexure-based actuator design

» For more, see Strain Flexures.

The final design considered by the team but not fabricated focused on solving the problems with bushings and bearings as described in the section above. Rather than having Belleville washers and bearings hold the shaft in concert, the team moved to flexures which themselves have bearings to hold the shaft in place radially. This also provided a new opportunity for a sensor location: a strain gauge on the flexure itself, or a magnetic angle sensor and a magnet on the flexure.


Electrical Design

A draft overview of the elecrical layout.
A draft overview of the elecrical layout.

» For more, see Electrical Design.

Based upon initial weight estimates and a survey of possible electric motors, the team decided on a 14.4 Volt power system throughout the robot and as the supply for the actuator. A weight of 2 kg on the biped was budgeted for batteries, which corresponds to approximately 20 Ah of energy capacity.

In order to integrate with legacy hardware and ease the adoption of the actuator among hobbyists, support for the 50 Hz PWM standard for position and force servo control was included. However, the team wanted to also support a higher-bandwith two-way data bus for more advanced control of the actuator. In making this decision, bandwidth, electrical characteristics, and common availability were important concerns. After a heated debate, the team decided to use the Ethernet bus. The trade study, along with more details about the resulting decision, are available in the Communications Spec.

Software Design

» For more, see Software Design.

For the initial prototypes, the team used a platform from National Instruments called CompactRIO (CRIO). Though not intended for the final actuator design, it allowed the team to sidestep the issue of electrical design by using an off the shelf CRIO motor controller module and digital I/O module to connect to the sensor adapter board from Austrian Microsystems. Therefore, most of the initial actuator software design work was done in LabView written for both the Power PC and the FPGA on the CRIO, and is essentially a PID block and a lot of protocol wrapper code sitting on the FPGA to grab sensor data over a serial protocol and control the motor over PWM.

In the standalone version of the actuator, the team intended to use a PIC microcontroller in the 33F family and write the code for it in C. The PIC would be responsible for an Ethernet peripheral on its SPI bus and would serve a webpage for configuration as well as supporting RC PWM input and an API over TCP/IP.

Conclusion

Nearly at the end of the semester, the team realized that the actuator design they had arrived at was essentially a load cell well integrated with a non-series elastic actuator; all the compliance in the system had been taken out to simplify the system and in the process the actuator had ceased to be particularly interesting to the team. Certain members of the team intend to continue portions of the project in the coming semester, but the team as a whole has dissolved.

Copyright Notice

The contents of this page and all daughter pages are Copyright © 2007 Matthew Aasted, Guilherme Cavalcanti, Jeffrey DeCew, Christopher Dellin, Gill Pratt, Kevin Sihlanick, and Jon Tse.

Personal tools