EECS 498

RED TEAM Charles Hardin, Colin Nangle, Deepak Sharma, Mykola

Kravchenko

Project 2: Final Report

“Cartesian Squared”

CONTENT 1. Background

1.1. Project Introduction 1.2. Equipment Involved

1.2.1. Computer Vision System 1.2.2. Dynamixel RX­64 and EX­106 Servo Motors

1.3. Design brainstorming 1.3.1. Hardware

1.3.1.1. SCARA Robot 1.3.1.2. R4 Robot 1.3.1.3. Cartesian Robot

1.3.2. Software 2. Implementation

2.1. Initial Concept 2.2. Robot Design and Construction 2.3. Design Considerations

2.3.1. Sources of Error 2.3.2. Re­evaluation and Modifications

2.4. Motion Algorithm 2.4.1. Robot 2.4.2. Manual Controller 2.4.3. Autonomous Controller

3. Expected Performance 3.1. Modelling Software 3.2. Calibration and Modification

4. Results 4.1. P­Day Results 4.2. Observations

5. Discussion 5.1. Discussion of Other Teams 5.2. Reflection on Current Design

5.2.1. Mechanical Design 5.2.2. Software

5.3. Future Modifications 5.3.1. Mechanical Design 5.3.2. Software

6. References 7. Appendix

1. Background 1.1. Project Introduction Our task was to build a robot arm which is capable of drawing on a piece of paper within a 1 ft.³ workspace. There were several paper positions and orientations, which were not known in advance except for the following properties:

(1) the paper is a standard sheet of letter paper, laid on a rigid backing, entirely within the workspace;

(2) the paper must face upwards or at most 5° downwards. (3) the paper must face within 90° of a designated “front” direction.

Before attempting to draw on each orientation, our team was allowed to calibrate the robot by hand, by moving it to known points on the paper. We were required to draw a four by four inch square, with sides parallel to the edges of the paper. In addition, the instructor provided a sequence of pen strokes as a list of two­dimensional positions relative to the corner of the page. The robot arm had to also draw these pen strokes on the page. 1.2. Equipment Involved

1.2.1. Computer System The robot was controlled via a JoyApp written in python and running on a linux machine. The

computer communicated with the robot via RS485 serial connection.

1.2.2. Dynamixel RX­64 and MX­64 Servo Motors Servo motors were provided along with the python library. These motors allowed both constant

rotation and joint mode operations, where prescribed torque between ­1 to +1 or prescribed angles between ­10000 to 10000 could be specified. Maximum of 6 servo motors (a combination of RX­64 and MX motors) were allowed in any suitable configuration.

1.3. Design brainstorming

1.3.1. Hardware Group brainstorming meetings focused on designing a robot with simplified inverse kinematics.

As a team we came up 3 designs satisfying the design constraints of this problem. These robot ideas are as follows:

1.3.1.1. Scara (the competition) Robot

The scara (Selective Compliance Assembly Robot Arm) is an RRRPR style robot arm that is typically used in industrial robotics. The arm is rigid in the z axis and pliable in the X­Y axes. In order

to meet the design constraints of the project, an additional axis of rotation would have to be implemented in order to control the orientation of the end effector.

The design would allow us to reach every point and pen orientation in the workspace, but at the expense of difficult inverse kinematics and the mechanical design challenge of correctly balancing the hanging servos.

Fig. 1: SCARA robot arm [1]

1.3.1.2. R­4 Robot Similarly, to the SCARA robot, the R­4 robot was an assemblage of 4 revolute joints that could

reach all of the points and orientation in the robot workspace. The design was better than the scara robot, in that the inverse kinematics calculations required for the design would be simplified, however this design would still be very hard to implement from a mechanical perspective. We anticipated issues with arm sag and torque requirements of the servo motors that were a result of the robot arms hanging servos.

Fig. 2: CAD model of a R­4 bot controlled with 4 revolute joints

1.3.1.3. Cartesian Robot Cartesian robot works similar to R­4 robot but

has a cartesian joint system to draw on the paper. This bot uses a sliding­bar mechanism to move the slider on a adjustable horizontal rod (which could be moved vertically using a hex nut and lead screw). After careful design considerations and based on team’s ability to complete project on time, cartesian robot was finalized as the final design.

Fig. 3: A schematic view cartesian robot

