Interactive Telerobotics Exhibit
|Duration||Fall 2017 - Spring 2018|
|Lead Instructor||Dr. Perry|
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.
- 1 Problem Definition
- 2 Project Learning
- 3 Design
- 4 Team Information
- 5 Document Archive
- Phase I (2017-2018 cycle): develop a single-user prototype of the telerobotic master/slave setup
- 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.
and validate function and durability.
- 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
- 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
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.
|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 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.|
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.
|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.|
|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 (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 :
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.
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:
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.
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
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.
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.
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.
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.
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:
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:
- 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:
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 Members (from left to right)
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.
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.
|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 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.
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.
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.
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.