Cable-Suspended

Platform System











ME 135 Design of Microprocessor-based Mechanical Systems

Ben Tearle (Group Leader), Isaac Moreno, Marie Biscarrat, Joseph Chung

Prepared for Prof. G. Anwar

05/15/2014
We designed and built a cable suspended platform system that utilized motion tracking to
turn hand gesture inputs into translational and tilting platform movements.

Background and Motivation

This project was chosen because it fulfilled all of our project requirements, had multiple
applications, and was a challenge to us as a group while still being financially feasible. The
project requirements included
Group effort (three to four members)
Demonstrate the use of real-time software
Design and development of host GUI software
Components running on multiple CPUs or cores
Interaction with the external world through sensors, actuators, or other computing units
Must be multitasking
Clearly, our project met the three to four members requirement, and each member
contributed to the finished project. The project demonstrated the interaction with the external
world by using a leap motion sensor, four stepper motors, two servos, and an external computer
to run LabVIEW. We met the requirement of running on multiple CPUs by using this external
computer. The real-time aspect of this project included but was not limited to using hand
tracking data to drive the motors. Calculations with the hand tracking data produced a number of
steps (1.8 degree/step) that each motor should move. Because each motor did not necessarily
have the same number of steps to move in the set increment time (t), each motor had to run at
varying angular velocities to ensure that their start and stop times were synchronized. This
increment time needed to be smaller than our leap motion loop time (T), which is when a new set
of steps would be calculated and sent to the motors. The movement of the platform actively
updated and responded to the users inputs. Our project demonstrated multitasking by
continuously and simultaneously recognizing a users gesture inputs while converting these
coordinates to an appropriate change in platform dynamics. Our code ran in such a way that we
were also controlling the platforms yaw and pitch motion at a faster rate than the platforms
translational position. Finally, we designed and developed a host GUI with the goal of giving the
user the option of having a simple or a more detailed interface.
Another reason we decided on this project was its multiple applications. Some of these
applications include but are not limited to
Camera mount
Game platform
Delivery system within bounds
Physical therapy equipment
Each one of these applications interested at minimum one member of the group which made this
an ideal project for us.
Lastly, we chose this project because it was financially feasible while still challenging us
as engineering students. At least one member of our group had some experience in machining,
control systems design, and embedded systems, so this project gave them a chance to expand on
that experience. This project also gave the other members in the group without this experience a
chance to learn these skills. None of our group members would consider themselves strong
programmers and the opportunity to gain some experience in real-time and data flow
programming was something each one of us looked forward to.
The sensor device used for this project was a Leap Motion Controller. This sensor utilizes
2 IR cameras and 3 IR led lights. The IR LEDs generate a pattern of lights that is reflected when
a persons hand is within the range of the LED light pattern. The two IR cameras pick up the
reflected data and the Leap Motion software is able to generate the 3D position data. The Leap
Motion was ideal for our project because it was able to track all movements in 6 degrees of
freedom. For this reason, we were able to move the platform in the x, y, and z directions and
rotate the platform in the yaw and pitch using gesture control. Movement in the x, y, and z
directions are confined to a 3x3x2 space. Yaw rotation was confined within a range of 180
degrees. Pitch rotation was confined within a range of 40 degrees.
The system was built using four 2 high metal posts each attached to quarter inch thick
1x1 aluminum plates using L-brackets. Casters were placed at the top of the posts for the cable
to easily connect to the platform and stay in tension. The motors were attached to the plates using
customized motor mounts, while the cable was wrapped around machined spools attached to the
motor output. The platform was made of a 6x6 polycarbonate square sheet where the servo
motors were mounted. The top polycarbonate platform was screwed to the top servo bracket and
the cables attached to platform center.



Figure 1: Picture of the overall system



Figure 2: Picture of the platform

Figure 3: Solidworks model of a single assembled post

Challenges prior to Proposal