1.3.2. Software The software has two primary functions; align the cartesian frame so that it is parallel to the

surface of the paper, and then move the pen to two­dimensional coordinates within that frame. Alignment with the paper was accomplished during the physical calibration of the trials. The servos were set slack, and the frame was moved into a parallel position by hand. A keyboard button was then pressed which called an initialization function that captured the current position of the two servos controlling the rotation and tilt of the frame and base. The robot was then returned to its zero position. The robot could then return to the appropriate tilt and rotation settings on its own while in autonomous mode.

The second task the software had to accomplish was moving the pen to appropriate coordinates. Having already aligned the frame parallel to the paper, reaching any particular point on the surface of the paper was reduced to a simple 2­D 2­link inverse kinematics problem. Due to the form of our robot, getting to a coordinate involved two steps. First, moving the pen in the y direction was accomplished directly. A state variable was maintained to record the height of the pen within the frame, and the lead­screw was driven to move the pen up or down to the desired height. Next the angle of the actively controlled linkage arm must be set. To do this, the desired x,y coordinates were converted to polar coordinates. With the length and angle of the destination vector now known, as well as the fixed length of the two linkage arms, all that was left to do was solve for one unknown angle using the law of cosines, as illustrated in the diagram below. Only one angle calculation was necessary as the linkage joint angle was passive and thus irrelevant to control of the pen. Once the relevant angle was calculated the servo would then be set to that position causing the pen and slider to move to the correct x coordinate. In order to achieve a straight line on an angle, a stroke would be broken into dozens of segments, and the robot would move to those points sequentially. By adjusting

x and y settings sequentially and in small increments, a close approximation of a straight line on an angle could be achieved.

Fig. 4: trigonometry used in inverse kinematics

2. Implementation 2.1. Robot Design and Construction

Throughout the brainstorming process, we considered several different designs but finally decided on a 4 degree of freedom cartesian robot arm. This design simplified the kinematics, in that it can be manually calibrated to match the plane of the piece of paper, allowing us to focus on only the x and y kinematics of the robot for drawing the square and the data from the text file.

The basic design is a 2 degree of freedom cartesian frame on a 2 degree of freedom base controlled by revolute joints. The base allows rotation around the z and x axis to orient the cartesian frame to match the plane of the paper. In the paper reference frame, the cartesian actuation is

Fig. 5: CAD model of final design with coordinates labeled

controlled in the y direction using a 1/4” threaded rod mounted to a Dynamixel MX­64 motor providing continuous rotation. A ¼” diameter wooden dowel is mounted to a 1/4” nut using manufactured rail supports and the nut/dowel assembly is screwed onto the threaded rod. Finally the x­axis orientation is controlled by a two link arm with a passive rotational joint attached to a rotational servo that is mounted to the base. The cartesian servos were mounted below the axis of the tilt servo in order to counterbalance the weight of the frame.

A more detailed description of the robots construction process, with step by step procedures

and a bill of materials, can be found in our construction documentation.

2.2. Design Considerations 2.2.1. Sources of Error

During testing several sources of large errors were identified. Primary among them was the general sloppyness in all of the many joints on the robot. Snap­lock joints between servos had substantial play, the joints connecting the linkage and end effector were loose and inconsistent, and the U­frame / servo horn couplings themselves flexed under the weight of the robot. Several design factors necessitated the use of linkage arms that were longer than strictly necessary to achieve the full range of motion in the x axis. This in turn meant that the inaccuracies of setting the position on the servo was amplified, as the longer arms resulted in a larger x displacement per degree turned on the servo. Finally, our initial construction had the x axis rod supported on only one side. This led to a large amount of bouncing in the rod.

2.2.2. Re­evaluation and Modifications

Efforts were made to reduce the amount of play in all of the robot’s joints. Snap­lock screws were adjusted to provide tighter, more stable connections. The foam­core linkage arms were adjusted to have as little stress as possible in directions other than the driving directions. The frame of the robot was also rebuilt to provide support to both ends of the x axis rod. This greatly reduces the mechanical inaccuracies of the robot. 2.3. Manual Controller

Manual control was implemented for each servo using the KORG Midi board. The tilt and rotate servos were allowed to be set up during our calibration stage for each paper orientation, so no further implementation was done. To prevent jitter in the servo motion from destroying our robot, the speed of each servo was set to 0.2, to create a very smooth motion. This introduced significant delay in the response, but it completely eliminated human jitter when moving the sliders, which improved the effect of control.

