Final Report

Document Sample
Final Report Powered By Docstoc
					TABLE OF CONTENTS
EXECUTIVE SUMMARY ........................................................................................................................................... I

TABLE OF CONTENTS.............................................................................................................................................. 1

1.0 BACKGROUND.................................................................................................................................................. 3

2.0 PROBLEM DEFINITION ...................................................................................................................................... 4

   2.1 CLIENT NEEDS ..........................................................................................................................................................4
   2.2 PROJECT GOALS........................................................................................................................................................4
   2.3 DELIVERABLES ..........................................................................................................................................................5

3.0 MECHANICAL CONCEPTS CONSIDERED............................................................................................................. 6

   3.1 PIVOT .....................................................................................................................................................................6
   3.2 BASE PLATE AND SERVO PLACEMENT ............................................................................................................................7
   3.3 STRINGS ..................................................................................................................................................................8
4.0 MECHANICAL CONCEPT SELECTION ................................................................................................................ 11

   4.1 PIVOT ...................................................................................................................................................................11
   4.2 BASE PLATE AND SERVO PLACEMENT ..........................................................................................................................11
   4.3 STRING AND STRING CONNECTIONS ............................................................................................................................12

5.0 ONE-BAR TESTING PLATFORM ....................................................................................................................... 13

   5.1 CONCEPT...............................................................................................................................................................13
   5.2 ONE-BAR UNIT .......................................................................................................................................................13
   5.3 ONE-BAR TESTING RUN............................................................................................................................................14
   5.4 CONCLUSIONS ........................................................................................................................................................14

6.0 CONTROL SYSTEMS CONSIDERED ................................................................................................................... 15

   6.1 SERVOS .................................................................................................................................................................15
   6.2 MICROCONTROLLER ................................................................................................................................................15

7.0 CONTROL SYSTEMS SELECTED ........................................................................................................................ 17

   7.1 SERVOS .................................................................................................................................................................17
   7.2 MICROCONTROLLER ................................................................................................................................................17
   7.3 COMMUNICATION BETWEEN MATLAB AND MICROCONTROLLER ......................................................................................17

8.0 CONTROL SCHEME ......................................................................................................................................... 19

   8.1 MODEL .................................................................................................................................................................19
   8.2 CONTROLLER ..........................................................................................................................................................19

9.0 FUTURE WORK ............................................................................................................................................... 23

APPENDIX A – DRAWING PACKAGE ..................................................................................................................... 24

APPENDIX B – CURRENT BUDGET ......................................................................................................................... 32

APPENDIX C – MATLAB CODE .............................................................................................................................. 35


                                                                                                                                                                                 1
   GUI CODE...................................................................................................................................................................36
   ONE-BAR SOLVER: MAIN FUNCTION ................................................................................................................................42
   ONE-BAR SOLVER: SUPPLEMENTARY FORCES FUNCTION ......................................................................................................44

APPENDIX D – PROPELLER CODE .......................................................................................................................... 45

   MAIN CONTROL SCHEME ...............................................................................................................................................45

REFERENCES......................................................................................................................................................... 51




                                                                                                                                                                              2
1.0 BACKGROUND
Tensegrity is a unique class of structures composed of axially loaded compression elements
encompassed within a network of tensile elements. These structures are lightweight and are
capable of controllable shape change by varying the lengths of the loaded compression elements,
the lengths of the tensile elements, or a combination of the two by use of actuators.
The artist Kenneth Snelson introduced tensegrity structures in 1948. Since then the structures
have been explored in areas including engineering, architecture, medicine, biology, and art. The
stability of integrity of these structures is due to the constant tension network, hence the word
tensegrity. A tensegrity structure is composed of axially loaded compression elements
suspended within a network of tension elements. Any type of applied load on a tensegrity
structure in always distributed as tension and compression throughout the entire structure.
Tensegrity structures offer the advantage of combined controller design with physical structure.
A tensegrity unit may undergo controllable shape change by varying the rest lengths of either the
compression or tension composing elements. The result is a strong, lightweight, controllable
structure loaded in pure tension and compression. The high strength to weight ratios, non-
subjectivity to gravitational fields, and global force distribution are excellent characteristics for
robotic design criteria. If the tension network is allowed to undergo slacking, the structure can
be collapsed, and reapplying the tension can self-deploy the structure.
The Intelligent Robotics Group at NASA Ames Research Center is interested in how tensegrity
structures might be used in robotic applications. The several unique characteristics of tensegrity
could enable robots to perform in ways not currently possible with traditional robotic design, and
the low weight and small size when stored are excellent characteristics for space exploration.
Controllable tensegrity structures could be used in several future applications in space
exploration, including manipulation of large payloads, pointing of solar arrays or communication
antennas, or even self-deploying habitats.
   -   This was the original background from the RLEP Project Proposal for the Robotic Tensegrity Unit




                                                                                                         3
2.0 PROBLEM DEFINITION

2.1 CLIENT NEEDS
The client needs are highlighted in the list below:

      Build a tensegrity unit with a rigid base and stage platforms
      Select actuators and design a control system to adjust the orientation of the two platforms
       relative to each other with six degrees of freedom, allowing the stage to move along any
       of the three axes, as well as rotate about any of the three axes.
      Design a user interface which accepts positional control input and provides sensory
       feedback of the tensegrity unit.
      Platforms must be mechanically and electrically modular (i.e. multiple units can be
       stacked and controlled using the same interface for any number of robotic applications,
       possibly including robotic arms and mobile robots)
      Determine the following parameters for the final design:
           o Range of motion in each degree of freedom
           o Velocity over the observed range of motion
           o Maximum sustained applied load
           o The most compact storage configuration
      Compare and contrast tensegrity structures to more traditional structures for use in space
       exploration.




           Figure 1: A six-bar tensegrity structure capable of six degrees of freedom.
                          The red elements are loaded in pure tension.

2.2 PROJECT GOALS
This project is unique in that it is mainly a research project as opposed to many senior design
projects where specifications are given by the client. This project requires us to find the bounds
and limitations of a modular tensegrity robotic unit including many mechanical and control
systems aspects. The following diagram shows a breakdown of our project goals.

                                                                                                     4
                            Figure 2: Breakdown of project goals

2.3 DELIVERABLES
The following deliverables were completed between August 23 and December 10, 2010:

Deliverable                                     Date
Final drawing package for six-bar prototype     October 18
One-bar test structure                          December 2
Snapshot presentation                           December 3
Interim design review                           December 9
Interim design report                           December 9
TensegriTeam website (updated intermittently)   December 10




                                                                                     5
3.0 MECHANICAL CONCEPTS CONSIDERED
Once the general structural components were understood, the mechanical design was divided
into three categories:
   1. Pivot
   2. Base Plate and Servo Placement
   3. Strings (Tensile Members)
The concepts for each category considered are outlined below:

3.1 PIVOT

Three designs were proposed: a universal joint, a ball and socket, and a rotating pivot (see figure
1). The universal joint would be similar to those used in socket sets this design would be cheap
and easy to machine. However, in order to get the full range of motion required, the middle
section would have to be elongated which would move the rod further away from the pivot
which would induce a moment to the rod. The universal joint would also require any cables
routed through it to be bent in two different angles which could cause problems with fraying or
chafing. The ball and socket was a nice compact design but it would be difficult to fabricate and
it could not produce the full range of motion. The rotating pivot consisted of a mounting piece
which was pressed into the middle of a ball bearing and an upper piece pressed around the
outside of the same bearing to allow for the 360˚ rotation. The rod would then be fitted to the
top of the upper piece in such a way as to allow it to rotate the full 90˚ from vertical. This design
would require more time to fabricate but would also be cheap to build. It would have the full
range of motion and require only one bend in the cable as the string was routed through the
center of it. It also met all of the criteria we deemed necessary.




