Design
Functionality
The desired functionality of the robot is to detect the locations of multiple large, red SOLO cups arranged in a pyramid pattern which were outside of the robot’s reachable workspace, decide a location to throw to, and execute a throw of a ping pong ball into the cup.
Engineering Constraints
We translated our goals into engineering constraints as follows:
Margin of error: the landing position of the throw should be maximally 2” away from the expected point.
Distance: must be able to throw outside of the robot’s reachable workspace. Note that the total distance we could throw to was constrained due to the max velocity of the Sawyer robots.
Safety: we did not exceed any limits of the Sawyer robot or hack the Sawyer to generate higher force than it is rated for
Runtime: all vision, calculation, alignment, and throwing of a ball should happen within 15 seconds.
Design Criteria
Our specific design choices, that totaled to our final design, is as follows.
We chose to fix the angular velocity of the joints we were using on the robot (Joints 1, 3, and 5) to their maximum values as opposed to changing them based on cup position.
Joints 1, 3, 5 were all the joints available to do pitch motion. We used Joint 0, a roll joint of the torso similar to swinging around the hips, to align joints 1, 3, and 5 with the cup. As such, we can reduce all our throws to a straight line
This allows us to simplify our model and optimization problem such that there are far fewer positions to release the ball at, which improves our robustness through better precision.
A trade-off with this approach is that the robot struggles to throw the ball short distances (because it ends up spiking the ball downwards as hard as it can), but outside of its reachable workspace it is good.
We chose to fix the time in the trajectory we released the ball to be the same across all throws as opposed to varying the time and choosing a set starting point.
By doing this, we are using the same motor impulse for movement, and thus it is easier to manage the error in velocity of releasing the ball – we have the same impulse for all the throws as we accelerate the ball at max velocity for the same amount of time.
We chose not to use Pilz or any other motion planning library that allows for velocity-based path planning
This was done due to the fact that implementing these systems would require time interfacing with the lab team and would become a major blocking issue for our team.
Additionally, velocity-based path planning, to our knowledge, is still a researched topic and does not have easy-to-implement solutions.
The trade-offs are that we must run the robot using a set velocity with intera_interface or use MoveIt and asynchronously release the ball at a set part of the trajectory.
We chose to use intera_interface to allow for more control of velocity during throwing, but the trade-off was implementation time.
We chose to use the right hand camera of the robot for vision.
This is as it was able to see the cups much more clearly than the head camera.
The tradeoff was a significant reduction in image quality – we were restricted to black and white, low contrast, and low resolution images as opposed to high resolution, color images. As such, we moved towards using circle detection instead of color detection for cup finding, which ended up being more robust as we didn’t have to worry about if one cup covered another cup’s colored body.
We chose to ignore air resistance of the ping pong ball in our model.
This is because we assumed that it would not be significant when throwing a ball a trajectory distance of ~1m.
We made no mechanical changes to the grippers.
We found that the current 3D-printed grippers, design-wise, were satisfactory to begin testing with.
We chose to assume the table was in a fixed location relative to the robot.
More details on this assumption were listed in implementation, but the TLDR is that we found that this saved us significant time without severely taking away from our goal.