Design

The Project in a Nutshell

Our design choices were guided by the motivating question of whether a robot could react in real-time to bounce a ball repeatedly by appropriately moving and tilting a board. Every design and implementation decision that we made allowed us to isolate extraneous variables to focus-in and test this question. At a high level, our project workflow can be broken down into the following steps:

Robot grips a board that has two handles.
A ball falls into our environment.
Robot senses the position of the ball, and predicts the contact dynamics of the ball with the board.
Robot moves and tilts a board based on this knowledge to ensure the ball will stay within a controllable region.

Specific design choices

Using Baxter as our robot

Baxter, a robot from the company Rethink Robotics, has 2 arms each with 7 joints. The Baxter robot was a natural choice for our project because its end-effector workspace was large, and the fact that it has two arms made the problem more "human-like". While a 1-arm robot could have perhaps sufficed for the ball-bouncing task, a 2-arm robot was initially thought to offer more robust control and movement of the board, as it could grip the board handles on both sides. Additionally, the Baxter robot is integrated with useful libraries, including Move-It, which allows for inverse kinematics computations as well as PID control for joint movements. We customized the grippers in its URDF file to use shorter fingers with paddle fingertips that had increased coefficient of friction for improved gripping performance during mechanical motion.

Creating our custom platform

Resorting to basic shapes in Gazebo model editor, we crafted a two-handled platform with a 0.55 x 1.00 x 0.02m red-colored plate that interfaces with the bouncing ball. The handles are 0.20 x 0.03 x 0.06m rectangular prisms that are purple-colored for distinguishability. While the handles appear floating, each one is linked to the board via a static revolute joint to ensure proper compilation in loading the environment (fixed joints are removed in launch). Each component has reasonable mass with calculated moments of inertia associated, but operate in zero gravity for easier manipulation by the Baxter robot. The board has adjusted collision properties to support bouncing, including a restitution coefficient of 1.00, bouncing threshold of 0.01, and maximum collision velocity of 10m/s. The handles have augmented coefficients of friction to increase the grip strength while interfacing with the Baxter grippers. This was an important design consideration to reduce the erroneous tilting from slippage.

Creating our custom ball

The ball constructed for our experiments and final demonstration was a sphere of radius 0.02m. The ball was colored green for further distinguishability, but also served as secondary aid to smoother image filtering and object detection in the vision stage of the algorithm. Also designed in Gazebo model editor, we changed the default parameters to enable proper bouncing functionality, which had similar collision properties to the board of the custom platform mentioned above. Specifically, these parameter changes included a restitution coefficient of 0.95, bouncing threshold of 0.01, maximum collision velocity of 10m/s, and a minimum compression depth of 0.05m prior to contact registration. Unlike the platform, the ball was affected by gravity to simulate typical parabolic motion of a real-world ball bounce. Initial velocity was also given to the ball during some trials to change the starting trajectory for algorithm robustness testing.

Our Sensing Modalities: Kinect Sensors with Kalman Filtering

To ensure robust sensing capabilities, we carefully place our Kinect cameras to be pointing in three different directions in the world frame, in order to fully capture the ball's movement and compute its centroid. This setup also gave us the flexibility to either use a triangulation procedure or a point-cloud approach to perform the ball localization. The data processed in the triangulation or point-cloud step was inputted into a Kalman Filter, which we developed in order to ensure greater robustness to sensing noise, and to allow for the tracking of the ball's velocity in addition to position.

Some practical simplifications

A primary challenge of this project was the real-time component; the robot has to sense, predict, and move within a fixed timespan in order to intercept the ball's movement and properly bounce the ball back up. Given that our simulator, Gazebo, rendered at a low FPS in real-time simulation, many frames and motions were cut from our view when we used normal gravity. Using normal gravity additionally proved to make the ball move too fast for feasible computation to occur. As a result, we reduced the gravity in our simulation environment to allow the Baxter robot to properly process and react to sensing information, in addition to better visualization and debugging.

Trade-offs made

Accuracy vs Speed

There were many challenging decisions that we had to make to find a good compromise between the accuracy and speed of Baxter’s reactions. Given that Baxter is reacting in real-time to a ball falling, it was very important that Baxter had the ability to both move the board to the correct position and react fast enough such that the ball had not already fallen to the floor. The following were some important design tradeoffs that were made pertaining to accuracy vs speed.

Point Cloud Data vs Image triangulation.

Our Kinect sensor setup allowed for two options to track the location of the ball's centroid in the 3D world frame:

1. Triangulate a pair of two dimensional images and compute points in the images that map onto our world’s reference frame through a series of transformations. This method proved to be faster, but often provided slightly less accurate results.

2. Utilize point-cloud data from the Kinect and compute a more direct mapping of the centroid onto our world’s reference frame. This method demonstrated more accurate tracking compared to triangulation, but was susceptible to higher latency.

Open loop vs Closed loop control

When deciding how to actuate Baxter’s joint angles in order to tilt the angle of the board at a desired location, we were presented with the decision of using Move-It's accurate, but slow closed loop PID control, or a custom-built open-loop controller which was faster and added a low-pass filter for greater movement stability.

High Gravity vs Low Gravity in simulation

We were presented with the challenge of deciding on an ideal gravity constant during the project in order to simulate a relatively realistic application that would also provide Baxter enough time to react. This selection also dictated a user's ability to watch our demonstration with ease.

Setup Complexity

Initially, we envisioned that Baxter would be able to grasp a tennis racket and bounce a real tennis ball. We soon realized that there were limited online resources for three dimensional objects that could be spawned in Gazebo. The few objects that we were able to find didn’t have the desired mechanical properties, such as perfectly elastic collisions in order to allow the robot to focus on merely adjusting the ball's bounce trajectory rather than having to induce additional momentum on the ball. However, we would like to investigate the possibility of having the Baxter robot hold and manipulate an actual tennis racket.

Robustness, Durability, and efficiency

Every design choice for our project revolves around consistent and efficient results. Given that the trajectory of our ball over multiple bounces can change drastically depending on the starting position of the ball in the world frame, we made sure to design our inference node to compute the correct tilt of the board given any ball position and movement. The implementation tab discusses the details of how we accomplished our goals in terms of sensing, planning, and actuation, and the results tab specifies some of the challenges and results.

Page updated

Report abuse