Figure 3: Joints considered from left to right: universal joint, ball and socket, and rotating pivot

3.1.1 THE CUBE AS SEATS FOR THE RODS
       The cube was thought of when trying to determine the best way to secure the rod to the
       pivot assembly. One of the design issues behind the decision was trying to run the cable
       as close to the central pivot point as possible. Although it was important to get the cables
       close to the pivot point, we also had to be careful not to bend the cables too sharply.
       Sharp corners would increase fatigue and/or fraying of the cable. One idea that was

                                                                                                    6
       considered was using a clevis pin, which has holes drilled through the pin. This idea was
       dismissed due to difficulty routing the wires through the holes, and for possible fraying
       from such a small radius of curvature. Another idea was to mill out the end of the rod to
       leave clearance for the cables and run the cables over the connecting pin. For this idea
       the possibility of catching the cable on the edge of the rod was too great, and we decided
       it was best not to decrease the structural integrity of the rod that much.

3.2 BASE PLATE AND SERVO PLACEMENT
3.2.1 SERVO PLACEMENT
       Three designs were proposed: an inside/outside configuration, an inside configuration,
       and an outside configuration (see figure 2). Each is designated by the position of the
       servos relative to the sides of the equilateral triangle formed by the three pivots. The
       triangle configuration of the pivots is inherent for the six-bar tensegrity structure selected.
       All of these concepts fulfill the specified needs; however the difference between them
       lies solely in the pivot to pivot (PTP) distance.




     Figure 4: Conceptual servo placements from left to right: Inside/outside configuration,
                          inside configuration, outside configuration

3.2.2 BASE PLATE
       Two base plates were considered: a modified equilateral triangle (see figure 3), and a
       square. The modified equilateral triangle was based around the equilateral triangle
       formed by the pivots. It left room for the servos to be mounted and removed excess
       material to reduce weight and provide stability. The square is simply a square of material
       with holes drilled equal distance from each other across the entirety of the material
       forming a grid. This grid would allow for easy modification and positioning of servos or
       the pivots in the future, but added unnecessary weight. The materials considered for the
       base were aluminum and plexiglass. These are relatively strong and lightweight, both
       properties that are required.




                                                                                                     7
                   Figure 5: Base plate concept; modified equilateral triangle


3.3 STRINGS
3.3.1 STRING TYPES
       There are several types of string that we have considered for our design: monofilament
       nylon fishing line, Dacron deep-sea fishing line, and spectra, a type of line used for kites.
       All are relatively inexpensive, available, and able to be routed through small diameters.

3.3.2 STRING CONNECTION
       In order for the control system to work properly the ends of the tensile members (strings)
       need to be fixed at known positions. The connections that need to be considered are the
       connections to the end of the rods, to the tops of the pivots, and to the servos.
       For the connections to the ends of the rods we considered two options. The first is a
       simple knot. The advantages of a knot that it can be tied and untied and should not slip (if
       done correctly). A knot would also be fairly small and would have a small chance of
       hindering the movement of the mechanism. The main disadvantage of using knots is that,
       if tied incorrectly, there is a good chance of slippage. This would cause loss of tension
       and could lead to the collapse of the tensegrity structure.
       The second option for the connection of the tensile members to the ends of the rods is a
       latching swivel similar to a fishing swivel (Figure 3).




              Figure 6: End of rod connection options from left to right: simple knot and
                                          latching swivel

       This swivel would have the string tied to one end (on the image above the right end) end
       so that it could loop around the rod and connect to the string using the latch (left end).
       This option would make it easier to disconnect and reconnect the string for adjustments.

                                                                                                    8
       It would also only require one simple knot and shouldn‟t get in the way of the movement
       of the mechanism. The disadvantage is that under a large load the wire in the latch end
       may deform plastically which would throw off the control system.
       For the connections to the top of the pivots, our first idea was to use eyebolts that could
       be screwed into the top of the pivots. When we went to purchase eyebolts we found that
       there were fasteners named “spring connector studs”. These were both considered.




    Figure 7: Top of pivot connections from left to right: eyebolt and spring connector stud

3.3.3 STRING ROUTING
       The tensile members (strings) need to be routed from the AX-12 servos to the ends of the
       rods with as little resistance or interference with other members as possible. The three
       main options we considered in order to solve this problem are to connect unsheathed
       tensile members from the servos directly to the ends of the rods, to route unsheathed
       tensile members through the center of the rods and through machined grooves, and to
       route sheathed tensile members through the center of the rods and through machined
       grooves.
       The advantages of connecting the strings directly from the servo to the rod are that there
       is no need for machining channels or for routing strings. This would make assembly
       much simpler because we would have to simply connect from one point to another
       without routing the strings through groves or the rods. The disadvantages of this is that
       when we build the six-bar tensegrity there would be exposed strings which would cause
       interference when the mechanism moves (there will be either three or four strings running
       to the end of each rod).




                         Figure 8: String connected directly from servo to rod

       The advantages of using an unsheathed string routed through the center of the rod and
       machined groves are that there would not be any interference between strings and the
       structure will look and be more organized. The disadvantages of routing the strings
       through the rods and machined groves are that it is difficult to machine and plan routing

                                                                                                     9
(groves and holes for string), assembling the six-bar tensegrity would be difficult, and the
string might fray or cause resistance on sharp surfaces.




  Figure 9: Top left: String routed through center of rod. Top right: Unsheathed string
    routed through machined grooves. Bottom: machined grooves in bottom of pivot
  assembly for string routing (see drawing package in appendices for more information
                                     about grooves).

The advantages of using a sheathed string (similar to a bicycle break cable system) routed
through the center of the rod and machined groves over the unsheathed string are that
there would be considerably less chance of the string fraying and if done properly there
would be less resistance caused by friction. The disadvantages are that a sheathed string
would make assembly even more difficult since there are two things to thread through the
groves and rod, and the sheath would take up extra room in the groves and rod that may
be needed for all of the strings to fit.




              Figure 10: Sheathed string routed through machined grooves.




                                                                                          10
4.0 MECHANICAL CONCEPT SELECTION
See Appendix A for the drawing package.

4.1 PIVOT

When deciding which pivot design was to be utilized we fell back on our design criteria. The ball
and socket pivot was ruled out due to the fact that it could not be designed for full range of
motion. Although the universal joint would be easier and cheaper to fabricate, it was not chosen
because it would cause a moment to be placed on the rod when the end of the rod was moved
away from the center of the pivot. To keep the structure a true tensegrity structure, any moments
needed to be eliminated. The fact that the universal joint required two bends in the cable and the
rotating pivot only required one bend was considered but it was not deemed a priority because a
suitable cable material could be chosen to minimize chafing and any additional stresses imposed
on the cable from the additional bend. In the end the rotating pivot was chosen, and after
fabrication, has proven to be a very effective pivot all around. So far no issues have arisen from
this choice.

4.1.1 THE CUBE AS SEATS FOR THE RODS
       The cube combines the design criteria that we have determined are important: A
       relatively large radius of curvature feeding into the rod to prevent fatigue failure, a small
       entry hole to keep the cables close to the pivot point, and enough material surrounding
       the rod and connecting pins to maintain structural integrity.