As stated above, one of the interesting aspects of this project was the challenges it posed
to the group.
Prior to the proposal presentation, we identified several challenges we would face
throughout the project. Since none of us had much experience with LabVIEW, we realized from
the beginning that programming with this interface would be one of the biggest obstacles to
overcome. We wanted to use gesture commands to control the platform, so converting the
control data acquired by the gesture device to accurate platform movements would become the
next difficulty once we became more familiar with the LabVIEW data flow. Finally, we
anticipated that coordinating the simultaneous rotation of the four motors to control the cable
lengths and move the platform to the desired position would be another challenge we would face.
After familiarizing ourselves with LabVIEW through the class assignments and through
our own experimenting, we felt more comfortable in the graphical coding language. For gesture
commands, we researched the systems available on the market and decided on the LeapMotion
sensor device to control our platform as it recorded all 6 degrees of freedom and was designed
for detecting small hand movements rather than full body motion (as opposed to a product like
the Xbox Kinect).We were able to find an open-source LeapMotion Controller Toolkit designed
for LabVIEW, which allowed us to more easily convert the data acquired by the device into
usable LabVIEW inputs. Using the live LeapMotion data, we established Boolean commands for
movement in the X, Y, and Z directions, and commands for tilting and panning the secondary
platform. From there, we used the initial and final position coordinates of the platform to
calculate the necessary change in length of the cables. This was done by subtracting the initial
and final length of the string calculated at every time interval (T) using the equations of the
inverted pyramid design (Equation 1, 2, 3, 4 below). We converted this change in cable length to
a change in motor rotation angle using our spool dimensions and basic geometry, which in turn
could easily be translated into a fixed number of steps based on our motors stepping ability of 1.8
degrees.








Equations 1, 2, 3, 4: Equations for the length of the slant height of the inverted pyramid



Figure 4: Diagram of the inverted pyramid design

Challenges Faced

As we moved further along towards the project completion and the anticipated challenges
were addressed and fixed, new difficulties arose. We first encountered timing issues. As
mentioned above, we wanted to synchronize the stopping time of all four motors, despite them
all running a different number of steps This problem was solved by setting a universal given time
(t) to perform the steps, which allowed us to calculate the period of a step for each motor. This
meant that motors with more steps to complete would run faster than those with smaller
movements. We needed to ensure that all the steps sent at one time interval (T) were performed
by the motor and that the step count sent from the following command did not interrupt the
current command from fully completing. This issue was resolved by increasing the loop time (T),
guaranteeing the completion of every step. However, we could not set a time interval (T) so big
that the next set of commands would be sent long after the first set was done, making the
movements of the platform choppy and lagging behind the user input. We used a trial and error
method to determine the perfect loop time (T) for our project. A similar process was performed
for the pitch and yaw servo motors to ensure smooth movement.
We faced several mechanical issues that slowed progress of our final product and resulted
in slight modifications to our design. Initially, each cable was connected to a corner of the lower
platform. When the platform was placed in the middle of the 3 x 3 x 2 space and was raised in

2
=
2
+
2
+
2

2
=
2
+
2
+
2

2
=
2
+
2
+
2

2
=
2
+
2
+
2


the z direction, it stayed flat and balanced. However, when we tried to move it in the x and y
direction, we saw unwanted tilt in the system. We reviewed the equations 1, 2, 3 and 4 and
realized that our efforts to take into account the modified location of our cable attachment points
from the center of the platform had produced undesired movement effects. We tried again to
further adapt these equations to fit our system, but none of our changes could completely resolve
the issue. We then switched strategy by modifying the attachment location so that the cables
would connect to a more centralized location point on the top platform. We used the screws
attaching the platform to the servo bracket as connection points for the cables. Not only did that
create what could be approximated as a single attachment point for all four cables in terms of the
equations of motion, but it also allowed all the weight of the servos to hang and stabilize the
platform.
Another issue we encountered was machining the rubber casters initially bought to act as
a pulley. These casters are meant to be used as desk chair wheels so the rubber material is
designed to be wear resistant. When we wanted to cut a groove in them for the string to go in, the
rubber would burn and leave behind a track filled with imperfections. To fix this problem, we
kept the swiveling mounts but replaced the rubber wheels with machined hard plastic wheels
where custom grooves were easily added.
We noticed a lot of undesirable rattling noise between the motors, metal brackets and
plate. To fix this, we went back and inserted small rubber pads between the L-brackets, motors,
and plates to dampen some of the vibrations. We occasionally faced issues with maintaining
tension in the cables after moving the platform close to the bounded edges of the 3D space. The
cables could get caught either on the rest of the wire or on the tape holding the string to the
spool. This issue is part of the improvements to be made to the system.
In fine tuning our gesture input control system, we noticed that when we had extreme
yaw rotation of the hand, our entire arm would naturally move and rotate in the input plane. This
created an unintentional translational displacement of the hand and thus triggered the
translational motion commands. Instead of going through and altering the translational and
rotational command priorities, we associated each category with a hand shape. If the LeapMotion
recorded one finger or more extended (e.g. a flat palm) then the only allowed movements were
pitch or yaw, while if we had a closed fist, the movements were in the x, y, and z directions only.
Our last set of challenges came from our electrical portion of the project. Since we were
using stepper motors, we used stepper motor drivers that would take our step and direction
outputs and turn them into the appropriate signals that our stepper motor could accept. This
approach was easier than generating the step sequence necessary within our LabVIEW FPGA.
Our particular motors needed 1A/phase to perform at full load, so we were pleased to find a
Quadstepper motor driver from Sparkfun that could drive all four of our motors while also
satisfying our voltage and current requirements. A couple of days before the project due date,
two of our four driver chips blew out, leaving us unable to run our back two motors. On such
short notice, we could not re-order new drivers and we wanted to avoid troubleshooting and
debugging the alternate approach of using dual H-bridges and generating the step sequence in
LabVIEW as mentioned above. Fortunately, were able to find two stepper motor drivers at a
local Berkeley store. However, they were only 750mA drivers which was lower than the
requirements of our motors. To ensure that these drivers would sufficiently run our motors, we
did not load our platform with any extraneous weight, so as to avoid bringing the motors to their
maximum load capacity. As an extra precaution against overheating our new smaller drivers, we
used 500mA power supplies as opposed to the 2A supply we were using for the Quadstepper
driver.

