MECEE3430 Senior Design Semester II

Professor Stolfi
Spring 2018

Four + One

Design Review II - Self-Stabilizing Crutch Mount

Nikita Komachkov
Ilaria Ferrari
Jonathan Chang
Veronica Over
Max Smith

Columbia University
Department of Mechanical Engineering
February 8, 2018
 I. Executive Summary and Introduction

The goal of our project is to isolate a platform at the end of a robotic arm from any motion at the
arm's base. Through the reactionary motion of the arm's links and a wrist, the platform will self-stabilize
as the arm's base moves in three dimensions. The robotic wrist will keep the platform parallel to the floor
while the arm will maintain the platform's altitude and control its acceleration.

This project was inspired by a team member's personal experience on crutches. She often found
herself wishing for a "third arm" to help her carry objects without disturbing their orientation. While there
are many applications for a self-stabilizing platform including marine, film, rescue, and medical - we will
demo our project as an attachment for crutches. The platform will be able to hold a glass of water or a
plate of food steady while the user is crutching. This attachment will greatly improve the autonomy of
people with disabilities and injuries by allowing them to carry precarious objects while using both hands
to crutch or walk with a walker.

In order to keep a glass of water steady despite the disturbances at the base of the robotic arm, we
determined that our system will need five degrees of control. We therefore designed a system with 5 links,
each attached to an actuated joint. The arm itself will have three links (for three degrees of freedom) in
order to maintain the platform's position relative to the user. The wrist will have two links (for two
degrees of freedom) in order to maintain the platform's orientation. The arm will be attached to a crutch at
a fixed point. The power supply for the actuators will also be attached to the crutch.

II. Literature Search

Through an internet search, we found existing designs that almost achieve the desired
functionality of our wrist. The designs use three gyro-sensors to detect instability and correct the platform,
along with three accelerometers to compensate for drift in the sensors.​2 ​We also investigated control
systems for our robotic arm. We found projects that use an Arduino to map the angle changes and
accelerations of a similar linkage read by an inertial measurement unit (IMU), and then determine the
required displacement of an end effector.​1​ We also found a simulation project that tackles the problem of
using inverse kinematics and dynamics to compensate for disturbances in the base of a robotic arm.​3

We will use similar methods to sense the position of our robotic arm’s end effector and provide
feedback to our control system, as shown in sections III. A through III.E of this report​. ​In summary, we
will use inverse kinematics to calculate the joint angles necessary to compensate for the base’s angular
and spatial displacements, as detected by the IMU at the arm’s base. We will also use data from the IMU
to implement jerk control (since jerky motion might cause a glass of water to spill, defeating the purpose
of the self- stabilizing platform), and our path planning will ensure that the robotic arm avoids
singularities and collisions with the user and the crutches themselves.

We then looked for journal articles describing the physical manifestation of self-stabilizing
platforms driven with control systems similar to those described above. In our general patent search, we
came across a modified version of the STEADICAM® linkage.​5​ This linkage mechanism was useful in
determining the general form of our final arm. However, the passive mechanism does not achieve what
our project calls for - a dynamically responsive powered system. Our project's linkage geometry will be
more similar to patent US 6659703 B1 for a hydraulically-controlled two-linkage arm mounted on a ship.
By manipulating the two-axis motorized gimbal at the apparatus’s base and the linkage’s intermediate
elbow joint, the device uses input from an altitude sensor to keep the end effector at a single altitude, as
depicted in the figure to the left.​4​ Our linkage geometry is discussed in detail in section III.G of this
report, along with a Static Finite Element Analysis of the design. Engineering drawings of the current
design are also included in appendix B​.

Lastly, we found a self-stabilizing platform with a 6 DOF MPU6050 sensor that used servo
motors to achieve x- and y- axis tilt, in conjunction with a Complementary filter to reduce noise in the
signal output.​6​ ​Our specific hardware selection is discussed in section III. F of this report.

III. Specifications and Parameter Analysis

A. Kinematics
The link geometry of the robot was decided through estimating the necessary degrees of control
and the predicted required reach of the arm based on the crutches motion. Position control is required to
steady the trajectory of the platform and orientation control is needed in two degrees to prevent the
platform from tipping. However, to keep a half-full glass of water in the center of the platform from
spilling, it was determined that yaw control is not
necessary. As a result, the kinematics of the arm
require five degrees of control leaving one degree
of freedom--namely the yawing motion of the
platform--free.