4.2 BASE PLATE AND SERVO PLACEMENT
4.2.1 SERVO PLACEMENT SELECTED
       We decided on the outside configuration for the servo placement. Having the outside
       servo placement allowed for a PTP distance of 5.18”, therefore allowing for a maximum
       range of movement for the module out of the three servo configurations (5.93” for the
       inside/outside configuration and 7.50” for the inside configuration). 5.18” is still close to
       6” so stability should not be an issue. As with all three servo configurations, the spools
       of the servos where the strings wrap around are aligned directly with the center of the
       pivots preventing unnecessary routing and friction. Material was added to the pivot
       equilateral triangle in order that the servos would mount securely. Material was also
       removed at the “points” of the triangle where not in use. All of the center material was
       left for attachment of the modular connections. The servos were mounted on the top of
       the base (inside of the tensegrity structure) to allow for more options for modular
       connection and likely little to no gap in between two modules.

4.2.2 BASE PLATE SELECTED
       The modified equilateral triangle was chosen over the square design for a few reasons.
       Firstly, the triangle prevented use of excess material. Secondly, while the square design
       may be helpful for prototyping, the grid pattern of the mounting holes would be difficult
       to fabricate in a way that both the pivots and servos could both be securely mounted.
       This is because the pivots and servos use different fastener sizes. The grid pattern would

                                                                                                   11
       also take more time to fabricate than we could dedicate to just the base plates. Finally,
       for the final design, it is a possibility that the base plates will not change using the
       modified equilateral triangle. However, if the square design was used for the prototype,
       the final base plate design would certainly have to be re-designed and fabricated, using
       additional time.

4.3 STRING AND STRING CONNECTIONS
4.3.1 STRING TYPE
       For our prototype we have used fishing line rated at a 50lb work load. We have found
       that the fishing line undergoes plastic deformation at very small loads instead of the
       needed elastic deformation. Because of this we have started trying other lines. The
       Dacron lines have proven good at avoiding plastic deformation but have shown to chafe
       easily, leading to breakage in the line. The chafing seems to only occur when the lines are
       run through the spring stud connectors which will likely only occur during the initial one-
       bar prototype and will not be an issue in the six-bar structure. To combat this chafing, we
       constructed a simple sheath out of rolled paper and glued it to the spring stud connectors.
       This has proven very effective so far.

4.3.2 STRING CONNECTION
       For the end of rod connection we selected the fishing swivel. This allows us removal and
       adjustment to be much easier. We are not currently working under high enough loads to
       plastically deform the swivel, so that is not a major concern.
       For the top of pivot connections we selected the spring connector stud. Although both
       the eyebolt and connector studs would work perfectly for our design we decided that the
       connector studs would be a better fit because they are somewhat smaller than the eyebolts
       and would have less chance of getting in the way of the motion of the tensegrity
       structure.

4.3.3 STRING ROUTING
       We decided to go with the unsheathed routed string because without the string being
       routed we have no chance of achieving an acceptable range of motion and adding a
       sheath would be a lot of work for little result. However, we may connect an extra set of
       wires directly from the servos to the end of the rods depending on whether the range of
       motion with only routed strings is satisfactory.




                                                                                                  12
      5.0 ONE-BAR TESTING PLATFORM

      5.1 CONCEPT
      The one-bar testing platform was intended to tests certain aspects of the design. Firstly, the test
      platform would make certain that the mechanical components performed as expected. Secondly,
      the control scheme would be tested to see if it would move a single bar as desired while keeping
      tension in all tensile members. Thirdly, the Propeller microcontroller would be checked for
      desired effect. Lastly, the one-bar test platform would allow us to begin to understand the
      intricacies of user interface and communication between the GUI (see Appendix C for detailed
      code) and the Propeller (see Appendix D for detailed code).

      5.2 ONE-BAR UNIT
      The one-bar unit is constructed from one of the bars and rotating pivots that will be used on the
      six-bar structure. Four servos are connected to the bar via tensile members made of Dacron deep
      sea fishing line. Two of the strings are routed from the servos through the base of the pivot, as
      they will be in the six-bar structure, and connect to the platform. The other two strings are
      routed from the servos through spring connector studs, for accurate positioning of the string, and
      attached to the top of the bar. The distance between the effective connection points of all of the
      strings to the platform are 8” and 16” apart. These four points form a rectangle (See Figure 10).



                                                                                                       Dacron strings



Propeller




                                                                                                       AX-12 Servo




Spring
Connector
Studs




                                       Figure 11: One-bar test platform

                                                                                                        13
5.3 ONE-BAR TESTING RUN
During the one-bar testing run, we were able to compare the one-bar and the Matlab GUI
running in real time. Comparing the two, they are very similar and the kind of results we were
looking for. In Figure 11 below, the red „X‟ is the desired location of the top of the bar and the
blue circle is the actual position. As the one-bar moves, the blue circle moves toward the red
„X‟. (see Appendix C for GUI code).




      Figure 12: Comparing the actual one-bar (left) to the Matlab GUI (right) in real time

In the upper right corner of the GUI, a table displays the current length and tension for each
corresponding string. At times, one or two of the tensions will go to zero when there is still
tension in the string. This is because those servos are loosening and there are elastic effects in
the strings occurring. Also, the tension measurements from the servos are not highly accurate.

5.4 CONCLUSIONS
Based on the one-bar testing platform we determined an alternate means of tension sensing is
needed. This is mainly because the AX-12 tension and position measurements are coupled. We
have also determined that the control scheme is feasible and worth pursuing further.
Communication between Matlab and the Propeller was successful.

The mechanical components worked well and no large problems were encountered. There was a
problem discovered where the friction from the string overlaying on the top of the bar prevented
the pivot from rotating completely. In order for the control scheme to work well for all motions,
the pivot needs to be able to rotate easily. Addressing this problem is described in section 9.0.




                                                                                                     14
6.0 CONTROL SYSTEMS CONSIDERED

6.1 SERVOS
The demands of this project in terms of motors were quite large. First, they had to have 360 of
rotation and the ability to go to any position specified. This disqualified using regular servos,
which can usually only go to a certain degree, unless modified to only spin in a continuous
rotation. It also disallowed the use of DC motors, since it would be time intensive and difficult
to modify one to maintain continuous rotation and report the current angle. Second, we would
need to control and report the torque, speed and current position. Unless heavily modified, this
ruled out the use of stepper motors. Finally, it would require, at the least, 6 motors. For most
micro-controller, this would be a costly investment of pins.

Our mentors had researched possible motors before the start of the project. They had previously
worked on tensegrity for NASA and they had spent the summer looking for servos suitable for
the project. They told us of an excellent servo that could record and do all the needed actions.
This servo, the AX-12, was able to do most of what was required. With it in hand, the robotic
arm would be able have the ability to sense tension on its saddle tendons and report the current
angle of each of the servos. In addition, because of the communication protocol used to by the
servos, daisy chaining was possible and cut down on pin use of the hosting microcontroller.

                                    Table 1: AX-12 Statistics [1]
   Weight(g)                    55
   Gear Reduction Ration        1/254
   Input Voltage (v)            At 7V                              At 10V
   Final Max Holding Torque     12                                 16.5
                                0.269                              0.196
   Resolution
   Operating Angle                   , Endless Turn
   Operation Temperature        -            C
   Physical Link                TTL Level Multi Drop (Daisy Chained)
   Communication Speed          77343bps ~ 1 Mbps
   Protocol Type                Half Duplex Asynchronous Serial Communication

