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 user’s inputs. Our project demonstrated multitasking by continuously and simultaneously recognizing a user’s 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 platform’s yaw and pitch motion at a faster rate than the platform’s 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 person’s 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 3’x3’x2’ 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 1’x1’ 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 6”x6” 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

|l1|2=x2+ y2+( z−h )2

|l2|2=(x−w)2+ y2+( z−h )2

|l3|2=x2+( y−w)2+( z−h )2

|l4|2=(x−w)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 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.

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

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.