Figure 1: The above is the geometry chosen in the

Denavit-Hartenberg (DH) notation. Each cylinder
represents a rotary motor with its axis representing
the axis of rotation. The platform is positioned at
the end of link 5.

θ d a α

Link 1 θ1 * d1 0 π /2

Link 2 θ2 * + π /2 0 a2 π /2

Link 3 θ3 * 0 a3 0

Link 4 θ4 * + π /2 0 a4 π /2

Link 5 θ5 * 0 a5 0
 * Denotes variable of control.
Table 1: The Denavit-Hartenberg (DH) variables for the forward kinematic transformations of the robot

B. Inverse Kinematics

The kinematics of the arm were decoupled into position control and orientation control.
Assuming a4 and a5 are small as compared with a2 and a3 , the position of the platform can be said to
be defined by the position of joint 3. As a result, the angles of each joint are given with equations (1-4)

x c 2 +y c 2 +z c 2 −d1 2 −a2 2 −a3 2

θ3 = acos( 2a2 a3
) (1)
l=
√a 2
2 + a3 2 + 2a2 a3 cos(θ3 ) (2)
xc 2 +y c 2
√
z c −d1
θ2 = atan2(asin( l2
), l
) (3)
yc xc
θ1 = atan2( l*sin(θ , l*sin(θ ) (4)
2) 2)

where (xc , y c , z c ) denote the desired coordinates of the platform and all other variables are the DH
variables shown in Table 1. The orientation of the platform is then found by solving the equation

R6 3 = (R3 0 )T R

where R6 3 is the rotation matrix from frame 3 to frame 6, R3 0 is the rotation matrix from frame 0 to frame
3 and R is the rotation matrix from frame 0 to the desired orientation of frame 5 i.e. the platform. Because
the yawing motion of the platform is free, we evaluate the inverse kinematics as though there were a 6th
joint whose z-axis is collinear with the axis of link 5 and whose θ6 compensates for all yaw motion in
the platform controlling . In reality, we will not control this variable but it allows us to use equation (5-6)
to solve for the angles of θ4 and θ5 . We then set θ6 = 0 and find the following

θ4 = atan2(cos(θ3 )sin(θ2 + π /2), sin(θ3 )sin(θ3 + π /2)) − π /2 (5)

θ5 = asin(− sin(θ1 )sin(θ2 + π /2)) (6)

The lengths of the major links were determined by assuring that the reach of the arm would allow
the motors to correct away from instantaneous singularities. In the 5-link arm, the major links are links 2
and 3 with the links 1,4, and 5 made as small as possible. We minimize all links but 2 and 3 to reduce the
moments between links and also the torsional spring effect of the different links. The average step of the
crutch is said to be 1 foot. The singularities of the arm occur when the wrist is positioned above the axis
of joint 2 and when the arm is fully extended. If the major links are set at 7 inches for links 2 and 3, the
singularities found through jacobian analysis for a full step occur over the surface of a shape that is
essentially a sphere of radius 17 in swept over a distance of 1 foot.
C. Path Planning

We decided to choose a method of path planning that would assure that the arm does not reach its
geometric limit while also guaranteeing the platform maintains smooth motion from the user’s first step to
the last. The robotic arm will assume a consistent stepping motion from the user. As the arm detects
forward acceleration in the base, the arm will be in full compensation mode, maintaining the same wrist
position in space and orientation as at the initiation of the forward acceleration. It will do this by using the
IMU to continually find the angular and spatial displacements of the base and using inverse kinematics to
discover the joint angles that will maintain the same platform configuration. At the end of the step, when
there is no longer forward acceleration in the base, the arm will calculate the base’s total displacement for
the step and adjust its position smoothly to the exact geometric middle of the next step according to the
last step’s distance and trajectory. This requires the user to take long pauses in between each step to allow
the robotic arm to re-adjust, but all motion will be able to be compensated for as long as it is done in steps
that are within the workspace of the base including turns, going up and down stairs, etc. The path plan for
each adjustment of the robotic arm between steps will also include configuration space obstacles at the
robot’s singularities and near the crutch/user. These are mapped to the torque of joint 3 through equations
(7-9).
F repS ,3 = ν ( ρs (o1(q)) − 1
ρ0
) ρ2 s (o1 (q)) ∇ρs (o3 (q)), ρ(o3 (q)) ≤ ρ0S (7)
3 S 3