6.2 MICROCONTROLLER
The microcontroller, at least in our application, acts as the spinal cord for our application. It acts
as an intermediary between Matlab and the servos to provide some simple logic and control to
ensure proper communication. Due to this nature, it was important to select an efficient, quick
microprocessor to handle all the tasks we handed to it. With this is mind, the Cyprus PSoC was
selected due to its reconfigurable pins, quick processing time, and suite of debugging tools [2].
The downsides of this choice were that the entire communication scheme needed to
communicate with the AX-12 servos would need to be written from scratch, which would be
time intensive process.

Luckily, an alternative was provided within a few weeks, the Propeller. This microcontroller,
while it lacked any useful peripherals, it had several libraries written for it that could already talk

                                                                                                     15
to the AX-12 and could emulate several different peripherals using several cores [3]. This came
at the expense of including concurrency in the project, introducing possible untestable error in
the project. It also lacked any form of debugging tools.

                 Table 2: PSoC versus Propeller Microcontroller Statistics [2], [3]

                                                PSoC CY3C55                     Propeller
   CPU Speed                                       80MHz                         80MHz
   RAM                                            64Kbytes                      37Kbytes
   ROM                                            2Kbytes                       37Kbytes
   I/O Pins                                          72                            31
   Peripherals                       ADC                             8 Programmable Cores
                                     PWM
                                      2
                                     I C, SPI, UART, USB




                                                                                               16
7.0 CONTROL SYSTEMS SELECTED

7.1 SERVOS
From initial opinion, the AX-12 was perfect for the task at hand, and was selected. However it
has several glaring drawbacks that we have encountered. The first we encountered had to do
with the rotation of the AX-12. hen we first got the motors, we didn‟t realize that the servos
were constrained to 300 of measured rotation. It could still go into full rotation; it just couldn‟t
record the angle for the dead zone, between 300o and 360o. This is actually expected, since the
angle is feedback from a potentiometer, which is limited in degrees [1]. The way we plan to fix
this is covered in future plans.

The second drawback of the AX-12s is the large amount of error introduced by the motor. This
is especially true for the torque readout. For the control system, we need accurate torque
measurements every few milliseconds. Due to the way the servos read torque, by measuring the
difference in angles between expected and current position, we lose the torque measurement
when the servo loosens the string [1]. This must be resolved if the current control system is to
work.

7.2 MICROCONTROLLER
The Propeller was selected, at least temporarily, due to the quick turnaround for hardware
testing. It is hoped we will be able to translate the code from the Propeller to the PSoC later on in
the project. The primary limitations of the Propeller are its lack of peripherals, no debugging
software, and its concurrent nature. Its lack of peripherals can be made up by its 8 cores, but this
means relying on the multiple cores to handle tasks [3]. This introduces errors that are rarely
repeatable and hard to remove. Its lack on debugging software makes it even harder to ensure
completely working code.

The PSoC‟s main drawbacks are its long write-compile time, and it‟s difficult to program. The
long write-compile time is something that can‟t be avoided, and slows down production and
testing of the project [2]. Its difficulty means it will take longer to write different parts of the
project.

7.3 COMMUNICATION BETWEEN MATLAB AND MICROCONTROLLER
To ensure proper communication between the microcontroller and Matlab, a simple protocol was
needed to ensure that the microcontroller and the Matlab were in the proper state for data
transfer. I decided that a simple handshaking protocol would be needed, without any checksum,
length, or address. It is only needed to ensure proper state of the propeller and the Matlab state
machine.




                                                                                                       17
Figure 13: Protocol




                      18
8.0 CONTROL SCHEME

8.1 MODEL
The model being developed will be a constrained particle dynamics system utilizing Lagrange
coefficients and the Principle of Virtual Work to apply the constraints. It is primarily based on
the work of Narongsak Kanchansaratool and Darrell illiamson (K ) in their paper, “Motion
Control of a Tensegrity Platform.” [4] The only major difference being that we will control the
tendons of the structure and they considered controlling the rods.

The system is modeled as 12 particles located at the endpoints of the rods. At each point there
exist forces due to the tension members and constraint forces due to the rigid (compression)
members. Tension forces are modeled simply as linear springs and then for any feasible
configuration of the structure, the forces must be consistent with tension in the tendons.
Compression forces are assumed to obey the principle of virtual work (which, in our case,
essentially boils down to the assumption that the rods deform negligibly) and therefore add no
energy to the system. Assurance that the forces obey virtual work is accomplished using
Lagrange coefficients determined as in the paper. The tension and constraint forces are summed
for each particle. Given a desired position of the top platform, these forces then become a
function of the positions of the nodes not associated with either top or bottom platforms and the
rest lengths of the tendons. Also, for a static situation (which we are primarily concerned with)
the forces must sum to zero. This leads to direct application of many numerical solution
techniques (Newton-Raphson, Runga-Kutta, etc.). The investigation into which technique is most
applicable in our case is currently underway.

In their paper, Kanchanasaratool and Williamson compare and contrast their model with that of
Sultan, Corless, and Skelton (SCS) expressed in “Tensegrity Flight Simulator.” [5] The SCS
model is derived using rigid-body mechanics to define the inertial quantities and then is cast in a
fully dynamic framework. The main points of K ‟s comparison are as follows. First, SCS
assumed that all the rods form similar (and symmetric) angles with the platform they are
connected to. This assumption is only valid when the center of mass of the stage is directly above
that of the base. So, if one is interested simply in small movements near such configurations the
assumption would be reasonable. Second, KW argue that though the dynamics (transient
response) of the two models will be different, they are equivalent when considering an
equilibrium condition. A final difference between the two works is that KW have cast their
equations such that they are general for any tensegrity platform. This means that their equations
are valid not only for the six-bar unit (of which they make a particular example) but that they can
be extended to structures constructed of an arbitrary number of stages of differing numbers of
bars. To clarify the terminology, a six-bar unit is a structure construct using two stages of three
bars.

8.2 CONTROLLER
Both KW and SCS propose control schemes to accompany their models. However, both use
techniques that we had issue with. SCS used the position (and Euler angles) of the stage as
feedback for the controller. This would involve sophisticated measurement equipment that may
be feasible for their intended application but, for the present objective, is not. KW accomplished

                                                                                                    19
control of their structure using a neural network to approximate the inverse of their model. This
would require an extensive amount of training data to provide a reasonable amount of accuracy.

During the time that these papers were being investigated, the work of Takuya Umedachi et al.
(UTNKI) came to our attention. [6] They demonstrated that a robot composed of constrained
springs (much like a tensegrity structure) could produce motion through local sensing at each
spring. In their case, they considered a robot based on the slime mold which was emulated by
surrounding a mass of protoplasm by interconnected springs with oscillators attached
periodically. Each oscillator was also envisioned to have the ability to change its coefficient of
friction with the floor, meaning that it could either slide freely along the floor or remain fixed.
To provide the impetus for motions, they exposed the robot to some attractant emanating from
the right. Then the robot was allowed to run based on simple rules for when the oscillators
should plant themselves or glide. Through simulation, this robot was shown to be able to
produce locomotion in both free space and with obstacles in its path towards the source of the
attractant.