Manual override was always available during autonomous drawing testing for safety purposes. The implementation of the manual control can be found in the python files in the Red team project 2 wiki.

2.3.1.1. Autonomous Controller

Autonomous algorithms were activated by pressing buttons on the Midi controller and the keyboard. Several methods were implemented for square drawing and arbitrary point following. The first issue that we worked to solve was absolute y position. Since the MX servo only gives the current angle as a reading, there needed to be a way to track the number of rotations it had completed to get the height of the pen. The threaded rod we used was rated at 20 rotations per inch, so if we could count the number of rotations from an arbitrary zero point, we could determine absolute height. The first method we implemented, was to sample the angle reading, and when it reached a certain range around zero to count that as a rotation. Then when the angle reading became either positive or negative 90 degrees we get the direction of rotation, and we reset the “full rotation” counter when the angle reading reaches a range around 180 degrees. The prevailing issues with this method, is that it required constant sampling of the servo. This limited the speed at which the servo could rotate, since we needed at least 2 samples every rotation to not lose count. Our servos would also frequently lose connection with the computer, causing the program to crash and the servos to get stuck. Using this method we found that rapidly reading data repeatedly from the servos was not a very robust solution, so we did not stick with turn counting and the MX.

Instead of turn counting, we fixed a certain torque for the y servo, and measured the amount of time it took to complete a full rotation at that torque. Since we know how many rotations the threaded rod has per inch, and we found the time for one rotation, we can calculate the time needed to move an arbitrary height. The processor was commanded to sleep during rotation for a specified amount of time. We found that when applying .3 torque and measuring manually, the end effector moved at approximately 1.25s/inch. This speed was used to calculate the time the processor should sleep when trying to move for longer vertical distances.

Our code also had teach­repeat functionality, although we did not end up using it during P­Day. We implemented a function by which we would save the state of each servo, and the current absolute height of the robot, then use a function to play back each state from beginning to end.

3. Expected Performance

3.1. Modeling Software Our modeling was done in MATLAB using the open source Robotics Toolbox. The Robotics

Toolbox is ideal for modeling robot arms. It provides a method to add an arbitrary amount of either rotational or prismatic joints, connected by links. It also calculates the forward kinematics and can plot the arm, as well as motion of the arm. Unfortunately there is a limitation, in that it does not allow branches of links (two links coming from the same node). This limits our ability to have a good representation of our robot using this software.

In our modeling code we first define the orientation of the paper. We allow for different orientations by creating a paper coordinate system, and defining a matrix to convert from the paper coordinate system to the robot coordinate system. Our simulation is then given a series of points (either for a square or for strokes) in paper coordinates, and we use our inverse kinematics function to get the angles required at each point. We then iterate between them in small increments and track the position to see what shape the arm would make. 3.2. Calibration and Modification

We did several calibration procedures while creating code for the driver in our model. See the software section 2. First we set the maximum and minimum angles of the x position servos. Since upon startup, the robot does not know a hard­coded value for the y position (since it takes many rotations to move up or down), we could not add safety limits in the y direction. For the x position servos, we moved the pen vertically inch by inch, and recorded the maximum and minimum x positions (at each end of the paper area). We created a file which the driver read when moving the x servo to limit the response to be within the allowed x range, depending on the y position.

At P­Day, we also found that while the pen was moving in the y direction, the pressure of the pen on the paper caused the x servo to drift, since the lever arm was not very rigid. To account for this, we measured the amount of drift that happened at a low level of pressure, and corrected the x servo in real time as the servo was moving. This made our vertical lines even straighter.

3.3. Simulation Results

To test our simulation, we provided an arbitrary list of paper coordinates between which the arm had to move. We focused our simulation efforts on drawing squares since it was the passing requirement. As you can see in the figure above, our simulation was capable of moving between 6 points in a square. The midpoints were added between the horizontal lines to improve accuracy, as the arm as we modeled it was inaccurate when moving in the x direction.

Fig. 6: Matlab simulation 3.4. Modeling Validation

There were several drawbacks with using this modeling method. The robot arm created in Matlab was an accurate robot arm, but did not match our physical construction. This modeling scheme would have been ideal for one of the teams which were making an arm. We found that the inaccuracies created when drawing our square were likely not going to be a problem for our design, and that the model was not very good at telling us where our design would stray. For example, in the