F repC ,3 = ν ( ρc (o1(q)) − 1
ρ0
) ρ2 c (o1 (q)) ∇ρc (o3 (q)) , ρ(o3 (q))≤ ρ0C
3 C 3

(8)
τ 3 = J o3 T (F rep ,3 + F repC ,3 ) (9)
S

where​ F repS ,3 and​ F repC ,3 are the artificial forces on the platform from the singularity boundary and the
crutch respectively.​ τ 3 is the resultant torque in joint 2 (acting on link 3) and​ ρ0 and ρ0 indicate the
S C

distance from the platform to where these forces initiate their influence and will be approximately 2 in
away from the actual obstacle. All path planning equations are derived from versions found in Spong
(2006). Artificial forces are created to prevent the joint from moving into a geometry from which the arm
cannot correct by programming a fake potential field that goes to infinity near the work-space obstacles. It
will only be turned on when the person has paused so that the platform can move forward and it will
overtake step-prediction control when the distance between the platform and the obstacle is in the critical
range. The angles will assume a gradient descent path where the final angle will place the platform within
the acceptable region.
To assure smooth motion, the path between angles chosen either by inverse kinematics or by
configuration space obstacles must be smooth as well. Furthermore, to assure that a glass of water on the
platform will not fall, there must be jerk control. The desired angle will be input into the control system as
the following:

q d (t) = q 0 + v 0 t + 0.5α0 t2 + a3 t3 + a4 t4 + a5 t5 (10)

q f = q 0 + v 0 tf + 0.5α0 tf 2 + a3 tf 3 + a4 tf 4 + a5 tf 5 (11)
 v f = a1 + 2a2 tf + 3a3 tf 2 + 4a4 tf 3 (12)
2 3
αf = 2a2 + 6a3 tf + 12a4 tf + 20a5 tf (13)

Solving for the desired a3 , a4 , and a5 using the final acceleration αf and final velocity v f .

D. Dynamics and Simulation

To find the torques of each of the motors under accelerations from the base, the DH
transformation matrix given by Table 1 was pre-multiplied by linear and rotational displacement matrices
to imitate the motion of a crutch. We will call these displacements as being the action of imaginary,
inertia-less links. These are produced from the DH Table 2.

θ d a α

Imaginary Link -2 θ−2 * d2 * 0 π /2

Imaginary Link -1 θ−1 * + π /2 d1 * 0 − π /2

Imaginary Link 0 θ0 * d0 * 0 0
* Denotes variable of disturbance.
Table 2: The DH table representing the variables of motion which affect the base of the arm.

The dynamic equations of motion are calculated using the multi-variable matrix form of the lagrangian
equation. The lagrangian is calculated by the following:
3
1
L=K −P = 2
∑ dij (q)q˙ i q˙ j − P (q) (14)
ij=−2

wh​ere K is the kinetic energy of the entire arm, q i is the angle of link ​i​, and dij are the entries of the
inertia matrix given by:
n
D(q) = [ ∑ {mi J vi (q)T J vi (q) + J wi (q)T Ri (q)I i Ri (q)T J wi (q)}] (15)
i=−2
J vi and J wi are the jacobian matrices of link ​i ​for linear velocity and angular velocity, I i is the
inertia matrix of link ​i​ and Ri (q) is the rotation matrix from the base frame to the orientation of link ​i​.
The torques are found via equation 16.

d δL δL
dt δq̇ k − δq k = τk (16)

To size the motors for a five link system requires several days of computation time to solve the
equations and calculate for several seconds of simulation. Instead we simulate for a three link system
consisting of joints 1-3 and links 2-4, simplifying the wrist into a mechanical gimbal. The inverse
kinematics are then:
 l2 +z c 2 −a2 2 −a3 2
D= 2a2 a3 (17)