Code description


VI/sub VI name Brief Description
Test Our main GUI where the data conversion from the LeapMotion
takes place.
Hand Tracking Leap
Motion
Extracts hand data such as yaw, pitch, roll direction and palm
position in xyz coordinates. Outputs the current and initial hand
position and direction.
Directional Priority Establishes directional priority for the xyz movement of the
platform, and establishes rotational priority for the yaw and pitch
rotation of the platform. We made it so that the platform will
move in the x, y, z direction sequentially, respectively. The
platform will rotate in the yaw direction before the pitch
direction.
Length Initial Based on the current xyz coordinate, this VI calculates the initial
length that the strings must be so that the platform center will be
For a more in depth look at the VIs, GUI, Real Time, and FPGA block diagrams, all of the
LabVIEW files will be attached to the Bspace submission.


Figure 5: Host GUI

at that exact xyz coordinate.
Increment with Limits Establishes software model of the moving platform system, and
takes into account the boundary extents.
Length Final Based on the xyz coordinate outputted from Increment with
Limits, this VI calculates the final length that the strings must
be so that the platform center will be at that exact xyz
coordinate.
Tilt and Limits Establishes the angle increments in which the platform will
rotate in the yaw and pitch directions. Sets the limits on the
range of angles that the platform can rotate for.


Figure 6: Host GUI (Data Specifics)


Room for Improvement

There are several improvements that could be implemented to the system. First, the last
degree of freedom can be added to the platform. This can be achieved by replacing the servo
used for pitch with four linear actuators and modifying the code accordingly. Using linear
actuators to add the last degree of freedom and using the servo for yaw, would require adding an
intermediate platform to attach the bracket of the servo and the bottom part of the actuators. The
above mentioned tension problem in the cables is also an improvement that should be considered
in a future phase. One way to fix it would be to decrease the amount of string on the spool closer
to the maximum length required to position diagonally across. This would lower the chances of
the string getting caught on itself when it wraps around the spool.
One of the main future goals would be to revamp the motor driver and power supply
system in the hopes of making it more robust. Instead of using cheaper but more convenient
products like those found on Sparkfun, more reliable methods of driving our motors would be
needed, such as programming our own stepping sequence and using more reliable H-bridges.
This would also save money instead of buying more expensive but reliable full stepper motor
drivers.
Lastly, to expand the applications of the system, the main platform should be larger to
allow for transport of bigger or more objects. Different styles of platforms designed for different
purposes could be available, so an easily attachment/detachment system could be implemented
onto the main platform. Quieter motors could be used to decrease the sound made by the system
when running. We could implement DC brushless motors and a feedback system to achieve this,
or we could also look into microstepping our current stepper motors. While the 6063 Aluminum
alloy we used was sufficient for our physical build, we could have used a metal with less
ductility, as we ran into issues with the metal deforming during machining.