Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P15201

TIGERBOT V: FULL SCALE HUMANOID PLATFORM

Chris CrippenElectrical Engineering

David ExtonMechanical Engineering

Vasu GuptaComputer Engineering

Ben HaagElectrical Engineering

Wunna KyawMechanical Engineering

Matthew MaresMechanical Engineering

Vincent PanElectrical Engineering

Jordan SkiffElectrical Engineering

Matthew WarnerComputer Engineering

AbstractThe objective of this Senior Design project is to design and build a full-scale humanoid robot capable of many feats, such as walking and responding to voice commands. TigerBot V is the fifth iteration of RIT’s humanoid robot series, designed and developed by RIT senior design projects consisting of multidisciplinary engineering student teams including mechanical, industrial, computer, and electrical engineering disciplines. The ultimate goal of the project is to develop a robotic tour guide for RIT that could be used to recruit prospective students and intrigue the younger generations about robotics. Due to the many fields of design available in this project, the locomotion aspect of TigerBot was chosen to be the primary focus for this team. This also provided the base platform for future teams to build upon. The final implementation includes a one leg design, the software packages to manipulate the leg, and the sensor and communication networks necessary for operation.

NomenclatureADC-Analog to Digital Converter CAD- Computer Aided DesignCAN-Controller Area NetworkDOF- Degrees of FreedomFSR- Force Sensing ResistorI2C-Inter-Integrated Circuit PCB- Printed Circuit BoardPWM-Pulse Width ModulationROS- Robot Operating System (Linux Based)UART-Universal Asynchronous Receiver/Transmitter

Copyright © 2015 Rochester Institute of Technology

Proceedings of the Multidisciplinary Senior Design Conference Page 2

USB-Universal Serial Bus

IntroductionIn the field of robotics, it has always been a goal to create a full-scale humanoid robot. This robotic system would be able to carry out tasks that are either too dangerous or difficult for humans and current non-humanoid machines to accomplish. A full-scale humanoid design is very complex, involving issues such as balancing and torque generation. As humans, our muscles are much more capable for movement and holding our position. For a robot, achieving similar functionality requires complex and well-researched design approaches.

This project is the fifth design iteration of the TigerBot series. The four previous versions have all been small-scale, i.e. less than four feet tall. This full-scale version requires the TigerBot to be approximately five feet tall. While the previous designs achieved the humanoid design, some could only stand and walk for a few steps; full locomotion has yet to be achieved. There are many objectives to be achieved for the TigerBot, although not limited to this iteration. The final TigerBot should be proportional to a five-feet tall human, be untethered, have human-like degrees of freedom, and have almost-human autonomy. This almost-human autonomy would include the abilities to walk in any direction, recover from falls, avoid obstacles during transit, and recognize certain vocal commands. In addition to the full-scale goal, TigerBot V is to serve as a future platform for robotics research. This entails focusing on a system-level design with more emphasis towards locomotion than component design. Due to constraints of the project, the final implementation will be a one-legged solution Therefore, the team’s major design goals lie in achieving a comprehensive design, emphasizing a modularity and flexibility, and ensuring autonomous operation of one leg.

Mechanical DesignTo meet the full-scale goal, the estimated torque values are increased with following goals in mind: the ability to recover from a fall and to support a load greater than 25% of its body weight. To meet these goals, the design necessitates 22 DOF (4 DOF arms, 5 DOF legs, 2 DOF head, and 2 DOF torso). The primary material used for the frame is aluminum; this aides in keeping material costs low and lowers the overall weight.

For our torque requirements, we calculated what torque is needed for each DOF in various walking/standing positions. We calculated the average torque needed for normal movement operations and also calculated the max torque needed when the robot is pushed to the limits. Using calculated torque values and added factors of safety from these scenarios, motors and gearboxes were selected accordingly.

Cycloidal gearboxes were used in our first iteration of our design. They have a high torque output and provided enough space in our designs. Following the requirement of maintaining a humanoid figure, we found that using a direct drive system connecting the motor to the gearbox to be unfeasible. Instead, we found that the use a belt and pulley system would allow us to better space the motor gearbox pairs. By consulting the manufacturer’s design manual, we were able to remove the need for tensioners on the belts, as it stated that using specific belt and pulley combinations with the correct center to center distances ensures proper belt tension. As it turns out the cycloidal gearbox is too heavy. So a new solution had to be found.

Project PXXXXX

Proceedings of the Multi-Disciplinary Senior Design Conference Page 3

With the goal of still keeping the robot light, harmonic gearboxes from Harmonic Drives are chosen as they have excellent weight to torque ratio. They are also small in size and still pancake style gearboxes which allows for a lot of room to join them with the Teknic motors. The same belt and pulley system from the Cycloidal is used.

With the joint design with the harmonic gearbox, it is going to be attached to our test joint setup for display. This will mimic the leg movement of the robot. Moving further into the design, the full CAD model was implemented into a robot movement simulation software to be used in software control of the frame.

