1. EECS 498
RED TEAM
Charles Hardin, Colin Nangle, Deepak Sharma, Mykola
Kravchenko
Project 2: Final Report
“Cartesian Squared”

2. 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

3.
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

4. 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

5. 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

6. 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.

8.
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

9.
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.

10. 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.

11. 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

12. 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.

13. 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

14.
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.

15.
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.

16.
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.

17.
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

18. 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.

19.
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