This idea of local control provided the inspiration for the control scheme we have designed. To
draw an analogy to the “slime mold” robot of UTNKI, the tendons are similar to the springs and
the constraints due to the rods are similar to the conservation of protoplasmic mass. Control is
then implemented by sensing the local condition of individual tendons and changing them
towards the desired condition while obeying simple rules. The attractant used in UTNKI‟s work
is then analogous to the desired condition of each tendon in our tensegrity structure. Once
desired tensions and lengths of the tendons are computed according to the model, they are sent to
the controller which then performs the actuation as necessary. A flow diagram of this control
scheme follows.




                             Figure 14: Control scheme flow diagram


                                                                                                      20
            Table 3: Operations and Definitions of Control Scheme Diagram Blocks

                              Selector Block:
                              This block selects the next tendon in sequence (starting over when it
                              gets to the end)
                              Case Checker:
                              Given a tendon, this block decides which case it falls into, one of the
                              two operable cases (top and bottom), or neither.




                              Operate until Error Occurs:
                               This block changes the length of the given tendon as indicated until an
                              error occurs (either some tendon reaches the maximum or minimum
                              tension).
                              Previous Error Checker:
                              This block checks the previous error to ensure that the possible
                              op ration do sn’t xa rbat an xisting probl m

                              Tendon Finder:
                              Finds a tendon that meets the conditions specified in the adjacent
                              block.



In order to better understand the flow diagram, consider the following example. The tendon is
selected by the Selector Block and is then passed to the Case Checker. The condition of is then
examined to see if it falls into one of the two desired cases. The first (the top block in the Case
Checker) is when the length of , is greater than its desired length and that its tension is below
some maximum tension. In this case, the length of could be lessened, thus moving towards the
desired length and tending to increase the tension in the system. This operation would be
performed until some tendon reached either a maximum or minimum tension, generating an
error. However, before this operation is actually performed, it must be of an opposite sense
compared to the previous error. In other words, we don‟t want to increase the tension in the
system if the previous error was a maximum tension. This is was the Previous Error Checker
accomplishes. The other desirable case is when the length of is less than its desired length and
the tension is above some minimum tension, in which case the desired operation would be to
lengthen the tendon. If does not fall into one of these two cases, it is returned to the Selector
Block which then moves to the next tendon. Also note that after an error in tendon is generated
by performing an operation on , is sent directly to the Case Checker to see if the error can be
dealt with by altering itself.

The “red” loop differs from the “blue” loop in that it performs permissible but not desired
operations. The distinction here is that a permissible operation is one that does not violate a


                                                                                                        21
tension condition but moves the tendon away from the desired length. This is included in the
control system to account for the case when none of the tendons are in a desirable condition. The
idea here is that the performance of the permissible but not desired operation will “reset” the
system to where it can then proceed through desired operations towards the end state. The
maximum and minimum tension can be set to change overall speed of the scheme by narrowing
or widening the difference between the two. This will cause each operation to take a shorter or
longer time respectively. Also the average tension in the system can be set by increasing or
decreasing the average of the two bounds.

There are several major benefits to this control scheme. The first is that it‟s model independent.
Given that the desired tensions and lengths can be computed for a given desired configuration of
the structure, this scheme will iterate until each tendon reaches the desired state. This means that
even if the KW model we are pursuing does not work out but the control scheme is successful,
pursuing a new model will not affect the controller. A second potential benefit is that much as
the “slime mold” robot of UTNKI was able to navigate obstacles in its path, this scheme could
allow our tensegrity structure to self adjust to deal with externally applied forces. While these
benefits are significant, there are a few questions that have yet to be answered about this control
scheme. One is whether rules based on the local condition of a single tendon will be sufficient to
qualify when to perform a given operation. The alternative would be to generate rules for
performing operations based on the conditions of multiple tendons. If such “multi-tendon” rules
are necessary, we should be able to discern the form of such rules from observing the failures of
the current control scheme. Another question is if we should include conditions comparing the
current and desired tension as well as current and desired tension. These additional conditions
could be implemented in both single- and multi-tendon logic.




                                                                                                 22
9.0 FUTURE WORK
One thing we have discussed, but have left for future development, is modularity. We have
talked about using clamps and servos attached to screws to physically link modules together.
There are many different routes we can take in accomplishing these connections, and can be
easily implemented on our base plates. The second part to this modularity is the wire
connections. We have discussed using simple USB cabling to connect the tooling option
throughout the modules, as well as a three pin connection for the servos. We have also discussed
using spring loaded connector studs for the entire system, which could prevent far protruding
connectors. If oriented in a three ray pattern from the center of the base plate, they could
eliminate the need for a check on module positioning when connecting. Both of these will be
addressed in the following months.
The choices for strings will be evaluated and possibly other string choices added as options.
Factors influencing the final string choice may consist of ability to resist wear and fraying, total
stretch, and ability to resist plastic deformation among others. Spectra seem promising due to
their almost slippery surface that is very effective against chafing. Spectra also have very limited
stretch and plastic deformation.
The current servos can only index 300o. The other 60o of rotation cannot be accounted for;
however angular position is crucial for the control system. Therefore, a gear reduction system
and additional sensors may be needed to be able to read the full rotation of each servo.
Similarly, tension readings need to be made from additional sensors. These sensors will either
be in line with the strings or computed from torque that the sensors exert on the base plate.
Another option that will give us more range of motion of the structure with the 300o index would
be increasing the spool size.
As discovered by testing the one-bar structure, there was a problem discovered where the friction
from the string overlaying on the top of the bar prevented the pivot from rotating completely.
This can be addressed by possibly changing the type of string or allowing the top of the bar to
pivot as well.
The propeller has proven an efficient microcontroller for initial tests. It has started to show
several drawbacks, from using others libraries and from the built in concurrence of the system.
The looming needs of the torque sensors, and the possible need for communications with other
microcontrollers and devices, mean that the limits of the propeller will quickly be overcome. I
feel we must switch to the PSoC, and migrate our current code to the PSoC, if we are to continue
towards our objective.




                                                                                                 23
APPENDIX A – DRAWING PACKAGE




                               24
25
26
27
28
29
30
31
APPENDIX B – CURRENT BUDGET




                              32
All raw materials were purchased for the six-bar unit. The servos and microcontroller purchases
were the bulk of the cost. Future expected expenses include:

      Tension measurement sensors
      Mechanical and electrical connections to accomplish modularity
      Dacron fishing line for tendons
      Miscellaneous odds and ends
      Possibly a second six-bar structure to demonstrate modularity
Below is the summary of our current budget:



                   2010 RLEP TensegriTeam Budget


                               Starting Balance                             Current Balance

                                  $6,000.00                                 $5,097.43


                                                                 Expensed

                                                                 $902.57


                                     Item                          Cost                 Notes

                  9/13/10 Tensegritoy-ebay-mysweetcharlotte       $34.52

                        9/15/10 Tensegritoy-ebay-jil112           $17.99

                      PSoC board-Purchased from Cypress          $274.00

                   1 AX-12 Servo-Purchased from Robot shop        $64.43

                      PSOC Parts-Purchased from Digikey           $3.30

                Mechanical parts-Purchased from McMasterCarr     $147.33

                 5 AX-12 Servos--Purchased from Crust Crawler    $295.72

                 Propeller proto board-Purchased fromPropeller    $47.25

             1 Metric Tap (M2x0.4P)--Purchased from McMasterCarr $18.03




                                                                                                33
Mechanical parts -- McMasterCarr

                                                                                     part       price       sub
                     quantity limiting dimensions    what we want to buy             number     each    qty total

base plate           2       7.57 across             8x8x.25                         9246k11    16.38   2    32.76

base         plate
bushing              6       1.11 dia 1.375 length   12x1.25                         8974k161   8.86    2    17.72

                                                     taken care of with pivot
pivot bushing        6       1.11 dia .5 length      material                                                0

threaded studs 12                                    8-32 thread                     9634k22    2.98    12   35.76

