Interactive Telerobotics Exhibit

The goal of this project is to develop a robotic arm for an exhibit placed in the Discovery Center that will provide users with a first-person perspective of a remote workspace and allow them to interact with objects from a distance in order to complete a task. The robot workstation will have a tethered stationary base with sufficient degrees of freedom to manipulate (pick, orient, and place) objects of interest. The system will be capable of use with a specific task, such as stacking compliant objects, or playing a simple board game.

Objective
 Phase I (2017-2018 cycle): develop a single-user prototype of the telerobotic master/slave setup and validate function and durability. Phase II (2018-2019 cycle): extend the Phase I prototype to a mutli-user setup where 2 or more individuals can collaborate and/or compete in task completion.  

Specifications
Required  Safety of users and spectators at all times Robust design that withstands interaction by users of all ages and minimizes maintenance Intuitive design that allows users of all ages to easily and quickly understand the interfaces of the exhibit Maximal use of standard parts for replacement and repair ADA compliant and physically accessible to a range of heights from small children to adults</li> Minimal staff supervisions while on exhibit</li> Fit within 36" cube</li> Mobile (fit through a door frame and be movable with two people)</li> Internal mechanisms should be largely visible</li> </ul>

Preferred  User vision of the exhibit should be restricted and user should be provided some form of 3D vision of the work space</li> Haptic feedback to the master controller</li> Large output device of visual feedback for spectators</li> </ul>

Robotic Arm
After researching robotic arms and the process of designing and assembling one, we decided to look into an open source option. This would allow us to have a good starting point much quicker than if we designed an arm from the bottom up. Many open source options also are made of 3D printed parts, which would allow our client to easily replace parts of the arm. We will then later make modifications to the arm to fit our design specifications. Below are two options we narrowed our design down to.

BCN3D Moveo

THOR

Controller
One of our biggest challenges has been coming up with a controller design that works well and fits all of our specifications. Intuitiveness is a key aspect of controller design, as we want any patron of the Discovery Center to easily understand how to use our controller and be able to use it effectively.

Medical Controllers

Master/Slave Controller Setup

Leap Motion

Final Design
Our final design is largely based on the design of the THOR arm but has some major changes. These include:  Transparent structure</li> Off the shelf components</li> Change to 3D printed parts</li> Ease of assembly</li> </ul>

Transparent Structure

Off the Shelf Components

Change to 3D Printed Parts

Ease of Assembly

Control System
The Leap Motion was unable to be directly used with an Arduino so a computer was needed to handle the computational side of the controller system. Overall this was a good thing as the kinematics require computation-heavy calculations which will be must faster if using a computer rather than an Arduino. With this in mind our the data flow of our control system can be represented by:

Software

To handle the conversions from Leap Motion positional data to joint angles, a C++ ROS node was used. Before we were able to begin computing, a model of the arm was created by importing STL files and converting those into a URDF format. Once this was completed, we were then also able to compute kinematics the TRAC-IK plugin from MoveIt!. The steps to do this were:
 * 1) Define the group of joints to compute kinematics for
 * 2) Receive positional and rotation data from ROS Leap Motion node
 * 3) Covert Leap Motion coordinates to DiscoverBot arm coordinates
 * 4) Set converted coordinates to a position in 3D space
 * 5) Plug position into kinematics function which returns joint angles
 * 6) Send joint angles to Arduino for movement (or Rviz for visualization)

An issue we ran into during computation was that failed kinematics solutions caused a noticeable slowdown. To prevent this the equation for ellipsoids was used in order to make sure that only valid positions were sent to the kinematics solver. Radii for the x, y, and z axes were found and then used in the following equation accordingly: where x, y, and z are the positional data and a, b, and c are the corresponding radii for each axes.

After solving these issues and being able to compute the joint angles almost real-time, we were able to test our software using Rviz. Joint angles were sent to a visual model of the arm in Rviz and the model would move accordingly. Having this visual model allowed us to test our control system without having a physical arm which was very helpful.