figure above, the horizontal lines have curved edges between the points, but our physical construction will not allow that, as motion in the x direction will be along a predefined stiff wooden bar. Even though we had a good model for a robot arm, we did not build that robot arm in the end, so our modeling efforts were not very productive.

4. Results

4.1. P­Day Results On P­day our robot did not perform as well as we expected. As listed in our sources of error

section, we had considered problems with robot sag at certain orientations and we had realized that at certain easel orientations (specifically the varying x and y axes orientation), our robot would not be able to draw a square without a strokes or inverse kinematics function. However, we did not account for the end effector being the main cause of our problems in the other orientation. In the results shown below, it is obvious that our robot worked best in when the paper was being held vertically, and the worst when paper was facing up at an angle.

Fig. 7: Red team Results (from top, clockwise) (a) run 1 RMS: .131 (b) run 3 RMS: 0.129 (~45 degree orientation) (c ) run 3 repeated RMS:0 .164 (~45 degrees) (d) run 5 RMS 0.0714 (vertical orientation)

Fig. 8: Red Team Further results: clockwise from top (a) Repeated vertical orientation RMS: .0616

Repeated runs flat horizontal orientation (b) RMS: 0.0357 (c ) 0.0200

Qualitatively, our robot worked best for the horizontal orientation; where the effects of gravity had little effect on the performance of our end effector. In assessing our squares it is apparent that our robot was not yet tuned for straight line travel. For example, looking at run 3 when the paper was held at approximately a 45 degree angle from the horizontal, it drew a curved line while actuating downward. This curve appeared in each of our runs, and was likely the result of our failure to compensate the passive arm as we moved in the y direction. If there was ever a significant amount of pressure resulting from the markers contact with the paper, the marker would drift left as it went upwards and right as it went downwards resulting in the curved shapes seen in our results.

We did not design our robot to compete in the strokes challenge of this project, because of the issues we had with our robot vertical motion we did not have time to define a strokes function that could be used for competition. 4.2. Observations

Our robot suffered heavily from the pressure applied by the easel onto the pen. We did not experience this in testing, but when the board was oriented to be too close to the paper, the pen would drag to the left during vertical motion. A correction factor was introduced, and the amount of pressure the easel exerted on the pen was greatly reduced. We did not see this in modeling or experience this in previous testing because we only tried vertical orientation and oriented the bot with extra caution.

4.3. Other Team Performance

The other teams were all able to draw closed, four corner figures using their various designs. All five teams used different designs for their robot, which tended to produce different results with different types of errors. With regards to drawing pen strokes, only one team had built in functionality for drawing strokes, while the rest settled for drawing only the square. 4.3.1 Green team’s Project Day results

Green team built 5R robot similar to the robot that we considered in our brainstorming process. However there robot was mechanically balanced, and used bour bar linkages for actuation. When it came to drawing squares, green team was the clear winner. Regardless of the orientation of the paper, blue team was able to draw a closed four sided square.

Fig. 9: Green team run 1 RMS: .0413

Green team also designed functionality for the strokes portion of the project, but they ran into

errors in the code while trying to run on P­Day. Thus their strokes functionality was not quantitatively tested. Had they fixed the bugs in there code, it is likely that they would have won both the square drawing and points drawing competition, due to the mechanical robustness of their design.

4.3.2 Purple Teams Project Day Results

Purple team built an RRR robot taking using four bar linkages as the link between their joints. They used a grid system to determine the distance their robot had to be moved, and calculated the joint angles required to move the end effector across the surface. Once defining the grid, they were able to teach their robot how to draw a square and attempted to draw the points using the grid system that they had defined. Since, they were the only group to try strokes, they achieved the best results for the stroke part of the competition, and when they were able to complete their squares they had very low RMS values. in the .06 ­.09 range.

Fig. 10: (a) Team Purple’s square RMS: .0609 (b) feasible strokes result

4.3.3 Maize Team Project Day Results

Maize team built an RRP robot that took advantage of the mechanical characteristics of a Hoekens linkage to turn rotational motion into prismatic motion. On P­day their code had a few bugs, and it took them several tries to complete a square at different orientations. However for run 3 and run 7 they were able to complete a square, achieving their best RMS score of .0824 on the roughly 45 degree angle plane.