Software Design To properly control the robot’s mechanical frame and various hardware, the Robotic Operating System (ROS) was selected. ROS is a flexible framework for writing robot software which provides an industry-grade software stack, a simplified communication layer across all hardware, and a package repository for libraries and plugins.

Copyright © 2008 Rochester Institute of Technology

Figure 2: Body Designs

Figure 1: Modular Joint Design

Proceedings of the Multidisciplinary Senior Design Conference Page 4

Hardware Interface - The hardware interface is responsible for managing the communication between the hardware resource interface and the hardware. Communication is achieved by using a rosserial node which allows a ros node to run on Teensy via USB. Data is transferred by serializing messages sent through topics and deserializing them upon arrival. Tigerbot uses the tigerbot control node to receive feedback through state topics, and issue commands using

Hardware Resource Interface- The hardware resource interface is responsible for relaying information between the hardware interface and controllers via buffers. A single joint is represented by a state interface(position, velocity, and effort) for feedback, a command interface (position, velocity, or effort) for executing orders, and a unique ID for registering the joint in the controller manager. The tigerbot_control_node is responsible for updating the position, velocity, and effort buffers by subscribing to the corresponding topics exposed by the hardware. In addition, the node queries the command buffer and publishes the changes to the corresponding hardware command topic.

Controller- The controllers are responsible for exposing the hardware resource interfaces(PositionInterface, VelocityInterface, etc.) via topics. A controller will query the controller manager for a given resource name and claim the resource if it is found. This will create a state topic which contains the position, velocity, and effort of the current joint and a command topic which takes a floating point number and writes it into the corresponding

Project PXXXXX

Figure 3: ROS Stacks

Proceedings of the Multi-Disciplinary Senior Design Conference Page 5

interface. Tigerbot uses positional controllers which directly forward the specified positions to the command topic, rather than using a PID loop as in the velocity controllers.

Controller Manager- The controller manager is used to load, unload, and operate the specified controllers in the parameter server. In tigerbot, all of the hardware resource interfaces register with the controller manager when the node is initialized. The controller manager then parses the parameter server and loads the specified controllers if the specified interfaces exist. The controller manager is also responsible for the refresh intervals of every controller. A refresh is when the controller requests the next command and returns the current state.

The ROS Interface- The ROS Interface is a layer of abstraction between the ROS motion planning packages and the ros controls interface topics that require only positions, velocities or effort information. These abstraction layers allow the move groups follow joint trajectory goal messages to be decomposed into the individual joint trajectory points for a move group and a single point along the trajectory and sent to the controller at a predetermined interval.

TigerBot Robot Description and Model- In order to describe Tigerbot in a way that is meaningful to ROS a Universal Robotic Description File (URDF) is used. This URDF is written in XML syntax which conforms to the SDF V1.5 standard and describes all aspects of the physical robot. This Robotic description is parsed out and placed on the ROS parameter server to allow any package that required the physical robot description the ability to access it without the need to read and store the file itself. This parameter server then contains all information extracted from the 3D Solidworks model such as joint location, orientation, link inertia, mass and other dynamic information. All this descriptive information is provided to the Moveit package interface to calculate the forward and inverse kinematics and all static transformations required for motion and trajectory planning. This modified representation of the robot description is the Robot Model, which is continually updated through the robot state publisher to allow the ROS system to have an accurate view of robots physical state.

MoveIt- To utilize the software stack, a motion planning library, MoveIt!, is used. MoveIt provides libraries for kinematics, control, and navigation for moving tigerbot. Many of the operations it invokes rely heavily on feedback from sensors to properly respond to the planning scene.

Electrical DesignIn order to meet the primary objectives of this project, a sensor network for the robot and an interface network between the primary processor, secondary microprocessors, servo motors, and the sensor network are required to be developed. Due to constraints of the project limiting the final implementation to a one leg solution, a full sensor network and power grid were not implemented. However, the hardware that has been developed are all extremely modular and can be applied to any future phases of the TigerBot project.

Copyright © 2008 Rochester Institute of Technology

Figure 4: FSR PCB

Proceedings of the Multidisciplinary Senior Design Conference Page 6

To meet the requirements of the leg implementation, the main focus of the sensor network design revolves around the use of effective feedback and communication. FSRs are the primary feedback used. They are placed in the corners of the underside of each foot, sensing the weight distribution on each foot for proper balancing. To effectively pass data between the FSRs and microcontrollers, ADCs are used as an intermediary step. The FSRs will relay differences in force as analog voltage to the ADCs which then convert them to digital signals. This information is then forwarded over an I2C communication line to the microcontrollers. The collected and transmitted data will be used by the processor network to aid in balancing the robot. A custom PCB solution was needed for the FSRs and the ADCs; a unique breakout board was needed for the microprocessor. The FSR manufacturer, FlexiForce, recommended an implementation that required a negative voltage which was unsuitable for this project, so a custom solution was needed. The custom FSR board consists of a simple op-amp solution used to scale up the voltage at the output of the FSRs to roughly 5V. Each input to the op-amp has an RC filter network to allow for extraneous noise to be filtered prior to digital conversion. The FSR output is then passed on to the ADC