tubes                6       3/8x.145                8'x3/8x.145                     1658t43    6.16    1    6.16

end caps             6       .5x.5x.5                .5x.5x.5 acrylic                8680k24    0.33    10   3.3

                             8-32 .47 length counter 8-32 x.5 socket cunter pack
screws                       sink                    of 25                       91263a524 6.25         1    6.25

                                                     .125 dia      shoulder   4-40
shoulder screws 12                                   thread                          91829a517 1.16     12   13.92

                                                     50 lb fishing line .028 dia
string                                               825 feet                    9442t4         11.19   1    11.19

                                                     taken care of with pivot
spool                6                               material                                                0


                             McMaster-Carr                                                              total 127.06




                                                                                                                     34
APPENDIX C – MATLAB CODE




                           35
GUI CODE

function varargout = OneBarGUI(varargin)
% ONEBARGUI M-file for OneBarGUI.fig
%      ONEBARGUI, by itself, creates a new ONEBARGUI or raises the existing
%      singleton*.
%
%      H = ONEBARGUI returns the handle to a new ONEBARGUI or the handle to
%      the existing singleton*.
%
%      ONEBARGUI('CALLBACK',hObject,eventData,handles,...) calls the local
%      function named CALLBACK in ONEBARGUI.M with the given input arguments.
%
%        ONEBARGUI('Property','Value',...) creates a new ONEBARGUI or raises
the
%      existing singleton*. Starting from the left, property value pairs are
%      applied to the GUI before OneBarGUI_OpeningFcn gets called. An
%      unrecognized property name or invalid value makes property application
%      stop. All inputs are passed to OneBarGUI_OpeningFcn via varargin.
%
%      *See GUI Options on GUIDE's Tools menu. Choose "GUI allows only one
%      instance to run (singleton)".
%
% See also: GUIDE, GUIDATA, GUIHANDLES

% Edit the above text to modify the response to help OneBarGUI

% Last Modified by GUIDE v2.5 01-Dec-2010 23:18:07

% Begin initialization code - DO NOT EDIT
gui_Singleton = 1;
gui_State = struct('gui_Name',       mfilename, ...
                   'gui_Singleton', gui_Singleton, ...
                   'gui_OpeningFcn', @OneBarGUI_OpeningFcn, ...
                   'gui_OutputFcn', @OneBarGUI_OutputFcn, ...
                   'gui_LayoutFcn', [] , ...
                   'gui_Callback',   []);
if nargin && ischar(varargin{1})
    gui_State.gui_Callback = str2func(varargin{1});
end

if nargout
     [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:});
else
     gui_mainfcn(gui_State, varargin{:});
end
% End initialization code - DO NOT EDIT


% --- Executes just before OneBarGUI is made visible.
function OneBarGUI_OpeningFcn(hObject, eventdata, handles, varargin)
% This function has no output args, see OutputFcn.
% hObject    handle to figure
% eventdata reserved - to be defined in a future version of MATLAB


                                                                           36
% handles    structure with handles and user data (see GUIDATA)
% varargin   command line arguments to OneBarGUI (see VARARGIN)

% Choose default command line output for OneBarGUI
handles.output = hObject;

% Update handles structure
guidata(hObject, handles);

% UIWAIT makes OneBarGUI wait for user response (see UIRESUME)
% uiwait(handles.figure1);

hserial=serial('COM4','baudrate',230400);
handles.hserial=hserial;
handles.init='notdone';
handles.frmcnt=1;
guidata(gcf,handles)
fopen(hserial)




% --- Outputs from this function are returned to the command line.
function varargout = OneBarGUI_OutputFcn(hObject, eventdata, handles)
% varargout cell array for returning output args (see VARARGOUT);
% hObject    handle to figure
% eventdata reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

% Get default command line output from handles structure
varargout{1} = handles.output;