√1 − D )
2
θ3 = atan2(D,∓ (18)
θ2 = atan2(l, z c ) − atan2(a2 + a3 cos(θ3 ), a3 s3 ) (19)
yc
θ1 = atan2( axc+l , a +l ). (20)
1 1

E. Position Tracking
The Raw Data

There is first the question of accuracy of the IMU in use. In theory, it should be taking data 100
lines per second. However, we have only been able to achieve 77 lines of data per second. After the data
is taken, there is the question of whether the data is accurate. A simple plot of the data shown in Fig.
(Max1) shows that a simple oscillatory motion, the actual motion illustrated in red, is read by the IMU,
the discrete data shown in blue, to be much more chaotic than it actually is.

xactual = xm sin(wt) (21)

aactual = − w2 xm sin(wt) (22)

The data in blue is the input to the integration process. If the data for the input is not cleaned up,
the integration process is impossible.

Figure 2 : Comparison Graph to Illustrate the Amount of Noise in the IMU Data

Integrating the Raw Data

There are many methods of numerical integration and we seek to choose the one which minimizes
integration error. A classic integrator with error of O(Δx5 ) is known as Simpson’s Rule. This technique
uses a weighted average of the initial point, midpoint, and final point at the end of the step with a ratio of
1:4:1 to numerically integrate data.
 This technique was tried on the Acceleration Data from IMU shown in Fig. 2. The position in
time was simple harmonic oscillation created by moving the accelerometer back and forth. This can be
represented by a sinusoidal function, whose derivatives will also be sinusoidal.

At the very least, oscillating the accelerometer back and forth and ending where the accelerometer
began should produce an average velocity of zero, although the average speed will not be zero. The graph
for the integrated acceleration, or velocity, is shown in Fig. 3.

Figure 3: Incorrect Integrated Velocity

As stated, the position in time is approximately simple harmonic motion. ​However​, this can not be seen in
either the acceleration data shown in Fig. 2 nor in the velocity data shown in Fig. 3. ​Either the sampling
rate needs to increase substantially or the data needs to be smoothed by way of additive smoothing or
bandwidth filtering.

Data Smoothing, High-Pass or Low-Pass Filtering, Bandpass Filtering and Butterworth Filtering

A degree of smoothing has been achieved by using a Butterworth Filter on the acceleration data.
The filtered data is shown in red in Fig. 4 while the actual data is shown in blue. This filter was applied
with a low cutoff frequency of 70 hertz and a high cutoff frequency of 1000 hertz. The choice of of these
two cutoff frequency was based on an example. Further investigation needs to be done into which cutoff
frequencies would be best for filtering this data. The low-pass Butterworth filter creates a delay, shifting
the line in red slightly to the right of the raw data shown in blue. This could present issues with real-time
position and velocity tracking.
 Figure 4: Using a Butterworth Filter to Reduce Noise in Data

The average acceleration produced by the data in blue in Fig. 4 is 0.128 meters per second
squared. Taking the average acceleration and multiplying by the length of time, 4 seconds, gives a final
velocity of about 0.51 meters per second. This same final velocity is found using the filtered data shown
in red. The final velocity of 0.51 meters per second is in agreement with the final velocity shown in Fig.
3. Due to the inaccuracies of this measurement method we have also considered an alternative (see
Appendix C.)

IV. Hardware Selection:

The electronics required to actuate our hardware involve a single microcontroller and an IMU that
provides accelerometer and gyrometer data in 6 DOF. Given the number of servos used in our assembly,
we will easily exceed the built in power output of the microcontroller. Thus, an external power delivery
system is required to drive our actuators. In total, there are three subsystems that govern our hardware
requirements: 1) Microcontroller, 2) IMU, and 3) Power Delivery.

A. Microcontroller

