Interactive Telerobotics Exhibit

From Mindworks
Jump to navigation Jump to search
DiscoverBot Arm
Team Name DiscoverBot
Duration Fall 2017 - Spring 2018
Sponsor Discovery Center
Students
  • Joe Carter
  • Brian Gift
  • Nathan Park
  • Kierra Ryan
  • Tim Sonnen
  • Marshall Townsend
  • Qinlin Xu
Lead Instructor Dr. Perry
Mentor Sarah Willis

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[edit | edit source]

Objective[edit | edit source]

  • 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[edit | edit source]

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[edit | edit source]

Robotic Arm[edit | edit source]

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.
BCN3D Moveo Open Source Arm

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.
THOR Open Source Arm


Controller[edit | edit source]

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.
Geomagic Phantom Omni


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.
TeleroboticsCAR Master Controller Design

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.
Inner Workings of a Leap Motion

ROS[edit | edit source]

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.

2017 DiscoverBot Node.png

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.

THOR arm visualization in Rviz from ROS

Design[edit | edit source]

Initial THOR Design[edit | edit source]

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.

Assembled THOR Arm

Final Design[edit | edit source]

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.

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.

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.

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.

Initial assembly of DiscoverBot arm. More open design can be seen along with wiring plugs extending from top joint


Control System[edit | edit source]

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:

2017 DiscoverBot DataFlow.png

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:

DiscoverBot URDF visualized in Rviz
  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:

2017 DiscoverBot Ellipsoid.png

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[edit | edit source]

2017 DiscoverBot Team.jpg

Team Members (from left to right)[edit | edit source]

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[edit | edit source]

Gantt Chart[edit | edit source]

File:2017 DiscoverBot Gantt Chart.pdf

Presentations[edit | edit source]

File:2017 DiscoverBot Design Review.pdf

File:2017 DiscoverBot Detailed Design Review.pdf

File:2017 DiscoverBot EXPO Presentation.pdf

Meeting Minutes[edit | edit source]

Google Doc Meeting Minutes