% --- Executes on button press in execute.
function execute_Callback(hObject, eventdata, handles)
% hObject    handle to execute (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

htheta=handles.theta;
hphi=handles.phi;
theta=str2double(get(htheta,'String'));
phi=str2double(get(hphi,'String'));

[l,lo,T,Fr]=one_bar(theta,phi);
% data(:,1)=lo;
% data(:,2)=T;

l_bin=round((lo-14.89)/(.3*pi*150/360)*512+512);
T_bin=round((T-5)/.44*512+512);

hserial=handles.hserial;
if strcmp(handles.init,'notdone')   %First time
    fwrite(hserial,204,'uint8');

                                                                        37
    while fread(hserial,1,'uint8')~=255;
    end
    handles.init='done';
    guidata(gcf,handles)
elseif strcmp(handles.init,'done') && hserial.BytesAvailable~=0
    if hserial.BytesAvailable==1
         trash=fread(hserial,1,'uint8');
    else
         trash=fread(hserial,8,'uint16');
    end
    fwrite(hserial,255,'uint8') %Flag that lets prop know i have new data
    while fread(hserial,1,'uint8')~=255
    end
elseif strcmp(handles.init,'done') && hserial.BytesAvailable==0
    fwrite(hserial,255,'uint8') %Flag that lets prop know i have new data
    while fread(hserial,1,'uint8')~=255
    end
end

for c1=1:4
        fwrite(hserial,l_bin(c1),'uint16');
end
for c2=1:4
        fwrite(hserial,T_bin(c2),'uint16');
end

while fread(hserial,1,'uint8')~=255
end

% if handles.init=='done'
%     commenab_Callback(handles.commenab,eventdata,handles);
% end

%   hserial=handles.hserial;
%   fwrite(hserial,204);
%   l_bin=round((lo-14.89)/(.3*pi*150/360)*512+512);
%   T_bin=round((T-5)/.44*512+512);
%   while fread(hserial,1,'uint8')~=255;
%   end
%   for c1=1:4
%       fwrite(hserial,l_bin(c1),'uint16');
%   end
%   for c2=1:4
%       fwrite(hserial,T_bin(c2),'uint16');
%   end


function theta_Callback(hObject, eventdata, handles)
% hObject    handle to theta (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of theta as text
%           str2double(get(hObject,'String')) returns contents of theta as a
double


                                                                            38
% handles.theta=hObject;
% guidata(gcf,handles);

% --- Executes during object creation, after setting all properties.
function theta_CreateFcn(hObject, eventdata, handles)
% hObject    handle to theta (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows.
%       See ISPC and COMPUTER.
if          ispc           &&          isequal(get(hObject,'BackgroundColor'),
get(0,'defaultUicontrolBackgroundColor'))
    set(hObject,'BackgroundColor','white');
end




function phi_Callback(hObject, eventdata, handles)
% hObject    handle to phi (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of phi as text
%            str2double(get(hObject,'String')) returns contents of phi as a
double




% --- Executes during object creation, after setting all properties.
function phi_CreateFcn(hObject, eventdata, handles)
% hObject    handle to phi (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows.
%       See ISPC and COMPUTER.
if          ispc           &&          isequal(get(hObject,'BackgroundColor'),
get(0,'defaultUicontrolBackgroundColor'))
    set(hObject,'BackgroundColor','white');
end


% --------------------------------------------------------------------
function Untitled_1_Callback(hObject, eventdata, handles)
% hObject    handle to Untitled_1 (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)


% --- Executes on button press in commenab.
function commenab_Callback(hObject, eventdata, handles)
% hObject    handle to commenab (see GCBO)

                                                                             39
% eventdata   reserved - to be defined in a future version of MATLAB
% handles     structure with handles and user data (see GUIDATA)

% Hint: get(hObject,'Value') returns toggle state of commenab

hcheck=hObject;

while get(hcheck,'Value')==1

    hserial=handles.hserial;
    flag=fread(hserial,1,'uint8');
    if flag==204
        fwrite(hserial,204,'uint8');
        indata=fread(hserial,8,'uint16');
        fwrite(hserial,204,'uint8');
        l=(double(indata(1:4))-512)*pi/512*(.15)+14.89;   %Assumes 1 cm radius
of bobbin
        T=double(indata(5:8));

        htheta=handles.theta;           %Get values for phi and theta
        hphi=handles.phi;
        theta=str2double(get(htheta,'String'));
        phi=str2double(get(hphi,'String'));

        htable=handles.currdata;             %Put updated current lengths and
tensions in table
        set(htable,'Data',horzcat(l,T));

        %Compute desired rod posision
        R_z=[cosd(theta+90),sind(theta+90),0;-
sind(theta+90),cosd(theta+90),0;0,0,1];
        u=[1,0,0]*R_z;
        R=u'*u+cosd(-phi)*(eye(3)-u'*u)+sind(-phi)*[0,-u(3),u(2);u(3),0,-
u(1);-u(2),u(1),0];
        pr=[0,0,12]*R;

        %Compute rod posision based on current string lengths
        a=8;
        b=4;
        x=(l(2)^2-l(3)^2+(2*a)^2)/(2*(2*a))-8;
        y=-(l(2)^2-l(1)^2+(2*b)^2)/(2*(2*b))+4;

        %Set endpoints of tendons
        p(3,:)=[a,b,0];
        p(2,:)=[-a,b,0];
        p(1,:)=[-a,-b,0];
        p(4,:)=[a,-b,0];

        %Plot visualization
        hdisp=handles.display;
        plot(hdisp,pr(1),pr(2),'rx','Markersize',20,'Linewidth',3)
        hold on
        plot(hdisp,x,y,'o','Markersize',15)
        plot(hdisp,p(:,1),p(:,2),'o','Markersize',5)
        for c2=1:4

                                                                            40
                plot(hdisp,[p(c2,1),x],[p(c2,2),y])
            end
            hold off
            %     axis([-9,9,-5,5])
            grid on
            handles.F(handles.frmcnt)=getframe(gcf);
            handles.frmcnt=handles.frmcnt+1;
            guidata(gcf,handles)
            pause(.5)
      end
end


% --- Executes during object deletion, before destroying properties.
function figure1_DeleteFcn(hObject, eventdata, handles)
% hObject    handle to figure1 (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

hcheck=handles.commenab;
set(hcheck,'Value',0)
pause(10)
F=handles.F;
save movie F
hserial=handles.hserial;
fclose(hserial);
delete(hserial);




                                                                       41
ONE-BAR SOLVER: MAIN FUNCTION
function [l,lo,T,Fr]=one_bar(theta,phi)

a=8;
b=4;
l_r=12;
k=ones(1,4)*1000;

%Set servo points
p(1,:)=[-a,-b,0];
p(2,:)=[-a,b,0];
p(3,:)=[a,b,0];
p(4,:)=[a,-b,0];

%Compute rod end location
R_z=[cosd(theta+90),sind(theta+90),0;-sind(theta+90),cosd(theta+90),0;0,0,1];
u=[1,0,0]*R_z;
R=u'*u+cosd(-phi)*(eye(3)-u'*u)+sind(-phi)*[0,-u(3),u(2);u(3),0,-u(1);-
u(2),u(1),0];
pr=[0,0,l_r]*R;

%Compute tendon vectors
l(1,:)=p(1,:)-pr;
l(2,:)=p(2,:)-pr;
l(3,:)=p(3,:)-pr;
l(4,:)=p(4,:)-pr;

%Set tension and compute free lengths in tendons opposite bar lean
T=zeros(1,4);
if mod(theta,360)>=180
     T(1)=5; %lbs
     T(2)=5; %lbs
     lo(1)=norm(l(1,:))-T(1)*norm(l(1,:))/k(1);
     lo(2)=norm(l(2,:))-T(2)*norm(l(2,:))/k(2);
else
     T(3)=5; %lbs
     T(4)=5; %lbs
     lo(3)=norm(l(3,:))-T(3)*norm(l(3,:))/k(3);
     lo(4)=norm(l(4,:))-T(4)*norm(l(4,:))/k(4);
end

%Compute unit vectors in plane of rod end
e1=[1,0,0]*R_z;
e2=[0,1,0]*R_z*R;
e3=[0,0,1]*R_z*R;


%Now compute tensions of other tendons using iterative solver
options=optimset('Display','off');
c1=1;
while any(T<=zeros(1,4))==1
    xo=[1,1]*c1;
    out=fsolve(@(unk) forces_one(unk,l,T,e1,e2,theta),xo,options);
    if mod(theta,360)>=180

                                                                            42
             T(3:4)=out;
             lo(3)=norm(l(3,:))-T(3)*norm(l(3,:))/k(3);
             lo(4)=norm(l(4,:))-T(4)*norm(l(4,:))/k(4);
      else
             T(1:2)=out;
             lo(1)=norm(l(1,:))-T(1)*norm(l(1,:))/k(1);
             lo(2)=norm(l(2,:))-T(2)*norm(l(2,:))/k(2);
      end
      c1=c1+1;
end

%Compute force in rod
Fr=0;
for c1=1:4
    Fr=Fr+T(c1)*dot(l(c1,:),e3)/norm(l(c1,:));
end

end




                                                          43
ONE-BAR SOLVER: SUPPLEMENTARY FORCES FUNCTION
function out=forces_one(unk,l,T,e1,e2,theta)

%Put unknowns in tensions vector
if mod(theta,360)>=180
     T(3:4)=unk;
else
     T(1:2)=unk;
end

%Sum of forces in e1 and e2 directions at rod end
F1=0;
F2=0;
for c1=1:4
    F1=F1+T(c1)*dot(l(c1,:),e1)/norm(l(c1,:));
    F2=F2+T(c1)*dot(l(c1,:),e2)/norm(l(c1,:));
end

out=[F1,F2];

end




                                                    44
APPENDIX D – PROPELLER CODE

MAIN CONTROL SCHEME
{{
Author: Sean Wagoner
Date: November 1, 2010
Class: Senior Design
}}
con
 _clkmode       = xtal1 + pll16x
 _xinfreq     = 5_000_000

CON
 NUM_SERVOS = 4
 STACK_SIZE = 120
 RADIUS = 2 'Need to find the proper Measurement
 TENSION_MAX = 700 'Find proper value through experimentation
 TENSION_MIN = -1 'Find Proper value through experimentation
 SET_SPEED = 128 'Higher the speed in continuous rotation, higher the torque. Will need to change for 6 Bar
 INITIAL_ANGLE = 512
 TOTAL_RUNS = 1000
 WAIT_TIME = 10
var
 long currAngles[NUM_SERVOS]
 long currTens[NUM_SERVOS]
 long nextTens[NUM_SERVOS]
 long initAngles[NUM_SERVOS]
 long nextAngles[NUM_SERVOS]

obj
 dy : "Dynacomv1.2"
 txrx: "FullDuplexSerialPlus"


pub main | i, flag

 i:= 0

 txrx.start(31, 30, 0, 230_400)
 dy.start(7, 1_000_000)

 waitcnt(clkfreq*10 + cnt)

 initServos
 yellow_On
 txrx.rx

 getFirstDat
 yellow_Off
{{
 nextAngles[0] := 0

                                                                                                              45
 nextAngles[1] := 0
 nextAngles[2] := 1023
 nextAngles[3] := 1023
}}
 repeat
   green_On
   RunServos
   green_Off
{{
   if((flag := getNewDat) == -1) 'Possibly start in new cog (will take up 2 cogs and will need to implement
semaphores). It should be fast enough we won't need to.
      repeat
       green_On
       yellow_On
       red_On
       waitcnt(clkfreq*1 +cnt)
       green_Off
       yellow_Off
       red_Off
       waitcnt(clkfreq*1 +cnt)
   yellow_Off
}}

pub getFirstDat | i
 i:= 0

 'Initialize Handshaking
 red_On
 txrx.tx($FF)
 'Get new Tensions
 repeat
   nextAngles[i] := (txrx.rx & $00FF) | (txrx.rx << 8 )
   i:=i+1
 while(i < NUM_SERVOS)

 i:= 0

 'Get new Angles
 repeat
  nextTens[i] := (txrx.rx & $00FF) | (txrx.rx << 8 )
  i:=i+1
 while(i < NUM_SERVOS)

 txrx.tx($FF)
 waitcnt(clkfreq*1 + cnt)
 red_Off
 return 1

pub initServos | i
 i := 0
 repeat
   dy.writedata(i, 6, 0)
   dy.writedata(i, 8, 1024)

                                                                                                        46
  dy.writedata(i, 32, SET_SPEED)
  dy.writedata(i, 30, 600)
  i:=i+1
 while(i < NUM_SERVOS)

 waitcnt(clkfreq*4 + cnt)

 i:=0

 repeat
  currAngles[i] := dy.getsrvpos(i) 'Set initial starting positions
  nextAngles[i] := currAngles[i]
  currTens[i] := dy.getsrvtrq(i)
  i:=i+1
 while(i < NUM_SERVOS)

 i:=0

 repeat
  dy.writedata(i, 30, INITIAL_ANGLE)
  i:=i+1
 while(i < NUM_SERVOS)

 dira[0] := 1
 dira[2] := 1
 dira[4] := 1
 dira[6] := 0
 green_Off
 red_Off
 yellow_Off

pub RunServos | currMotor, prevErr, runsWithErr, i, stateErr

 prevErr := 0
 runsWithErr := 0
 i := 0
 'stateErr := 0

 repeat
  currMotor := (currMotor + 1) // NUM_SERVOS
  i++

  'Get current motor state
 ' waitcnt(clkfreq*1 + cnt)
  currTens[currMotor] := dy.getsrvtrq(currMotor) 'Response will take about .5ms
  currAngles[currMotor] := dy.getsrvpos(currMotor) 'Response will take about .5ms
 ' waitcnt(clkfreq*1 + cnt)

  'Send data to Matlab
  if(currMotor == (NUM_SERVOS - 1))
    stateErr := sendOne(stateErr)

  if((currTens[currMotor] < TENSION_MAX) AND (currAngles[currMotor] > nextAngles[currMotor]))

                                                                                                47
   if(prevErr)
     runsWithErr++

    else
     dy.setsrvpos(currMotor, currAngles[currMotor] - 10) 'needs to be changed to go with actual needed servo
direction
     runsWithErr := 0

  elseif((currTens[currMotor] > TENSION_MIN) AND (currAngles[currMotor] < nextAngles[currMotor]))

   if(prevErr)
     runsWithErr++

    else
     dy.setsrvpos(currMotor, currAngles[currMotor] + 10) 'needs to be changed to go with actual needed servo
direction
     runsWithErr := 0

  else
   yellow_On
   prevErr := 0 'Current error check, will stop the system entirely if out of bounds. Will need to investigate.

 while(((runsWithErr < NUM_SERVOS) AND (i < TOTAL_RUNS)) OR (stateErr <> -1))

pub sendOne(temp) | contents, i

 i:= 0

 'Start Handshaking
 red_On
 if(temp <> 2)
   txrx.tx($CC)

 'Wait for Response

 if((contents:= txrx.rxtime(10)) == $CC)
    red_Off
    yellow_On
   'Send Current Angle State
   repeat
     txrx.tx(currAngles[i])
     txrx.tx(currAngles[i]>>8)
     i:=i+1
   while(i < NUM_SERVOS)

  i:= 0
  'Send Current Tensions
  repeat
    txrx.tx(currTens[i])
    txrx.tx(currTens[i]>>8)
    i:=i+1
  while(i < NUM_SERVOS)

                                                                                                                  48
  yellow_Off
  'txrx.tx($FF)

  if(txrx.rx == $CC)
    return 1
  else
    return -1

 'Error State

 elseif(contents == $FF)
  red_Off
  yellow_On
  i := 0

  'Finish Handshaking
  txrx.tx($FF)
  'Get new Tensions
  repeat
    nextAngles[i] := (txrx.rx & $00FF) | (txrx.rx << 8 )
    i:=i+1
  while(i < NUM_SERVOS)

  i:= 0

  'Get new Angles
  repeat
   nextTens[i] := (txrx.rx & $00FF) | (txrx.rx << 8 )
   i:=i+1
  while(i < NUM_SERVOS)

  yellow_Off
  if(txrx.tx($FF))
    return 1
  else
    return -1

 else
  red_Off
  return 2

Pub getNewDat | i, contents
 i:= 0

 'Initialize Handshaking
 red_On
 txrx.tx($FF)

 'Wait for Proper Response
 if((contents:=txrx.rx) == $FF)
   red_Off
   yellow_On

                                                           49
  i := 0

  'Finish Handshaking
  txrx.tx($FF)
  red_Off
  'Get new Tensions
  repeat
    nextAngles[i] := (txrx.rx & $00FF) | (txrx.rx << 8 )
    i:=i+1
  while(i < NUM_SERVOS)

  i:= 0

  'Get new Angles
  repeat
   nextTens[i] := (txrx.rx & $00FF) | (txrx.rx << 8 )
   i:=i+1
  while(i < NUM_SERVOS)

  yellow_Off
  if(txrx.rx == $FF)
    return 1
  else
    return -1

 'Error State
 elseif(contents <> $FF)
  red_Off
  repeat
    txrx.tx($EE)
    i:=i+1
  while(i<4)

  return -1
 red_Off
 return 1

pub green_On
 outa[4] := 1
pub yellow_On
 outa[2] := 1
pub red_On
 outa[0] := 1
pub green_Off
 outa[4] := 0
pub yellow_Off
 outa[2] := 0
pub red_Off
 outa[0] := 0




                                                           50
REFERENCES

[1] Robotis, Dynamixel AX-12 User Manual, 16 Jun. 2006.
[2] Cypress Semiconductor Corporation, PSoC 5 CY8C55 Family Datasheet, Doc. No. 001-
    44094 Rev. *J, 2 Sep. 2010.
[3] Parallax, Inc., Propeller P8X32A Datasheet, Rev. 1.2, 24 Apr. 2009.
[4] N. Kanchanasaratool and D. Williamson, Motion Control of a Tensegrity Platform, Commun.
    Inf. Sys., Vol. 2, No. 3, (2002), pp. 299-324.
[5] C. Sultan, M. Corless, and R.E. Skelton, Tensegrity Flight Simulator, J. Guidance, Control,
    and Dynamics, Vol. 23, No. 6 (2000), pp. 1055-1064
[6] T. Umedachi, et al., Fully decentralized control of a soft-bodied robot inspired by true slime
    mold, Biol. Cybern., 102:261-269, DOI 10.1007/s00422-010-0367-9




                                                                                               51