Our initial prototype was constructed with an Arduino UNO as the microcontroller. Through the
early stages of our literature search, we identified a 2 DOF stabilizing platform that served as a starting
point for our wrist prototype. Since the open source code for that project was based on Arduino, it served
as a natural choice for our first iteration of our prototype. Only small modifications to the program were
needed to get our initial prototype working.
However, as we ramped up with our dynamics simulations and adding more functionality to our
project, we found that the execution time of the Arduino UNO was insufficient to match the rated output
of our IMU (Adafruit BNO055). Our own independent testing on the prototype found that the IMU was
pushing positional outputs at only 77 Hz, compared to the rated 100 Hz. There were a few potential
causes identified for this discrepancy - 1) the Arduino does not poll at the desired rate to achieve the
100Hz as rated by the IMU, 2) The Arduino does not push the data through to our desired output quick
enough, 3) the I2C protocol has limited bandwidth and can be temperamental when making adjustments.
An important thing to note is that the IMU is making its own on board calculations to output positional
coordinates, which actually makes the IMU our one confirmed bottleneck beyond 100 Hz.
A less likely explanation for the slow data output is that the Arduino command signal (reading the
positional feedback data from the servos, reading the positional data from the IMU, making the necessary
calculations, and then pushing the command through to the servos) takes too long to run through the
Arduino CPU. This delay means that by the time the next positional feedback data point comes in, the
Arduino has not necessarily completed its calculations and will skip the next positional data points,
introducing additional error.
While the first issue is easily rectified with proper setup and ensuring the I2C connection is setup
correctly, the second issue is only changed by upgrading the microcontroller. We investigated two
external options - a Raspberry Pi 3, and an MBED series microcontroller (in particular the MBED NXP
LPC1768). Compared to the Arduino UNO, both options have much more powerful hardware.
The Raspberry Pi 3 is an easy write off for our project - since it is intended to be a full scale
computer running an operating system, the hardware has a certain amount of overhead that is dedicated to
higher priority tasks such as keeping the OS running. Thus, even if the hardware was setup to take
advantage of as much processing power as possible, the subroutines that prioritize OS operations and
other essential tasks would affect the performance of our program.
On the other hand, the MBED NXP LPC1768 serves the same purpose as an Arduino UNO, but is
far more optimized for single operations than the Raspberry Pi. In fact, MBED chips are not only cheaper,
but run also faster with more processing power and RAM. Since MBED chips are designed to replace
Arduinos in their role, there are no hardware incompatibilities to worry about. The only missing element
is writing the control software, which must be done in the MBED proprietary IDE. While the MBED IDE
is not as user friendly as the Arduino IDE, the code is entirely based off C++, which is also fully
supported by Arduino. Any code we've written through the Arduino IDE should theoretically be easy to
recompile in C++.
Given that the MBED chip supports all protocols, inputs and layouts of the Arduino and more, it
is a logical choice to remove the possible bottleneck on the microcontroller side of the system. The
particular chip we have chosen carries the part number OM11043,598. The chip supports the same chipset
as we've researched, NXP LPC 1768.

B. IMU
The basis of our project involves using an IMU. As mentioned before, the current 100 Hz
positional data output rate of the Adafruit BNO055 IMU is not sufficient for us to perform the required
smoothing for the numerical integrator. The packaging of the particular IMU does not matter, as the
different packaging sizes do not vary in any significant degree. Hence, we based our IMU selection purely
on the highest polling rate of both the gyrosensor and the accelerometers. The SparkFun 6 Degrees of
Freedom IMU Digital Combo Board - ITG3200/ADXL345 (SEN-10121) provided the highest rates at
8000 Hz for the gyrosensor and 3200 Hz for the accelerometer.
C. Power Delivery System
During Design Review I, we projected that we wanted the arm to have a runtime of 30 minutes on
a single charge. Our prototype has 8 MG996r Servo Motors, each rated at normal operating current of
500-900 mA at 6V. Using the equation:

battery capacity (mAh)

runtime (h) = current draw (mA)

We estimate the necessary battery capacity to be between 2000 mAh and 3600 mAh, both of
which are common capacities in the RC and hobbyist world. Since we want the longest runtime possible
without spending too much on the battery, we have selected a LiPo cell with 30C discharge capacity rated
at 5200 mAh. In theory, this gives us a total current rating at 156 Amps, and an estimated runtime of
between 0.72 and 1.3 hours, greatly exceeding our initial estimate. The use of a

V. CAD Description:
The first prototype was redesigned in order to minimize the total weight of the system. The
system can be decoupled into two subassemblies: the platform and the robotic arm. The components of
the platform include 2 servo motors, 2 small linkages, the Inertial Measurement Unit (IMU), IMU casing,
and the platform itself, see Fig. 6. The total mass of the platform is 421.58 g. The robotic arm consists of
4 linkages, whose purpose is to assemble the remaining 6 servo motors to account for the 3 axis of
rotation as shown in Fig. 5. The system will be fixed to a table to perform initial control tests. This part of
the subassembly will consequently be replaced or redesigned so that the arm can be attached to crutches
for demonstration purposes. Individual parts and their mass and material are displayed below in Fig. 7.

Figure 5: Full assembly

 Figure 6: Platform subassembly