PCB.

The next stage of the sensor network design was the implementation of an ADC to perform digital conversion. This solution needed to be able to handle multiple sensors and relay the collected data to the microcontrollers. A Texas Instruments chip was chosen based on a brief cost/performance analysis. To maximize the capability of each ADC, the PCB is capable of accepting up to 8 inputs, however the ADC can be coded into other modes. The ADC’s converted inputs are outputted to the microcontrollers via I2C communication lines. Each sensor connector has a power-out pin, a data-in pin and a ground pin. To ensure a flexible design, each power-out pin has a jumper to select a +5V or +3.3V supply to the sensor. In future revisions, an additional jumper select will be included to change the reference voltage to an external 5V. The key benefit of this chip implementation is its I2C digital output.

To cap off the sensor network and provide a bridge between the main processor and sensors, a microcontroller was required. In order to ease the interfacing of the Teensy microcontrollers with the servo motors, the sensor network, and the main processor, a custom breakout PCB was designed. Each breakout PCB has 6 outputs to motor controllers, each consisting of 3 digital I/O pins and a PWM pin. Maintaining the policy of flexibility and modularity each PCB has in addition to an I2C interface, a CAN interface, and UART implementation is included.

Project PXXXXX

Figure 5: ADC PCB

Figure 6: Teensy Breakout PCB

Proceedings of the Multi-Disciplinary Senior Design Conference Page 7

Additionally to establish communication between the lower voltage microcontroller logic and the higher voltage motor controller logic, a digital level shifter was implemented on the breakout board. Each level shifter has a voltage reference select jumper so that the microcontroller can interface with 1.8V, 3.3V, and 5V logic. Reference voltages need to be supplied externally to the board.

Results and DiscussionIn the end, a test assembly with the cycloidal gearbox is designed and built. The design was made for a single bearing shaft while the gearbox we got from Onvio uses double bearings. The input shaft of the gearbox is not flattened for the pulley to be fit onto it. Adjustments were made and the test joint is built and fully functional. A modular joint design utilizing the Harmonic Component set is designed and incorporated into the test joint to mimic a leg from the hip downward. There was a mix-up with the material thickness and the center to center distance for the belt and pulley system was off. Our test results prove that the motor and gearbox can provide the required torque. Using the modular joint design, a full lower assembly from the hip to the ankles has been designed and is conceptually functional with a few exceptions. The yaw rotation of the leg still needs to be implemented. The ankles may need a redesign. The upper torso is also designed in CAD and has room to add more DOF if needed in the future. The arms utilized older designs with the belt and pulley system outside the links and instead of using the Harmonic Component Set, they use the Harmonic Gearheads which allows radial and axial load. A hardware package for the project is finalized and ready for use. Of the three PCBs designed, the breakout board and ADC board are tested and operational. The FSR board has technical difficulties and needs to be reevaluated.

Conclusions and RecommendationsA full scale humanoid robot that is fully functional could not be implemented within the given timeframe. However with the sponsorships, the modular joint design, the hardware and software packages, the groundwork is in place for future teams to continue from where we have left off. Mechanically, we recommend stress analysis be done to the limbs and joint design. Currently, we have connecting rods to decrease weight but they might fail. Changing the rods material to steel might help as it will get twice the strength. Since there was a lot of design reiterations and no convergence to one finalized design, the shell is just in a conceptual stage. Having the endo-skeleton design finalized and ready before starting to work on the shell is recommended. The hardware has been tested to such a degree that it is useable for future designs.

References● ROS● Nodes● Topics● Services● Messages● Publishers & Subscribers● Parameter Server● Gates Design Manual ● Gates Power Transmission

Copyright © 2008 Rochester Institute of Technology

Proceedings of the Multidisciplinary Senior Design Conference Page 8

AcknowledgementsThere are many people who deserve the team’s gratitude for their time, effort, and knowledge over the course of this project. The team would like to thank Dr. Ferat Sahin for the opportunity to work on this project. We would like to thank Prof. George Slack for his advice and guidance. We would also like to thank Brendan Flozensier and Abe Amirana for all of their support from Teknic, John Chiu for his help with the mechanical design, and John Bonzo, Dave Hathaway, Rob Kraynik, Jan Manetti for their technical help in the machine shop, and other faculty and staff who supported our work including but not limited to Prof. Mark Kempski, Prof. Adrianna Becker-Gomez, and Carlos Barrios. Special thanks to Onvio with their assistance in providing their M02 and M03 cycloidal gearboxes, and Harmonic Drives for their harmonic gearboxes.

Project PXXXXX