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.
==Problem Definition==
===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
Minimal staff supervisions while on exhibit
Fit within 36" cube
Mobile (fit through a door frame and be movable with two people)
Internal mechanisms should be largely visible
Preferred
User vision of the exhibit should be restricted and user should be provided some form of 3D vision of the work space
Haptic feedback to the master controller
Large output device of visual feedback for spectators
==Project Learning==
===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
The BCN3D Moveo is an open source arm with 5 degrees of freedom. All pieces of the arm are 3D printable. The arm uses steppers and servo motors for movement and is controlled by an Arudino Mega. This arm was a serious consideration, but due to a lack in documentation and having one less degree of freedom than we wanted, we decided not to go with this option.	
THOR
THOR is an open source arm with 6 degrees of freedom. This arm has 3D printable parts and users steppers and servo motors for movement. THOR is controlled using an Arduino Mega and uses an open source gcode-base firmware. One thing that put THOR in front of many other open source options we found was the extensive documentation of the development process. The THOR arm what we've decided to begin our robotic arm design with.	
===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
These are some of the first controllers we encountered during our research. Controllers of this type are mainly used in the medical field. This category includes controllers such as the Geomagic Phantom Omni and Force Dimension Omega-3. These controllers are very intuitive and offer upwards of 7 degrees of freedom which works with our arm perfectly. The issues we found with controllers in this category is that they have extremely high price points that don't fit in our budget. Another large issue is that these controllers seem to be very fragile which does not fit our design specification. We decided to not go with any controller in this category as even though many of them did fit what we were looking for in a controller, they didn't work with our design specifications.	
Master/Slave Controller Setup
The Master/Slave controller setup uses a master controller very similar in design to the robotic arm in order to control the slave (robotic arm). This was a design we had been researching since the start of the project. The issue we were finding with this design was finding a way to design a master controller that was intuitive to use. Designing a second arm similar to our robotic arm wouldn't easily allow the user to move the arm effectively due to the amount of degrees of freedom we have. While researching this type of design, we found a design from TeleroboticsCAR. Their design allowed the user to control all degrees of freedom without running into any restrictions. Their controller also allowed for haptic feedback using the handheld part of thee controller.	
Leap Motion
The Leap Motion controller is a controller main used alongside virtual reality devices like the Oculus Rift. It can be used as a standalone device to track a user's hand and lower arm. It uses two monochromatic IR cameras ans three infrared LEDs to track in a hemispherical area, to a distance of about 1 meter. This device is something we've received great reception about from users and from our client. It is the controller system we are using to control are arm. There are a few issues we've seen from other designs that have used the device and from our own testing, such as inaccurate tracking and lag.	
===ROS===
ROS (Robot Operating System) is an open source framework for robotics software. It includes a large collection of tools and packages for creating, managing, and using robotics software. Some of these tools and packages include :
*Leap Motion package for manipulating Leap data inside of ROS
*Kinematics solver plugins
*Robotic visualization
*Robot control systems
ROS uses a node system where nodes subscribe to and publish data from or to other nodes. A visualization of this can be seen below.
This shows a /sender_freq (Leap Motion node) publishing Leap motion data to an inverse kinematics solver node which is subscribing to the Leap data.
One of the biggest and most valuable tools of this framework is being able to import an STL model of a robot and being able to solve kinematics and visualize that model inside of Rviz. This allows for control system testing without having a physical robot arm to test systems on.	
==Design==
===Initial THOR Design===
Our team initially began with the THOR design as a starting point for our robotic arm. We used the given open source CAD files to print all parts of the arm. This took a large amount of time to do as we had many large parts and many parts to prints. After beginning assembly, we ran into several problems with the THOR arm. These included:
Lack of assembly instructions
Frustrating assembly due to arm requiring specific order of parts for assembly and disassembly
Due to difficult assembly/disassembly, part replacement would also be quite difficult
Non-transparent and closed design
Poor cable management
Clunky and overall poor design for our goal
Modularity for easier access of internals
Due to these issues, no major testing went into the THOR as the time we would need to get it running was not available. We instead decided to begin on a improved design for our final arm.	
===Final Design===
Our final design is largely based on the design of the THOR arm but has some major changes. These include:
Transparent structure
Off the shelf components
Change to 3D printed parts
Ease of assembly
Transparent Structure
The THOR design was extremely enclosed and gave no view of the inner workings of the arm. One of the wants from the Discovery Center was a transparent design to show off how the robot arm was working. To accomplish this many of the larger 3D printed parts were changed to be laser cut acrylic parts. This accomplished a few things. It made the frame of the arm much more rigid and clear allowing for a view of the inside parts of the arm. It also made these parts easier to make with more consistent results as many of the larger 3D part prints often failed.	thumb|center|300px|Assembled part of arm with new transparent pieces. Allows for view of motor and bearing.
Off the Shelf Components
The THOR design included 3D printed gears and bearings. While some of them were functional others were not. In order to increase the lifetime and overall functionality of our moving parts we decided to go with off the shelf gears and bearings. The gears we purchased were steel, meaning they were much more durable than their 3D printed counterpart. One trade-off to switching to steel gears was increased weight in the upper joints of the arm. The original 3D printed bearings had issues with smooth movement due to the precision of the 3D printer. The new off the shelf bearings were much smoother but again had the trade-off of increased weight in upper joints.	thumb|center|200px|Off the shelf steel gear used in final design
Change to 3D Printed Parts
3D printed parts were made much simpler and limited to the smaller components of our design. The parts were made simpler by having less complex shapes such as cubes and cylinders. This meant our parts would print more accurately and require less supporting material. Only printing smaller parts allowed us to have our prints done faster and reduced complications with prints. This meant a failed print or part replacement was much less critical as smaller parts could be reprinted quickly. The addition of a 3D printed gripper also was added to our final design.	thumb|center|200px|Example of a new small and simple part used in final design
Ease of Assembly
The change to simpler laser cut pieces reduced the bulkiness of our design and made it much more open. This made it much easier to access the internals and overall assembly/disassembly much easier. Changes to wiring were also made. The initial THOR design had one long grouping of wires going from the end effector down to the base of the arm. The was unpractical so the wiring was split into sections based around joints removing restrictions due to wiring.	thumb|center|200px|Initial assembly of DiscoverBot arm. More open design can be seen along with wiring plugs extending from top joint
===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:
right|300px|thumb| DiscoverBot URDF visualized in Rviz
#Define the group of joints to compute kinematics for
#Receive positional and rotation data from ROS Leap Motion node
#Covert Leap Motion coordinates to DiscoverBot arm coordinates
#Set converted coordinates to a position in 3D space
#Plug position into kinematics function which returns joint angles
#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: 
none|300px|
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.
==Team Information==
center|500px
=== Team Members (from left to right) ===
Member 	Biography 	Discipline
Marshall Townsend	
Marshall is a senior in mechanical engineering at the University of Idaho. He is interested in robotic design and control and will be pursuing his master's degree at the U of I in the fall. 	Mechanical Engineering
Tim Sonnen 	
Tim is a senior Computer Science student at the University of Idaho. He spent his first few years studying Computer Engineering and Computer Science, but his interests changed to focus more on Computer science. He is interested in Machine Learning and embedded applications, and hopes to apply his knowledge in these fields once he graduates. 	Computer Science
Joe Carter 	Joe is a senior Computer Science student at the University of Idaho. He spent his first few years studying Mechanical Engineering but quickly gained interest in Computer Science. His interests are in artificial intelligence and software development. One day he hopes to apply what he's gained at the University of Idaho to developing software at a well known company such as Google or Amazon.	Computer Science
Kierra Ryan 	
Kierra is a senior in Mechanical Engineering at the University of Idaho. She loves engineering and is particularly interested in mechanical and structural design, especially as applies to robotics and automation. She will be applying her skills as a contractor for the navy after graduation and hopes to move into a position more focused on design and automation. 	Mechanical Engineering
Nathan Park 	
Nathan is a senior Mechanical Engineering student at the University of Idaho. He is interested in many aspects of engineering, but is particularly interested in electromechanical design, automation, and robotics. He looks forward to applying the knowledge and skills gained throughout his undergraduate degree in the industry after graduation. 	Mechanical Engineering
Qinlin Xu 	
Qinlin is a senior Electrical Engineering at the University of Idaho. She is a transfer student from China and since she began journey in this field, her dedication to engineering work and motivation to grow stronger have led her to exceptional projects and experiences. She hopes to pursue higher attainments in engineering field and will apply her knowledge to future work. 	Electrical Engineering
Brian Gift 	
Brian is a senior Computer Engineering student at the University of Idaho. Although his path through engineering has wandered between mechanical and electrical engineering since he began his education, his main interests lie in embedded firmware development and system integration. He will be looking to apply his knowledge in industry following graduation. 	Computer Engineering
==Document Archive==
===Gantt Chart===
===Presentations===
===Meeting Minutes===
Google Doc Meeting Minutes