Figure 7: Individual links of the robotic arm subassembly

All linkages are 3D printed to keep the cost and weight as low as possible. If stronger material is
required, aluminum 6061 T-6 alloy will be used as alternative, however the total weight will be doubled.
Servo motors are sized according to dynamics section. Current servo motors are capable of a maximum
torque of 138 oz-in rated at 6.0V, priced at around $10. Our research shows that there are servos with a
much higher torque, up to 500 oz-in, but the price scales proportionally, up to $200. Standard hub shaft
servo block, made of aluminum 6061 T-6, is purchased from ServoCity.com and individual components
are outlined in Fig. 8. The advantage of a servo is that it uses feedback devices that use built-in encoders
to sense error and correct for this error to meet a desired position. Servo blocks increase a servo’s
load-bearing capabilities by helping to isolate the lateral load from the servo spline and case.
 Figure 8: Servo assembly and a base support

Static Finite Element Analysis (FEA) was performed in SolidWorks, treating all linkages as
cantilever beams. Each consequent linkage was analyzed by adding additional mass it ts supposed to hold.
For example, consider the first linkage that supports the platform shown in Fig. 7. The total mass of the
platform and an assumed mass of 1 kg were applied at the tip of the linkage as a 14 N load. The next
linkage was analyzed in similar way, but the load now included additional mass of the first linkage and
the mass of the two servos, that was 16.1 N load. As a result, each subsequent linkage had a higher load
applied to it. The FEA shows that all linkages are well below the yield point of the chosen material, in this
case PLA. Strain and displacement is almost negligible. The design of each link was optimized to remove
as much material as possible, while maintaining the overall structural strength of the part. FEA results are
summarized below in Fig. 9.
 Figure 9: Robotic arm subassembly FEA

VI. Plan
The below table outlines the blockers that need to be resolved before we move on to instrumented
testing with an actual prototype. These should be read from left to right, top to bottom.

Obtain Positional Purchase new Construct Test Write code for Positional
Tracking components Bed for Arm (1 new IMU and Compensation
DOF) Microcontroller Response Test

Wrist Develop Control Transfer system to Wrist Refine Control

Compensational System using high acceleration Compensational System
Test (mechanical) wrist test to environment Test (Powered)
maintain glass (mount to crutch)
steady

A. Risks
The risks involved in this project lie mostly in control. Multi-input and multi-output control is an
extremely advanced form of control system, and getting it just right with our limited knowledge of
controls design may be beyond our capabilities. As a result we have rescoped our levels of success to
focus mainly on getting two motors to compensate for lateral and vertical movement of the crutch. As
mentioned in Appendix III we are also considering other methods of sensing position of the arm as it has
thus far proved faulty and different methods of simplifying the controls process. Other risks include
burning out motors when the crutch experiences high-impact with the ground, and long downtimes
between replacement parts (if majority 3D printed).

VII. Final Design

Our final design is detailed in Appendix B. As shown throughout the report, the desired
mechanism is a crutch mounted, 5-link, 5-actuator fully articulating arm with 5 degrees of control, and 1
DOF (yaw around the wrist). The IMU outputs acceleration data for the base of the crutch which is then
integrated in real time in the microcontroller to obtain position. Inverse kinematics are then run to
command the platform to return to the same relative position where it began. Our design is flexible
enough to accommodate different servo motors as we narrow down our torque requirements. Our IMU
(SEN-10121) and microcontroller (MBED NXP LPC 1768) are small enough that they have minimal
impact to the construction of the arm, while our power delivery is chosen to provide adequate runtime of
greater than thirty minutes. The full cost breakdown is shown in Appendix C. Our only in house
components are the 3D printed linkages, which will be made of PLA plastic.

VIII. Conclusion

Inspired by the need for a third arm while in an injured state, the goal of this project is to create a
self-stabilizing platform to aid in transporting small items while using crutches. This project has the
potential to improve the autonomy of those with disabilities or those in an injured state.
To completely control a stabilizing platform like this, we would need 5 degrees of control.

The CAD modelling and FEA were performed in Solidworks, while the Dynamics, Inverse
Kinematics and Forward Kinematics were implemented in MATLAB. Simulations and torque
calculations are still running and yet to be finished.