Fig. 11: Maize team square results RMS: 0.0824

Similar, to all of the other teams. Maize was not able to design the robot to actuate pen

strokes. Thus there is no quantitative data to report, about the strokes portion of the project. 4.3.4 Blue Team Project Day Results

The blue team chose to design a planar delta arm which seemed more rigid than most of the robots. There robot simplified the process by aligning the delta arm linkage with the plane of the paper, allowing the robot to only need 2 degrees of freedom in order to draw on the paper. The blue team was able to complete a four sided object for 3 out of the 7 orientations with their RMS error ranging from .116 to .132. The RMS error was relatively high in comparison to the other teams and it appeared that they had difficulty drawing in one of the directions as their squares often came out looking like triangles.

Fig. 12: Blue Team Square Results Run 1 RMS: 0.116 and (b) Run 3 RMS: 0.218

Their robot was unique because it used a homemade force feedback loop with a force detection sensor and a sarrus linkage attached to the end of the delta arm in order to adjust the z position of the end effector. This elegant design allowed the other parts of their robot to be built with less accuracy, and improved the performance of their end effector.

4.4. Discussion 4.4.1. Mechanical Design

One area where our mechanical design could be improved, is in the x direction lever arm. The current lever arm made out of foam core was only connected by a single bolt, and therefore not very rigid. The joint had a lot of give, and for a given x position of the end effector there was a range of x servo angles (up to several degrees) that would result in the same x position. Therefore small changes in the angle of the x position servo did not result in any motion of the end effector. This limited the precision of the end effector in the x direction. If we improved the joint by adding additional bolts and adding more foam core layers to the joint to increase the grip the bolts would have.

Additionally the location of the servo itself could be optimized. In the current configuration the linkage arms are much longer than strictly needed to provide a full range of motion on the x axis. This is due to the servo being mounted so low, relative to the cartesian frame and top of the pivot servo. By raising the height of the servo, the length of that linkage could be greatly reduced, thereby reducing the effects of servo error on x coordinate position.

The inner and outer guides for the slider support rod were an ad­hoc construction that could be greatly improved upon. Gross manufacturing defects in these pieces led to uneven vertical motion of the slider support rod. Vertical motion could also be aided by using a screw with a lower pitch. The lead screw we used required 20 revolutions per inch of displacement. This made a painfully slow robot and made it difficult to track vertical movement, as the servos needed to be run at full speed.

4.4.2. Software

Our software had features which were underdeveloped and thus not used at P­Day. This prevented us from trying the stroke challenge even though we had written software for it. Our correction efforts worked well in keeping our straight lines drawn, but we could have done more to mitigate and predict the effect of applied pressure on the pen from a software perspective. Reducing the speed of the servo motion had a very good effect on the response to the midi board, and no additional filtering should be necessary.

There is much more work needed to be done on the software. Stroke following should be better tested. The framework has been made, but since drawing a square was the main requirement of the robot, a lot of effort was spent in making sure that it would draw a square, and not much on the following of arbitrary points. Much more testing should be done to make sure that the proposed function in RedArmDriver.py will go between poits. The inverse kinematics function must also be implemented to convert between paper coordinates and robot arm angles. It was deemed unnecessary for the drawing of the square as we could hard­code the four corners in the x­y robot plane and orient our robot accordingly.

The moveTogether function in the driver file has shown good diagonal motion in testing, so fully testing that with added pen pressure and creating an additional function to read the vector of

points and create vectors of small points in between for the moveTogether function to follow should be sufficient to implement strokes. It would also be convenient to test the robot with an actual P­Day easel, as well as a sample stroke file.

5. References [1] http://www.societyofrobots.com/robot_arm_tutorial.shtml#joint_force additionally, see references in the presentations 6. Appendix

7.1 Source Code: https://wiki.eecs.umich.edu/hrb/index.php/File:Red_2_Source_Code.py 7.2. CAD Model: https://drive.google.com/folderview?id=0Bw2WF0CVsfPnNldDblNQUE5FYVk&usp=sharing 7.3 Robot Video: https://www.youtube.com/watch?v=2r7dksC­IGA 7.4 Modeling code: https://wiki.eecs.umich.edu/hrb/index.php/File:RedArmModel.txt