The data acquisition rate will be significantly improved with an improved IMU and an MBED
microcontroller, which will lead to more useful velocity and position predictions. Should the error
produced through integration persist, a PID feedback controller can be used to control the error in angular
displacement of the links relative to the user’s body.
IX. Reference List

1​
Bhuyan, Ariful Islam, and Tuton Chandra Mallick. Gyro-Accelerometer based control of a robotic Arm
using AVR Microcontroller, ​180.211.172.109/ifost2014Pro/pdf/S4-P69.pdf

2​
Cressell, Jonathan, and Anders Karlsson. Self-Stabilizing Platform : ZTäBiLAjZöR. 2016,
http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-191519​.

3​
Fongjun, Theerapong, “Control of stabilized platform for two-Link planar manipulator arm under parallel
base motion disturbance with Passivity-Based Adaptive Control.” IEEE Xplore, 8 May 2009,
ieeexplore.ieee.org/document/4913216/?part=14

4​
Kirkley, David. Stabilized Ship-Borne Access Apparatus and Control Method for The Same. 9 Dec.
2003.

5​
Paddock, George K., et al. Body Mounted Camera Support System. 29 Feb. 2000.

6​
Popelka, Vladimir. “A self stabilizing platform.” Publication, IEEE Xplore, 26 June 2014,
ieeexplore.ieee.org/document/6843648/?reload=true

7​
Spong, Mark W., et al. Robot Modeling and Control. John Wiley & Sons, 2006.
X. Appendix
A. Butterworth Filtering in Python
import csv
import numpy as np
import matplotlib.pyplot as plt
import scipy as sp
from scipy.signal import butter, lfilter, freqz

def butter_lowpass(cutoff, fs, order=5):

nyq = 0.5 * fs
normal_cutoff = cutoff / nyq
b, a = butter(order, normal_cutoff, btype='low', analog=False)
return b, a

def butter_lowpass_filter(data, cutoff, fs, order=5):

b, a = butter_lowpass(cutoff, fs, order=order)
y = lfilter(b, a, data)
return y

cutoff = 800
fs = 8000
acc_smooth = butter_lowpass_filter(np.array(df.Ax), cutoff, fs)

plt.plot(df.Time, acc_smooth, linewidth=2.0, color='r')

plt.plot(np.array(df.Time), np.array(df.Ax))
plt.title('Butterworth Filtering')
plt.xlabel('Time(sec)')
plt.ylabel('Acceleration')
plt.savefig('Butterworth.jpeg', dpi=1000)
B. Assembly Drawing
C. Cost Breakdown

Fig A: Cost breakdown with inexpensive servos

Fig B: Cost breakdown with expensive servos

D. Alternative Control without Accelerometer

An alternative method for this project would avoid using an accelerometer altogether and instead
find a way to keep the position of the platform in a set location in space ​relative​ to the body of the user.
This means that the platform would be directly connected to the user’s body via a harness instead of being
connected to the user’s crutch.

For example, knowing the angles of each link of the design and the length of the links, one can
use forward kinematics to determine where the stabilizing platform is in space relative to the user. This
position in space, as determined by the initial conditions for the angles, can be the setpoint. When the user
first moves forward, the angles will change as the platform falls behind. This change in angular position
signals acceleration.

For this control loop, y c = 0 would be the constant command for each angle to return to its
beginning setpoint. To be clear, y i = θi = (the angle between each link). The control equation for each
angle would be,
t
d2 θ(t) dθ(t) de(t)
α dt2
+β dt + ζ θ(t) = K p e(t) + K i ∫ e(τ )dτ + K d dt + v (t)
0
where θ is the given angle, e(t) is the difference between the commanded angle and the angle, θc (t) − θ(t)
, α, β , ζ are coefficients particular to the given plant for the associated angle, K p , K i , K d are coefficients
particular to the controller of said angle, and v (t) is the disturbance in time to that angle.

E. Motor Sizing and Selection Based on Dynamic Simulation

Using the simplified model of the arm described in section D., we simulated a compensation path
for a one-dimensional displacement with dynamic torque equations. From the crutching data we estimate
the maximum acceleration event will occur at 1.1g’s for approximately 0.01 s (our sampling rate). Setting
the gain at 50 in the control system for the link angles and the damping constant at 20 N-s, we find the
following torque reactions to a constant acceleration simulating the maximum case.

Fig E: Motor torques for 2-link simulation at 1.1g over .01s.